Query tuning-how to reduce physical reads-help me

1* select * from masterbillingInvoiceview Where SiteIID =300964 and InvoiceID like '%' order by Invoice asc
SQL> /
33 rows selected.
Elapsed: 00:00:00.34
Execution Plan
Plan hash value: 352896138
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 16 | 6304 | 341 (3)| 00:00:05 |
| 1 | SORT ORDER BY | | 16 | 6304 | 341 (3)| 00:00:05 |
| 2 | TABLE ACCESS BY INDEX ROWID | ADDRESS | 1 | 48 | 2 (0)| 00:00:01
| 3 | NESTED LOOPS | | 16 | 6304 | 340 (3)| 00:00:05 |
| 4 | NESTED LOOPS | | 16 | 5536 | 316 (3)| 00:00:04 |
|* 5 | HASH JOIN OUTER | | 16 | 5168 | 308 (3)| 00:00:04 |
|* 6 | HASH JOIN | | 16 | 4992 | 302 (3)| 00:00:04 |
|* 7 | HASH JOIN | | 16 | 4752 | 298 (3)| 00:00:04 |
| 8 | NESTED LOOPS | | 17 | 4828 | 44 (0)| 00:00:01 |
| 9 | NESTED LOOPS | | 17 | 3451 | 35 (0)| 00:00:01 |
| 10 | NESTED LOOPS OUTER | | 1 | 91 | 2 (0)| 00:00:01 |
| 11 | TABLE ACCESS BY INDEX ROWID| SITEMASTER | 1 | 74 | 1 (0)| 00:00:01 |
|* 12 | INDEX UNIQUE SCAN | PK_SITEMASTER | 1 | | 1 (0)| 00:00:01 |
| 13 | TABLE ACCESS BY INDEX ROWID| INVGROUPS | 1735 | 29495 | 1 (0)| 00:00:01 |
|* 14 | INDEX UNIQUE SCAN | PK_INVGROUPS | 1 | | 1 (0)| 00:00:01 |
|* 15 | TABLE ACCESS BY INDEX ROWID | INVOICEHEAD | 17 | 1904 | 33 (0)| 00:00:01 |
|* 16 | INDEX RANGE SCAN | IDX_INVOICEHEADSITEIID | 271 | | 1 (0)| 00:00:01 |
| 17 | TABLE ACCESS BY INDEX ROWID | CUSTOMER | 1 | 81 | 1 (0)| 00:00:01 |
|* 18 | INDEX UNIQUE SCAN | PK_CUSTOMER | 1 | | 1 (0)| 00:00:01 |
| 19 | VIEW | | 35844 | 455K| 254 (3)| 00:00:04 |
| 20 | HASH GROUP BY | | 35844 | 455K| 254 (3)| 00:00:04 |
| 21 | TABLE ACCESS FULL | CONTACT | 56100 | 712K| 250 (1)| 00:00:03 |
| 22 | VIEW | index$_join$_009 | 7 | 105 | 3 (0)| 00:00:01 |
|* 23 | HASH JOIN | | | | | |
| 24 | INDEX FAST FULL SCAN | IDX_PAYMENTTERMSID | 7 | 105 | 1 (0)| 00:00:01
| 25 | INDEX FAST FULL SCAN | PK_PAYMENTTERMS | 7 | 105 | 1 (0)| 00:00:01
| 26 | VIEW | index$_join$_011 | 1428 | 15708 | 6 (0)| 00:00:01 |
|* 27 | HASH JOIN | | | | | |
| 28 | INDEX FAST FULL SCAN | PK_EMPLOYEE | 1428 | 15708 | 3 (0)| 00:00:01 |
| 29 | INDEX FAST FULL SCAN | IDX_EMPLOYEEEMPLOYEEID | 1428 | 15708 | 3 (0)| 00:00:01
| 30 | TABLE ACCESS BY INDEX ROWID | CONTACT | 1 | 23 | 1 (0)| 00:00:
|* 31 | INDEX UNIQUE SCAN | PK_CONTACT | 1 | | 1 (0)| 00:00:01 |
|* 32 | INDEX RANGE SCAN | PK_ADDRESS | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
5 - access("A"."CREATEDBY"="J"."EMPIID"(+))
6 - access("A"."TERMSIID"="H"."PAYMENTTERMSIID")
7 - access("D"."CUSTOMERIID"="F"."CUSTOMERIID")
12 - access("B"."SITEIID"=300964)
14 - access("B"."PARENTIID"="I"."GROUPIID"(+))
15 - filter("A"."TYPE"=4 AND "A"."INVOICEID" LIKE '%')
16 - access("A"."SITEIID"=300964)
18 - access("A"."BILLINGCUSTOMERIID"="D"."CUSTOMERIID")
23 - access(ROWID=ROWID)
27 - access(ROWID=ROWID)
31 - access("F"."CONTACTIID"="G"."CONTACTIID")
32 - access("E"."ADDRESSIID"=NVL("D"."BILLINGADDRESSIID","D"."ADDRESSIID"))
Statistics
107 recursive calls
0 db block gets
2819 consistent gets
0 physical reads
0 redo size
6586 bytes sent via SQL*Net to client
356 bytes received via SQL*Net from client
4 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
33 rows processed
SQL> ed
Wrote file afiedt.buf
1* select * from masterbillingInvoiceview Where SiteIID =300964 and InvoiceID like '%%%' order by Invoice asc
SQL> /
33 rows selected.
Elapsed: 00:06:15.23
Execution Plan
Plan hash value: 1828716447
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 2 | 964 | 295 (3)| 00:00:04 |
|* 1 | FILTER | | | | | |
| 2 | SORT GROUP BY | | 2 | 964 | 295 (3)| 00:00:04 |
| 3 | MERGE JOIN CARTESIAN | | 72315 | 33M| 291 (1)| 00:00:04 |
| 4 | TABLE ACCESS BY INDEX ROWID | ADDRESS | 1 | 52 | 2 (0)| 00:00:01 |
| 5 | NESTED LOOPS | | 1 | 447 | 41 (0)| 00:00:01 |
| 6 | NESTED LOOPS | | 1 | 395 | 40 (0)| 00:00:01 |
| 7 | NESTED LOOPS | | 1 | 382 | 38 (0)| 00:00:01 |
| 8 | NESTED LOOPS OUTER | | 1 | 289 | 37 (0)| 00:00:01 |
| 9 | NESTED LOOPS | | 1 | 266 | 36 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | 1 | 239 | 35 (0)| 00:00:01 |
| 11 | NESTED LOOPS OUTER | | 1 | 115 | 2 (0)| 00:00:01 |
| 12 | TABLE ACCESS BY INDEX ROWID| SITEMASTER | 1 | 86 | 1 (0)| 00:00:01 |
|* 13 | INDEX UNIQUE SCAN | PK_SITEMASTER | 1 | | 1 (0)| 00:00:01 |
| 14 | TABLE ACCESS BY INDEX ROWID| INVGROUPS | 1735 | 50315 | 1 (0)| 00:00:01 |
|* 15 | INDEX UNIQUE SCAN | PK_INVGROUPS | 1 | | 1 (0)| 00:00:01 |
|* 16 | TABLE ACCESS BY INDEX ROWID | INVOICEHEAD | 1 | 124 | 33 (0)| 00:00:01 |
|* 17 | INDEX RANGE SCAN | IDX_INVOICEHEADSITEIID | 271 | | 1 (0)| 00:00:01 |
| 18 | TABLE ACCESS BY INDEX ROWID | PAYMENTTERMS | 1 | 27 | 1 (0)| 00:00:01 |
|* 19 | INDEX UNIQUE SCAN | PK_PAYMENTTERMS | 1 | | 1 (0)| 00:00:01 |
| 20 | TABLE ACCESS BY INDEX ROWID | EMPLOYEE | 1 | 23 | 1 (0)| 00:00:01 |
|* 21 | INDEX UNIQUE SCAN | PK_EMPLOYEE | 1 | | 1 (0)| 00:00:01 |
| 22 | TABLE ACCESS BY INDEX ROWID | CUSTOMER | 1 | 93 | 1 (0)| 00:00:01 |
|* 23 | INDEX UNIQUE SCAN | PK_CUSTOMER | 1 | | 1 (0)| 00:00:01 |
| 24 | TABLE ACCESS BY INDEX ROWID | CONTACT | 1 | 13 | 2 (0)| 00:00:01 |
|* 25 | INDEX RANGE SCAN | IDX_CONTACTCUSTOMERIID | 2 | | 1 (0)| 00:00:01 |
|* 26 | INDEX RANGE SCAN | PK_ADDRESS | 1 | | 1 (0)| 00:00:01 |
| 27 | BUFFER SORT | | 56100 | 1917K| 294 (3)| 00:00:04 |
| 28 | TABLE ACCESS FULL | CONTACT | 56100 | 1917K| 250 (1)| 00:00:03 |
Predicate Information (identified by operation id):
1 - filter("G"."CONTACTIID"=MAX("CONTACTIID"))
13 - access("B"."SITEIID"=300964)
15 - access("B"."PARENTIID"="I"."GROUPIID"(+))
16 - filter("A"."TYPE"=4 AND "A"."INVOICEID" LIKE '%%%')
17 - access("A"."SITEIID"=300964)
19 - access("A"."TERMSIID"="H"."PAYMENTTERMSIID")
21 - access("A"."CREATEDBY"="J"."EMPIID"(+))
23 - access("A"."BILLINGCUSTOMERIID"="D"."CUSTOMERIID")
25 - access("D"."CUSTOMERIID"="CUSTOMERIID")
filter("CUSTOMERIID" IS NOT NULL)
26 - access("E"."ADDRESSIID"=NVL("D"."BILLINGADDRESSIID","D"."ADDRESSIID"))
Statistics
1952 recursive calls
78 db block gets
4649 consistent gets
236151 physical reads
0 redo size
6586 bytes sent via SQL*Net to client
356 bytes received via SQL*Net from client
4 SQL*Net roundtrips to/from client
1 sorts (memory)
1 sorts (disk)
33 rows processed
this is the execution plan of my one query with a small difference, bt there is large diffference in physical reads..
can anyone help me out of this
thanks
aju

Hi,
Can you please format your explain plan using
{ code } --without space
Explain plan
{ code } -- without any space
What is your DB version?
There are differences in access and filter criteria...
-- FRIST QUERY
5 - access("A"."CREATEDBY"="J"."EMPIID"(+))
6 - access("A"."TERMSIID"="H"."PAYMENTTERMSIID")
7 - access("D"."CUSTOMERIID"="F"."CUSTOMERIID")
12 - access("B"."SITEIID"=300964)
14 - access("B"."PARENTIID"="I"."GROUPIID"(+))
15 - filter("A"."TYPE"=4 AND "A"."INVOICEID" LIKE '%')
16 - access("A"."SITEIID"=300964)
18 - access("A"."BILLINGCUSTOMERIID"="D"."CUSTOMERIID")
23 - access(ROWID=ROWID)
27 - access(ROWID=ROWID)
31 - access("F"."CONTACTIID"="G"."CONTACTIID")
32 - access("E"."ADDRESSIID"=NVL("D"."BILLINGADDRESSIID","D"."ADDRESSIID"))
------SECOND QUERY
1 - filter("G"."CONTACTIID"=MAX("CONTACTIID"))
13 - access("B"."SITEIID"=300964)
15 - access("B"."PARENTIID"="I"."GROUPIID"(+))
16 - filter("A"."TYPE"=4 AND "A"."INVOICEID" LIKE '%%%')
17 - access("A"."SITEIID"=300964)
19 - access("A"."TERMSIID"="H"."PAYMENTTERMSIID")
21 - access("A"."CREATEDBY"="J"."EMPIID"(+))
23 - access("A"."BILLINGCUSTOMERIID"="D"."CUSTOMERIID")
25 - access("D"."CUSTOMERIID"="CUSTOMERIID")
filter("CUSTOMERIID" IS NOT NULL)
26 - access("E"."ADDRESSIID"=NVL("D"."BILLINGADDRESSIID","D"."ADDRESSIID"))-Avinash

Similar Messages

How to reduce physical reads - very interesting issue

HI,
Every week i generate a statspack report which will give me top20 buffer gets queries and top 20 physical reads query.When i start reducing physical reads by placing the heavy accessed table in buffer i will get the same query in top 20 higher buffer gets list in the next week.If i want to reduce buffer gets i have to remove the heavy accessed table from buffer which will cause higer physical reads.How can i solve this problem.I am trying to tune query as much as possible.
Your help is appreciated..
Thanks and Regards
Anand

I think that you are labouring under a misapprehension. Buffer gets and physical reads are basically the same thing. In order to satisfy your query, Oracle needsto read X number of blocks to find all of the data. Admittedly, it is generally faster to read those blocks from memory (buffer gets) than from disk (physical reads), but the blocks have to be read (this is called logical I/O). The only way to reduce I/O is to re-write the query to be more efficient. This may or may not be possible.
As Kamal said, if the query is fast enough, then you are done. If it is too slow, then you need to look at ways of reducing I/O. It is unlikely that any database parameters will have a significant impact on the I/O. You need to look at the statisitics on the table and the actual sql statement.
John

Reducing Physical Reads

Hi
My oracle version is 10.2.0.4
Is there any way to reduce the physical reads apart from tuning the query and index creation.
Can I have my whole table arranged in blocks sequentially one after the other so that my search becomes simple.
Is there any option for that like Coallesce /deallocate unused space/ Compact.

littleboy wrote:
Is there any way to reduce the physical reads apart from tuning the query and index creation.Incorrectly phrased. By reducing PIO (physical I/O) you can imply that you want to increase LIO (logical I/O) as this is faster and will thus increase performance.
That is not tuning. That is hacking of a terrible kind.
In fact, a high percentage LIO is indicative of an application design problem.
The correctly phrased question is "how to reduce I/O?" - as less I/O means less work. And less work does not equate to only less PIOs. It means less I/O (of all kinds). Period.
Can I have my whole table arranged in blocks sequentially one after the other so that my search becomes simple.
Is there any option for that like Coallesce /deallocate unused space/ Compact.From the questions you have asked the past few days, I get the feeling that you are looking for magical silver bullet solutions to performance. A knob to turn somewhere in Oracle, a switch to throw to enable some special behaviour.
That is, and never was, performance tuning. Performance starts with the design of the system. It continues with the architecture used and implemented. And remains with every single line of code written.
You do not pop Oracle's hood and rummage around in the engine, muck about with the fuel injectors, in order to get it to go faster. You design the application to use Oracle correctly. You implemented Oracle correctly. That is where performance start. Not with popping the hood.
Messing with space management to make Oracle go faster? Messing with undocumented parameters? Changing process priorities? Supersizing this and that? That is a FAIL as far as the correct software engineering approach to performance goes.

Unable to reduce Physical Reads

Hi
Problem:
Need to reduce the Physical reads in Oracle 8.1.7
Information:
Optimizer_mode= Choose
Statistics will not be gathered.
Intially the cache hit ratio is 18%. At this point when we checked the SQL Statement
SELECT a32,
F_DOCNUMBER,NVL(a109,'BIWS') AS WorkFlow,
a147 AS Service_Subsidary,
a89 AS StaffInd,
a88 AS SubsidiaryInd
FROM doctaba
WHERE a94 = 'CCOC_CARDS_CCA_060824_6'
AND a40 IN ('3','4','5')
0 recursive calls
81 db block gets
5020 consistent gets
3909 physical reads
0 redo size
401 bytes sent via SQL*Net to client
311 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed.
Once we increase the Buffer Cache Hit Ratio to 90% We got the following
0 recursive calls
81 db block gets
3717 consistent gets
3576 physical reads
0 redo size
401 bytes sent via SQL*Net to client
311 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed.
But can you please advice how to reduce the Physical Reads further.
Note: Table DOCTABA is a Snapshot that is present in Other Database.
Please advice!!
Cheers
Ramkannan.A

Buffer hit cache ratios are totally meaningless as was proven many years ago by Connor's brilliant little utility that allows you to dial in any ratio you want.
The reason your are getting FTEs is because your totally antiquated version of the product, never supported during the current century, is that it thinks FTEs cost less than using any indexes that may (or may not) exist. You've not established in your email that there are any indexes or posted DDL or provided much of anything else that would be helpful.
I would think moving from the Jurassic to 10.2.0.4, or above, would be your first priority.

Physical read & logical read

Hi
What is ment by Physical-Read and Logical-Read in oracle?Can anybody explain me clearly.
Aqueel.

Physical read, reading from the disk and logical reads mean reading it from the memory.
When a session(query) required information (data blocks), it will first look into the buffer cache (SGA), if it find the required data block, it will read it from the memory, i.e. logical reads, but, if it doesn't find required data block in the memory, then it read from the disk(datafile), physical read.
Generally, people motive to reduce physical read and read as much as possible from the memory, I was also int he same wrong impression until I came across a good paper by tuning expert Cary Milsap, 'why we should focus on LIO instead of PIO'. also, search http://asktom.oracle.com 'logical reads', there are good discussion on this point.
Jaffar

Query Tuning Help please

I ran the below query two times . first this query run within 4 minutes now it is running withing 20 minutes only . and how can I reduce the running time of this query.
my first table TABLE1 has partitioned day wise.
Total 14 partition in TABLE1 so if it runs for total 14 partitions it will take 14*20= 280 minutes.
Index created for TABLE1 and TABLE2
CREATE INDEX TABLE1_COL_A_INX ON TABLE1(COL_A);
CREATE INDEX TABLE1_COL_B_INX ON TABLE1(COL_B);
CREATE INDEX TABLE2_BNO_TYP_INX ON TABLE2(COL_B,RECORD_TYP);TABLE1 contain 3 billion records
TABLE2 contain 87 thousand records
INSERT INTO TARGET_TABLE
SELECT   t1.col_A,
                         t1.col_b,
                         t1.record_typ,
                         TO_date('14/06/2012','DD/MM/YYYY') ,
                         MIN( start_dt) AS First_Seen,
                         MAX( start_dt) AS Last_Seen
                FROM     TABLE1 t1,
                         TABLE2 t2
                WHERE    t1.start_dt = TO_date('14/06/2012','DD/MM/YYYY') - 12
                         AND t1.col_b = t2.col_b
                         AND t1.record_typ = t2.record_typ
                GROUP BY t1.col_a,t1.col_b,t1.record_typ,TO_date('14/06/2012','DD/MM/YYYY') ;Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for 64-bit Windows: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production
Explain plan with statistics
SQL>
117794 rows selected.
Execution Plan
Plan hash value: 1844245574
| Id | Operation                           | Name                    | Rows | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT                    |                         |   147K| 7362K|       |   615K (1)| 02:03:05 |       |       |
|   1 | HASH GROUP BY                      |                         |   147K| 7362K| 9320K|   615K (1)| 02:03:05 |       |       |
|   2 |   NESTED LOOPS                      |                         |       |       |       |         |             |       |       |
|   3 |    NESTED LOOPS                     |                         |   147K| 7362K|       |   613K (1)| 02:02:43 |       |       |
|   4 |     TABLE ACCESS FULL               | TABEL2                  | 87586 | 1282K|       |   137   (1)| 00:00:02 |       |       |
|   5 |     PARTITION RANGE SINGLE          |                         |     3 |       |       |     3   (0)| 00:00:01 |     4 |     4 |
|* 6 |      INDEX RANGE SCAN               | TABLE1_COL_B_INX        |     3 |       |       |     3   (0)| 00:00:01 |     4 |     4 |
|* 7 |    TABLE ACCESS BY LOCAL INDEX ROWID| TABLE1                  |     2 |    72 |       |     7   (0)| 00:00:01 |     4 |     4 |
Predicate Information (identified by operation id):
   6 - access("T1"."COL_B"="T2"."COL_B")
   7 - filter("T1"."START_DT"=TO_DATE(' 2012-06-02 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
              "T1"."RECORD_TYP"="T2"."RECORD_TYP")
Statistics
        105 recursive calls
          0 db block gets
     640720 consistent gets
     363307 physical reads
     635656 redo size
    3896682 bytes sent via SQL*Net to client
      86718 bytes received via SQL*Net from client
       7854 SQL*Net roundtrips to/from client
          2 sorts (memory)
          0 sorts (disk)
     117794 rows processed
SQL>TKPROF
SELECT   t1.COL_A,
                         t1.COL_B,
                         t1.record_typ,
                         TO_date('14/06/2012','DD/MM/YYYY') ,
                         MIN(start_dt) AS First_Seen,
                         MAX(start_dt) AS Last_Seen
                FROM     TABLE1 t1,
                         TABLE2 t2
                WHERE    t1.start_dt = TO_date('14/06/2012','DD/MM/YYYY') - 12
                         AND
                         t1.COL_B = t2.COL_B
                         AND t1.record_typ = t2.record_typ
                GROUP BY t1.col_a,t1.col_b,t1.record_typ,TO_date('14/06/2012','DD/MM/YYYY')
call     count       cpu    elapsed       disk      query    current        rows
Parse        0      0.00       0.00          0          0          0           0
Execute      0      0.00       0.00          0          0          0           0
Fetch     7853      0.15       0.28          0          0          0      117793
total     7853      0.15       0.28          0          0          0      117793
Misses in library cache during parse: 0
Parsing user id: 85 Which parameters or settings I want to check , because this query run before 4 minutes. now it takes 20 minutes... or in anyway I can rewrite this query using multiple staging table or something like that...

Hi,
1) you didn't trace the session correctly -- you probably switched tracing off before the session finished fetching all rows. Do it again, and this time end tracing by exiting the session (this way you make sure that the cursor is closed and plan stats are dumped to the trace file)
2) the plan seems to be sensible -- it costs you only 600k reads to retrieve 150k rows, that's good read-to-row ratio. You can improve it if you get read of TABLE ACCESS BY ROWID operation, but that would require creating an index on all the columns that the query needs (both in WHERE clause and in column projection) which looks like a big overhead (especially given that this is a table with 3 billion records)
3) autotrace stats seem to agree with the plan -- you're making 600k gets and half of them result in single-block disk reads. Assuming 5ms per read that's close to 20 min that you are getting. Of course, 50% buffer cache ratio is far from being perfect, and better caching is most likely the reason why the query was performing better in the past. Look at the the buffer hit ratio trend for the database -- perhaps some other activity is trashing the buffer cache, resulting in performance degradation of this query as well
Best regards,
Nikolay

Query on data dictionary results in large number of physical reads

I don't understand why I am getting 80,000 physicals for this query. I am not looking for help re-writing this. I just don't understand why I would hit the disk at all.
My understanding had been that v$views where sql structures that pointed to x$tables. These x$tables are sql structures.
underneath, the x$tables were linked lists stored in memory. This is why when you bounce the database, all the data, gets reset. Since it is not saved to disk.
I am doing a simple insert/select off of v$open_cursor that is resulting in 80,000+ physical reads. I am posting the tkprof. It is all from v$open_cursor.
mysid_table has 6 records. It is 1 mb in size
if I index mysid_table.sid the query reduces to 20,000 physical reads. (but all the physical reads are on v$session_event)
the sequence number I am passing returns 2 SIDs
insert into my_save_table
select *
from v$session_event
where sid in (select sid
from my_sid_table
where id = vseq);
vrowcount := sql%rowcount;
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.01       0.01          0          0          0           0
Execute      1     31.70      47.57      88570         22          0           1
Fetch        0      0.00       0.00          0          0          0           0
total        2     31.71      47.58      88570         22          0           1
Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: 22
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
latch: row cache objects                        1        0.00          0.00
log file sync                                   1        0.00          0.00
SQL*Net message to client                       1        0.00          0.00
SQL*Net message from client                     1        0.00          0.00
********************************************************************************

It seems like there is some missing information.
You have a wait for a log file sync, but no commit.
Your table my_sid_table is 1 MB for only 6 records?
Does the target table you are inserting into (my_save_table) have indexes on it?

Query Tuning (sequential read + direct path read/write temp)

Following query takes nearly 10 minutes under 10.2.0.2 on WIN2K3 to execute but I am sure there would be an alternate to tune it further.
Major waits are 'db file sequential read' and 'direct path read temp' in addition to 'direct path write temp'
Increasing/tuning the work_area_policy/sort_area_size would help? moving the tables to faster disk would reduce PIO causing sequential read, query re-writing would prove to be helpful?.
Below is the tkprof:
SELECT
P.PER_ID
, CL.DESCR
, P.ENG_NAME
, P.ARA_NAME
, P.NATION
, P.ADDR
, ('Mob:' || NVL(P.MOB, '') || ', Home:' || NVL(P.HOME, '') || ', Bus.:' || NVL(P.BUS, '') || ', Fax:' || NVL(P.FAX, '')) PHONE
, SUM(CASE
          WHEN FT.FT_TYPE_FLG IN ('BS','BX','AD','AX') THEN FT.CUR_AMT
        ELSE 0
        END) BILL
, SUM(CASE
          WHEN FT.FT_TYPE_FLG IN ('PS','PX') THEN FT.CUR_AMT * -1
        ELSE 0
        END) PAY
, SUM(FT.CUR_AMT) DUE
, SUM(CASE
          WHEN FT.FREEZE_DTTM > '03-JUN-08' THEN
              CASE WHEN FT.FT_TYPE_FLG IN ('PS','PX') THEN FT.CUR_AMT * -1
              ELSE 0
              END
        ELSE 0
        END) PAY_02JUN
FROM
CI_FT FT
, CI_SA SA
, CI_ACCT_CHAR AC
, CI_CUST_CL_L CL
, CI_ACCT A
, CI_ACCT_PER AP
      SELECT
        P.PER_ID
        , (P.CITY || ', ' || P.STATE || ',' || P.COUNTRY) ADDR
        , MAX(DECODE(PP.PHONE_TYPE_CD, 'MOB         ', PP.PHONE)) MOB
        , MAX(DECODE(PP.PHONE_TYPE_CD, 'BUSN        ', PP.PHONE)) BUS
        , MAX(DECODE(PP.PHONE_TYPE_CD, 'HOME        ', PP.PHONE)) HOME
        , MAX(DECODE(PP.PHONE_TYPE_CD, 'FAX         ', PP.PHONE)) FAX
        , MAX(DECODE(PN.NAME_TYPE_FLG, 'PRIM', PN.ENTITY_NAME)) ENG_NAME
        , MAX(DECODE(PN.NAME_TYPE_FLG, 'ALT ', PN.ENTITY_NAME)) ARA_NAME
        , MAX(DECODE(PC.CHAR_TYPE_CD, 'NATION ', PC.CHAR_VAL)) NATION
      FROM
        CI_PER P
        , CI_PER_PHONE PP
        , CI_PER_NAME PN
        , CI_PER_CHAR PC
      WHERE
        P.PER_ID = PP.PER_ID (+)
      AND P.PER_ID = PN.PER_ID (+)
      AND P.PER_ID = PC.PER_ID (+)
      GROUP BY
        P.PER_ID
        , (P.CITY || ', ' || P.STATE || ',' || P.COUNTRY)
    ) P
WHERE
P.PER_ID = AP.PER_ID
AND AP.ACCT_ID = AC.ACCT_ID
AND AP.ACCT_ID = SA.ACCT_ID
AND AP.MAIN_CUST_SW = 'Y'
AND A.ACCT_ID = SA.ACCT_ID
AND A.ACCT_ID = AP.ACCT_ID
AND AC.CHAR_TYPE_CD = 'ACCTYPE'
AND AC.CHAR_VAL IN ('UOS', 'DEFAULT')
AND AC.ACCT_ID = SA.ACCT_ID
AND CL.LANGUAGE_CD = 'ENG'
AND A.ACCT_ID = AC.ACCT_ID
AND A.CUST_CL_CD = CL.CUST_CL_CD
AND SA.SA_ID = FT.SA_ID
AND FT.FREEZE_DTTM IS NOT NULL
GROUP BY
P.PER_ID
, CL.DESCR
, P.ENG_NAME
, P.ARA_NAME
, P.NATION
, P.ADDR
, ('Mob:' || NVL(P.MOB, '') || ', Home:' || NVL(P.HOME, '') || ', Bus.:' || NVL(P.BUS, '') || ', Fax:' || NVL(P.FAX, ''))
HAVING
SUM(FT.CUR_AMT) > 0
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.64       0.64          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch      304    353.09     430.04      21720   52997832          0        4543
total      306    353.73     430.69      21720   52997832          0        4543
Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: 79 (CISADM)
Rows     Row Source Operation
   4543 FILTER (cr=52997832 pr=21720 pw=10311 time=430019418 us)
   5412   HASH GROUP BY (cr=52997832 pr=21720 pw=10311 time=430015729 us)
199471    VIEW (cr=52997832 pr=21720 pw=10311 time=423392346 us)
199471     HASH GROUP BY (cr=52997832 pr=21720 pw=10311 time=423192867 us)
4013304      TABLE ACCESS BY INDEX ROWID CI_FT (cr=52997832 pr=11409 pw=0 time=140469508 us)
17717785       NESTED LOOPS (cr=49295470 pr=8987 pw=0 time=407554071 us)
13704480        NESTED LOOPS (cr=21818135 pr=7655 pw=0 time=287797921 us)
2782119         NESTED LOOPS OUTER (cr=3915432 pr=2950 pw=0 time=38953485 us)
571492          NESTED LOOPS OUTER (cr=2545763 pr=2711 pw=0 time=7433194 us)
286061           NESTED LOOPS OUTER (cr=2253263 pr=2671 pw=0 time=26607373 us)
123411            NESTED LOOPS (cr=1989056 pr=2642 pw=0 time=22711194 us)
123411             NESTED LOOPS (cr=1864959 pr=2642 pw=0 time=20860026 us)
123411              NESTED LOOPS (cr=1494040 pr=1754 pw=0 time=15553373 us)
243088               NESTED LOOPS (cr=29540 pr=1754 pw=0 time=10213331 us)
13227                TABLE ACCESS FULL CI_PER (cr=251 pr=49 pw=0 time=43331 us)
243088                INDEX RANGE SCAN XM150S1 (cr=29289 pr=1705 pw=0 time=6178159 us)(object id 97173)
123411               INLIST ITERATOR (cr=1464500 pr=0 pw=0 time=7220251 us)
123411                INDEX RANGE SCAN CM064S0 (cr=1464500 pr=0 pw=0 time=5631936 us)(object id 108631)
123411              TABLE ACCESS BY INDEX ROWID CI_ACCT (cr=370919 pr=888 pw=0 time=7241286 us)
123411               INDEX UNIQUE SCAN XM148P0 (cr=247508 pr=0 pw=0 time=1198649 us)(object id 97147)
123411             TABLE ACCESS BY INDEX ROWID CI_CUST_CL_L (cr=124097 pr=0 pw=0 time=1391837 us)
123411              INDEX UNIQUE SCAN XC523P0 (cr=686 pr=0 pw=0 time=595005 us)(object id 97745)
283749            TABLE ACCESS BY INDEX ROWID CI_PER_PHONE (cr=264207 pr=29 pw=0 time=3549713 us)
283749             INDEX RANGE SCAN XM172P0 (cr=125886 pr=4 pw=0 time=1307395 us)(object id 98733)
571492           INDEX RANGE SCAN XM171S2 (cr=292500 pr=40 pw=0 time=2976807 us)(object id 98728)
2777066          TABLE ACCESS BY INDEX ROWID CI_PER_CHAR (cr=1369669 pr=239 pw=0 time=23084761 us)
2777066           INDEX RANGE SCAN XM168P0 (cr=596156 pr=53 pw=0 time=7394319 us)(object id 98719)
13704480         TABLE ACCESS BY INDEX ROWID CI_SA (cr=17902703 pr=4705 pw=0 time=163320548 us)
13704480          INDEX RANGE SCAN XM199S1 (cr=5688247 pr=104 pw=0 time=51063061 us)(object id 98973)
4013304        INDEX RANGE SCAN CM112S1 (cr=27477335 pr=1332 pw=0 time=124063022 us)(object id 116797)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
SQL*Net message to client                     304        0.00          0.00
db file sequential read                     11366        0.34         65.63
direct path write temp                       1473        0.06          2.91
latch: cache buffers chains                    17        0.00          0.00
db file scattered read                          7        0.01          0.03
read by other session                           2        0.00          0.00
direct path read temp                        1473        0.03          6.85
SQL*Net message from client                   304        0.02          2.74
SQL*Net more data to client                   292        0.00          0.00
********************************************************************************

Luckys
I've just realised that I mis-read part of your plan:
199471     HASH GROUP BY (cr=52997832 pr=21720 pw=10311 time=423192867 us)
4013304      TABLE ACCESS BY INDEX ROWID CI_FT (cr=52997832 pr=11409 pw=0 time=140469508 us)
17717785       NESTED LOOPS (cr=49295470 pr=8987 pw=0 time=407554071 us)The time component for a line is the time it supplies, plus the sum of the time from its direct descendents.
In this case I looked at the HASH GROUP BY and TABLE ACCESS and got a difference of about 283 seconds. In fact I should have taken more notice of the other lines in the plan - comparing the HASH GROUP BY with the NESTED LOOP for a difference of about 16 seconds and assuming that the time in the TABLE ACCESS line was not to be trusted. (See http://jonathanlewis.wordpress.com/2007/04/26/heisenberg/ for a couple of comments on the timing issue).
So the grouping is responsible for relatively little of the excess time - most of the time goes into the nested loop.
I shall be using the Hints as advised, when we say we
have to "rewrite the query"
given the current context excluding the HINTS, what
exactly should I be
considering in terms of query rewrite, what
additional intelligence I can add to the
query in question so that CBO produces a different
plan.
The main consideration is what the query is supposed to report. Compare this with the way the optimizer is running the query and see if it makes sense.
When are talking about high intermediate rows
processing are we referring to this
section of the plan?;
4013304      TABLE ACCESS BY INDEX ROWID CI_FT
(cr=52997832 pr=11409 pw=0 time=140469508 us)
17717785       NESTED LOOPS (cr=49295470 pr=8987
pw=0 time=407554071 us)
13704480        NESTED LOOPS (cr=21818135 pr=7655
pw=0 time=287797921 us)
2782119         NESTED LOOPS OUTER (cr=3915432
pr=2950 pw=0 time=38953485 us)
2777066          TABLE ACCESS BY INDEX ROWID
CI_PER_CHAR (cr=1369669 pr=239 pw=0 time=23084761
us)
2777066           INDEX RANGE SCAN XM168P0 (cr=596156
pr=53 pw=0 time=7394319 us)(object id 98719)
13704480         TABLE ACCESS BY INDEX ROWID CI_SA
(cr=17902703 pr=4705 pw=0 time=163320548 us)
13704480          INDEX RANGE SCAN XM199S1
(cr=5688247 pr=104 pw=0 time=51063061 us)(object id
98973)
4013304        INDEX RANGE SCAN CM112S1 (cr=27477335
pr=1332 pw=0 time=124063022 us)(object id 116797)
Correct - one of the nested loops returns 2.78M rows - but as you run the next join you end up collecting 13.7M entires from the next index and table. That step is responsible for quite a lot of your work and time (as is the following step where you USE the 13.7M rows to probe the next index/table combination). If the optimizer had not grown the data set by merging the P view earlier on, the data sizes would be significantly smaller at that point.
Your inline view looks as if it is trying to turn rows into columns (the max(decode()) trick) - which is why I think it might be a good idea to stop Oracle from merging the view. So, as I suggested, look at the query withouth that bit of complexity and work out a sensible way to walk through the tables - bearing in mind the statistics below and the available indexes, and the amount of data your predicates identify at each stage.
Moreover tables have been analyzed:
CI_ACCT                            243068
CI_ACCT_CHAR                       222320
CI_ACCT_PER                        242971
CI_FT                              794510
CI_PER                              13227
CI_PER_CHAR                         42555
CI_PER_PHONE                        18488
CI_SA                             1082301
Parameters:
optimizer_features_enable string 10.2.0.2
optimizer_index_caching integer 100
optimizer_index_cost_adj integer 1
Unless you've been given strict instructions by a 3rd-part supplier, those settings for the optimizer_index_caching and optimizer_index_cost_adj are particularly bad - especially in 10g. With those settings, the optimizer is quite likely to choose stupid plans with excessive use of indexes - and pick the wrong index while doing it.
It's not appropriate to fiddle with system parameters to address one query - but at some stage you need to rethink your entire set of parameter settings to do things the 10g way. See this note from the Optimizer Group: http://www.oracle.com/technology/products/bi/db/10g/pdf/twp_bidw_optimizer_10gr2_0208.pdf
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"The greatest enemy of knowledge is not ignorance,
it is the illusion of knowledge." Stephen Hawking.

How to reduce the query execution time

hai all,
We have created query on Purchasing Cube 0PUR_C01 for
                            Purchase Order (PO) analysis for single vendor materials, but it is taking long time to execute (about 45 sec...).
In the above Query we have used the following things:
In Columns:
i) Exceptional aggregation for maximum & minimum PO Net Price using reference characteristic as Calendar Day.
ii) Minimum PO Price value we have multiplied with Actual GR Quantity for the calculation of Impact of Lowest PO Net Price.
iii) Number of vendors calculated key figure.
In Rows:i)     Only Material
In Filters:
i)     Plant with variable select Option u2013 Optional.
ii)     Calendar Year / Month with Select Option u2013 Optional.
iii)     Material with excluded Unassigned (#).
iv)     Vendor with excluded Unassigned (#).
Following are we have used for Performance:
i)     Aggregates using Propose from query (only for this query).
ii)     Partitioning on Calendar Year / Month (For 1 year 14 partitions) i.e. (04.2007 to 03.2008).
iii)      Collapse.
iv)     In RSRT we have set the following properties
Read Mode = H
Req.Status = 0
Catch Mode = 4
Persistence Mode = 3 (BLOB)
Optimization mode = 0.
Our inputs to this Query:
i)     We are passing plant range 1201 to 1299.
ii)     Calendar Year / Month 04.2007 to 03.2008.
So please suggest me how to reduce the execution time.
please help me.
Thanks,
kiran manyam

Hi,
First of all its a complete question with all the details. Good work.
As you partitioned the cube based on calmonth and you are also giving calmonth in selection, it will definitely work towards improved query performance.
As you are putting plant values in the selection, is there any aggregate available on plant characteristics? If not creating a aggregate on plant will help.
Regards,
Yogesh

In a SQL query whihc has join, How to reduce Multiple instance of a table

in a SQL query which has join, How to reduce Multiple instance of a table
Here is an example: I am using Oracle 9i
is there a way to reduce no.of Person instances from the following query? or can I optimize this query further?
TABLES:
mail_table
mail_id, from_person_id, to_person_id, cc_person_id, subject, body
person_table
person_id, name, email
QUERY:
SELECT p_from.name from, p_to.name to, p_cc.name cc, subject
FROM mail, person p_from, person p_to, person p_cc
WHERE from_person_id = p_from.person_id
AND to_person_id = p_to.person_id
AND cc_person_id = p_cc.person_id
Thnanks in advance,
Babu.

SQL> select * from mail;
        ID          F          T         CC
         1          1          2          3
SQL> select * from person;
       PID NAME
         1 a
         2 b
         3 c
--Query with only ne Instance of PERSON Table
SQL> select m.id,max(decode(m.f,p.pid,p.name)) frm_name,
2         max(decode(m.t,p.pid,p.name)) to_name,
3         max(decode(m.cc,p.pid,p.name)) cc_name
4 from mail m,person p
5 where m.f = p.pid
6 or m.t = p.pid
7 or m.cc = p.pid
8 group by m.id;
        ID FRM_NAME   TO_NAME    CC_NAME
         1 a          b          c
--Expalin plan for "One instance" Query
SQL> explain plan for
2 select m.id,max(decode(m.f,p.pid,p.name)) frm_name,
3         max(decode(m.t,p.pid,p.name)) to_name,
4         max(decode(m.cc,p.pid,p.name)) cc_name
5 from mail m,person p
6 where m.f = p.pid
7 or m.t = p.pid
8 or m.cc = p.pid
9 group by m.id;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 902563036
| Id | Operation           | Name   | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT    |        |     3 |   216 |     7 (15)| 00:00:01 |
|   1 | HASH GROUP BY      |        |     3 |   216 |     7 (15)| 00:00:01 |
|   2 |   NESTED LOOPS      |        |     3 |   216 |     6   (0)| 00:00:01 |
|   3 |    TABLE ACCESS FULL| MAIL   |     1 |    52 |     3   (0)| 00:00:01 |
|* 4 |    TABLE ACCESS FULL| PERSON |     3 |    60 |     3   (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
   4 - filter("M"."F"="P"."PID" OR "M"."T"="P"."PID" OR
              "M"."CC"="P"."PID")
Note
   - dynamic sampling used for this statement
--Explain plan for "Normal" query
SQL> explain plan for
2 select m.id,pf.name fname,pt.name tname,pcc.name ccname
3 from mail m,person pf,person pt,person pcc
4 where m.f = pf.pid
5 and m.t = pt.pid
6 and m.cc = pcc.pid;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 4145845855
| Id | Operation            | Name   | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT     |        |     1 |   112 |    14 (15)| 00:00:01 |
|* 1 | HASH JOIN           |        |     1 |   112 |    14 (15)| 00:00:01 |
|* 2 |   HASH JOIN          |        |     1 |    92 |    10 (10)| 00:00:01 |
|* 3 |    HASH JOIN         |        |     1 |    72 |     7 (15)| 00:00:01 |
|   4 |     TABLE ACCESS FULL| MAIL   |     1 |    52 |     3   (0)| 00:00:01 |
|   5 |     TABLE ACCESS FULL| PERSON |     3 |    60 |     3   (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
|   6 |    TABLE ACCESS FULL | PERSON |     3 |    60 |     3   (0)| 00:00:01 |
|   7 |   TABLE ACCESS FULL | PERSON |     3 |    60 |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - access("M"."CC"="PCC"."PID")
   2 - access("M"."T"="PT"."PID")
   3 - access("M"."F"="PF"."PID")
PLAN_TABLE_OUTPUT
Note
   - dynamic sampling used for this statement
25 rows selected.
Message was edited by:
        jeneesh
No indexes created...

How to reduce logical count and scan count for a select query

hi,
I have two tables one is master and other is history. i need to combine this two tables into one temporary table.
I am using the below query to create temp table.
Select * into temporders
from
(select * from orders
union
select * from ordershistory) b
where updateon= (select max(updateon)from (select updateon,name,units,subunits from orders
union
select updateon,name,units,subunits from ordershistory) a
where updateon <='11/08/2008 11:18 AM' and a.name=b.name and a.units=b.units and a.subunits=b.subunits group by name,units,subunits)
order by report,subunitsorder
the statistics for this query:
SQL Server parse and compile time:
CPU time = 47 ms, elapsed time = 62 ms.
Table 'Worktable'. Scan count 556, logical reads 1569, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'ORDERSHISTORY'. Scan count 116, logical reads 339, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'ORDERS'. Scan count 116, logical reads 285, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SQL Server Execution Times:
CPU time = 32 ms, elapsed time = 63 ms.
(115 row(s) affected)
you see logical reads and scan count for worktable(temporary) is quite high.
So anyone can give a solution for reduce the scan count and logical reads.
NOTE: name,units, subunits,updateon columns have primarykey

SQL ServerAm i reading it properly? :(
This is Oracle Forum And not the SQL Server.
Regards.
Satyaki De.

How to reduce the query fetch from TKPROF output?

Hi,
Below is my query contains the TKPROF output.Here fetch is too high. How to reduce the fetch from here. And please check the explain plan is good or not?
SELECT czci.config_hdr_id,
        czci.config_rev_nbr,
        asoqla.quantity,
         (SELECT
                node_desc.LOCALIZED_STR
             FROM   CZ_LOCALIZED_TEXTS node_desc,
                    CZ_PS_NODES ps_nodes,
                    CZ_CONFIG_ITEMS czci1
            WHERE   czci1.config_hdr_id = asoqld.config_header_id
            AND     czci1.config_rev_nbr = asoqld.config_revision_num
            AND    node_desc.INTL_TEXT_ID = ps_nodes.INTL_TEXT_ID
            AND     NVL(node_desc.LANGUAGE,userenv('LANG')) = userenv('LANG')
            AND     czci1.PS_NODE_ID = ps_nodes.PERSISTENT_NODE_ID
             AND    ps_nodes.DEVL_PROJECT_ID = (SELECT MAX(DEVL_PROJECT_ID) FROM CZ_DEVL_PROJECTS WHERE NAME LIKE 'Control Model')
            AND czci1.PARENT_CONFIG_ITEM_ID IN (SELECT sub_sub.CONFIG_ITEM_ID FROM CZ_CONFIG_ITEMS sub_sub
                                                    WHERE sub_sub.CONFIG_HDR_ID = asoqld.config_header_id
                                                    AND sub_sub.CONFIG_REV_NBR = asoqld.config_revision_num
                                                    AND      sub_sub.PS_NODE_NAME = 'fittings')) fitting_material,
         (SELECT
                node_desc.LOCALIZED_STR
             FROM   CZ_LOCALIZED_TEXTS node_desc,
                    CZ_PS_NODES ps_nodes,
                    CZ_CONFIG_ITEMS czci
            WHERE   czci.config_hdr_id = asoqld.config_header_id
            AND     czci.config_rev_nbr = asoqld.config_revision_num
            AND    node_desc.INTL_TEXT_ID = ps_nodes.INTL_TEXT_ID
            AND NVL(node_desc.LANGUAGE,userenv('LANG')) = userenv('LANG')
            AND     czci.PS_NODE_ID = ps_nodes.PERSISTENT_NODE_ID
             AND    ps_nodes.DEVL_PROJECT_ID = (SELECT MAX(DEVL_PROJECT_ID) FROM CZ_DEVL_PROJECTS WHERE NAME LIKE 'Control Model')
            AND czci.PARENT_CONFIG_ITEM_ID IN (SELECT sub_sub.CONFIG_ITEM_ID FROM CZ_CONFIG_ITEMS sub_sub
                                                    WHERE sub_sub.CONFIG_HDR_ID = czci.CONFIG_HDR_ID
                                                    AND sub_sub.CONFIG_REV_NBR = czci.CONFIG_REV_NBR
                                                    AND      sub_sub.PS_NODE_NAME = 'tubing')) tubing_material
FROM    aso_quote_lines_all asoqla,
        aso_quote_line_details asoqld,
        cz_config_items czci
WHERE   asoqla.quote_header_id = 55774
AND     asoqla.item_type_code = 'MDL'
--AND     asoqla.org_id = 2763
AND     asoqla.quote_line_id = asoqld.quote_line_id
AND     asoqld.config_header_id = czci.config_hdr_id
AND     asoqld.config_revision_num = czci.config_rev_nbr
AND     czci.ps_node_name = 'CONTROL MASTER ASLY'
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.04       0.03          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        3      0.09       0.08          0       5100          0          19
total        5      0.13       0.12          0       5100          0          19
Misses in library cache during parse: 1
Optimizer goal: ALL_ROWS
Parsing user id: 173 (APPS)
Rows     Row Source Operation
      3 TABLE ACCESS BY INDEX ROWID CZ_LOCALIZED_TEXTS (cr=2161 pr=0 pw=0 time=32425 us)
     40   NESTED LOOPS (cr=2158 pr=0 pw=0 time=32276 us)
      3    NESTED LOOPS (cr=2147 pr=0 pw=0 time=32156 us)
      3     NESTED LOOPS (cr=925 pr=0 pw=0 time=15885 us)
      3      TABLE ACCESS BY INDEX ROWID CZ_CONFIG_ITEMS (cr=665 pr=0 pw=0 time=13456 us)
   5490       INDEX RANGE SCAN CZ_CONFIG_ITEMS_PK (cr=96 pr=0 pw=0 time=1237 us)(object id 3049621)
      3      TABLE ACCESS BY INDEX ROWID CZ_CONFIG_ITEMS (cr=260 pr=0 pw=0 time=2401 us)
   1094       INDEX RANGE SCAN CZ_CONFIG_ITEMS_PK (cr=19 pr=0 pw=0 time=250 us)(object id 3049621)
      3     TABLE ACCESS BY INDEX ROWID CZ_PS_NODES (cr=1222 pr=0 pw=0 time=16249 us)
      3      INDEX RANGE SCAN CZ_PS_NODES_N12 (cr=1219 pr=0 pw=0 time=16211 us)(object id 750095)
      1       SORT AGGREGATE (cr=1211 pr=0 pw=0 time=16125 us)
    209        TABLE ACCESS FULL CZ_DEVL_PROJECTS (cr=1211 pr=0 pw=0 time=15883 us)
     18    INDEX RANGE SCAN CZ_LOCALIZED_TEXTS_N1 (cr=11 pr=0 pw=0 time=68 us)(object id 31504)
      3 TABLE ACCESS BY INDEX ROWID CZ_LOCALIZED_TEXTS (cr=2161 pr=0 pw=0 time=31499 us)
     40   NESTED LOOPS (cr=2158 pr=0 pw=0 time=31351 us)
      3    NESTED LOOPS (cr=2147 pr=0 pw=0 time=31215 us)
      3     NESTED LOOPS (cr=925 pr=0 pw=0 time=15271 us)
      3      TABLE ACCESS BY INDEX ROWID CZ_CONFIG_ITEMS (cr=665 pr=0 pw=0 time=12441 us)
   5490       INDEX RANGE SCAN CZ_CONFIG_ITEMS_PK (cr=96 pr=0 pw=0 time=1230 us)(object id 3049621)
      3      TABLE ACCESS BY INDEX ROWID CZ_CONFIG_ITEMS (cr=260 pr=0 pw=0 time=2795 us)
   1094       INDEX RANGE SCAN CZ_CONFIG_ITEMS_PK (cr=19 pr=0 pw=0 time=264 us)(object id 3049621)
      3     TABLE ACCESS BY INDEX ROWID CZ_PS_NODES (cr=1222 pr=0 pw=0 time=15920 us)
      3      INDEX RANGE SCAN CZ_PS_NODES_N12 (cr=1219 pr=0 pw=0 time=15863 us)(object id 750095)
      1       SORT AGGREGATE (cr=1211 pr=0 pw=0 time=15753 us)
    209        TABLE ACCESS FULL CZ_DEVL_PROJECTS (cr=1211 pr=0 pw=0 time=15452 us)
     18    INDEX RANGE SCAN CZ_LOCALIZED_TEXTS_N1 (cr=11 pr=0 pw=0 time=79 us)(object id 31504)
     19 TABLE ACCESS BY INDEX ROWID CZ_CONFIG_ITEMS (cr=778 pr=0 pw=0 time=20571 us)
   5816   NESTED LOOPS (cr=202 pr=0 pw=0 time=8497 us)
     21    NESTED LOOPS (cr=96 pr=0 pw=0 time=2037 us)
     23     TABLE ACCESS BY INDEX ROWID ASO_QUOTE_LINES_ALL (cr=47 pr=0 pw=0 time=1427 us)
   1058      INDEX RANGE SCAN ASO_QUOTE_LINES_ALL_N1 (cr=9 pr=0 pw=0 time=51 us)(object id 81688)
     21     TABLE ACCESS BY INDEX ROWID ASO_QUOTE_LINE_DETAILS (cr=49 pr=0 pw=0 time=596 us)
     21      INDEX RANGE SCAN ASO_QUOTE_LINE_DETAILS_N1 (cr=28 pr=0 pw=0 time=323 us)(object id 81706)
   5794    INDEX RANGE SCAN CZ_CONFIG_ITEMS_PK (cr=106 pr=0 pw=0 time=1424 us)(object id 3049621)

Hi
After affed the exist operator i got below output. But it is more than that the previous one.
SELECT czci.config_hdr_id, czci.config_rev_nbr, asoqla.quantity,
       (SELECT node_desc.localized_str
          FROM cz_localized_texts node_desc,
               cz_ps_nodes ps_nodes,
               cz_config_items czci1
         WHERE czci1.config_hdr_id = asoqld.config_header_id
           AND czci1.config_rev_nbr = asoqld.config_revision_num
           AND node_desc.intl_text_id = ps_nodes.intl_text_id
           AND NVL (node_desc.LANGUAGE, USERENV ('LANG')) = USERENV ('LANG')
           AND czci1.ps_node_id = ps_nodes.persistent_node_id
           AND ps_nodes.devl_project_id = (SELECT MAX (devl_project_id)
                                             FROM cz_devl_projects
                                            WHERE NAME = 'Control Model')
           AND EXISTS (
                  SELECT NULL
                    FROM cz_config_items sub_sub
                   WHERE sub_sub.config_hdr_id = asoqld.config_header_id
                     AND sub_sub.config_rev_nbr = asoqld.config_revision_num
                     AND sub_sub.ps_node_name = 'fittings'
                     AND czci1.parent_config_item_id = sub_sub.config_item_id))
                                                             fitting_material,
       (SELECT node_desc.localized_str
          FROM cz_localized_texts node_desc,
               cz_ps_nodes ps_nodes,
               cz_config_items czci1
         WHERE czci1.config_hdr_id = asoqld.config_header_id
           AND czci1.config_rev_nbr = asoqld.config_revision_num
           AND node_desc.intl_text_id = ps_nodes.intl_text_id
           AND node_desc.LANGUAGE = USERENV ('LANG')
           AND czci1.ps_node_id = ps_nodes.persistent_node_id
           AND ps_nodes.devl_project_id = (SELECT MAX (devl_project_id)
                                             FROM cz_devl_projects
                                            WHERE NAME = 'Control Model')
           AND EXISTS (
                  SELECT NULL
                    FROM cz_config_items sub_sub
                   WHERE sub_sub.config_hdr_id = czci.config_hdr_id
                     AND sub_sub.config_rev_nbr = czci.config_rev_nbr
                     AND sub_sub.ps_node_name = 'tubing'
                     AND czci1.parent_config_item_id = sub_sub.config_item_id))
                                                              tubing_material
FROM aso_quote_lines_all asoqla,
       aso_quote_line_details asoqld,
       cz_config_items czci
WHERE asoqla.quote_header_id = 55774
   AND asoqla.item_type_code = 'MDL'
--AND     asoqla.org_id = 2763
   AND asoqla.quote_line_id = asoqld.quote_line_id
   AND asoqld.config_header_id = czci.config_hdr_id
   AND asoqld.config_revision_num = czci.config_rev_nbr
   AND czci.ps_node_name = 'CONTROL MASTER ASLY'
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.02       0.03          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        3      0.16       0.14          0      16526          0          19
total        5      0.18       0.17          0      16526          0          19
Misses in library cache during parse: 1
Optimizer goal: ALL_ROWS
Parsing user id: 173 (APPS)
Rows     Row Source Operation
      3 TABLE ACCESS BY INDEX ROWID CZ_LOCALIZED_TEXTS (cr=7874 pr=0 pw=0 time=51192 us)
     40   NESTED LOOPS (cr=7871 pr=0 pw=0 time=50953 us)
      3    NESTED LOOPS (cr=7860 pr=0 pw=0 time=50729 us)
      3     TABLE ACCESS BY INDEX ROWID CZ_CONFIG_ITEMS (cr=6638 pr=0 pw=0 time=33183 us)
      3      INDEX RANGE SCAN CZ_CONFIG_ITEMS_N1 (cr=6635 pr=0 pw=0 time=33060 us)(object id 31734)
      3       TABLE ACCESS BY INDEX ROWID CZ_CONFIG_ITEMS (cr=6536 pr=0 pw=0 time=22873 us)
   1292        INDEX UNIQUE SCAN CZ_CONFIG_ITEMS_PK (cr=5244 pr=0 pw=0 time=15326 us)(object id 3049621)
      3     TABLE ACCESS BY INDEX ROWID CZ_PS_NODES (cr=1222 pr=0 pw=0 time=17483 us)
      3      INDEX RANGE SCAN CZ_PS_NODES_N12 (cr=1219 pr=0 pw=0 time=17411 us)(object id 750095)
      1       SORT AGGREGATE (cr=1211 pr=0 pw=0 time=17266 us)
    209        TABLE ACCESS FULL CZ_DEVL_PROJECTS (cr=1211 pr=0 pw=0 time=16844 us)
     18    INDEX RANGE SCAN CZ_LOCALIZED_TEXTS_N1 (cr=11 pr=0 pw=0 time=122 us)(object id 31504)
      3 NESTED LOOPS (cr=7874 pr=0 pw=0 time=48203 us)
      3   NESTED LOOPS (cr=7860 pr=0 pw=0 time=47973 us)
      3    TABLE ACCESS BY INDEX ROWID CZ_CONFIG_ITEMS (cr=6638 pr=0 pw=0 time=30352 us)
      3     INDEX RANGE SCAN CZ_CONFIG_ITEMS_N1 (cr=6635 pr=0 pw=0 time=30218 us)(object id 31734)
      3      TABLE ACCESS BY INDEX ROWID CZ_CONFIG_ITEMS (cr=6536 pr=0 pw=0 time=20960 us)
   1292       INDEX UNIQUE SCAN CZ_CONFIG_ITEMS_PK (cr=5244 pr=0 pw=0 time=14224 us)(object id 3049621)
      3    TABLE ACCESS BY INDEX ROWID CZ_PS_NODES (cr=1222 pr=0 pw=0 time=17570 us)
      3     INDEX RANGE SCAN CZ_PS_NODES_N12 (cr=1219 pr=0 pw=0 time=17510 us)(object id 750095)
      1      SORT AGGREGATE (cr=1211 pr=0 pw=0 time=17395 us)
    209       TABLE ACCESS FULL CZ_DEVL_PROJECTS (cr=1211 pr=0 pw=0 time=16937 us)
      3   TABLE ACCESS BY INDEX ROWID CZ_LOCALIZED_TEXTS (cr=14 pr=0 pw=0 time=165 us)
      3    INDEX UNIQUE SCAN CZ_LOCALIZED_TEXTS_PK (cr=11 pr=0 pw=0 time=132 us)(object id 3050530)
     19 TABLE ACCESS BY INDEX ROWID CZ_CONFIG_ITEMS (cr=778 pr=0 pw=0 time=41677 us)
   5816   NESTED LOOPS (cr=202 pr=0 pw=0 time=16173 us)
     21    NESTED LOOPS (cr=96 pr=0 pw=0 time=3617 us)
     23     TABLE ACCESS BY INDEX ROWID ASO_QUOTE_LINES_ALL (cr=47 pr=0 pw=0 time=2528 us)
   1058      INDEX RANGE SCAN ASO_QUOTE_LINES_ALL_N1 (cr=9 pr=0 pw=0 time=83 us)(object id 81688)
     21     TABLE ACCESS BY INDEX ROWID ASO_QUOTE_LINE_DETAILS (cr=49 pr=0 pw=0 time=1053 us)
     21      INDEX RANGE SCAN ASO_QUOTE_LINE_DETAILS_N1 (cr=28 pr=0 pw=0 time=598 us)(object id 81706)
   5794    INDEX RANGE SCAN CZ_CONFIG_ITEMS_PK (cr=106 pr=0 pw=0 time=8245 us)(object id 3049621)

Corruption Parameters Increase High Physical Read for one query

Hi Oracle Experts,
Here is what I am currently facing in my non-prod environment:
We are testing out corruption parameters in non-prod environment and doing a perf test for them and we found that one SELECT query has seen significant decreases in performance; What I mean by that is after adding corruption parameters query is executing 40 sec compare to 18 sec and less. Also, this query is widely use by user in Prod environment, so performance degradation will create serious impact on their work.
I have generated AWR Diff for baseline and perf test following are parameter we have set for corruption test:
db_block_checking (Baseline) LOW (Perftest) MEDIUM
db_block_checksum (Baseline) TRUE (Perftest) FULL
Load Profile from AWR Diff are below:
Load Profile
1st Per Sec 2nd Per Sec %Diff 1st Per Txn 2nd Per Txn %Diff
Redo size: 758,356.06 752,760.94 -0.74 67,161.76 66,631.71 -0.79
Logical reads: 104,637.62 108,677.76 3.86 9,266.95 9,619.77 3.81
Block changes: 1,578.11 1,560.15 -1.14 139.76 139.76 0.00
Physical reads: 103.78 544.41 424.58 9.19 48.19 424.37
Physical writes: 108.94 107.13 -1.66 9.65 9.48 -1.76
User calls: 3,477.02 3,497.26 0.58 307.93 309.57 0.53
Parses: 948.36 949.61 0.13 83.99 84.06 0.08
Hard parses: 0.79 0.54 -31.65 0.07 0.05 -28.57
Sorts: 121.48 120.32 -0.95 10.76 10.65 -1.02
Logons: 0.36 0.27 -25.00 0.03 0.02 -33.33
Executes: 1,575.55 1,591.40 1.01 139.53 140.87 0.96
Transactions: 11.29 11.30 0.09
If we gather stats for tables involved in the query than it performs well in fact with in 5 Sec, but I believe in prod we can't gather state very often.
Questions:
1) How to remedy this situation and have query perform well along with corruption parameters?
2) Does corruption parameters have impact on SELECT query too, I believe it will have impact on INSERT and UPDATE.
3) Any reference to Doc will be highly appreciated.

1) How to remedy this situation and have query perform well along with corruption parameters?Use faster CPU. Checksum is a thing that needs to be computed.
2) Does corruption parameters have impact on SELECT query too, I believe it will have impact on INSERT and UPDATE.According to docs corruption parameters do not have impact on SELECT queries.
However, I believe, checksum has to be recomputed after delayed block cleanout that may be done by SELECT query after big update. ( http://jonathanlewis.wordpress.com/2009/06/16/clean-it-up/ )
3) Any reference to Doc will be highly appreciated.
Why is it difficult for you to find the docs yourself?

How can we send read mode for a query..?

How can we send read mode for a query..?
thanks in advance
regards

Hi Chaudhary.
I am not sure I understand your question correct?
Do you want to set a query to read only so it can not be changed? If so you should be controlling this with authorizations.
Hope it helps.
BR
Stefan

Query tuning help required:

I have a query which is taking long time. Is there any way I can improve the query to shorten its time of execution.
I have given below the details of it.
SQL> set pagesize 1000;
SQL> set linesize 170;
SQL> alter session set events '10046 trace name context forever, level 8';
Session altered.
Elapsed: 00:00:00.25
SQL> SELECT pa.regn_no,
2 (SELECT mst.status_desc
3 FROM m_status mst
4 WHERE mst.trans_id = 'PA01'
5 AND mst.status_code = pa.regn_status) AS regn_status,
6 (SELECT pp.NAME
7 FROM people_profile pp
8 WHERE pp.pp_id = pa.ident_no) AS NAME, pa.ident_no,
9 TO_CHAR (pa.approval_date, 'dd/mm/yyyy') AS approval_date,
10 TO_CHAR (pa.de_reg_date, 'dd/mm/yyyy') AS de_regist_date,
11 TO_CHAR (pa.cert_reg_exp_date, 'dd/mm/yyyy') AS cert_expiry_date,
12 pa.gender, pa.fax_no,
13 (SELECT nationality_desc
14 FROM people_profile pp, m_nationality
15 WHERE pp.pp_id = pa.ident_no
16 AND pp.nationality = nationality_code) AS nationality,
17 (SELECT pp.email_add
18 FROM people_profile pp
19 WHERE pp.pp_id = pa.ident_no) AS email_add,
20 (SELECT pp.mobile_no
21 FROM people_profile pp
22 WHERE pp.pp_id = pa.ident_no) AS mobile_no,
23 TO_CHAR ((SELECT pp.birth_date
24 FROM people_profile pp
25 WHERE pp.pp_id = pa.ident_no),
26 'dd/mm/yyyy'
27 ) AS birth_date,
28 REPLACE (sf_get_address_people (pa.ident_no, '2', 'C'),
29 ' ',
30 CHR (10)
31 ) AS address,
32 sf_get_pa_firm_info (pa.ident_no) AS firm_profile,
33 sf_get_pa_firm_partner (pa.ident_no) AS firm_partner,
34 sf_get_pa_pmp_code (pa.ident_no) AS pmp_code, ppv.pae_name,
35 ppv.pmp_code AS pmp_code_1, ppv.cycle_no, ppv.seq_no,
36 DECODE (ppv.visit_type,
37 'I', 'INITIAL',
38 'R', 'REVISIT',
39 ''
40 ) AS visit_type,
41 TO_CHAR (ppv.initial_ltr_date, 'dd/mm/yyyy') AS initial_ltr_date,
42 TO_CHAR (ppv.sec_ltr_date, 'dd/mm/yyyy') AS sec_ltr_date,
43 TO_CHAR (ppv.review_from, 'dd/mm/yyyy') AS review_from,
44 TO_CHAR (ppv.review_to, 'dd/mm/yyyy') AS review_to,
45 TO_CHAR (ppv.finding_date, 'dd/mm/yyyy') AS finding_date,
46 TO_CHAR (ppv.finding_due_date, 'dd/mm/yyyy') AS finding_due_date,
47 TO_CHAR (ppv.finding_reply_date,
48 'dd/mm/yyyy'
49 ) AS finding_reply_date,
50 ppv.pmsc,
51 TO_CHAR (ppv.clarif_ltr_date, 'dd/mm/yyyy') AS clarif_ltr_date,
52 ppv.paoc_date,
53 TO_CHAR (ppv.final_paoc_date, 'dd/mm/yyyy') AS final_paoc_date,
54 (SELECT result_desc
55 FROM m_pmp_result ms
56 WHERE result_id = ppv.pmp_status) AS pmp_status,
57 TO_CHAR (ppv.suspension_end_date,
58 'dd/mm/yyyy'
59 ) AS suspension_end_date,
60 TO_CHAR (ppv.final_ltr_date, 'dd/mm/yyyy') AS final_ltr_date,
61 ppv.findings_summary,
62 TO_CHAR (ppv.invoice_date, 'dd/mm/yyyy') AS invoice_date,
63 ppv.amount_billed,
64 TO_CHAR (ppv.payment_date, 'dd/mm/yyyy') AS payment_date,
65 DECODE (ppv.pay_icpas,
66 'Y', 'YES',
67 'N', 'NO',
68 'V', 'NA',
69 ''
70 ) AS pay_icpas,
71 ppv.updated_date, ppv.updated_by, ppv.remarks,
72 DECODE ((SELECT ppr.review_status
73 FROM pa_pmp_reviews ppr
74 WHERE ppr.regn_no = ppv.regn_no
75 AND ppr.cycle_no = ppv.cycle_no),
76 'P', 'In Progress',
77 'C', 'Closed',
78 ''
79 ) AS review_status,
80 pcl.complaint_no,
81 DECODE (pcl.complaint_status,
82 'P', 'Pending',
83 'C', 'Closed',
84 ''
85 ) AS complaint_status,
86 pcl.remarks AS remarks_1,
87 DECODE (pcl.complaint_outcome,
88 'C', 'Cancelled',
89 'R', 'Restriction of Practice',
90 'P', 'Penalty (Fine) - Disciplinary',
91 'E', 'Censure - Disciplinary',
92 'S', 'Suspended - Disciplinary',
93 ''
94 ) AS complaint_outcome,
95 TO_CHAR (pcl.complaint_date, 'dd/mm/yyyy') AS complaint_date,
96 pcl.complainant_nric, pcl.complainant_name, pcl.complaint_details,
97 TO_CHAR (pcl.effective_date, 'dd/mm/yyyy') AS effective_date,
98 TO_CHAR (pcl.effective_date_to,
99 'dd/mm/yyyy') AS effective_date_to,
100 sf_get_pa_exam_info (pa.regn_no, 'L') AS local_exam_detail,
101 sf_get_pa_exam_info (pa.regn_no, 'F') AS foreign_exam_detail,
102 sf_get_pa_exempt_info (pa.regn_no) AS exempt_detail
103 FROM pa_profile pa, pa_pmp_visits ppv, pa_complaint pcl
104 WHERE pa.regn_no = ppv.regn_no(+) AND pa.regn_no = pcl.regn_no(+)
105 ORDER BY pa.regn_no DESC;
1163 rows selected.
Elapsed: 00:02:08.87
Execution Plan
Plan hash value: 2912197266
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1109 | 330K| 17 (12)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID | M_STATUS | 1 | 23 | 2 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | PK_M_STATUS | 1 | | 1 (0)| 00:00:01 |
| 3 | TABLE ACCESS BY INDEX ROWID | PEOPLE_PROFILE | 1 | 25 | 3 (0)| 00:00:01 |
|* 4 | INDEX UNIQUE SCAN | SYS_C00103408 | 1 | | 2 (0)| 00:00:01 |
| 5 | NESTED LOOPS | | 1 | 26 | 4 (0)| 00:00:01 |
| 6 | TABLE ACCESS BY INDEX ROWID| PEOPLE_PROFILE | 1 | 12 | 3 (0)| 00:00:01 |
|* 7 | INDEX UNIQUE SCAN | SYS_C00103408 | 1 | | 2 (0)| 00:00:01 |
|* 8 | INDEX RANGE SCAN | PK_M_NATIONALITY | 1 | 14 | 1 (0)| 00:00:01 |
| 9 | TABLE ACCESS BY INDEX ROWID | PEOPLE_PROFILE | 1 | 20 | 3 (0)| 00:00:01 |
|* 10 | INDEX UNIQUE SCAN | SYS_C00103408 | 1 | | 2 (0)| 00:00:01 |
| 11 | TABLE ACCESS BY INDEX ROWID | PEOPLE_PROFILE | 1 | 11 | 3 (0)| 00:00:01 |
|* 12 | INDEX UNIQUE SCAN | SYS_C00103408 | 1 | | 2 (0)| 00:00:01 |
| 13 | TABLE ACCESS BY INDEX ROWID | PEOPLE_PROFILE | 1 | 10 | 3 (0)| 00:00:01 |
|* 14 | INDEX UNIQUE SCAN | SYS_C00103408 | 1 | | 2 (0)| 00:00:01 |
| 15 | TABLE ACCESS BY INDEX ROWID | M_PMP_RESULT | 1 | 37 | 1 (0)| 00:00:01 |
|* 16 | INDEX UNIQUE SCAN | XPK_M_PMP_RESULT | 1 | | 0 (0)| 00:00:01 |
| 17 | TABLE ACCESS BY INDEX ROWID | PA_PMP_REVIEWS | 1 | 8 | 1 (0)| 00:00:01 |
|* 18 | INDEX UNIQUE SCAN | SYS_C00103321 | 1 | | 0 (0)| 00:00:01 |
| 19 | SORT ORDER BY | | 1109 | 330K| 17 (12)| 00:00:01 |
|* 20 | HASH JOIN RIGHT OUTER | | 1109 | 330K| 16 (7)| 00:00:01 |
| 21 | TABLE ACCESS FULL | PA_COMPLAINT | 146 | 20294 | 3 (0)| 00:00:01 |
|* 22 | HASH JOIN RIGHT OUTER | | 1109 | 179K| 13 (8)| 00:00:01 |
| 23 | TABLE ACCESS FULL | PA_PMP_VISITS | 90 | 11340 | 3 (0)| 00:00:01 |
| 24 | TABLE ACCESS FULL | PA_PROFILE | 1109 | 44360 | 9 (0)| 00:00:01 |
Predicate Information (identified by operation id):
 2 - access("MST"."TRANS_ID"='PA01' AND "MST"."STATUS_CODE"=:B1)
 filter("MST"."STATUS_CODE"=:B1)
 4 - access("PP"."PP_ID"=:B1)
 7 - access("PP"."PP_ID"=:B1)
 8 - access("PP"."NATIONALITY"="NATIONALITY_CODE")
10 - access("PP"."PP_ID"=:B1)
12 - access("PP"."PP_ID"=:B1)
14 - access("PP"."PP_ID"=:B1)
16 - access("RESULT_ID"=:B1)
18 - access("PPR"."REGN_NO"=:B1 AND "PPR"."CYCLE_NO"=:B2)
20 - access("PA"."REGN_NO"="PCL"."REGN_NO"(+))
22 - access("PA"."REGN_NO"="PPV"."REGN_NO"(+))
Statistics
 17577 recursive calls
 0 db block gets
 8703644 consistent gets
 6138 physical reads
 0 redo size
 424453 bytes sent via SQL*Net to client
 3641 bytes received via SQL*Net from client
 13 SQL*Net roundtrips to/from client
 1 sorts (memory)
 0 sorts (disk)
 1163 rows processed
NAME TYPE VALUE
user_dump_dest string /opt/app/oracle/diag/rdbms/ebi
 zfile/EBIZFILE/trace
SQL> show parameter optimizer
NAME TYPE VALUE
optimizer_capture_sql_plan_baselines boolean FALSE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 11.2.0.1
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
optimizer_use_invisible_indexes boolean FALSE
optimizer_use_pending_statistics boolean FALSE
optimizer_use_sql_plan_baselines boolean TRUE
SQL> show parameter db_file_multi
NAME TYPE VALUE
db_file_multiblock_read_count integer 128
SQL> show parameter db_block_size
NAME TYPE VALUE
db_block_size integer 8192
SQL> show parameter cursor_sharing
NAME TYPE VALUE
cursor_sharing string EXACT
SQL>
SQL> column sname format a20
SQL> column pname format a20
SQL> column pval2 format a20
SQL>
SQL> select
2 sname, pname, pval1, pval2
3 from
4 sys.aux_stats$;
SNAME PNAME PVAL1 PVAL2
SYSSTATS_INFO STATUS COMPLETED
SYSSTATS_INFO DSTART 11-20-2009 09:46
SYSSTATS_INFO DSTOP 11-20-2009 09:46
SYSSTATS_INFO FLAGS 1
SYSSTATS_MAIN CPUSPEEDNW 1676.76768
SYSSTATS_MAIN IOSEEKTIM 10
SYSSTATS_MAIN IOTFRSPEED 4096
SYSSTATS_MAIN SREADTIM
SYSSTATS_MAIN MREADTIM
SYSSTATS_MAIN CPUSPEED
SYSSTATS_MAIN MBRC
SYSSTATS_MAIN MAXTHR
SYSSTATS_MAIN SLAVETHR

Hi,
obviously the problem you are having is described by the following lines of your execution plan
SORT ORDER BY | | 1109 | 330K| 17 (12)| 00:00:01 |
|* 20 | HASH JOIN RIGHT OUTER | | 1109 | 330K| 16 (7)| 00:00:01 |
| 21 | TABLE ACCESS FULL | PA_COMPLAINT | 146 | 20294 | 3 (0)| 00:00:01 |
|* 22 | HASH JOIN RIGHT OUTER | | 1109 | 179K| 13 (8)| 00:00:01 |
| 23 | TABLE ACCESS FULL | PA_PMP_VISITS | 90 | 11340 | 3 (0)| 00:00:01 |
| 24 | TABLE ACCESS FULL | PA_PROFILE | 1109 | 44360 | 9
You don't have a "real" "WHERE" condition in the query that could lead the Oracle CBO to consider using an index.
This leads to a full scan of PA_PMP_VISITS and PA_PROFILE and subsequently -in order to process the join condition between these two tables-
to this "HASH JOIN RIGHT OUTER". You cannot avoid this, with the current WHERE condition ...
Following thoughts :
1) Try narrowing down your result set by specifying a "real" WHERE Condition on one of the two tables, specifying an indexed column
2) If this cannot be done, try using query parallelism (parallel hint). This will give you acceptable SQL-execution times.
3) If this is not possible, there would be a third approach : You could consider the definition of an index on "pa.regn" and use a hint on your query in order to use it. Due to your order condition there is a possibility that CBO is going to use it, especially if you specify WHERE ROWNUM < ...
Regards,
Michalis

Query tuning-how to reduce physical reads-help me

Similar Messages

Maybe you are looking for