Consistent gets/physical reads issue
Dear all,
There are not any of DML on table tb_hxl_user.
First Select:
SQL> select count(1) from tb_hxl_user;
COUNT(1)
286435658
Elapsed: 00:04:03.67
Statistics
357 recursive calls
0 db block gets
2106478 consistent gets
2106316 physical reads
0 redo size
422 bytes sent via SQL*Net to client
416 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
6 sorts (memory)
0 sorts (disk)
1 rows processed Second Select:
SQL> select count(1) from tb_hxl_user;
COUNT(1)
286435658
Elapsed: 00:03:02.29
Statistics
0 recursive calls
0 db block gets
2106395 consistent gets
2106273 physical reads
0 redo size
422 bytes sent via SQL*Net to client
416 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed After the first,I know that all the blocks have been flushed to SGA,
but the second select,it generated many " 2106395 consistent gets" and " 2106273 physical reads" also,
why?
What exactly is consistent gets read below link:
http://jonathanlewis.wordpress.com/2009/06/12/consistent-gets-2/
Which is similar to docs clearity and authenticity.
What exactly is physical read read below link:
http://download.oracle.com/docs/cd/B16240_01/doc/doc.102/e16282/oracle_database_help/oracle_database_instance_throughput_physreads_ps.html
Regards
Girish Sharma
Similar Messages
-
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 -
No physical reads, plenty of consistant gets
Hi All,
Oracle v11.2 on Linux.
Please have a look at the query I ran and the output. The SQL_ID is of a SELECT command.
What does this situation represents, where there are zero physical reads and plenty of consistant gets ?
For consistant gets, we do read undo information (correct ??), if that undo is read from disk, will that be a "physical read"? i.e. if we read disks for consistant gets, will that be counted under physical reads or not ?
How can I describe the exact data retrival of the command here? Is it the case of "everything it needs is found in the buffer cache" ?
select a.sid, a.value , B.NAME , s.sql_id
from v$sesstat a, v$statname b, v$session s
where A.STATISTIC# = B.STATISTIC#
and b.name in ( 'redo size','physical read bytes','physical reads cache','consistent gets' )
and a.sid = s.sid
and a.sid=1018
order by a.sid;
SID VALUE NAME SQL_ID
1018 7281396 consistent gets 434u36htuz0s9
1018 0 physical reads cache 434u36htuz0s9
1018 0 physical read bytes 434u36htuz0s9
1018 4448 redo size 434u36htuz0s9
4 rows selected.Thanks in advance.>
There are no physical reads, so weather its doing consistant-gets or not, can I say, all data required for the SELECT was in buffer cache ?
>
The data for those system views is cached in memory so Oracle does not read the disk (except at startup) to gather the information.
Some static information, like dictionary objects, is stored stored on disk in the system tablespace but this data is read when the database is mounted and stored in memory structures.
Other dynamic information, like session info, is only stored in memory structures (similar to C arrays) and Oracle can query these as if they were tables.
So no, the data was not in the buffer cache. It was already in system memory. -
Oracle 9i Performance Issue High Physical Reads
Dear All,
I have Oracle 9i Release 9.2.0.5.0 database under HP Unix, I have run the query and got following output. Can any body just have a look and advise what to do in the following situation? We have performance issues.
Many thanks in advance
Buffer Pool Advisory for DB: DBPR Instance: DBPR End Snap: 902
-> Only rows with estimated physical reads >0 are displayed
Size for Size Buffers for Est Physical Estimated
P Estimate (M) Factr Estimate Read Factor Physical Reads
D 416 .1 51,610 4.27 1,185,670,652
D 832 .2 103,220 2.97 825,437,374
D 1,248 .3 154,830 2.03 563,139,985
D 1,664 .4 206,440 1.49 412,550,232
D 2,080 .5 258,050 1.32 366,745,510
D 2,496 .6 309,660 1.23 340,820,773
D 2,912 .7 361,270 1.14 317,544,771
D 3,328 .8 412,880 1.09 301,680,173
D 3,744 .9 464,490 1.04 288,191,418
D 4,096 1.0 508,160 1.00 276,929,627Hi,
Actually you didnt give the exact problem statement.
Seems to be your database is I/O bound. Ok, do the following one by one:
1. Identify the FTS queries and try to create the optimal indexes (depending on the disk reads factor!!) on the problem queries.
2. To reduce the 276M physical reads, you need to allocate more memory to db_cache_size. try 8GB (initially) and then depending on the buffer advisery you can increase further if you have more memory on the box.
3. as a Next step , configure KEEP and RECYCLE cache to get the benefits of reduced I/O by multiple pools. Allocate objects to the KEEP/RECYCLE pools.
Thanks, -
I get a message "The file "iTunes Library.itl" cannot be read because it was created by a newer version of iTunes." Please advise what I need to do to get around this issue - at the moment iTunes wont open up!
Hi did you ever get a solution to this problem? Having the same issue myself!
-
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 -
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 -
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 -
Query 1 shows less consistent gets but more cost than Query 2..
Hi ,
SQL> select dname from scott.dept where deptno not in (select deptno from scott.emp)
Ðñüãñáììá åêôÝëåóçò
Plan hash value: 3547749009
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 22 | 4 (0)| 00:00:01 |
|* 1 | FILTER | | | | | |
| 2 | TABLE ACCESS FULL| DEPT | 4 | 88 | 2 (0)| 00:00:01 |
|* 3 | TABLE ACCESS FULL| EMP | 11 | 143 | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter( NOT EXISTS (SELECT /*+ */ 0 FROM "SCOTT"."EMP" "EMP"
WHERE LNNVL("DEPTNO"<>:B1)))
3 - filter(LNNVL("DEPTNO"<>:B1))
Note
- dynamic sampling used for this statement
ÓôáôéóôéêÜ
0 recursive calls
0 db block gets
15 consistent gets
0 physical reads
0 redo size
416 bytes sent via SQL*Net to client
384 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL>
SQL> select dname from scott.dept,scott.emp where dept.deptno=emp.deptno(+)
2 and emp.rowid is null;
Ðñüãñáììá åêôÝëåóçò
Plan hash value: 2146709594
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 12 | 564 | 5 (20)| 00:00:01 |
|* 1 | FILTER | | | | | |
|* 2 | HASH JOIN OUTER | | 12 | 564 | 5 (20)| 00:00:01 |
| 3 | TABLE ACCESS FULL| DEPT | 4 | 88 | 2 (0)| 00:00:01 |
| 4 | TABLE ACCESS FULL| EMP | 12 | 300 | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter("EMP".ROWID IS NULL)
2 - access("DEPT"."DEPTNO"="EMP"."DEPTNO"(+))
Note
- dynamic sampling used for this statement
ÓôáôéóôéêÜ
0 recursive calls
0 db block gets
6 consistent gets
0 physical reads
0 redo size
416 bytes sent via SQL*Net to client
384 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processedI have two questions:
1) which one is preferable.... the first which is less costy to the system or the second which causes less consistent gets to the system and so is considered to be more scalable..????
2)Whereas the number of rows returned by both queries is 1.. why the is difference in the underlined values in the two queries (values 1 and 12 respectively)?
I use Oracle10g v.2
Thanks.. a lot
SimThe less logical I/O's the better.
So always do it like your query 2 (btw. your title is the wrong way)
Your example is probably flawed. If I try it in SQL*Plus I get correct results:
SQL> get t
1* select dname from dept where deptno not in (select deptno from emp)
SQL> /
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=6 Card=3 Bytes=39)
1 0 FILTER
2 1 TABLE ACCESS (FULL) OF 'DEPT' (TABLE) (Cost=2 Card=4 Bytes=52)
3 1 TABLE ACCESS (FULL) OF 'EMP' (TABLE) (Cost=2 Card=1 Bytes=3)
Statistics
0 recursive calls
0 db block gets
15 consistent gets
0 physical reads
0 redo size
537 bytes sent via SQL*Net to client
660 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL> get tt
1 select dname from dept,emp where dept.deptno=emp.deptno(+)
2* and emp.rowid is null
SQL> /
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=5 Card=14 Bytes=322)
1 0 FILTER
2 1 HASH JOIN (OUTER) (Cost=5 Card=14 Bytes=322)
3 2 TABLE ACCESS (FULL) OF 'DEPT' (TABLE) (Cost=2 Card=4 Bytes=52)
4 2 TABLE ACCESS (FULL) OF 'EMP' (TABLE) (Cost=2 Card=14 Bytes=140)
Statistics
0 recursive calls
0 db block gets
6 consistent gets
0 physical reads
0 redo size
537 bytes sent via SQL*Net to client
660 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL> I'm wondering for instance why you have there 11 rows in emp for query 1 (should be only 1 row) and why you have only 12 rows in query 2 (should be 14 rows) -
Reduce Logical IO [db block gets/consistent gets]
Hi,
Still I'm unsure about the Logical IO (db block gets + consistent gets).
I want to reduce 'consistent gets' for this query
SQL> set autotrace traceonly
SQL> select * from cm_per_phone_vw;
905 rows selected.
Execution Plan
Plan hash value: 524433310
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 868 | 38192 | 8 (0)| 00:00:01 |
| 1 | SORT GROUP BY NOSORT | | 868 | 38192 | 8 (0)| 00:00:01 |
| 2 | TABLE ACCESS BY INDEX ROWID| CI_PER_PHONE | 1238 | 54472 | 8 (0)| 00:00:01 |
| 3 | INDEX FULL SCAN | CM172C0 | 1238 | | 1 (0)| 00:00:01 |
Statistics
8 recursive calls
0 db block gets
922 consistent gets
4 physical reads
0 redo size
39151 bytes sent via SQL*Net to client
1045 bytes received via SQL*Net from client
62 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
905 rows processedFollowing is the view it's accessing
CREATE OR REPLACE VIEW CM_PER_PHONE_VW
AS
SELECT
per_id
, MAX(DECODE(TRIM(phone_type_cd), 'MOB', phone)) AS MOB
, MAX(DECODE(TRIM(phone_type_cd), 'HOME', phone)) AS HOME
, MAX(DECODE(TRIM(phone_type_cd), 'BUSN', TRIM(phone) || ' ' || TRIM(extension))) AS BUSN
, MAX(DECODE(TRIM(phone_type_cd), 'FAX', phone)) AS FAX
, MAX(DECODE(TRIM(phone_type_cd), 'INT', phone)) AS INT
FROM
ci_per_phone
GROUP BY
per_idI have following indexes on table ci_per_phone
INDEX_NAME COLUMN_NAME COLUMN_POSITION
XM172P0 PER_ID 1
XM172P0 SEQ_NUM 2
XM172S1 PHONE 1
CM172C0 PER_ID 1I tried creating indexes on PER_ID and PHONE_TYPE_CD but the consistent gets reduces to 920 instead of 922.
Just for curiosity, how can I reduce this?
secondly, is there any explanation on 'OPERATION' break of the plan, e.g. TABLE ACCESS BY INDEX ROWID ?
Please advice.
Luckys.Further I'm having problem with another query which is a view
CREATE OR REPLACE VIEW CM_PER_CHAR_VW
AS
SELECT
/*+ full (a) */
a.acct_id
, MAX(DECODE(a.char_type_cd, 'ACCTYPE', a.char_val)) acct_type
, MAX(DECODE(a.char_type_cd, 'PRVBLCYC', a.adhoc_char_val)) prev_bill_cyc
FROM
ci_acct_char a
WHERE
a.effdt =
(SELECT
MAX(a1.effdt)
FROM
ci_acct_char a1
WHERE a1.acct_id = a.acct_id
AND a1.char_type_cd = a.char_type_cd)
GROUP BY
a.acct_idI'm not able to reduce the consistent gets and even the filter appears.
I've analyzed the table as well as the index on the table.
cisadm@CCBDEV> select * from cm_acct_char_vw;
2649 rows selected.
Execution Plan
Plan hash value: 132362271
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 27 | 4536 | 14 (8)| 00:00:01 |
| 1 | HASH GROUP BY | | 27 | 4536 | 14 (8)| 00:00:01 |
| 2 | VIEW | | 27 | 4536 | 14 (8)| 00:00:01 |
|* 3 | FILTER | | | | | |
| 4 | HASH GROUP BY | | 27 | 2916 | 14 (8)| 00:00:01 |
| 5 | NESTED LOOPS | | 2686 | 283K| 13 (0)| 00:00:01 |
| 6 | TABLE ACCESS FULL| CI_ACCT_CHAR | 2686 | 157K| 12 (0)| 00:00:01 |
|* 7 | INDEX RANGE SCAN | XM064P0 | 1 | 48 | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - filter("A"."EFFDT"=MAX("A1"."EFFDT"))
7 - access("A1"."ACCT_ID"="A"."ACCT_ID" AND
"A1"."CHAR_TYPE_CD"="A"."CHAR_TYPE_CD")
Statistics
0 recursive calls
0 db block gets
2754 consistent gets
0 physical reads
0 redo size
76517 bytes sent via SQL*Net to client
2321 bytes received via SQL*Net from client
178 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
2649 rows processedhere's the tkprof
select *
from
cm_acct_char_vw
call count cpu elapsed disk query current rows
Parse 2 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 178 0.07 0.05 0 2754 0 2649
total 181 0.07 0.05 0 2754 0 2649
Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: 63 (CISADM)
Rows Execution Plan
0 SELECT STATEMENT MODE: CHOOSE
0 HASH (GROUP BY)
0 VIEW
0 FILTER
0 HASH (GROUP BY)
0 NESTED LOOPS
0 TABLE ACCESS MODE: ANALYZED (FULL) OF 'CI_ACCT_CHAR'
(TABLE)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF 'XM064P0'
(INDEX (UNIQUE))
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 179 0.00 0.00
SQL*Net message from client 179 0.00 0.08
********************************************************************************I've an similar query for another table, where there are 1110 rows, but in the explain, no filter appears in the predicate
Predicate Information (identified by operation id):
2 - access("P"."EFFDT"="VW_COL_1" AND "PER_ID"="P"."PER_ID" AND
"CHAR_TYPE_CD"="P"."CHAR_TYPE_CD")Both the queries have somewhat similar views.
I've got 2 questions,
Is there a way I can reduce the consistent gets( I've tried with/without HINTS),
secondly whats the predicate access shows as 'VW_COL_1'
please advice. -
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.ABuffer 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. -
Consistent gets are reduced but elapsed time is increased.
Hi All,
While tuning a application my consistent gets are reduced by 50% but the query is still taking the same time.
In a Warehouse env data is coming from With clause that is having some 40000 rows .Then these 40K rows are joined to a table that is having 2 Billion records having indexes on primary key and date column(bitmap)indexes .This forum is for issues with the SQL Developer tool. You'd get more response in the General Database forum.
Have fun,
K. -
Consistent gets are reduced by 50% but the query is still taking the same t
Hi ,
I am tuning a query in DWH env using a WITH clause .Doing that my consistent gets are reduced by 50% but the elapsed time in increased.
In that one 40000 rows are coming from WITH clause and joined with a table having 250000000 rows joined through Hash join.
can anybody help me out in this issue.
Thanx
NitinNitinMishra wrote:
Hi ,
I am tuning a query in DWH env using a WITH clause .Doing that my consistent gets are reduced by 50% but the elapsed time in increased.Unusual! Normally time goes, down when system resources do - but not always as you are seeing :(. Last time I saw something like this the reads had gone down but the CPU usage had gone up. You can get CPU usage from V$SQL.
Can you post the query, the execution plan, and statistics - both before and after the tuning? -
Physical query issued by Obiee when cache is on is different and slow
When the same report runs in OBIEE 10g and cache is OFF it takes less then 1min to get results. If cache is turned ON physical query issued by Obiee is totally different and it takes 2h to get results. Has anyone experienced this with having cache on that some queries are performing poorly.
Thanks,
TatjanaWe are using BI Apps Order Management and Fulfillment Analytics and all tables are cached anyway. Dimensions used are not that huge up to 40K rows. What should I check when it comes to DB query? As I said is different than one generated when cache is disabled although both have the almost the explain plan.
Maybe you are looking for
-
Problem in UWL Substitution Rules
Hi all, I have created a Substitution Rules for user X from user Y. when user X logins and accepts for user Y's rules but he is not able see the rule above his UWL. But when I create a rule for some other user U from user Y, user U is able to
-
Is it possible to change cabinet / exchange?
Hi all been waiting for infinity for what seems a long time. Cabinet number 12 denton burn exchange it's got power and cabled to the old box HOWEVER the spine Cable isn't in yet due to blockages. They were booked in according g to roadworks.org last
-
Is it possible Encrypt files in document library after uploading OOB
Is it possible Encrypt files in document library after uploading using OOB? if so please share how the above can be achieved. V Jean
-
Hello, I'm working to export maps from the old WCS 7.0.240.0 to Cisco Prime 2.0. Everything works fine, but from one map I receive an error. I cannot find what to do. Cisco has no workaround for it. Map Path Message
-
Can I download firefox for my Blackberr 9300?
The only options seems to be for Android phones and computers. I would like to downlaod Firefox,but it doesn't seem to feature for Blackberrys!