RE: Tracking Temp Segment Usage and Event 10046

2002-09-19 Thread Jamadagni, Rajendra
Title: Tracking Temp Segment Usage and Event 10046 Thanks Cary   One thing I noticed is some parameters referenced in that document are different in 9iR2 ... I guess Wolfgang is probably working on the 9iR2 version ...   It is a very nice paper ... Raj

RE: Tracking Temp Segment Usage and Event 10046

2002-09-19 Thread Cary Millsap
Title: Tracking Temp Segment Usage and Event 10046 For more information about 10053, see Wolfgang Breitling’s http://www.hotsos.com/dnloads/1/10053/Breitling2002.pdf. Wolfgang will present this and another new 10053 paper at our Symposium in Dallas next February (http://www.hotsos.com

RE: Tracking Temp Segment Usage and Event 10046

2002-09-18 Thread Connor McDonald
v$sort_usage and v$sort_segment are always a good start hth connor --- "Khedr, Waleed" <[EMAIL PROTECTED]> wrote: > I'd start looking at the execution plans first and > examine if there is any > Cartesian joins and the order the tables get joined. > > Waleed > > -Original Message- >

RE: Tracking Temp Segment Usage and Event 10046

2002-09-18 Thread Jamadagni, Rajendra
Title: Tracking Temp Segment Usage and Event 10046 I spent last two days working on that SQR and finally nailed it. Developers were using DISTINCT as a rule and CBO was choosing incorrect indexes.   I had to do following to make it work ...   1. we put hints in appropriate places 2. created

RE: Tracking Temp Segment Usage and Event 10046

2002-09-18 Thread STEVE OLLIG
aren't Cartesian joins are unlikely since all was well in the RBO world? sounds to me like the RBO was simply selecting better query plans than the CBO is. Raj - have you tried playing around with the OPTIMIZER_MODE parameter or OPTIMIZER_INDEX_CACHING; and OPTIMIZER_INDEX_COST_ADJ as described

RE: Tracking Temp Segment Usage and Event 10046

2002-09-18 Thread Khedr, Waleed
Title: Tracking Temp Segment Usage and Event 10046 I'd start looking at the execution plans first and examine if there is any Cartesian joins and the order the tables get joined.   Waleed -Original Message-From: Jamadagni, Rajendra [mailto:[EMAIL PROTECTED]]Sent: Tu

RE: Tracking Temp Segment Usage and Event 10046

2002-09-17 Thread DENNIS WILLIAMS
Raj - I personally favor using the simpler diagnostics first. Why not run your SQL through EXPLAIN PLAN and see which SQL is performing sorts? My immediate guess is that under RBO an index was being used that isn't now. Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED]

RE: Tracking Temp Segment Usage and Event 10046

2002-09-17 Thread Jamadagni, Rajendra
Title: RE: Tracking Temp Segment Usage and Event 10046 Dennis, I did, but the problem is this is a SQR report, and it ain't one sql. SQR reports are like giant cursor loops but un structured. There are about 100 different sql statements (not including the recursive ones). In RBO,

RE: Tracking Temp Segment Usage and Event 10046

2002-09-17 Thread K Gopalakrishnan
Title: Tracking Temp Segment Usage and Event 10046 Raj:   You will be able to identify the processes (along with the SQLs and number of extents) using the 10046 level 8 trace. If you use the temp files you see the file# ( in the direct path read/write events) as db_files+1 or MAXDBFILES+1

Tracking Temp Segment Usage and Event 10046

2002-09-17 Thread Jamadagni, Rajendra
Title: Tracking Temp Segment Usage and Event 10046 I have a problem with a process and its temp segment usage. Previously, in RBO (8161) we used to run 8 reports with slightly different parameters in parallel and it used to work fine with all other load on the system and the total TEMP