Re: Re: [Q] wait time /lob def
i apologize if someone posted this answer(i missed it if you did), but why do cached lobs require writes on the control file? and jonathan said that isnt 'necessarily' bad. is that because there isnt alot of I/O? so caching lobs are primarily useful for read only or read 'mostly' LOBs? > > From: "Jonathan Lewis" <[EMAIL PROTECTED]> > Date: 2004/01/30 Fri AM 04:09:25 EST > To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > Subject: Re: [Q] wait time /lob def > > > Tanel, > > Oracle 9-2 SQL Ref manual. Lob storage clause. > The options for lobs on creation are: > CACHE > NO CACHE > CACHE READS > > I don't think the last one appeared until 9.2 > I was wrong about caching only writes, though - > one of the joys of trying to quote everything from > memory. > > The CACHE READS option means that the > LOB goes into the buffer cache for reads, but > not for writes. Pity, really, because I'd quite > like to see it the other way around. > > > > Regards > > Jonathan Lewis > http://www.jlcomp.demon.co.uk > > The educated person is not the person > who can answer the questions, but the > person who can question the answers -- T. Schick Jr > > > Next public appearances: > Jan 29th 2004 UKOUG Unix SIG - v$ and x$ > March 2004 Hotsos Symposium - The Burden of Proof > March 2004 Charlotte NC OUG - CBO Tutorial > April 2004 Iceland > > > One-day tutorials: > http://www.jlcomp.demon.co.uk/tutorial.html > > > Three-day seminar: > see http://www.jlcomp.demon.co.uk/seminar.html > UK___February > UK___June > > > The Co-operative Oracle Users' FAQ > http://www.jlcomp.demon.co.uk/faq/ind_faq.html > > > - Original Message - > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> > Sent: Friday, January 30, 2004 12:19 AM > > > > Jonathan, > > > > about which version are you talking here? > > > > > (You do also have the option in more recent versions > > > of refining the caching properties so the LOB can be > > > readcache only, writecache only or read/write cache > > > or nocache, I believe). > > > > I haven't found a way to explicitly set read or write caching for LOBs in > > system level, although I've done some research on them lately (on 10g as > > well). Or are you talking about OCI LOB caching here? > > > > Tanel. > > > > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Jonathan Lewis > 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.net -- Author: <[EMAIL PROTECTED] 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: When does Oracle use 'Index Fast Scan'
ive found that index_ffs typically incur higher logical I/Os that index range scans. so its not just access speeds. > > From: David Hau <[EMAIL PROTECTED]> > Date: 2004/01/27 Tue AM 11:54:26 EST > To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > Subject: Re: When does Oracle use 'Index Fast Scan' > > This is where the access time of your disks (or SAN) makes a difference. > If your disks have really fast access time, then a random-access > pattern would not cause much performance degradation and so a range scan > would not be slow at all, even though it's traversing the b-tree index > structure. If you're only striping together disks with relatively slow > access time (e.g. using a striped IDE disk array), then you have high > throughput but not that fast an access time. In this case, fast full > index scan would be much faster than an index range scan because the > fast full scan reads the blocks sequentially and a sequential disk I/O > requires only positioning the head once (assuming the disk is not > fragmented). The rest of the time depends on the throughput. If you > stripe together a large enough number of IDE disks, then your throughput > is great but your access time is still the access time of a single IDE > drive which is not that fast. > > This is assuming you need to do a physical I/O to obtain the blocks. Of > course, if the blocks already reside in the buffer cache, then it's a > different story. > > Regards, > Dave > > > [EMAIL PROTECTED] wrote: > > > btw, in many cases range scan is faster than a fast full scan. Range scan > > recursively hits the nodes that are needed and skips the ones that are not. So it > > reads less blocks. > > > > So if you are looking for a 'range' or a specific value, range scan beats fast > > full scan most of the time. Less Logical and Physical I/Os. > > > > test it and hint your queries > > > > > > > >>From: David Hau <[EMAIL PROTECTED]> > >>Date: 2004/01/26 Mon PM 10:34:25 EST > >>To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > >>Subject: Re: When does Oracle use 'Index Fast Scan' > >> > >>Correction: the Index Range Scan can be parallelized when it involves > >>multiple partitions. > >> > >>- Dave > >> > >> > >>David Hau wrote: > >> > >> > >>>I assume you're talking about the Fast Full Index Scan. This is used > >>>when the index contains all the columns necessary to answer the query. > >>> > >>>It's faster than a Full Table Scan because indexes are smaller than > >>>entire rows, so a Fast Full Index Scan will scan fewer blocks than a > >>>Full Table Scan. > >>> > >>>It's faster than an Index Range Scan firstly because Fast Full Index > >>>Scan scans the blocks in sequential order, whereas the Index Range > >>>Scan traverses the B-tree index structure in scanning the blocks, > >>>resulting in a random access I/O pattern which is slower. This is > >>>also why the Oracle documentation says that with a Fast Full Index > >>>Scan, the result is not sorted by the index key (because the result is > >>>not obtained by traversing the index structure.) Secondly, the better > >>>performance is also because the Fast Full Index Scan uses multiblock > >>>reads and is capable of parallel operation, whereas the Index Range > >>>Scan is capable of neither. > >>> > >>>Regards, > >>>Dave. > >>> > >>> > >>> > >>>[EMAIL PROTECTED] wrote: > >>> > >>> > I have found that the vast majority of time that Oracle chooses this > method, my statistics are stale and the query is sub-optimal. One > time, Oracle changed from a 'range scan' to this type of scan with a > FIRST_ROWS hint and this reduced performance. > > This is just a full scan of the index, one block at a time right? > When would this ever be superior to a Fast Full Scan or a Range Scan? > >>> > >>> > >>> > >>-- > >>Please see the official ORACLE-L FAQ: http://www.orafaq.net > >>-- > >>Author: David Hau > >> 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.net > -- > Author: David Hau > 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 >
Re: Re: When does Oracle use 'Index Fast Scan'
my question pertains to regular 'index full scans' NOT index fast full scans. any ideas? I rarely ever find this to be an optimal index access method for anything. > > From: "Tanel Poder" <[EMAIL PROTECTED]> > Date: 2004/01/27 Tue AM 11:19:27 EST > To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > Subject: Re: When does Oracle use 'Index Fast Scan' > > Another situation where index full scans might be handy, would be where hash > joins are disabled and sorted output can be used for "fast" sort-merge join. > > Btw, multiblock reads are available for regular index range and full scan > under some specific conditions as well - I'm talking about readahead and > parameter _non_contiguous_multiblock_read for example. However, in my brief > tests I've not managed to see this kind of behaviour yet. > > Tanel. > > - Original Message - > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> > Sent: Tuesday, January 27, 2004 6:04 PM > > > > One situation I can think of where a (non-fast) full index scan can be > > helpful is when the index contains all the columns needed for the query, > > the query requires all the rows of the table, and the query requires the > > results to be sorted according to the index. This way, fast full index > > scan may be slower because you need to sort the rows after retrieving > > the blocks, whereas the non-fast full index scan does not. > > > > Regards, > > Dave > > > > > > > > [EMAIL PROTECTED] wrote: > > > > > I know when oracle uses a fast full scan. Its the full scan that does 1 > I/O at a time. I rarely see oracle using it and when it does, it generally > means my table(s) aren't properly analyzed. > > > > > > > > >>From: David Hau <[EMAIL PROTECTED]> > > >>Date: 2004/01/26 Mon PM 10:34:25 EST > > >>To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > > >>Subject: Re: When does Oracle use 'Index Fast Scan' > > >> > > >>Correction: the Index Range Scan can be parallelized when it involves > > >>multiple partitions. > > >> > > >>- Dave > > >> > > >> > > >>David Hau wrote: > > >> > > >> > > >>>I assume you're talking about the Fast Full Index Scan. This is used > > >>>when the index contains all the columns necessary to answer the query. > > >>> > > >>>It's faster than a Full Table Scan because indexes are smaller than > > >>>entire rows, so a Fast Full Index Scan will scan fewer blocks than a > > >>>Full Table Scan. > > >>> > > >>>It's faster than an Index Range Scan firstly because Fast Full Index > > >>>Scan scans the blocks in sequential order, whereas the Index Range > > >>>Scan traverses the B-tree index structure in scanning the blocks, > > >>>resulting in a random access I/O pattern which is slower. This is > > >>>also why the Oracle documentation says that with a Fast Full Index > > >>>Scan, the result is not sorted by the index key (because the result is > > >>>not obtained by traversing the index structure.) Secondly, the better > > >>>performance is also because the Fast Full Index Scan uses multiblock > > >>>reads and is capable of parallel operation, whereas the Index Range > > >>>Scan is capable of neither. > > >>> > > >>>Regards, > > >>>Dave. > > >>> > > >>> > > >>> > > >>>[EMAIL PROTECTED] wrote: > > >>> > > >>> > > I have found that the vast majority of time that Oracle chooses this > > method, my statistics are stale and the query is sub-optimal. One > > time, Oracle changed from a 'range scan' to this type of scan with a > > FIRST_ROWS hint and this reduced performance. > > > > This is just a full scan of the index, one block at a time right? > > When would this ever be superior to a Fast Full Scan or a Range Scan? > > >>> > > >>> > > >>> > > >>-- > > >>Please see the official ORACLE-L FAQ: http://www.orafaq.net > > >>-- > > >>Author: David Hau > > >> 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.net > > -- > > Author: David Hau > > 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 messag
Re: Re: When does Oracle use 'Index Fast Scan'
i found numerous cases(I dont have them in front of me) when fast full scan incurred far more logical I/Os than an index range scan. I found this particularly for oltp type get 10 records transactions. However, I forced an index_ffs once and it increased my logical I/Os by 30% but decreased my response time by about 50%. now this is non-scalable. Must be my disk access speeds as you said. It was for a batch process. unfortunately I didnt hold onto my cases. any comments on the 'full scan'. I rarely have seen oracle make good use of this type of index scan. > > From: David Hau <[EMAIL PROTECTED]> > Date: 2004/01/27 Tue AM 11:14:27 EST > To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > Subject: Re: When does Oracle use 'Index Fast Scan' > > This is where the access time of your disks (or SAN) makes a difference. > If your disks have really fast access time, then a random-access > pattern would not cause much performance degradation and so a range scan > would not be slow at all, even though it's traversing the b-tree index > structure. If you're only striping together disks with relatively slow > access time (e.g. using a striped IDE disk array), then you have high > throughput but not that fast an access time. In this case, fast full > index scan would be much faster than an index range scan because the > fast full scan reads the blocks sequentially and a sequential disk I/O > requires only positioning the head once (assuming the disk is not > fragmented). The rest of the time depends on the throughput. If you > stripe together a large enough number of IDE disks, then your throughput > is great but your access time is still the access time of a single IDE > drive which is not that fast. > > This is assuming you need to do a physical I/O to obtain the blocks. Of > course, if the blocks already reside in the buffer cache, then it's a > different story. > > Regards, > Dave > > > [EMAIL PROTECTED] wrote: > > > btw, in many cases range scan is faster than a fast full scan. Range scan > > recursively hits the nodes that are needed and skips the ones that are not. So it > > reads less blocks. > > > > So if you are looking for a 'range' or a specific value, range scan beats fast > > full scan most of the time. Less Logical and Physical I/Os. > > > > test it and hint your queries > > > > > > > >>From: David Hau <[EMAIL PROTECTED]> > >>Date: 2004/01/26 Mon PM 10:34:25 EST > >>To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > >>Subject: Re: When does Oracle use 'Index Fast Scan' > >> > >>Correction: the Index Range Scan can be parallelized when it involves > >>multiple partitions. > >> > >>- Dave > >> > >> > >>David Hau wrote: > >> > >> > >>>I assume you're talking about the Fast Full Index Scan. This is used > >>>when the index contains all the columns necessary to answer the query. > >>> > >>>It's faster than a Full Table Scan because indexes are smaller than > >>>entire rows, so a Fast Full Index Scan will scan fewer blocks than a > >>>Full Table Scan. > >>> > >>>It's faster than an Index Range Scan firstly because Fast Full Index > >>>Scan scans the blocks in sequential order, whereas the Index Range > >>>Scan traverses the B-tree index structure in scanning the blocks, > >>>resulting in a random access I/O pattern which is slower. This is > >>>also why the Oracle documentation says that with a Fast Full Index > >>>Scan, the result is not sorted by the index key (because the result is > >>>not obtained by traversing the index structure.) Secondly, the better > >>>performance is also because the Fast Full Index Scan uses multiblock > >>>reads and is capable of parallel operation, whereas the Index Range > >>>Scan is capable of neither. > >>> > >>>Regards, > >>>Dave. > >>> > >>> > >>> > >>>[EMAIL PROTECTED] wrote: > >>> > >>> > I have found that the vast majority of time that Oracle chooses this > method, my statistics are stale and the query is sub-optimal. One > time, Oracle changed from a 'range scan' to this type of scan with a > FIRST_ROWS hint and this reduced performance. > > This is just a full scan of the index, one block at a time right? > When would this ever be superior to a Fast Full Scan or a Range Scan? > >>> > >>> > >>> > >>-- > >>Please see the official ORACLE-L FAQ: http://www.orafaq.net > >>-- > >>Author: David Hau > >> 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 o
Re: Exam promo code
no, but you can buy one on Ebay that is 40% off for $8. A friend of mine did it and it works. > > From: "Boivin, Patrice J" <[EMAIL PROTECTED]> > Date: 2004/01/27 Tue AM 08:09:26 EST > To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > Subject: Exam promo code > > Does the OTN promo code for exams still exist? > > Patrice. > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Boivin, Patrice J > 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.net -- Author: <[EMAIL PROTECTED] 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: When does Oracle use 'Index Fast Scan'
btw, in many cases range scan is faster than a fast full scan. Range scan recursively hits the nodes that are needed and skips the ones that are not. So it reads less blocks. So if you are looking for a 'range' or a specific value, range scan beats fast full scan most of the time. Less Logical and Physical I/Os. test it and hint your queries > From: David Hau <[EMAIL PROTECTED]> > Date: 2004/01/26 Mon PM 10:34:25 EST > To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > Subject: Re: When does Oracle use 'Index Fast Scan' > > Correction: the Index Range Scan can be parallelized when it involves > multiple partitions. > > - Dave > > > David Hau wrote: > > > I assume you're talking about the Fast Full Index Scan. This is used > > when the index contains all the columns necessary to answer the query. > > > > It's faster than a Full Table Scan because indexes are smaller than > > entire rows, so a Fast Full Index Scan will scan fewer blocks than a > > Full Table Scan. > > > > It's faster than an Index Range Scan firstly because Fast Full Index > > Scan scans the blocks in sequential order, whereas the Index Range > > Scan traverses the B-tree index structure in scanning the blocks, > > resulting in a random access I/O pattern which is slower. This is > > also why the Oracle documentation says that with a Fast Full Index > > Scan, the result is not sorted by the index key (because the result is > > not obtained by traversing the index structure.) Secondly, the better > > performance is also because the Fast Full Index Scan uses multiblock > > reads and is capable of parallel operation, whereas the Index Range > > Scan is capable of neither. > > > > Regards, > > Dave. > > > > > > > > [EMAIL PROTECTED] wrote: > > > >> I have found that the vast majority of time that Oracle chooses this > >> method, my statistics are stale and the query is sub-optimal. One > >> time, Oracle changed from a 'range scan' to this type of scan with a > >> FIRST_ROWS hint and this reduced performance. > >> > >> This is just a full scan of the index, one block at a time right? > >> When would this ever be superior to a Fast Full Scan or a Range Scan? > > > > > > > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: David Hau > 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.net -- Author: <[EMAIL PROTECTED] 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: When does Oracle use 'Index Fast Scan'
I know when oracle uses a fast full scan. Its the full scan that does 1 I/O at a time. I rarely see oracle using it and when it does, it generally means my table(s) aren't properly analyzed. > > From: David Hau <[EMAIL PROTECTED]> > Date: 2004/01/26 Mon PM 10:34:25 EST > To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > Subject: Re: When does Oracle use 'Index Fast Scan' > > Correction: the Index Range Scan can be parallelized when it involves > multiple partitions. > > - Dave > > > David Hau wrote: > > > I assume you're talking about the Fast Full Index Scan. This is used > > when the index contains all the columns necessary to answer the query. > > > > It's faster than a Full Table Scan because indexes are smaller than > > entire rows, so a Fast Full Index Scan will scan fewer blocks than a > > Full Table Scan. > > > > It's faster than an Index Range Scan firstly because Fast Full Index > > Scan scans the blocks in sequential order, whereas the Index Range > > Scan traverses the B-tree index structure in scanning the blocks, > > resulting in a random access I/O pattern which is slower. This is > > also why the Oracle documentation says that with a Fast Full Index > > Scan, the result is not sorted by the index key (because the result is > > not obtained by traversing the index structure.) Secondly, the better > > performance is also because the Fast Full Index Scan uses multiblock > > reads and is capable of parallel operation, whereas the Index Range > > Scan is capable of neither. > > > > Regards, > > Dave. > > > > > > > > [EMAIL PROTECTED] wrote: > > > >> I have found that the vast majority of time that Oracle chooses this > >> method, my statistics are stale and the query is sub-optimal. One > >> time, Oracle changed from a 'range scan' to this type of scan with a > >> FIRST_ROWS hint and this reduced performance. > >> > >> This is just a full scan of the index, one block at a time right? > >> When would this ever be superior to a Fast Full Scan or a Range Scan? > > > > > > > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: David Hau > 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.net -- Author: <[EMAIL PROTECTED] 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: pga_aggregate_target and a memory leak
i heard tom kyte speak in december. He said first quarter 2004 for solaris. most people seem to still be on 8i. We have both 8i and 9i instance here. It will probably be a year before many employers are using it anywy. > > From: "Grabowy, Chris" <[EMAIL PROTECTED]> > Date: 2004/01/23 Fri PM 03:24:45 EST > To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > Subject: RE: pga_aggregate_target and a memory leak > > Kirti, > > So is April 12th the latest date you heard for when 10g "might" be > released?? Because it was the end of 2003, but I didn't know it had > slipped all the way into April... > > -Original Message- > Kirtikumar Deshpande > Sent: Wednesday, January 21, 2004 7:24 PM > To: Multiple recipients of list ORACLE-L > > > Thanks, Ryan. > Yes, it is on OWI, for those who are new to OWI. Covers OWI from 8i to > 10g. Co-authored with > Richmond Shee and K.Gopalakrishnan. > > It will not be out till 10g goes production. Unfortunately, April 12th > is not firm. 10g changes > > Regards, > > - Kirti > > --- Ryan <[EMAIL PROTECTED]> wrote: > > Im assuming its his wait interface book. Ill get it as soon as it > comes out. > > Hopefully it will be as good as his other tuning book. Is the April > 12th > > date firm? Now the bigger question: Will it be out before the 10G > database? > > > > > http://www.amazon.com/exec/obidos/tg/detail/-/007222729X/qid=1074724628/ > sr=1 > > -2/ref=sr_1_2/104-1361632-8254324?v=glance&s=books > > - Original Message - > > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> > > Sent: Wednesday, January 21, 2004 5:14 PM > > > > > > > > > > A comment I picked up from Tom Kyte's > > > Masterclass in Copenhagen last week was > > > that there is an effective limit of 1GB to > > > P_A_T - and although a single session is > > > supposed to be allowed 5% of the P_A_T, > > > you could get about 90MB. So there are > > > some funny things going on in that area > > > which still need fixing. > > > > > > It's a bit tough for big systems, as I've > > > found that the optimizer seems to be > > > much smarter about memory user and > > > access paths when P_A_T and W_S_P > > > are set. > > > > > > What's the book about ? > > > > > > Regards > > > > > > Jonathan Lewis > > > http://www.jlcomp.demon.co.uk > > > > > > The educated person is not the person > > > who can answer the questions, but the > > > person who can question the answers -- T. Schick Jr > > > > > > > > > Next public appearance2: > > > March 2004 Hotsos Symposium - Keynote > > > March 2004 Charlotte NC - OUG Tutorial > > > April 2004 Iceland > > > > > > > > > One-day tutorials: > > > http://www.jlcomp.demon.co.uk/tutorial.html > > > > > > > > > Three-day seminar: > > > see http://www.jlcomp.demon.co.uk/seminar.html > > > UK___February > > > > > > > > > The Co-operative Oracle Users' FAQ > > > http://www.jlcomp.demon.co.uk/faq/ind_faq.html > > > > > > > > > - Original Message - > > > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> > > > Sent: Wednesday, January 21, 2004 7:44 PM > > > > > > > > > > Replies in line... > > > > > > > > - Kirti > > > > > > > > --- [EMAIL PROTECTED] wrote: > > > > > Kirti, you're back! > > > > > > > > Thanks. Found some slack time from routine DBA work! > > > > > > > > > > > > > > Must have finished the book. :) > > > > > > > > Not yet.. Its tough.. > > > > > > > > > > > > > > > > > > > > > > Re the PGA problems, what was the value for 'over allocation > count' in > > > > > v$pgastat? > > > > > > > > Actually, I never bothered to look at v$pgastat. Should have.. and > will, > > > when we do some more > > > > testing next week.. > > > > > > > > > > -- > > > Please see the official ORACLE-L FAQ: http://www.orafaq.net > > > -- > > > Author: Jonathan Lewis > > > 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.net > > -- > > Author: Ryan > > 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
are the 9.2.0.3 memory leaks critical?
There are a series of metalink notes detailing memory leaks with the PGA in 9203. Has anyone had critical problems? Oracle recommends patching to 9204 to fix this, but it just came out and we prefer to be conservative with our patches. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: <[EMAIL PROTECTED] 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: Healty ratio of index segment size vs table segment size?
comments in line... I may need correction from some of you on this. > -Original Message- > Sent: Wednesday, January 21, 2004 9:39 AM > To: Multiple recipients of list ORACLE-L > > > Wondering if there is a "rule of thumb", quick'n fast but good enough > to be used as an indicator, litmus paper so to speak, of overly indexed > table(s)... the only rule of thumb I have seen is the script on Steve Adams site at www.ixora.com.au that finds unnecessary indexes. The site appears to be down, so you can try google and the cache feature. > > Can, better yet - should, sheer size comparison of index versus table > segments be used as a reliable pointer to problematic table indexing? No. some people would argue that the size of an index is an indicator of needing a rebuild, but many of the big time tuners say this is not true, so I take their advice. Disk space is cheap. > > If it can, what could be considered as average "healthy ratio" above > which would be prudent to have a closer look and investigate? no,no,no... I hate ratios. > > Related to the above dilemma, how "expensive" is to monitor index usage, > say if script is run against all few hundred indexes on app tables, > would the additional load noticeably affect application performance or > is it better/safer or may be required to monitor not more than just a > few "most suspected" indexes at a time? do all monitoring during off peak hours. Can you run it over the weekend? Benchmark it. You can do alot of good monitoring during off peak hours. I run all kinds of high load stuff on the weekends. You may want to run Steven Adams script once a month or so. Do it from a batch job and send yourself an email if something comes up. > > Thoughts, pointers, opinions - appreciated. > > Branimir > The key to a good index screen is database design and understanding the goal of your system. What are you users trying to do most frequently? What is most critical to the system? Design towards that. Can you make a small change to your data model so that you do not really need to add an extra index and what is the impact of it? (pros and cons to everything). The big question is are your indexes affecting performance of your DML statements? do you foresee any possible problems in the future? Could someone correct me here. Im willing to bet Im half right.. though not sure which half. > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Branimir Petrovic > 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.net > -- > Author: DENNIS WILLIAMS > 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.net -- Author: <[EMAIL PROTECTED] 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).
data manipulation of a large unix file
We are getting a feed of an 800 MB file that will come in nightly. It needs to be loaded to the database. Per requirements, we have to add some data to the file before loading(its not negotiable). ksh eats up 24% of total CPU on a 4 CPU Solaris box. We cannot do this. I am not allowed to stream it with a named pipe. any other solutions? -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: <[EMAIL PROTECTED] 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).
any over head with DBMS_STATS.ALTER_DATABASE_TABLE_MONITORING
Especially on high transaction tables? I dont have any numbers for transactions/second since we are not live. Any known issues? how does the monitoring work? Does it use an internal trigger and then use SQL to write the data? or does the monitoring data bypass the SQL layer and get written directly to the block? -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: <[EMAIL PROTECTED] 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: pga_aggregate_target and a memory leak
kirti-- would you recommend avoiding pga_aggregate_target for now? > > From: Kirtikumar Deshpande <[EMAIL PROTECTED]> > Date: 2004/01/21 Wed PM 02:44:31 EST > To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > Subject: Re: pga_aggregate_target and a memory leak > > Replies in line... > > - Kirti > > --- [EMAIL PROTECTED] wrote: > > Kirti, you're back! > > Thanks. Found some slack time from routine DBA work! > > > > > Must have finished the book. :) > > Not yet.. Its tough.. > > > > > > > Re the PGA problems, what was the value for 'over allocation count' in > > v$pgastat? > > Actually, I never bothered to look at v$pgastat. Should have.. and will, when we do > some more > testing next week.. > > > > > > Did you try increasing P_A_T to a larger number? > > Yes... > > > > > > Oracle is supposed to grab the memory it needs, if available, regardless > > of > > the P_A_T setting. > > > > Also, did your system go in to excessive paging or swapping? > > Yes, it did with a large P_A_T. > > > > > > I've been curious as to what the effects would be of having P_A_T too low. > > I saw more disk sorts.. > > As time permits, I will play with event 10032, 10033 trace for sorts to see what's > going on.. > > > > > > Oracle is supposed to grab whatever memory it needs. I'm assuming at this > > point that doing so involves a different code path as it needs to alloc > > the memory. > > > > Don't know what the cost of that is, haven't tried to test it. > > > > It seems likely that the OS was out of memory, regardless of the P_A_T > > value. > > > No. The system has 4 GB of physical memory. Over 2GB was free. > > > Jared > > > > > > > > > > > > > > Kirtikumar Deshpande <[EMAIL PROTECTED]> > > Sent by: [EMAIL PROTECTED] > > 01/21/2004 06:09 AM > > Please respond to ORACLE-L > > > > > > To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > > cc: > > Subject:Re: pga_aggregate_target and a memory leak > > > > > > Setting P_A_T to a 1GB limit with over 2GB of *available memory* on AIX > > 4.3.3 and 9.2.0.4 caused > > ORA-4030, till we turned off hash joins. OS level resources (ulimit -a) > > were all set to > > 'unlimited'. In a very limited testing, setting P_A_T to less than S_A_S > > (and S_A_R_S) worked, > > however, the disk sorts increased. Finally, Developers chose no hash > > joins, 1GB P_A_T and 'AUTO' > > workarea_size_policy... seems to run okay... > > > > - Kirti > > > > > > --- Stephane Faroult <[EMAIL PROTECTED]> wrote: > > > [EMAIL PROTECTED] wrote: > > > > > > > > One of our production DBAs does not want to use pga_aggregate_target > > on a 9.2.0.3 instance due > > > to a possible memory leak. The only note on memory leaks and > > pga_aggregate_target I can find on > > > metalink is: 334427.995 > > > > > > > > doesnt seem to apply to pga_aggregate_target. We are on sun solaris. > > Dont know version > > > offhand. > > > > > > > > he is under the impression that if we patch to 9.2.0.4 this goes away. > > not sure about that > > > either... > > > > > > > > > > Be careful with pga_aggregate_target. I have very recently seen a case > > > (Solaris + 9.2 but I cant't tell you exactly which patch level - > > > probably the most recent) where two (by the way atrocious) queries > > > generated by a DSS tool were responding very differently - and in a way > > > that differences in the queries couldn't explain. From an Oracle > > > standpoint, stats were roughly the same. Tracing proved that we were > > > waiting for CPU, and truss that a call to mmap() was the culprit. Why, > > > no idea. We first switched it (pga_thing) off, no more slow call to > > > mmap(). However, it was still slow because we hadn't checked > > > sort_area_size which was ridiculously small. We set sort_area_size to > > > 10M, still with pga_aggregate_target unset, and once again the same very > > > slow calls to mmap(). Memory misalignment? Anything else? Not much time > > > to enquire but it looks like a mine field. > > > > > > -- > > > Regards, > > > > > > Stephane Faroult > > > Oriole Software > > > -- > > > > > > > > > > > > > __ > Do you Yahoo!? > Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes > http://hotjobs.sweepstakes.yahoo.com/signingbonus > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Kirtikumar Deshpande > 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 se
Re: Healty ratio of index segment size vs table segment size?
www.ixora.com.au there is a script in there that will identify unnecessary redundant indexes. for the record, that is one of the best oracle websites out there. Lots of great stuff on it. > > From: Branimir Petrovic <[EMAIL PROTECTED]> > Date: 2004/01/21 Wed AM 10:39:25 EST > To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > Subject: Healty ratio of index segment size vs table segment size? > > Wondering if there is a "rule of thumb", quick'n fast but good enough > to be used as an indicator, litmus paper so to speak, of overly indexed > table(s)... > > Can, better yet - should, sheer size comparison of index versus table > segments be used as a reliable pointer to problematic table indexing? > > If it can, what could be considered as average "healthy ratio" above > which would be prudent to have a closer look and investigate? > > Related to the above dilemma, how "expensive" is to monitor index usage, > say if script is run against all few hundred indexes on app tables, > would the additional load noticeably affect application performance or > is it better/safer or may be required to monitor not more than just a > few "most suspected" indexes at a time? > > Thoughts, pointers, opinions - appreciated. > > Branimir > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Branimir Petrovic > 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.net -- Author: <[EMAIL PROTECTED] 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).
cman and oracle names
I sent this last night. Im not sure if it went through. If it did, I apologize for the spam. Does anyone use CMAN? Its in the certification books(yes I know certification isnt very good, but I might as well learn something if Im going to do it), but I dont know anyone using it. It strikes me as a poor mans application serve? Or am I missing something? Does anyone use names server? It strikes me as only being useful for client server applications or for a large development team where lots of people need Toad and/or SQLPlus access to many instances. Or have I underestimated its value? -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: <[EMAIL PROTECTED] 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: Has anyone done any scalability work on dbms_lock?
nuno-- what level are you trying to scale it to? how long will you hold the locks? I used it last year because only one process could run at a time. seemed to have similiar over head to 'select for update'. If you look at the PL/SQL Packages book by Fuerstein et al(not a real popular book, but I like it)... there is a nifty wrapper for DBMS_LOCK. I based my code off of that. > > From: "Carel-Jan Engel" <[EMAIL PROTECTED]> > Date: 2004/01/21 Wed AM 08:24:25 EST > To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > Subject: Re: Has anyone done any scalability work on dbms_lock? > > > As in: does it present an inherent or hidden performance > > problem when a lot of sessions try to lock/release the same > > lock? > Will serialize perfectly! > > > Or how many lock/release per second. Or some other > > idea of how efficient it is? > Depends on the work done between acquiring the lock and releasing it. > > > > > Need to use it in a design, but not sure of any potential > > performance hits or scalability issues. Any ideas? > When sessions acquire the same lock (as asked), only one session can do > the work in a given moment. So, it doesn't scale. There will be overhead, > but that also is relative to the duration of the work done while the lock > is held. > > Maybe AQ can help, by doing the work asynchronously in the background and > so lift the serialization from the primary proces(ses)? > > > Regards, Carel-Jan > > === > If you think education is expensive, try ignorance. (Derek Bok) > === > > > > > TIA. > > Cheers > > Nuno Souto > > [EMAIL PROTECTED] > > -- > > Please see the official ORACLE-L FAQ: http://www.orafaq.net > > -- > > Author: Nuno Souto > > 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.net > -- > Author: Carel-Jan Engel > 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.net -- Author: <[EMAIL PROTECTED] 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: Has anyone done any scalability work on dbms_lock?
i think expert one on one has some comments on it. Its in a section referring to building your own insert locks. So if a table is locked, the user gets notified. I read the book last year. > > From: "Nuno Souto" <[EMAIL PROTECTED]> > Date: 2004/01/21 Wed AM 07:49:25 EST > To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > Subject: Has anyone done any scalability work on dbms_lock? > > As in: does it present an inherent or hidden performance > problem when a lot of sessions try to lock/release the same > lock? Or how many lock/release per second. Or some other > idea of how efficient it is? > > Need to use it in a design, but not sure of any potential > performance hits or scalability issues. Any ideas? > > TIA. > Cheers > Nuno Souto > [EMAIL PROTECTED] > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Nuno Souto > 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.net -- Author: <[EMAIL PROTECTED] 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).
OT: Does SQL Server have a wait interface?
anyone know? -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: <[EMAIL PROTECTED] 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).
pga_aggregate_target and a memory leak
One of our production DBAs does not want to use pga_aggregate_target on a 9.2.0.3 instance due to a possible memory leak. The only note on memory leaks and pga_aggregate_target I can find on metalink is: 334427.995 doesnt seem to apply to pga_aggregate_target. We are on sun solaris. Dont know version offhand. he is under the impression that if we patch to 9.2.0.4 this goes away. not sure about that either... -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: <[EMAIL PROTECTED] 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: Oracle vs Mysql
if Oracle is offshoring its develeoping of its database, everyone else will also... so much for job security. anyone I heard postgre sql has multi-versioning? Is it implemented like Oracle? So UDB is the new DB2? Oracle claims that DB2 is not one database but a different database for different Operating Systems, is this true? Is it true with UDB? > > From: Mladen Gogala <[EMAIL PROTECTED]> > Date: 2004/01/19 Mon PM 11:04:26 EST > To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > Subject: Re: Oracle vs Mysql > > It needs not to have the same capabilities, it needs to have capabilities that people > are using. The primary capabilities that people need, in my opinion, are a decent > scripting language, with the full complement of the database triggers, procedures, > packages and functions, ability to store/access/administer huge objects, hundreds > of gigabytes in size, a decent SQL implementation with plethora of functions and a > support for standard APIs like JDBC, ODBC, OLE and DBI. A good compiler support > with something similar to long extinct SQL*Module (originally an IBM technology) > and > there would be huge number of users. Fortunately for oracle, MySQL still has problems > with the most basic things: transactions, versioning, locking and SQL > implementation. > My conclusion is that MySQL will never be much more then a toy, despite the hype, > catchy name and apparent popularity. I see much more dangerous adversaries in > UDB (artist formerly known as DB2) and PostgresSQL. If IBM decides to play open > source on Unix, and there are rumors of IBM musing over such a move, Oracle > would most probably be toast. I must say that after some oracle's mischiefs, I > wouldn't be the last one to defect and switch the databases. I wasn't the last one > to leave DEC either, despite the fact that I was teaching VMS courses in 1992. > My point is that Oracle is extremely feature rich. Very few people are using more > then 20% of the database capabilities. Initially, in V8, I worked hard to learn about > the Object PL/SQL, datatypes and classes. Believe it or not, I've never seen it used > in production. By now, I've forgotten it all. It's almost the same situation with > Java > in the database. Very few are using it. Most people test it, then say "aha!" and > move > on. Those two features will not make a whole lot of difference when a viable > competitor > emerges. Oracle 10g was written, for the most part outside of US. With beta testing > this closed and restricted, it's not going to be tested thoroughly, not even close > to thoroughly. > What we are likely to get is an unstable, buggy and almost unusable "gridlock" > version. > Competitor might emerge sooner then some people are realizing. > > On 2004.01.19 20:42, [EMAIL PROTECTED] wrote: > > If MySQL comes to have the same capabilities that many people expect > > from Oracle, marketing will have no effect. The huge differential in > > price > > point will be all that matters. > > > > > > Jared > > > > > > > > > > > > > > DENNIS WILLIAMS <[EMAIL PROTECTED]> > > Sent by: [EMAIL PROTECTED] > > 01/19/2004 04:04 PM > > Please respond to ORACLE-L > > > > > > To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > > cc: > > Subject:RE: Oracle vs Mysql > > > > > > Sounds like the old Oracle vs. Ingress battles. Oracle won because it was > > better at marketing. All detailed in the book "The Difference Between God > > and Larry Ellison". I can see it now -- MySQL, the Oracle of the free > > databases. > > > > Dennis Williams > > DBA > > Lifetouch, Inc. > > [EMAIL PROTECTED] > > > > -Original Message- > > Sent: Wednesday, January 14, 2004 4:39 PM > > To: Multiple recipients of list ORACLE-L > > > > > > Ryan, > > > > It's postgres.org. I'm not sure how they generate the > > operating > > revenue they need, but that's why they are not advertising like MySql AB > > is. > > > > Dick Goulet > > Senior Oracle DBA > > Oracle Certified 8i DBA > > > > -Original Message- > > Sent: Wednesday, January 14, 2004 5:05 PM > > To: Multiple recipients of list ORACLE-L > > > > > > i thought postgre was a for profit company? how do they generate revenues? > > - Original Message - > > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> > > Sent: Wednesday, January 14, 2004 4:19 PM > > > > > > > 1) DBI is a perl module to handle the communication with various > > databases. > > > 2) Postgres is free. I believe that you can buy commercial support, but > > I > > don't know > > >where. May be Rich can jump in with that. > > > 3) DBI is free and so is perl. I'm cheap & easy, but not free. > > > > > > > > > On 01/14/2004 02:34:52 PM, Ryan wrote: > > > > what is DBI? > > > > > > > > is postgre free? Is it like linux where you pay for support? I cant > > find > > any > > > > licensing info on the website. Mos
