Top 10 SQL's by Physical reads
Dear experts,
Oracle version - 11.1.0.7
Do we have a way to pull top 10 SQL's (physical reads) for a 24 hour period based on AWR data or other V$ views.
Thanks
From DBA_HIST_SQLSTAT, all you can tell is who the parsing user was.
Not the executing user.
So for queries which are executed multiple times by multiple users, DBA_HIST_SQLSTAT is insufficient and there's no great solution.
You could have a look in the underlying ASH data - V$ACTIVE_SESSION_HISTORY and DBA_HIST_ACTIVE_SESS_HISTORY which is respectively sampled data and a sample of a sample and it might give an indication of who is executing.
Edited by: Dom Brooks on Jul 19, 2012 10:18 AM
Part of sentence was missing
Similar Messages
-
9582.69043 gigabytes of physical read total bytes and increasing!
In EM
Database Instance: PROD > Top Activity > I got following
physical read total bytes 62763565056 10289335500800 4183122176
cell physical IO interconnect bytes 62763565056 10289335500800 4183122176
physical read bytes 62763565056 10289335500800 4183122176
And the session is running following update procedure:
declare
FM_BBBB MT.BBBB_CODE%TYPE;
l_start NUMBER;
cursor code_upd is select /*+ parallel(FM_KWT_POP_BBBB_MISMATCH, 10) */ DDD_CID, DDD_BBBB, CCCC_BBBB from MT_MISMATCH;
begin
-- Time regular updates.
l_start := DBMS_UTILITY.get_time;
FOR rec IN code_upd LOOP
update /*+ parallel(MT, 10) nologging */ MT
set BBBB_code = rec.CCCC_BBBB
where source= 0
and cid_no = rec.DDD_CID
and BBBB_code = rec.DDD_BBBB;
commit;
END LOOP;
DBMS_OUTPUT.put_line('Bulk Updates : ' || (DBMS_UTILITY.get_time - l_start));
end;
There are 9.5 million records in MT but source=0 have only 3 million records and 376K records in MT_MISMATCH, What I don't understand why this is taking so much of time and so many bytes read? Both Tables are analyzed before running this procedure.
Can someone shed some light on this? Is there any better way of doing the same job?Nabeel Khan wrote:
In EM
Database Instance: PROD > Top Activity > I got following
physical read total bytes 62763565056 10289335500800 4183122176
cell physical IO interconnect bytes 62763565056 10289335500800 4183122176
physical read bytes 62763565056 10289335500800 4183122176
And the session is running following update procedure:
declare
FM_BBBB MT.BBBB_CODE%TYPE;
l_start NUMBER;
cursor code_upd is select /*+ parallel(FM_KWT_POP_BBBB_MISMATCH, 10) */ DDD_CID, DDD_BBBB, CCCC_BBBB from MT_MISMATCH;
begin
-- Time regular updates.
l_start := DBMS_UTILITY.get_time;
FOR rec IN code_upd LOOP
update /*+ parallel(MT, 10) nologging */ MT
set BBBB_code = rec.CCCC_BBBB
where source= 0
and cid_no = rec.DDD_CID
and BBBB_code = rec.DDD_BBBB;
commit;
END LOOP;
DBMS_OUTPUT.put_line('Bulk Updates : ' || (DBMS_UTILITY.get_time - l_start));
end;
There are 9.5 million records in MT but source=0 have only 3 million records and 376K records in MT_MISMATCH, What I don't understand why this is taking so much of time and so many bytes read? Both Tables are analyzed before running this procedure.
Can someone shed some light on this? Is there any better way of doing the same job?Lots of badness going on here.
1) looping / procedural code where none is needed.
2) commit within the loop, one of the worst evils of all in Oracle. Please read this
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:2680799800346456179
I'd look into rewriting this as a single SQL (maybe merge) statement. Or at worst .. a bulk process utilizing collections and FORALL's. -
Dear Experts,
I want to find out the query (sql id) that contributed to highest number of physical reads over a 24 hours period (snap id's 1 to 24) by a specific user - 'USER'
I'm using query as below, don't think it's giveing me right..any suggestions pls
select sql_id, PHYSICAL_READ_BYTES_DELTA from DBA_HIST_SQLSTAT
where PARSING_SCHEMA_NAME = 'USER' and snap_id between 1 and 24 order by PHYSICAL_READ_BYTES_DELTA;You can try this
select substr(sql_text,1,500) "SQL",
(cpu_time/1000000) "CPU_Seconds",
disk_reads "Disk_Reads",
buffer_gets "Buffer_Gets",
executions "Executions",
case when rows_processed = 0 then null
else round((buffer_gets/nvl(replace(rows_processed,0,1),1)))
end "Buffer_gets/rows_proc",
round((buffer_gets/nvl(replace(executions,0,1),1))) "Buffer_gets/executions",
(elapsed_time/1000000) "Elapsed_Seconds",
module "Module"
from v$sql s
order by disk_reads desc nulls lastYou can get this from the SQL DEveloper --reports-database administration-Topsql-diskreads -
Hi,
How can i find the top 10 sql queries which consuming high IO, CPU's. in oracle db.
I am doing in one way that by using TOP command trying to get PID's then i am getting the sql query by applying the hash value in v$sqlarea.
Is there any way to get directly high consumed IO and CPU's with out seeing PID's in TOP command.
Thanskhi,
try something along the lines of
select c.* from
(select disk_reads,
buffer_gets,
rows_processed,
executions,
first_load_time,
sql_text
from v$sqlarea
where parsing_user_id !=0
order by
buffer_gets/decode(executions,null,1,0,1,executions) desc ) c
where rownum < 11;
select c.* from
(select disk_reads,
buffer_gets,
rows_processed,
executions,
first_load_time,
sql_text
from v$sqlarea
order by
disk_reads/decode(rows_processed,null,1,0,1,rows_processed) desc ) c
where rownum <11;or even
--Top 10 by Buffer Gets:
set linesize 100
set pagesize 100
SELECT * FROM
(SELECT substr(sql_text,1,40) sql,
buffer_gets, executions, buffer_gets/executions "Gets/Exec",
hash_value,address
FROM V$SQLAREA
WHERE buffer_gets > 10000
ORDER BY buffer_gets DESC)
WHERE rownum <= 10
--Top 10 by Physical Reads:
set linesize 100
set pagesize 100
SELECT * FROM
(SELECT substr(sql_text,1,40) sql,
disk_reads, executions, disk_reads/executions "Reads/Exec",
hash_value,address
FROM V$SQLAREA
WHERE disk_reads > 1000
ORDER BY disk_reads DESC)
WHERE rownum <= 10
--Top 10 by Executions:
set linesize 100
set pagesize 100
SELECT * FROM
(SELECT substr(sql_text,1,40) sql,
executions, rows_processed, rows_processed/executions "Rows/Exec",
hash_value,address
FROM V$SQLAREA
WHERE executions > 100
ORDER BY executions DESC)
WHERE rownum <= 10
--Top 10 by Parse Calls:
set linesize 100
set pagesize 100
SELECT * FROM
(SELECT substr(sql_text,1,40) sql,
parse_calls, executions, hash_value,address
FROM V$SQLAREA
WHERE parse_calls > 1000
ORDER BY parse_calls DESC)
WHERE rownum <= 10
--Top 10 by Sharable Memory:
set linesize 100
set pagesize 100
SELECT * FROM
(SELECT substr(sql_text,1,40) sql,
sharable_mem, executions, hash_value,address
FROM V$SQLAREA
WHERE sharable_mem > 1048576
ORDER BY sharable_mem DESC)
WHERE rownum <= 10
--Top 10 by Version Count:
set linesize 100
set pagesize 100
SELECT * FROM
(SELECT substr(sql_text,1,40) sql,
version_count, executions, hash_value,address
FROM V$SQLAREA
WHERE version_count > 20
ORDER BY version_count DESC)
WHERE rownum <= 10
;you may have to play around with the column formatting a little to show the best results
regards
Alan
Edited by: alanm on Dec 22, 2008 4:01 PM -
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
AnandI 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 -
What causes BUFFER GETS and PHYSICAL READS in INSERT operation to be high?
Hi All,
Am performing a huge number of INSERTs to a newly installed Oracle XE 10.2.0.1.0 on Windows. There is no SELECT statement running, but just INSERTs one after the other of 550,000 in count. When I monitor the SESSION I/O from Home > Administration > Database Monitor > Sessions, I see the following stats:
BUFFER GETS = 1,550,560
CONSISTENT GETS = 512,036
PHYSICAL READS = 3,834
BLOCK CHANGES = 1,034,232
The presence of 2 stats confuses. Though the operation is just INSERT in database for this session, why should there be BUFFER GETS of this magnitude and why should there by PHYSICAL READS. Aren't these parameters for read operations? The BLOCK CHANGES value is clear as there are huge writes and the writes change these many blocks. Can any kind soul explain me what causes there parameters to show high value?
The total columns in the display table are as follows (from the link mentioned above)
1. Status
2. SID
3. Database Users
4. Command
5. Time
6. Block Gets
7. Consistent Gets
8. Physical Reads
9. Block Changes
10. Consistent Changes
What does CONSISTENT GETS and CONSISTENT CHANGES mean in a typical INSERT operation? And does someone know which all tables are involved in getting these values?
Thank,
...Flake wrote:
Hans, gracias.
The table just have 2 columns, both of which are varchar2 (500). No constraints, no indexes, neither foreign key references are in place. The total size of RAM in system is 1GB, and yes, there are other GUI's going on like Firefox browser, notepad and command terminals.
But, what does these other applications have to do with Oracle BUFFER GETS, PHYSICAL READS etc.? Awaiting your reply.Total RAM is 1GB. If you let XE decide how much RAM is to be allocated to buffers, on startup that needs to be shared with any/all other applications. Let's say that leaves us with, say 400M for the SGA + PGA.
PGA is used for internal stuff, such as sorting, which is also used in determing the layout of secondary facets such as indexes and uniqueness. Total PGA usage varies in size based on the number of connections and required operations.
And then there's the SGA. That needs to cover the space requirement for the data dictionary, any/all stored procedures and SQL statements being run, user security and so on. As well as the buffer blocks which represent the tablespace of the database. Since it is rare that the entire tablespace will fit into memory, stuff needs to be swapped in and out.
So - put too much space pressure on the poor operating system before starting the database, and the SGA may be squeezed. Put that space pressure on the system and you may enbd up with swapping or paging.
This is one of the reasons Oracle professionals will argue for dedicated machines to handle Oracle software. -
Consistent gets and physical reads
Hi all,
I am tuning a DM SQL query, by comparing execution plans with STAR TRANSFORMATION enabled or disabled. I got the following results:
STAR TRANSFORMATION ON
74889 consistent gets
254365 physical reads
STAR TRANSFORMATION OFF
1945892 consistent gets
168028 physical reads
I thought a physical read would be counted as a logical read as well, because the data block would be read from disk (1 physical IO), placed in the buffer cache and then read from there (1 more logical IO or consistent get).
So, one physical IO does not cause a logical IO?
Thanks!
Edited by: user10634835 on 12-Jul-2011 08:40But shouldn't consistent gets be >= physical reads (Since, as per my understanding, 1 PIO causes at least 1 LIO)? In this case it is not.
74889 consistent gets
254365 physical readsJust clarifying for my knowledge.
regards -
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? -
My top button stopped working, the physical button is broken.
My top button stopped working, the physical button is broken. Apple genius' stated they will not fix my phone because there are signs of moisture in my phone. What does that have to do with my broken button, and why can't my phone functioning the way it is supposed to due to an issue that is not my fault?
wow i dont know who you are getting your phone "fixed" through but its not apple.
Apple does not charge prices like that.
If you got it 1 year ago in september, the hardware warranty has expired by now unless you had your device covered by applecare insurance.
and if it WERE covered by limited hardware warranty, an obvious hardware issue like the power button not working is covered under the warranty UNLESS it was due to accidental damage.
So if you paid 198 dollars, chances are its because you dropped your phone and thats why the button was not working,.
..and even then, the iphone 4 out of warranty/accidental damage replacement fee is 149. not 198. -
High no. of physical reads of a query in statspack report
we have a Oracle database 9.2.0.6 on solaris box....
SQL ordered by Reads for DB: ic Instance: ic12 Snaps: 19 -20
-> End Disk Reads Threshold: 1000
CPU Elapsd
Physical Reads Executions Reads per Exec %Total Time (s) Time (s) Hash Value
1,103,253 77 14,328.0 53.1 1641.98 11428.17 3825541888
Module: w3wp.exe
select MRH_MRN,DECODE(MRH_SEX,'M','MALE','FEMALE') AS SEX, trim
((mrh_sur_name||' '||mrh_first_name||' '||mrh_middle_name)) as M
EMNAME, decode(nvl(mrh_fellow_status_yn,'333'),'Y','FCA','ACA')
AS ACA_FCA, DECODE(MRH_RESI_STATUS,'I',MRH_PROF_ADDR_LINE_1,'A',
MRH_RES_ADDR_LINE_1) AS L_ADD1, DECODE(MRH_RESI_STATUS,'I',MRH_Pexplain plan
SQL> explain plan for select MRH_MRN,DECODE(MRH_SEX,'M','MALE','FEMALE') AS SEX
, trim((mrh_sur_name||' '||mrh_first_name||' '||mrh_middle_name)) as MEMNAME, de
code(nvl(mrh_fellow_status_yn,'333'),'Y','FCA','ACA')AS ACA_FCA, DECODE(MRH_RESI
_STATUS,'I',MRH_PROF_ADDR_LINE_1,'A',
2 MRH_RES_ADDR_LINE_1) AS L_ADD1, DECODE(MRH_RESI_STATUS,'I',MRH_PROF_ADDR_LI
NE_2,'A',MRH_RES_ADDR_LINE_2) AS L_ADD2, DECODE(MRH_RESI_STATUS,'I',MRH_PROF_ADD
R_LINE_3,'A',MRH_RES_ADDR_LINE_3) ASL_ADD3, DECODE(MRH_RESI_STATUS,'I',MRH_PROF_
ADDR_LINE_4,'A',
3 MRH_RES_ADDR_LINE_4) AS L_ADD4, DECODE(MRH_RESI_STATUS,'I',a.city_name,'A',
C.CITY_NAME) AS L_CITY, DECODE(MRH_RESI_STATUS,'I',MRH_PROF_ZIP_POSTAL_CODE,'A',
MRH_RES_ZIP_POSTAL_CODE) AS L_PIN, DECODE(MRH_RESI_STATUS,'I',b.cou_name,'A',D.C
OU_NAME) as L_Country,
4 DECODE(MRH_RESI_STATUS,'I','NOT APPLICABLE',MRH_PROF_ADDR_LINE_1)AS R_ADD1,
DECODE(MRH_RESI_STATUS,'I',' ',MRH_PROF_ADDR_LINE_2)AS R_ADD2, DECODE(MRH_RESI_
STATUS,'I',' ',MRH_PROF_ADDR_LINE_3)
5 AS R_ADD3, DECODE(MRH_RESI_STATUS,'I',' ',MRH_PROF_ADDR_LINE_4)AS R_ADD4, D
ECODE(MRH_RESI_STATUS,'I',' ','A',A.CITY_NAME) AS R_CITY, DECODE(MRH_RESI_STATUS
,'I',' ','A',MRH_PROF_ZIP_POSTAL_CODE) AS R_PIN, DECODE(MRH_RESI_STATUS,'I',' ',
'A',B.COU_NAME) as
6 R_Country, decode(nvl(mrh_mem_sub_status,'555'),'26','EXPIRED','') as sub_s
tatus, decode(nvl(mrh_mem_status,'777'),'1','ACTIVE','2','REMOVED') as mem_statu
s,mrh_resi_status, DECODE(MRH_COP_STATUS,'1',DECODE(MRH_COP_TYPE ,'13','FULLTIME
-COP','1',
7 'FULLTIME-COP', '12','PARTTIME-COP','2','PARTTIME-COP'),'NOT HOLDING COP')
AS COP_STATUS, TO_CHAR(MRH_ENROL_DT,'RRRR') AS ASSO_YR,TO_CHAR(MRH_FELLOW_DT,'RR
RR') AS FELLOW_YR from om_mem_reg_head,om_city A,
8 om_country B,om_city C,om_country D where mrh_doc_status=5 and mrh_prof_
city_code=A.City_code(+) and mrh_prof_cou_code=B.cou_code(+) and mrh_res_city_c
ode=C.City_code(+) and mrh_res_cou_code=D.cou_code(+) and trim((mrh_sur_name||'
'||mrh_first_name||
9 ''||mrh_middle_name)) like upper('%%') ORDER BY trim((mrh_sur_name||' '||m
rh_first_name||' '||mrh_middle_name))
10 ;
Explained.
SQL> select * from table(dbms_xplan.displaY());
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost
|
| 0 | SELECT STATEMENT | | 2870 | 762K| | 202
PLAN_TABLE_OUTPUT
8 |
| 1 | SORT ORDER BY | | 2870 | 762K| 1592K| 202
8 |
| 2 | NESTED LOOPS OUTER | | 2870 | 762K| | 190
2 |
| 3 | NESTED LOOPS OUTER | | 2870 | 714K| | 190
2 |
PLAN_TABLE_OUTPUT
| 4 | HASH JOIN OUTER | | 2870 | 667K| | 190
2 |
| 5 | HASH JOIN OUTER | | 2870 | 616K| | 189
2 |
| 6 | TABLE ACCESS FULL| OM_MEM_REG_HEAD | 2870 | 566K| | 188
2 |
| 7 | TABLE ACCESS FULL| OM_COUNTRY | 677 | 12186 | |
4 |
PLAN_TABLE_OUTPUT
| 8 | TABLE ACCESS FULL | OM_COUNTRY | 677 | 12186 | |
4 |
| 9 | INDEX UNIQUE SCAN | CITY_CODE_PK | 1 | 17 | |
|
| 10 | INDEX UNIQUE SCAN | CITY_CODE_PK | 1 | 17 | |
|
PLAN_TABLE_OUTPUT
Note: cpu costing is off, PLAN_TABLE' is old version
18 rows selected.
SQL>Please suggest me whjat cab done to overcome the same
Edited by: user00726 on Feb 3, 2009 5:03 AMSQL> show arraysize
arraysize 15
SQL>should i set SDU parameter in tnsnames and listener.ora
for more info related to the same...pls do visit the below thread:
n/w perfromance related problem -
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
ajuHi,
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 -
I 'm running the same query against two databases on two different servers, and not seeing the expected results.
Query runs in 6 seconds on server A, and 32 seconds on server B. The database on B is a copy of the database on A, same blocksize, same db_file_multiblock_read_count.
Query is:
SELECT
IMS_BO_PMAN08.REF_ID,( sum(IMS_BO_PMAN08_TRAN.MONTH_13_APR) ) + ( sum(IMS_BO_PMAN08_TRAN.MONTH_14_MAY) ) ,
decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast'),
decode(IMS_BO_PMAN08_TRAN.TRANS_TYPE,'E','Expenditure','U','Unit completions','A','Allocation Takeup','S','SOS units','T','SOS Expenditure','G','Grant Claim Units','H','Larger Homes','C','FC Unit Completions','F','FC Expenditure','V','ACQ Expenditure')
FROM
IMS_BO_PMAN08,
IMS_BO_PMAN08_TRAN
WHERE
( IMS_BO_PMAN08.PROG_MAN_ID=IMS_BO_PMAN08_TRAN.PROG_MAN_ID )
AND ( IMS_BO_PMAN08.VERSION_ID IN (select version_id from ims_bo_version where version_id = 1 ) )
AND ( IMS_BO_PMAN08.INV_REGION_CODE > 2 )
and decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast') ='Actual'
GROUP BY
IMS_BO_PMAN08.REF_ID,decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast'),
decode(IMS_BO_PMAN08_TRAN.TRANS_TYPE,'E','Expenditure','U','Unit completions','A','Allocation Takeup','S','SOS units','T','SOS Expenditure','G','Grant Claim Units','H','Larger Homes','C','FC Unit Completions','F','FC Expenditure','V','ACQ Expenditure');
I am seeing the same execution plan when running the query against either database, with the same cost in each case. However, the physical reads on server B is ten times that of on server A
Server A
=====
293851 rows selected.
Elapsed: 00:00:06.58
Execution Plan
0 SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=50270 Card=27811 Bytes=973385)
1 0 SORT (GROUP BY) (Cost=50270 Card=27811 Bytes=973385)
2 1 HASH JOIN (Cost=50088 Card=27811 Bytes=973385)
3 2 TABLE ACCESS (BY INDEX ROWID) OF 'IMS_BO_PMAN08' (Cost=17990 Card=26243 Bytes=446131)
4 3 INDEX (RANGE SCAN) OF 'IMS_BO_PMAN08_IX1' (UNIQUE) (Cost=105 Card=26243)
5 2 NESTED LOOPS (Cost=32049 Card=107258 Bytes=1930644)
6 5 INDEX (UNIQUE SCAN) OF 'IMS_BO_VERSION_IX1' (UNIQUE)
7 5 TABLE ACCESS (FULL) OF 'IMS_BO_PMAN08_TRAN' (Cost=32048 Card=107258 Bytes=1716128)
Statistics
0 recursive calls
13 db block gets
288529 consistent gets
*18,218 physical reads*
0 redo size
17924295 bytes sent via SQL*Net to client
2174914 bytes received via SQL*Net from client
19592 SQL*Net roundtrips to/from client
0 sorts (memory)
1 sorts (disk)
293851 rows processed
Server B
=====
292677 rows selected.
Elapsed: 00:00:32.66
Execution Plan
0 SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=50255 Card=27805 Bytes=973175)
1 0 SORT (GROUP BY) (Cost=50255 Card=27805 Bytes=973175)
2 1 HASH JOIN (Cost=50073 Card=27805 Bytes=973175)
3 2 TABLE ACCESS (BY INDEX ROWID) OF 'IMS_BO_PMAN08' (Cost=17984 Card=26237 Bytes=446029)
4 3 INDEX (RANGE SCAN) OF 'IMS_BO_PMAN08_IX1' (UNIQUE) (Cost=105 Card=26237)
5 2 NESTED LOOPS (Cost=32040 Card=107230 Bytes=1930140)
6 5 INDEX (UNIQUE SCAN) OF 'IMS_BO_VERSION_IX1' (UNIQUE)
7 5 TABLE ACCESS (FULL) OF 'IMS_BO_PMAN08_TRAN' (Cost=32039 Card=107230 Bytes=1715680)
Statistics
0 recursive calls
357 db block gets
250918 consistent gets
*188,332 physical reads*
0 redo size
17853447 bytes sent via SQL*Net to client
2166145 bytes received via SQL*Net from client
19513 SQL*Net roundtrips to/from client
0 sorts (memory)
1 sorts (disk)
292677 rows processed
8.1.6.3 on solaris 8
Can anyone tell me where the excessive physical i/o's (and presumably associated runtime) is coming from? Any pointers much appreciated.
Pete
Edited by: user12248598 on 17-Mar-2010 09:01sort_area_size, sort_area_retained_size & hash_area_size are the same size for both instances, as are all NLS settings.
Tables are not specified NOCACHE, and there are no additional buffer pools.
Running with sql_trace enabled for both queries highlighed some very interesting results:
For the slow query, this is the tkprof output, unfortunately waits=yes is not available in 8.1.6
TKPROF: Release 8.1.6.3.0 - Production on Tue Mar 23 14:54:18 2010
(c) Copyright 1999 Oracle Corporation. All rights reserved.
Trace file: imsroc_ora_10166.trc
Sort options: default
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
alter session set events '10046 trace name context forever, level 8'
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 1 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer goal: FIRST_ROWS
Parsing user id: 5
BEGIN DBMS_APPLICATION_INFO.SET_MODULE(:1,NULL); END;
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.01 0.01 0 0 0 1
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.01 0.01 0 0 0 1
Misses in library cache during parse: 1
Optimizer goal: FIRST_ROWS
Parsing user id: 5
SELECT
IMS_BO_PMAN08.REF_ID,
( sum(IMS_BO_PMAN08_TRAN.MONTH_13_APR) ) + ( sum(IMS_BO_PMAN08_TRAN.MONTH_14_MAY) ) ,
decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast'),
decode(IMS_BO_PMAN08_TRAN.TRANS_TYPE,'E','Expenditure','U','Unit completions','A','Allocation Takeup
','S','SOS units','T','SOS Expenditure','G','Grant Claim Units','H','Larger Homes','C','FC Unit Comple
tions','F','FC Expenditure','V','ACQ Expenditure')
FROM
bo_ims.IMS_BO_PMAN08,
bo_ims.IMS_BO_PMAN08_TRAN
WHERE ( IMS_BO_PMAN08.PROG_MAN_ID=IMS_BO_PMAN08_TRAN.PROG_MAN_ID )
AND ( IMS_BO_PMAN08.VERSION_ID IN (select version_id from bo_ims.ims_bo_version where version_id =
1 ) )
AND ( IMS_BO_PMAN08.INV_REGION_CODE > 2 )
and decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast') = 'Actual'
GROUP BY
IMS_BO_PMAN08.REF_ID,
decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast'),
decode(IMS_BO_PMAN08_TRAN.TRANS_TYPE,'E','Expenditure','U','Unit completions','A','Allocation Takeup
','S','SOS units','T','SOS Expenditure','G','Grant Claim Units','H','Larger Homes','C','FC Unit Comple
tions','F','FC Expenditure','V','ACQ Expenditure')
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 16278 15.36 36.39 215625 251560 361 244156
total 16280 15.36 36.39 215625 251560 361 244156
Misses in library cache during parse: 0
Optimizer goal: FIRST_ROWS
Parsing user id: 5
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 2 0.00 0.00 0 0 0 0
Execute 3 0.01 0.01 0 0 0 1
Fetch 16278 15.36 36.39 215625 251560 361 244156
total 16283 15.37 36.40 215625 251560 361 244157
Misses in library cache during parse: 1
Misses in library cache during execute: 1
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
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 0 0.00 0.00 0 0 0 0
total 0 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
3 user SQL statements in session.
0 internal SQL statements in session.
3 SQL statements in session.
Trace file: imsroc_ora_10166.trc
Trace file compatibility: 8.00.04
Sort options: default
2 sessions in tracefile.
5 user SQL statements in trace file.
0 internal SQL statements in trace file.
3 SQL statements in trace file.
3 unique SQL statements in trace file.
75998 lines in trace file.And this is the tkprof formatted output for the faster running query:
TKPROF: Release 8.1.6.3.0 - Production on Tue Mar 23 14:56:28 2010
(c) Copyright 1999 Oracle Corporation. All rights reserved.
Trace file: imslive_ora_7489.trc
Sort options: default
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
alter session set events '10046 trace name context forever, level 8'
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 1 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer goal: FIRST_ROWS
Parsing user id: 5
SELECT
IMS_BO_PMAN08.REF_ID,
( sum(IMS_BO_PMAN08_TRAN.MONTH_13_APR) ) + ( sum(IMS_BO_PMAN08_TRAN.MONTH_14_MAY) ) ,
decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,:SYS_B_00,:SYS_B_01,:SYS_B_02,:SYS_B_03),
decode(IMS_BO_PMAN08_TRAN.TRANS_TYPE,:SYS_B_04,:SYS_B_05,:SYS_B_06,:SYS_B_07,:SYS_B_08,:SYS_B_09,:SYS_B_10,:
SYS_B_11,:SYS_B_12,:SYS_B_13,:SYS_B_14,:SYS_B_15,:SYS_B_16,:SYS_B_17,:SYS_B_18,:SYS_B_19,:SYS_B_20,:SYS_B_21,:
SYS_B_22,:SYS_B_23)
FROM
BO_IMS.IMS_BO_PMAN08,
BO_IMS.IMS_BO_PMAN08_TRAN
WHERE ( IMS_BO_PMAN08.PROG_MAN_ID=IMS_BO_PMAN08_TRAN.PROG_MAN_ID )
AND ( IMS_BO_PMAN08.VERSION_ID IN (select version_id from bo_ims.ims_bo_version where version_id = :SYS_B_
24 ) )
AND ( IMS_BO_PMAN08.INV_REGION_CODE > :SYS_B_25 )
and decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,:SYS_B_26,:SYS_B_27,:SYS_B_28,:SYS_B_29) = :SYS_B_30
GROUP BY
IMS_BO_PMAN08.REF_ID,
decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,:SYS_B_31,:SYS_B_32,:SYS_B_33,:SYS_B_34),
decode(IMS_BO_PMAN08_TRAN.TRANS_TYPE,:SYS_B_35,:SYS_B_36,:SYS_B_37,:SYS_B_38,:SYS_B_39,:SYS_B_40,:SYS_B_41,:
SYS_B_42,:SYS_B_43,:SYS_B_44,:SYS_B_45,:SYS_B_46,:SYS_B_47,:SYS_B_48,:SYS_B_49,:SYS_B_50,:SYS_B_51,:SYS_B_52,:
SYS_B_53,:SYS_B_54)
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 2 0.00 0.00 0 0 0 0
Fetch 20042 0.00 0.00 20064 295221 13 300608
total 20045 0.00 0.00 20064 295221 13 300608
Misses in library cache during parse: 1
Optimizer goal: FIRST_ROWS
Parsing user id: 5
Rows Row Source Operation
300608 SORT GROUP BY
300628 NESTED LOOPS
55647 NESTED LOOPS
2 INDEX UNIQUE SCAN (object id 151050)
55647 TABLE ACCESS BY INDEX ROWID IMS_BO_PMAN08
55649 INDEX RANGE SCAN (object id 185149)
300628 TABLE ACCESS BY INDEX ROWID IMS_BO_PMAN08_TRAN
356274 INDEX RANGE SCAN (object id 157241)
DELETE FROM PLAN_TABLE
WHERE
STATEMENT_ID=:1
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 3 5 12 0
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.00 0.00 3 5 12 0
Misses in library cache during parse: 1
Optimizer goal: FIRST_ROWS
Parsing user id: 5
Rows Row Source Operation
1 DELETE PLAN_TABLE
1 TABLE ACCESS FULL PLAN_TABLE
EXPLAIN PLAN SET STATEMENT_ID='PLUS18028884' FOR SELECT
IMS_BO_PMAN08.REF_ID,
( sum(IMS_BO_PMAN08_TRAN.MONTH_13_APR) ) + ( sum(IMS_BO_PMAN08_TRAN.MONTH_14_MAY) ) ,
decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast'),
decode(IMS_BO_PMAN08_TRAN.TRANS_TYPE,'E','Expenditure','U','Unit completions','A','Allocation Takeup','S','S
OS units','T','SOS Expenditure','G','Grant Claim Units','H','Larger Homes','C','FC Unit Completions','F','FC E
xpenditure','V','ACQ Expenditure')
FROM
BO_IMS.IMS_BO_PMAN08,
BO_IMS.IMS_BO_PMAN08_TRAN
WHERE ( IMS_BO_PMAN08.PROG_MAN_ID=IMS_BO_PMAN08_TRAN.PROG_MAN_ID )
AND ( IMS_BO_PMAN08.VERSION_ID IN (select version_id from bo_ims.ims_bo_version where version_id = 1 ) )
AND ( IMS_BO_PMAN08.INV_REGION_CODE > 2 )
and decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast') = 'Actual'
GROUP BY
IMS_BO_PMAN08.REF_ID,
decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast'),
decode(IMS_BO_PMAN08_TRAN.TRANS_TYPE,'E','Expenditure','U','Unit completions','A','Allocation Takeup','S','S
OS units','T','SOS Expenditure','G','Grant Claim Units','H','Larger Homes','C','FC Unit Completions','F','FC E
xpenditure','V','ACQ Expenditure')
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 1 0.00 0.00 0 0 0 0
Misses in library cache during parse: 1
Optimizer goal: FIRST_ROWS
Parsing user id: 5
insert into plan_table (statement_id, timestamp, operation, options,
object_node, object_owner, object_name, object_instance, object_type,
search_columns, id, parent_id, position, other,optimizer, cost, cardinality,
bytes, other_tag, partition_start, partition_stop, partition_id,
distribution )
values
(:1,SYSDATE,:2,:3,:4,:5,:6,:7,:8,:9,:10,:11,:12,:13,:14,:15,:16,:17,:18,:19,
:20,:21,:22)
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 7 0.00 0.00 1 3 9 7
Fetch 0 0.00 0.00 0 0 0 0
total 8 0.00 0.00 1 3 9 7
Misses in library cache during parse: 1
Optimizer goal: FIRST_ROWS
Parsing user id: 5 (recursive depth: 1)
select o.name, u.name
from
sys.obj$ o, sys.user$ u where obj# = :1and owner# = user#
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 2 0.00 0.00 0 0 0 0
Fetch 2 0.00 0.00 3 12 0 2
total 5 0.00 0.00 3 12 0 2
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: SYS (recursive depth: 1)
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 3 0.00 0.00 0 0 0 0
Execute 4 0.00 0.00 3 5 12 0
Fetch 20042 0.00 0.00 20064 295221 13 300608
total 20049 0.00 0.00 20067 295226 25 300608
Misses in library cache during parse: 3
Misses in library cache during execute: 1
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 2 0.00 0.00 0 0 0 0
Execute 9 0.00 0.00 1 3 9 7
Fetch 2 0.00 0.00 3 12 0 2
total 13 0.00 0.00 4 15 9 9
Misses in library cache during parse: 2
5 user SQL statements in session.
1 internal SQL statements in session.
6 SQL statements in session.
Trace file: imslive_ora_7489.trc
Trace file compatibility: 8.00.04
Sort options: default
3 sessions in tracefile.
8 user SQL statements in trace file.
1 internal SQL statements in trace file.
6 SQL statements in trace file.
6 unique SQL statements in trace file.
77410 lines in trace file.The sql statement as run did not make use of bind variables, so the ones in the tkprof output for the longer running statement made me immediately think of cursor sharing, and right there in the init.ora for the faster running database was CURSOR_SHARING=FORCE.
I'm not familiar with the history of the databases, nor the specific reasoning for enabling cursor sharing (bind variable usage seems prevalent in all custom code) so I've replicated the setting on the slower database, resulting in a similar tkprof output to the faster server, with a runtime of 7 seconds for 2nd and subsequent runs.
My immediate issue is now solved, thanks to all who contributed, and apologies for not spotting the obvious earlier.
Regards, Pete -
SQL*Loader-510: Physical record in data file (clob_table.ldr) is long
If I generate loader / Insert script from Raptor, it's not working for Clob columns.
I am getting error:
SQL*Loader-510: Physical record in data file (clob_table.ldr) is long
er than the maximum(1048576)
What's the solution?
Regards,Hi,
Has the file been somehow changed by copying it between windows and unix? Ora file transfer done as binary or ASCII? The most common cause of your problem. Is if the end of line carriage return characters have been changed so they are no longer /n/r could this have happened? Can you open the file in a good editor or do an od command in unix to see what is actually present?
Regards,
Harry
http://dbaharrison.blogspot.co.uk/ -
Urgt:How to identify TOP 5 SQL using more CPU time without using statspack
How to identify the TOP 5 SQL queries which are consuming more CPU time during the timespan of 24 hours for entire database. There are N number of users who have issued sql queries, out of which few users have disconnected and few user are still connected to the database(I need to consider all sessions). My database version is 9.0.1. I don't want to use statspack. Is there any way to identify TOP 5 SQL consuming more CPU time without affecting the performance of the database. Can any one help me on this? Its urgent!!. I don't want to use statspack becasue it degrades the performance and i cannot afford to run it for 24 hours.
You don't run statspack for 24 hours, that would infact be pointless...
Run statspack for say a 10 or 15 minute window during a particular "busy" period on your database. If you run it for longer then all the useful data will have been "averaged out". You want a snapshot in time, not an average over the day. -
How to identify TOP 5 SQL consuming more CPU time without using statspack
How to identify the TOP 5 SQL queries which are consuming more CPU time during the timespan of 24 hours for entire database. There are N number of users who have issued sql queries, out of which few users have disconnected and few user are still connected to the database(I need to consider all sessions). My database version is 9.0.1. I don't want to use statspack. Is there any way to identify TOP 5 SQL consuming more CPU time without affecting the performance of the database. Can any one help me on this? Its urgent!!.
My database version is 9.0.1. I don't want
to use statspack. Is there any way to identify TOP 5
SQL consuming more CPU time without affecting the
performance of the database. Can any one help me on
this? Its urgent!!.I cant understand why you dont want to use statspack. As it is very easy to use and very quick to identify bottlenecks. Try using statspack. Its really wonderful.
Particularly in your case statspack is the best.
Regards,
Sanju.
Maybe you are looking for
-
ISE 1.2.1 Complaining about High latency - can´t figure out why.
Hello! my 2 node (16 core, 32 GB Ram, SAN) ISE installation on VMWARE is, complaining about High latency. I have about 250 Test clients connected, and the VMWARE guys can´t seem to find anything wrong. Is there anyway to get a more detailed test WHA
-
JMS sender adapter issue for encrypted message
Hello Folks, We have JMS to AS2 interface facing issues when JMS sender channel read the encrypted files placed in MQ queue, messages size is increasing to almost double when it reaches PI. When sending an encrypted message from MQ to AS2, message is
-
Java 7.20 rev 1 (OSX): changes lost in ABAP EDITOR
Hi, since rev 1 of Java GUI 7.20 (Mac OS X 10.6.2) when editing text in abap editor (SE80, SE38) sometimes the entered text is lost. It happens often when applying "pretty printer" or checking syntax before saving the text. Is it a known bug or it's
-
I have a custom webapp where users can turn on /off blog posts via their tag name. This works fine, however how would I get the count of how many posts are associated with each tag? I'm using this syntax to display a list of tags in a side bar, but
-
Importing a Final Cut Pro7's XML into Premiere Pro CS6 - 2
Hello, im trying to import an xml exported from Final Cut Pro 7 into Premiere Pro CS6, but Premiere returns me an error message saying that the sequence cant be opened because the codec cant be accessed. The codec is Apple Prores 422 (HQ), and also a