The problem is generic, the specific query
isn't the point. RAC is a massive improvement
on OPS because block transfer is by wire not
disc - but it still takes a serious amount of
time to fling blocks from node to node, especially
if the blocks have been subject to very recent update
at the
Title: RE: Extremely Slow Query
Thanks everyone ...
Yes it is RAC (in fact I don't have non-rac databases anymore). Unfortunately this is not my query. TOAD runs this query when it starts-up and it seems like it hangs. As I am in process of deploying newest version of TOAD, I am pretty sure
Sorry,
I can't take credit for improving the query.
The improved time looks like an accident.
The plan now has two scans of OBJ$, rather
than one - it just that the two plans take 4 and 9
seconds - whereas the single scan in the first
plan took 370 seconds.
I guess that the first plan was a
Jonathan Lewis wrote:
The problem is generic, the specific query
isn't the point. RAC is a massive improvement
on OPS because block transfer is by wire not
disc - but it still takes a serious amount of
time to fling blocks from node to node, especially
if the blocks have been subject to
Title: Extremely Slow Query
Does any know how to speed up following query?
Select *
from dba_types
/
It is taking about 2-3 minutes on my 9202 database. I see a lot of Global Cache waits. The hammer shows following information
Jamadagni, Rajendra wrote:
Does any know how to speed up following query?
Select *
from dba_types
/
It is taking about 2-3 minutes on my 9202 database. I see a lot of
Global Cache waits. The hammer shows following information ...
Title: Extremely Slow Query
Are
you running RAC?
Waleed
-Original Message-From: Jamadagni, Rajendra
[mailto:[EMAIL PROTECTED]]Sent: Thursday, January 02,
2003 3:51 PMTo: Multiple recipients of list
ORACLE-LSubject: Extremely Slow Query
Does any know how to speed up
Title: Extremely Slow Query
Doesnt seem to be a problem in my 9013 instance.
returned 240 rows in 1.26 elapsed seconds
- Original Message -
From:
Jamadagni, Rajendra
To: Multiple recipients of list ORACLE-L
Sent: Thursday, January 02, 2003 12:51
PM
Subject
RAC/OPS?
A guess: obj$ is a very popular table (and possibly
RAC-caches-wide-spread one ;) -- some its blocks
were not in the local cache. Does it take 2-3 mins
everytime you launch the query? Probably somebody
else is doing some manipulations with obj# actively
creates/alters/drops objects?
Looks like you've hit the big problem with RAC -
how many nodes do you have, how busy
are the nodes which are supposed to supply
with with CR copies across the interconnect,
and what's the latency and bandwidth of your
interconnect ? (And how did you get that many
objects into obj$ !!!)
If you
Jonathan Lewis wrote:
Looks like you've hit the big problem with RAC -
Do you think it's really the big problem? I'm just
thinking about Oracle APPS instance or something
alike. Somebody could start object recompilation
(maint. pack/adadmin), synonyms creation or whatever
like that on a node.
]
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Subject: Re: Extremely slow query
Date: Sun, 16 Jun 2002 23:28:19 -0800
Set autotrace traceonly explain normally causes extra seconds for the
query.
But this query only lasts for 20 seconds in my database.
Is hash_join_enabled=y ? what is your
: Extremely slow query
I have the exact same explain plan when I run it, and it takes 2 seconds
for
me. What is this session waiting on? What are the system waits? Check
v$system_event, v$system_wait, v$session_event, and v$session_wait.
From: Bunyamin Karadeniz [EMAIL PROTECTED
* Solaris 2.6
* Oracle RDBMS v8.0.5.2.1
List:
We are (still) having difficult with a production database. (Users
experiencing severe slowness at times.) I'm constructing a series of
queries to run at intervals to check the health/status of the system.
I'm attempting to run the
respond to ORACLE-L
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
cc:
Subject:Extremely slow query
* Solaris 2.6
* Oracle RDBMS v8.0.5.2.1
List:
We are (still) having difficult with a production database. (Users
Have you looked at System Waits, Session Waits and
or event 10046 trace data ? They hold the keys to
the kingdom on where you should proceed to diagnose
your performance issue.
-Original Message-
Sent: Friday, June 14, 2002 5:03 PM
To: Multiple recipients of list ORACLE-L
*
16 matches
Mail list logo
