Oracle-L: Re:RE: CONSISTANT GETS

From: <dgoulet_at_vicr.com>
Date: Thu, 14 Nov 2002 12:44:08 -0800
Message-ID: <F001.00503BA3.20021114124408@fatcity.com>

Hamid,

This is one of those instances where I'll heartly agree with Cary in ALL respects. We run PeopleSoft and have found many a query that seems to spinn around and around creating a pile of consistent gets and little if any IO. The problem that most often exists is that a coorrelated subquery is the last item in the where clause or the first thing that Oracle does. Damned nasty. Check your code over again and trace it.

Dick Goulet

____________________Reply Separator____________________
Author: "Cary Millsap" <cary.millsap_at_hotsos.com>
Date:       11/14/2002 10:34 AM

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: hamid.alavi_at_quovadx.com

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: ListGuru_at_fatcity.com (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: cary.millsap_at_hotsos.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------