Re: Too many db calls
Cary, Thank you. Could you elaborate on the issue of excessive database calls, which show up as excessive network traffic? I can picture a PL/SQL loop, which executes an SQL statement over and over again. This would produce many database calls, and it might be possible to remove the loop altogether, replacing it with a single SQL statement. This would reduce the database calls. Is this the classic type of situation that produces too many db calls? Or are there other situations I'm missing that are more likely to be the source of this problem? Thanks again. - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Friday, November 15, 2002 4:13 PM Greg, I believe that the cultural root cause of the excessive LIO problem is the conception that physical I/O is what makes databases slow. Disk I/O certainly *can* make a system slow, but in about 598 of 600 cases we've seen in the past three years, it hasn't. [Why you should focus on LIOs instead of PIOs at www.hotsos.com/catalog] The fixation on PIO of course focuses people's attention on the database buffer cache hit ratio (BCHR) metric for evaluating efficiency. The problem is that the BCHR is a metric of INSTANCE efficiency, not SQL efficiency. However, many people mistakenly apply it as a metric of SQL efficiency anyway. Of course, if one's radar equates SQL efficiency with the BCHR's proximity to 100%, then a lot of really bad SQL is going to show up on your radar wrongly identified as really good SQL. [Why a 99% buffer cache hit ratio is not okay at www.hotsos.com/catalog] One classic result is that people go on search and destroy missions for all full-table scans. They end up producing more execution plans that look like this than they should have: NESTED LOOPS TABLE ACCESS BY INDEX ROWID INDEX RANGE SCAN TABLE ACCESS BY INDEX ROWID INDEX RANGE SCAN This kind of plan produces great hit ratios because it tends to revisit the same small set of blocks over and over again. This kind of plan is of course appropriate in many cases. But sometimes it is actually less work in the database to use full-table scans. [When to use an index at www.hotsos.com/catalog.] Cary Millsap Hotsos Enterprises, Ltd. http://www.hotsos.com Upcoming events: - Hotsos Clinic, Dec 9-11 Honolulu - 2003 Hotsos Symposium on OracleR System Performance, Feb 9-12 Dallas - Jonathan Lewis' Optimising Oracle, Nov 19-21 Dallas -Original Message- Sent: Friday, November 15, 2002 4:39 PM To: Multiple recipients of list ORACLE-L A while back someone mentioned that the two main causes of slow SQL are excesive LIO's and excesscive database calls, which show up as excessive CPU use and excessive network traffic, respectively. Regarding the database calls, is there a classic reason for this problem? My best guess is it's caused by an SQL statement in a PL/SQL loop, which could be rewritten as a single SQL statement. But is this the single, commonly seen cause for this problem, or are there other common ways this inefficiency is introduced? Thanks in advance for help in understanding this. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Greg Moore INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Cary Millsap INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Greg Moore INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include
RE: Too many db calls
Greg, That's one case. PL/SQL is a really poor language in which to write an application. The language tricks you into believing that writing a scalable application can be accomplished in just a few lines of 4GL code, but it's really not true. To write scalable PL/SQL, you need to use DBMS_SQL. The resulting code is even more cumbersome than the same function written in Pro*C. Any language can be abused, though. We see a lot of Java, Visual Basic, and Powerbuilder applications that do stuff like... 1. Parse inside loops, using literals instead of bind variables. 2. Parse *twice* for each execute by doing describe+parse+execute. 3. Manipulate one row at a time instead of using array processing capabilities on fetches or inserts (this one, ironically, raises a system's BCHR while it kills response time). 4. Join result sets in the application instead of in the database. Cary Millsap Hotsos Enterprises, Ltd. http://www.hotsos.com Upcoming events: - Hotsos Clinic, Dec 9-11 Honolulu - 2003 Hotsos Symposium on OracleR System Performance, Feb 9-12 Dallas - Jonathan Lewis' Optimising Oracle, Nov 19-21 Dallas -Original Message- Sent: Saturday, November 16, 2002 2:38 AM To: Multiple recipients of list ORACLE-L Cary, Thank you. Could you elaborate on the issue of excessive database calls, which show up as excessive network traffic? I can picture a PL/SQL loop, which executes an SQL statement over and over again. This would produce many database calls, and it might be possible to remove the loop altogether, replacing it with a single SQL statement. This would reduce the database calls. Is this the classic type of situation that produces too many db calls? Or are there other situations I'm missing that are more likely to be the source of this problem? Thanks again. - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Friday, November 15, 2002 4:13 PM Greg, I believe that the cultural root cause of the excessive LIO problem is the conception that physical I/O is what makes databases slow. Disk I/O certainly *can* make a system slow, but in about 598 of 600 cases we've seen in the past three years, it hasn't. [Why you should focus on LIOs instead of PIOs at www.hotsos.com/catalog] The fixation on PIO of course focuses people's attention on the database buffer cache hit ratio (BCHR) metric for evaluating efficiency. The problem is that the BCHR is a metric of INSTANCE efficiency, not SQL efficiency. However, many people mistakenly apply it as a metric of SQL efficiency anyway. Of course, if one's radar equates SQL efficiency with the BCHR's proximity to 100%, then a lot of really bad SQL is going to show up on your radar wrongly identified as really good SQL. [Why a 99% buffer cache hit ratio is not okay at www.hotsos.com/catalog] One classic result is that people go on search and destroy missions for all full-table scans. They end up producing more execution plans that look like this than they should have: NESTED LOOPS TABLE ACCESS BY INDEX ROWID INDEX RANGE SCAN TABLE ACCESS BY INDEX ROWID INDEX RANGE SCAN This kind of plan produces great hit ratios because it tends to revisit the same small set of blocks over and over again. This kind of plan is of course appropriate in many cases. But sometimes it is actually less work in the database to use full-table scans. [When to use an index at www.hotsos.com/catalog.] Cary Millsap Hotsos Enterprises, Ltd. http://www.hotsos.com Upcoming events: - Hotsos Clinic, Dec 9-11 Honolulu - 2003 Hotsos Symposium on OracleR System Performance, Feb 9-12 Dallas - Jonathan Lewis' Optimising Oracle, Nov 19-21 Dallas -Original Message- Sent: Friday, November 15, 2002 4:39 PM To: Multiple recipients of list ORACLE-L A while back someone mentioned that the two main causes of slow SQL are excesive LIO's and excesscive database calls, which show up as excessive CPU use and excessive network traffic, respectively. Regarding the database calls, is there a classic reason for this problem? My best guess is it's caused by an SQL statement in a PL/SQL loop, which could be rewritten as a single SQL statement. But is this the single, commonly seen cause for this problem, or are there other common ways this inefficiency is introduced? Thanks in advance for help in understanding this. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Greg Moore INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be
Re: Oracle on MVS able to submit JCL ??
Babette Turner-Underwood wrote: Does anyone on this listserv using Oracle on a mainframe? I was asked today if I can use Oracle's extproc feature on the mainframe to submit JCL. I said that I doubted it because the OS structure is so much different than UNIX or NT, but I would look into it. Has anyone tried to somehow have Oracle PL/SQL trigger or submit JCL?? Thanks I have never tried it but I think you can basically do whatever you want with an extproc and the system() C call. A long time ago, with Oracle 6 I think, (before extproc were available) I wrote a daemon under VMS which was waiting on a DBMS_PIPE, getting commands, appending /OUTPUT=something (OK VMS-lovers, Unix pipes are a great thing ...), calling system(), reading the something file and shovelling the result back the DBMS_PIPE. Simpler of course with an external procedure. It was funny to issue VMS commands from client PC. If you can do it with DCL, there is no reason why you couldn't with JCL. -- Regards, Stephane Faroult Oriole Software -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Stephane Faroult INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
how to download all the openworld documents?
Does their has way that can download (or purchase CD) all the ORACLE Openworld documents? Thanks. _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: dist cash INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: raw versus Mounted File Systems
There is an (older) paper on www.jlcomp.demon.co.uk, and some very good info on www.ixora.com.au hth connor --- VIVEK_SHARMA [EMAIL PROTECTED] wrote: Any Good Docs , Links , sources ? Need to present a paper to the Managers Thanks -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: VIVEK_SHARMA INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). = Connor McDonald http://www.oracledba.co.uk http://www.oaktable.net GIVE a man a fish and he will eat for a day. But TEACH him how to fish, and...he will sit in a boat and drink beer all day __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: =?iso-8859-1?q?Connor=20McDonald?= INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: RE: RE: CONSISTANT GETS
In some cases, NOT IN is better than NOT EXISTS. In other cases, the opposite is true. Moral: It never pays to discount an option out of hand - eg, NOT IN often works very very nicely for uncorrelated subqueries hth connor --- Post, Ethan [EMAIL PROTECTED] wrote: Hold the press. NOT IN better than NOT EXISTS? Is this theory or fact? If so is there any supporting evidence out there? This is the first I have heard of this. Thanks! -Original Message- Sent: Friday, November 15, 2002 11:35 AM To: Multiple recipients of list ORACLE-L Jerry, I suspect that the improvments are more likely due to your rewriting the WHERE clause rather than the use of NOT EXISTS. Especially if the database were 9i, where NOT IN actually seems get a better execution path than NOT EXISTS. That original WHERE clause is really a piece of work. Jared -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Post, Ethan INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). = Connor McDonald http://www.oracledba.co.uk http://www.oaktable.net GIVE a man a fish and he will eat for a day. But TEACH him how to fish, and...he will sit in a boat and drink beer all day __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: =?iso-8859-1?q?Connor=20McDonald?= INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: Too many db calls
On index-obsessed apps, you'll often see massive amount of LIO to a target of a nested loop. ie, scan mega table and then index probe the inner table for every row of the mega table... Generally you'll see smoke coming out of the index root/branch blocks on the target table :-) hth connor --- Greg Moore [EMAIL PROTECTED] wrote: A while back someone mentioned that the two main causes of slow SQL are excesive LIO's and excesscive database calls, which show up as excessive CPU use and excessive network traffic, respectively. Regarding the database calls, is there a classic reason for this problem? My best guess is it's caused by an SQL statement in a PL/SQL loop, which could be rewritten as a single SQL statement. But is this the single, commonly seen cause for this problem, or are there other common ways this inefficiency is introduced? Thanks in advance for help in understanding this. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Greg Moore INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). = Connor McDonald http://www.oracledba.co.uk http://www.oaktable.net GIVE a man a fish and he will eat for a day. But TEACH him how to fish, and...he will sit in a boat and drink beer all day __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: =?iso-8859-1?q?Connor=20McDonald?= INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Too many db calls
With the advent of bulk bind and bulk collection facilities in PL/SQL, you can get very close to the correct SQL mechanisms...its just that not many people tend to do it, and you end up with a gazillion 'one-row-at-a-time' applications out there. Cheers Connor --- Cary Millsap [EMAIL PROTECTED] wrote: Greg, That's one case. PL/SQL is a really poor language in which to write an application. The language tricks you into believing that writing a scalable application can be accomplished in just a few lines of 4GL code, but it's really not true. To write scalable PL/SQL, you need to use DBMS_SQL. The resulting code is even more cumbersome than the same function written in Pro*C. Any language can be abused, though. We see a lot of Java, Visual Basic, and Powerbuilder applications that do stuff like... 1. Parse inside loops, using literals instead of bind variables. 2. Parse *twice* for each execute by doing describe+parse+execute. 3. Manipulate one row at a time instead of using array processing capabilities on fetches or inserts (this one, ironically, raises a system's BCHR while it kills response time). 4. Join result sets in the application instead of in the database. Cary Millsap Hotsos Enterprises, Ltd. http://www.hotsos.com Upcoming events: - Hotsos Clinic, Dec 9-11 Honolulu - 2003 Hotsos Symposium on OracleR System Performance, Feb 9-12 Dallas - Jonathan Lewis' Optimising Oracle, Nov 19-21 Dallas -Original Message- Sent: Saturday, November 16, 2002 2:38 AM To: Multiple recipients of list ORACLE-L Cary, Thank you. Could you elaborate on the issue of excessive database calls, which show up as excessive network traffic? I can picture a PL/SQL loop, which executes an SQL statement over and over again. This would produce many database calls, and it might be possible to remove the loop altogether, replacing it with a single SQL statement. This would reduce the database calls. Is this the classic type of situation that produces too many db calls? Or are there other situations I'm missing that are more likely to be the source of this problem? Thanks again. - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Friday, November 15, 2002 4:13 PM Greg, I believe that the cultural root cause of the excessive LIO problem is the conception that physical I/O is what makes databases slow. Disk I/O certainly *can* make a system slow, but in about 598 of 600 cases we've seen in the past three years, it hasn't. [Why you should focus on LIOs instead of PIOs at www.hotsos.com/catalog] The fixation on PIO of course focuses people's attention on the database buffer cache hit ratio (BCHR) metric for evaluating efficiency. The problem is that the BCHR is a metric of INSTANCE efficiency, not SQL efficiency. However, many people mistakenly apply it as a metric of SQL efficiency anyway. Of course, if one's radar equates SQL efficiency with the BCHR's proximity to 100%, then a lot of really bad SQL is going to show up on your radar wrongly identified as really good SQL. [Why a 99% buffer cache hit ratio is not okay at www.hotsos.com/catalog] One classic result is that people go on search and destroy missions for all full-table scans. They end up producing more execution plans that look like this than they should have: NESTED LOOPS TABLE ACCESS BY INDEX ROWID INDEX RANGE SCAN TABLE ACCESS BY INDEX ROWID INDEX RANGE SCAN This kind of plan produces great hit ratios because it tends to revisit the same small set of blocks over and over again. This kind of plan is of course appropriate in many cases. But sometimes it is actually less work in the database to use full-table scans. [When to use an index at www.hotsos.com/catalog.] Cary Millsap Hotsos Enterprises, Ltd. http://www.hotsos.com Upcoming events: - Hotsos Clinic, Dec 9-11 Honolulu - 2003 Hotsos Symposium on OracleR System Performance, Feb 9-12 Dallas - Jonathan Lewis' Optimising Oracle, Nov 19-21 Dallas -Original Message- Sent: Friday, November 15, 2002 4:39 PM To: Multiple recipients of list ORACLE-L A while back someone mentioned that the two main causes of slow SQL are excesive LIO's and excesscive database calls, which show up as excessive CPU use and excessive network traffic, respectively. Regarding the database calls, is there a classic reason for this problem? My best guess is it's caused by an SQL statement in a PL/SQL loop, which could be rewritten as a single SQL statement. But is this the single, commonly seen cause for this problem, or are there other common ways this inefficiency is introduced? Thanks in advance for help in understanding this. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com --
Re: RMAN backup
How about switching to incremental (from full) backups? Even if all you do are level-0 backups? My understanding of the difference between a full and a level-0 backup (besides the obvious impact on any subsequent level-n incremental backups) is that level-0 backups only back up database blocks that are currently in use, as opposed to full backups which back up all database blocks which have ever been used (i.e. no longer unformatted). - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Friday, November 15, 2002 9:39 PM Hello All, Is resizing the datafiles the only way of reducing the size of an RMAN full backup? Oracle Version 8.0.6. We take RMAN hot backups to disk, and the size of the backup has grown considerably. There's one large table which we were considering truncating. But looks like that would not reduce the size of the backup. Dropping the table will call for an production outage. I am considering moving the table to another tablespace, and dropping the existing one. Any ideas? Thanks Raj -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Tim Gorman INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: RMAN backup
Tim, i'd be glad to hear someone else verify your statement as my understanding is the the only difference between full and level 0 is that full cannot be used as part of an incremental strategy, other than that they both back up the ever used blocks. Anyone else care to jump in on this one? joe Tim Gorman wrote: How about switching to incremental (from full) backups? Even if all you do are level-0 backups? My understanding of the difference between a full and a level-0 backup (besides the obvious impact on any subsequent level-n incremental backups) is that level-0 backups only back up database blocks that are currently in use, as opposed to full backups which back up all database blocks which have ever been used (i.e. no longer unformatted). - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Friday, November 15, 2002 9:39 PM Hello All, Is resizing the datafiles the only way of reducing the size of an RMAN full backup? Oracle Version 8.0.6. We take RMAN hot backups to disk, and the size of the backup has grown considerably. There's one large table which we were considering truncating. But looks like that would not reduce the size of the backup. Dropping the table will call for an production outage. I am considering moving the table to another tablespace, and dropping the existing one. Any ideas? Thanks Raj -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Joe Testa INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: RMAN backup
Joe Tim, It is accurate to state the both full and level 0 have the same impact on the database, and both backup all used blocks. It is also accurate that a full backup cannot be used as a piece of an incremental strategy. Although there may be rare instances (no pun intended :-) ) when you want to use a full backup (e.g. separate from your incremental flow) I never use full backups in RMAN myself. If you want to reduce the size of your backups: 1) Reduce the size of segments by reorging data (yes, I now this is stating the obvious) 2) Make any tablespaces containing static data read-only (thereby skipping them in RMAN after level 0) 3) Use an incremental strategy (level 0, 1...) Of course you must balance MTTR. If you just need to reduce disk space utilized, consider integrating RMAN with your backup vendor's software (Legato, Veritas...) so the backups go directly to tape. HTH, -Ron- Joe, nice to see you still contributing to this group. Hope all is well. -Ron- -Original Message- Sent: Saturday, November 16, 2002 1:33 PM To: Multiple recipients of list ORACLE-L Tim, i'd be glad to hear someone else verify your statement as my understanding is the the only difference between full and level 0 is that full cannot be used as part of an incremental strategy, other than that they both back up the ever used blocks. Anyone else care to jump in on this one? joe Tim Gorman wrote: How about switching to incremental (from full) backups? Even if all you do are level-0 backups? My understanding of the difference between a full and a level-0 backup (besides the obvious impact on any subsequent level-n incremental backups) is that level-0 backups only back up database blocks that are currently in use, as opposed to full backups which back up all database blocks which have ever been used (i.e. no longer unformatted). - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Friday, November 15, 2002 9:39 PM Hello All, Is resizing the datafiles the only way of reducing the size of an RMAN full backup? Oracle Version 8.0.6. We take RMAN hot backups to disk, and the size of the backup has grown considerably. There's one large table which we were considering truncating. But looks like that would not reduce the size of the backup. Dropping the table will call for an production outage. I am considering moving the table to another tablespace, and dropping the existing one. Any ideas? Thanks Raj -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Joe Testa INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Ron/Sarah Yount INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re:New development in Cobol or PL/SQL - please help
Babette, This is one of those from this old turd to that old fart messages. I've been around Oracle since 1985 I love it too. But it sounds like the director has a serious problem with new technology. Doing anything in COBOL today? Even PeopleSoft is busy re-writing their code in C++. Seesh his age is seriously showing. Oracle already has an adapter to MQ series, why re-invent the wheel when someone else has already done a better job of it. Then code the business logic in PL/SQL so that not only can this application use it, but any other that comes around. I believe it's known as code reuse. Another old term. You might start off by handing him a copy of Oracle 8i new features functions. BTW: add a copy of the 9i edition as well. Dick Goulet Reply Separator Author: Babette Turner-Underwood [EMAIL PROTECTED] Date: 11/15/2002 2:24 PM I just found out today that we have a major development initiative that is starting and they are planning on using Pro*Cobol to develop the application. (my head is still shaking in disbelief!!!) So we will have a Java front-end, invoking MQ series that will go across to the mainframe for MQ series to invoke Pro*Cobol programs that will then do the processing (accessing data and doing calculations) and then return data. If anyone has been in this or a similar situation, please help. I need some really good arguments as to why we should put the business logic into PL/SQL instead of Pro*Cobol. I understand the reason we are using Oracle is that the director has 15 years experience with it and loves it. Aaargh!!! thanks Babette -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Babette Turner-Underwood INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Monitoring Unix Question
Sthepen : I am very thankfull for you help ... But it is not all... Imagine you working at environment that doesn't know the database, and need to solve problems. So, the CPU is a item that you helped me to find out the user that is using it a lot, and in general, what more can i do, thinks like that : 1.) the average of load of the server 2.) disk i/o using 3.) the swap in disk of the memory Best regards Eriovaldo If you have the top utility installed on the Unix box, thi s makes an easy to use interface to identify CPU hogs. For non- root users to run it, your sys admin might have to change default permissions on certai n files such as /dev/kmem; or possibly make top SUID root. If you don't have top, or you can't run it as non- root, you can try using the following ps command to sort things by % CPU, but I think there might be differences among OS's on some of the more exotic ps and sor t options: ps -eo pid -o %cpu | sort -rk2 | head -20 After you have identified which PID is the hog, and can see that it is a dedicated server process, you can run something like the fol lowing to match SID SERIAL# to the correct OS process ID. If you must bru tally kill the process, kill the session in the database, then kill the pid in the OS. set linesize whatever_you_like set pagesize whatever_you_like col username format a15 col osuser format a15 select s.username, s.osuser, s.sid, s.serial#, s.process USER PRCS, p.spid SVR PRCS from v$process p,v$session s where p.addr = s.paddr and s.username ' ' / -Original Message- From: ecandrietta [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 14, 2002 1:20 PM To: Multiple recipients of list ORACLE-L Subject: Monitoring Unix Question Friends : How can i do for get what is running inside a PID that is using a lot of CPU ? How can I get the query that is running inside the databas e according PID of unix ? I would like to know commands of the unix and the query th at i need to run in the database for find out the problem. Regards Eriovaldo --- UOL, o melhor da Internet http://www.uol.com.br/ -- Please see the official ORACLE- L FAQ: http://www.orafaq.com -- Author: ecandrietta INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538- 5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services -- --- To REMOVE yourself from this mailing list, send an E- Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru ') and in the message BODY, include a line containing: UNSUB ORACLE- L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like sub scribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Stephen Lee INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538- 5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E- Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subsc ribing). --- UOL, o melhor da Internet http://www.uol.com.br/ -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: ecandrietta INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: New development in Cobol or PL/SQL - please help
In the for what it is worth department: In addition to Dick's comments (with which I agree) Be careful how you approach this situation. If you wish to succeed, it may be key to let the powers that be know that you are not proposing bleeding edge solutions, and that looking down the road towards total cost of ownership and supporting the application, it may behoove them to consider something more mainstream. Nobody ever truly wins a discussion by starting an argument with someone in a higher level of authority. Perhaps you should inquire about the why of the decisions so you understand the key issues to address to propose a better one. Good Luck, Yep, even technical decisions require us to exercise high levels of diplomacy :-) -Ron- -Original Message- [EMAIL PROTECTED] Sent: Saturday, November 16, 2002 3:13 PM To: Multiple recipients of list ORACLE-L Babette, This is one of those from this old turd to that old fart messages. I've been around Oracle since 1985 I love it too. But it sounds like the director has a serious problem with new technology. Doing anything in COBOL today? Even PeopleSoft is busy re-writing their code in C++. Seesh his age is seriously showing. Oracle already has an adapter to MQ series, why re-invent the wheel when someone else has already done a better job of it. Then code the business logic in PL/SQL so that not only can this application use it, but any other that comes around. I believe it's known as code reuse. Another old term. You might start off by handing him a copy of Oracle 8i new features functions. BTW: add a copy of the 9i edition as well. Dick Goulet Reply Separator Author: Babette Turner-Underwood [EMAIL PROTECTED] Date: 11/15/2002 2:24 PM I just found out today that we have a major development initiative that is starting and they are planning on using Pro*Cobol to develop the application. (my head is still shaking in disbelief!!!) So we will have a Java front-end, invoking MQ series that will go across to the mainframe for MQ series to invoke Pro*Cobol programs that will then do the processing (accessing data and doing calculations) and then return data. If anyone has been in this or a similar situation, please help. I need some really good arguments as to why we should put the business logic into PL/SQL instead of Pro*Cobol. I understand the reason we are using Oracle is that the director has 15 years experience with it and loves it. Aaargh!!! thanks Babette -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Babette Turner-Underwood INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Ron/Sarah Yount INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: Too many db calls
Cary M., Connor M., Thanks very much. - Greg -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Greg Moore INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: New development in Cobol or PL/SQL - please help
Cobol! Again!:( -Original Message- Sent: Friday, November 15, 2002 5:24 PM To: Multiple recipients of list ORACLE-L I just found out today that we have a major development initiative that is starting and they are planning on using Pro*Cobol to develop the application. (my head is still shaking in disbelief!!!) So we will have a Java front-end, invoking MQ series that will go across to the mainframe for MQ series to invoke Pro*Cobol programs that will then do the processing (accessing data and doing calculations) and then return data. If anyone has been in this or a similar situation, please help. I need some really good arguments as to why we should put the business logic into PL/SQL instead of Pro*Cobol. I understand the reason we are using Oracle is that the director has 15 years experience with it and loves it. Aaargh!!! thanks Babette -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Babette Turner-Underwood INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Khedr, Waleed INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Oracle Developer Application Tuning Resources/Guidlines.
Hi All ! I am new to Application Tuning i have the following queries: 0) where how to start?? the key areas in application tuning. 1) the tips techniques.. 2)useful tools scripts 3) othere resources [docs, websites etc] Best Regards Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site
