Re: same sql: different db block gets in different oracle version
Tablescans in Oracle 8 start with 4 current gets (db block gets) on the segment header block - in Oracle 9 tablescans start with 2 consistent gets on the segment header. I can't tell you why you have 12 current gets rather than 4 - but if the tests aren't identical, the physical reads and extra current gets may be related to delayed cleanout on a first read. Regards Jonathan Lewis http://www.jlcomp.demon.co.uk Coming soon a new one-day tutorial: Cost Based Optimisation (see http://www.jlcomp.demon.co.uk/tutorial.html ) Next Seminar dates: (see http://www.jlcomp.demon.co.uk/seminar.html ) England__January 21/23 USA_(CA, TX)_August The Co-operative Oracle Users' FAQ http://www.jlcomp.demon.co.uk/faq/ind_faq.html -Original Message- To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Date: 22 January 2003 07:42 Hi, dba friends: Look at the following test result, the first one is from oracle9.2, and the second is from the oracle 817. The table is same, and as you see, the execution path is the same. But there is difference in statistics: db_block_gets, in oracle92, it is 0, and in oracle817, it is not. And i noticed that in oracle8i, all sql that does only query with execution path full scan of table/index,there will always be db_block_gets, while in 9i, select won't make db_block_gets. As tom said, db_block_gets is increased when data is accessed for update, how does this query generate this statistics? ORA92 select count(*) from abc; COUNT(*) -- 1 Execution Plan -- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=6 Card=1) 1 0 SORT (AGGREGATE) 2 1 TABLE ACCESS (FULL) OF 'ABC' (Cost=6 Card=1) Statistics -- 0 recursive calls 0 db block gets 27 consistent gets 0 physical reads 0 redo size 379 bytes sent via SQL*Net to client 503 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed ORA817 select count(*) from abc; COUNT(*) -- 1 Elapsed: 00:00:00.26 Execution Plan -- 0 SELECT STATEMENT Optimizer=CHOOSE 1 0 SORT (AGGREGATE) 2 1 TABLE ACCESS (FULL) OF 'ABC' Statistics -- 0 recursive calls 12 db block gets 28 consistent gets 24 physical reads 0 redo size 367 bytes sent via SQL*Net to client 425 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed Regards zhu chao msn:[EMAIL PROTECTED] www.happyit.net www.cnoug.org(China Oracle User Group) -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jonathan Lewis INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: same sql: different db block gets in different oracle version
Check your setting parameter for db_block_gets and compare between oracle9.2 and oracle817. Is it equivalent setting parameter ? -Original Message- From: chao_ping [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 1:54 PM To: Multiple recipients of list ORACLE-L Subject: same sql: different db block gets in different oracle version Hi, dba friends: Look at the following test result, the first one is from oracle9.2, and the second is from the oracle 817. The table is same, and as you see, the execution path is the same. But there is difference in statistics: db_block_gets, in oracle92, it is 0, and in oracle817, it is not. And i noticed that in oracle8i, all sql that does only query with execution path full scan of table/index,there will always be db_block_gets, while in 9i, select won't make db_block_gets. As tom said, db_block_gets is increased when data is accessed for update, how does this query generate this statistics? ORA92 select count(*) from abc; COUNT(*) -- 1 Execution Plan -- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=6 Card=1) 1 0 SORT (AGGREGATE) 2 1 TABLE ACCESS (FULL) OF 'ABC' (Cost=6 Card=1) Statistics -- 0 recursive calls 0 db block gets 27 consistent gets 0 physical reads 0 redo size 379 bytes sent via SQL*Net to client 503 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed ORA817 select count(*) from abc; COUNT(*) -- 1 Elapsed: 00:00:00.26 Execution Plan -- 0 SELECT STATEMENT Optimizer=CHOOSE 1 0 SORT (AGGREGATE) 2 1 TABLE ACCESS (FULL) OF 'ABC' Statistics -- 0 recursive calls 12 db block gets 28 consistent gets 24 physical reads 0 redo size 367 bytes sent via SQL*Net to client 425 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed Regards zhu chao msn:[EMAIL PROTECTED] www.happyit.net www.cnoug.org(China Oracle User Group) -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: chao_ping INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Sony kristanto INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: Re: same sql: different db block gets in different oracle version
Jonathan Lewis, Thanks very much for your reply. Yes, in oracle 8i on sun solaris, the db block gets of fulltable scan is always 4block, no matter what the size of the table is. But in my tests in linux/817, it always show 12(8170 and 8172).I run the full scan again and again, but the value does not change. And another problem is why in oracle9i, there is no db_block_gets when doing full segment scan.I checked asktom.oracle.com, but unable to find the answer. And i also tested 9.0.1 on sun solaris , when very small, db_block_gets is 6,while larger tables(12K records from dba_tables), db_block_gets is 12. Scanning the segment header caused the current mode read,is it because of scanning the buffer pool head and getting the cache buffer chains latch in exclusive mode,and the buffer head will be moved the other end lru list? why scanning the other data block does not cause the current read? Sorry, I asked to much, and maybe they are meanless, but if possible, I still want to know. Sony kristanto, what kind of parameters do you think will affect the db_block_gets? I will post them. Thanks. Regards zhu chao msn:[EMAIL PROTECTED] www.happyit.net www.cnoug.org(China Oracle User Group) === 2003-01-22 00:33:00 ,you wrote£º=== Tablescans in Oracle 8 start with 4 current gets (db block gets) on the segment header block - in Oracle 9 tablescans start with 2 consistent gets on the segment header. I can't tell you why you have 12 current gets rather than 4 - but if the tests aren't identical, the physical reads and extra current gets may be related to delayed cleanout on a first read. Regards Jonathan Lewis http://www.jlcomp.demon.co.uk Coming soon a new one-day tutorial: Cost Based Optimisation (see http://www.jlcomp.demon.co.uk/tutorial.html ) Next Seminar dates: (see http://www.jlcomp.demon.co.uk/seminar.html ) England__January 21/23 USA_(CA, TX)_August The Co-operative Oracle Users' FAQ http://www.jlcomp.demon.co.uk/faq/ind_faq.html -Original Message- To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Date: 22 January 2003 07:42 -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: chao_ping INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: same sql: different db block gets in different oracle version
Cho, This is not unusual. I suspect your db_cache_size (or db_block_buffers) in 9.2 is more than db_block_buffers in 8.1. When you do a FTS, all the blocks are loaded into the buffers first time so 'db block gets' is a non zero value (it's the physical IO). The next time you do this, the blocks are found in the buffer already, so there is no physical IO, hence a zero value for 'db block gets'. However, your logical reads (consistent gets) should be the same and they are the same. In 817, run the query once again and see the 'db block gets' , it should be 0. If not then check if db_block_buffers is less than db_cache_size (or db_block_buffers) in 9.2. HTH. Arup - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Wednesday, January 22, 2003 1:53 AM Hi, dba friends: Look at the following test result, the first one is from oracle9.2, and the second is from the oracle 817. The table is same, and as you see, the execution path is the same. But there is difference in statistics: db_block_gets, in oracle92, it is 0, and in oracle817, it is not. And i noticed that in oracle8i, all sql that does only query with execution path full scan of table/index,there will always be db_block_gets, while in 9i, select won't make db_block_gets. As tom said, db_block_gets is increased when data is accessed for update, how does this query generate this statistics? ORA92 select count(*) from abc; COUNT(*) -- 1 Execution Plan -- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=6 Card=1) 1 0 SORT (AGGREGATE) 2 1 TABLE ACCESS (FULL) OF 'ABC' (Cost=6 Card=1) Statistics -- 0 recursive calls 0 db block gets 27 consistent gets 0 physical reads 0 redo size 379 bytes sent via SQL*Net to client 503 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed ORA817 select count(*) from abc; COUNT(*) -- 1 Elapsed: 00:00:00.26 Execution Plan -- 0 SELECT STATEMENT Optimizer=CHOOSE 1 0 SORT (AGGREGATE) 2 1 TABLE ACCESS (FULL) OF 'ABC' Statistics -- 0 recursive calls 12 db block gets 28 consistent gets 24 physical reads 0 redo size 367 bytes sent via SQL*Net to client 425 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed Regards zhu chao msn:[EMAIL PROTECTED] www.happyit.net www.cnoug.org(China Oracle User Group) -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: chao_ping INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Arup Nanda INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: Re: same sql: different db block gets in different oracle version
One reason for seeing more db_block_gets than you expect on a full segment scan is that every extent map block (of which the segment header block is just one) is accessed differently. If you have small extents and large objects, you may have overshoot the maximum extents allowed in the segment header block - so the 12 db_block_gets could indicate 2 extra map blocks. NOTE - Oracle 9 simply does not do 4 CU gets on map blocks. 8.14 CU gets per map block 9.22 CR gets per map block 9.02 gets, but can't remember if they are CU or CR Also - bigger tables = more map blocks may have been used Regards Jonathan Lewis http://www.jlcomp.demon.co.uk Coming soon a new one-day tutorial: Cost Based Optimisation (see http://www.jlcomp.demon.co.uk/tutorial.html ) Next Seminar dates: (see http://www.jlcomp.demon.co.uk/seminar.html ) England__January 21/23 USA_(CA, TX)_August The Co-operative Oracle Users' FAQ http://www.jlcomp.demon.co.uk/faq/ind_faq.html -Original Message- To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Date: 22 January 2003 15:47 version Jonathan Lewis, Thanks very much for your reply. Yes, in oracle 8i on sun solaris, the db block gets of fulltable scan is always 4block, no matter what the size of the table is. But in my tests in linux/817, it always show 12(8170 and 8172).I run the full scan again and again, but the value does not change. And another problem is why in oracle9i, there is no db_block_gets when doing full segment scan.I checked asktom.oracle.com, but unable to find the answer. And i also tested 9.0.1 on sun solaris , when very small, db_block_gets is 6,while larger tables(12K records from dba_tables), db_block_gets is 12. Scanning the segment header caused the current mode read,is it because of scanning the buffer pool head and getting the cache buffer chains latch in exclusive mode,and the buffer head will be moved the other end lru list? why scanning the other data block does not cause the current read? Sorry, I asked to much, and maybe they are meanless, but if possible, I still want to know. Sony kristanto, what kind of parameters do you think will affect the db_block_gets? I will post them. Thanks. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jonathan Lewis INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
