Naveen,
A CU block is fetched "as-is"; whatever's in the block at the time of
the read is what comes back from the LIO. CU mode is used when read
consistency is not an issue; for example, when reading your own
(private) sort blocks. I think if you DELETE without a WHERE clause,
you'll see CU blocks (not sure).
Reading in CR mode includes potentially more codepath that can
reconstruct the block as of a specified point in history. It's how the
Oracle kernel does read consistency. The mechanism includes checking the
ITL in the header of the block being read to understand whether the
version of the block is appropriate for the SCN of the query requesting
the block. It goes kind of like this:
while SCN of block is newer than SCN of query {
clone (i.e., copy) the block in the buffer cache;
LIO the undo block referenced by the most recent ITL entry (i.e., LIO
a rollback segment in CR mode);
apply the undo to the block (resulting in a new, older SCN for the
block);
}
I've never known whether the maximum number of clone operations per CR
read is the number of undo applications, or maybe it's just 1. The
algorithm might actually be this:
if SCN of block is newer than SCN of query then clone the block;
while SCN of block is newer than SCN of query {
LIO the undo block referenced by the most recent ITL entry;
Apply the undo to the block;
}
Jonathan Lewis was once on the trail of figuring this out, but I'm not
sure he ever satisfied himself with an answer. Has anyone on the list
constructed a test to reveal the answer?
Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
Upcoming events:
- Hotsos Clinic, Dec 9-11 Honolulu
- 2003 Hotsos Symposium on OracleR System Performance, Feb 9-12 Dallas
- Jonathan Lewis' Optimising Oracle, Nov 19-21 Dallas
-----Original Message-----
Nahata
Sent: Friday, November 15, 2002 6:48 AM
To: Multiple recipients of list ORACLE-L
Cary,
I read your wonderful article. What is the exact difference between CR
and
CU, blocks fetched in Consistent and Current mode?
Regards
Naveen
-----Original Message-----
Sent: Friday, November 15, 2002 2:54 PM
To: Multiple recipients of list ORACLE-L
It's the count of a certain type of fetch operations of blocks from the
database buffer cache. See "Why you should focus on LIOs instead of
PIOs" at www.hotsos.com/catalog for details.
Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
Upcoming events:
- Hotsos Clinic, Dec 9-11 Honolulu
- 2003 Hotsos Symposium on OracleR System Performance, Feb 9-12 Dallas
- Jonathan Lewis' Optimising Oracle, Nov 19-21 Dallas
-----Original Message-----
Alavi
Sent: Thursday, November 14, 2002 2:10 PM
To: Multiple recipients of list ORACLE-L
Sorry for asking such a obvious question, but CONSISTANT GETS means
calling
rows from Database????
Thanks,
-----Original Message-----
Sent: Thursday, November 14, 2002 10:35 AM
To: Multiple recipients of list ORACLE-L
Hamid,
I'm sorry: Unless your SQL returns fewer than about 800,000 rows to the
calling application (or an aggregation of 800,000 rows), then the
statement "we have done all the necessary tuning on all the SQL queries"
is not yet true.
If your SQL does actually return about 800,000 rows, then it is time to
begin thinking about the mismatch between business processing
requirements and the logical structure of your data.
The answer to your problem is not in your instance parameters.
Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
Upcoming events:
- Hotsos Clinic, Dec 9-11 Honolulu
- 2003 Hotsos Symposium on OracleR System Performance, Feb 9-12 Dallas
- Jonathan Lewis' Optimising Oracle, Nov 19-21 Dallas
-----Original Message-----
Alavi
Sent: Thursday, November 14, 2002 11:50 AM
To: Multiple recipients of list ORACLE-L
Dear List,
I am monitoring a database, & I findout there is a transaction which
runing
a long time and others are waiting for this transaction, this
transaction
have 8,000,000 consistant gets with only 1 Physical I/O.
My question is, what I have to do except the SQL tuning to make this
transaction faster, we have done all the necessary tuning on all the SQL
query's.
Here is a copy of ora.ini:
Oracle 8.1.7.4 on sun solaris 2.8
background_dump_dest = /oracle/admin/cmstst/bdump
compatible = 8.1.7.4
control_files = "/cmsdb/cmstst/control02.ctl"
control_files = "/oralogs1/cmstst/control03.ctl"
control_files = "/oracle/oradata/cmstst/control01.ctl"
core_dump_dest = /oracle/admin/cmstst/cdump
db_block_buffers = 10000 ??? this need to
increase?
db_block_lru_latches = 4
db_block_size = 8192
db_file_multiblock_read_count = 16
db_name = cmstst
hash_area_size = 2048000 ??? need tuning
???
instance_name = cmstst
java_pool_size = 20971520
large_pool_size = 614400
log_archive_dest_1 = "location=/archlogs/cmstst"
log_archive_format = "arch%s.arc"
log_archive_start = TRUE
log_buffer = 262144 ?? this log
buffer
is enough??
log_checkpoint_interval = 10000 ??
log_checkpoint_timeout = 1800
max_enabled_roles = 30
open_cursors = 300
optimizer_index_caching = 90
optimizer_index_cost_adj = 35
os_authent_prefix = ""
processes = 100
remote_login_passwordfile = EXCLUSIVE
session_cached_cursors = 100
shared_pool_size = 134217728
sort_area_retained_size = 262144
sort_area_size = 262144
timed_statistics = TRUE
I realy appreciate your help and assistant. I am getting confused, just
want
to know changing any of these parameter help the performance to reduce
the
number of CONSISTANT GETS or NOT???
Thanks in advance.
Hamid Alavi
Office 818 737-0526
Cell 818 416-5095
======================= Confidentiality Statement
=======================
The information contained in this message and any attachments is
intended only for the use of the individual or entity to which it is
addressed, and may contain information that is PRIVILEGED, CONFIDENTIAL
and exempt from disclosure under applicable law. If you have received
this message in error, you are prohibited from copying, distributing, or
using the information. Please contact the sender immediately by return
e-mail and delete the original message from your system.
===================== End Confidentiality Statement
=====================
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Hamid Alavi
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.com
--
Author: Cary Millsap
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).
======================= Confidentiality Statement
=======================
The information contained in this message and any attachments is
intended only for the use of the individual or entity to which it is
addressed, and may contain information that is PRIVILEGED, CONFIDENTIAL
and exempt from disclosure under applicable law. If you have received
this message in error, you are prohibited from copying, distributing, or
using the information. Please contact the sender immediately by return
e-mail and delete the original message from your system.
===================== End Confidentiality Statement
=====================
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Hamid Alavi
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.com
--
Author: Cary Millsap
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.com
--
Author: Naveen Nahata
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.com
--
Author: Cary Millsap
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).
