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" <[EMAIL PROTECTED]>
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: [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: 
  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).

Reply via email to