RE: [Fwd: Re: I may never see this again. SGA]

I swear I thought I read that px deq waits were idle waits.  Do you
still see these waits with parallel automatic tuning on?  I'm not
suggesting that turning it all to automatic is the answer, but it seems
to work rather well on the box I'm testing.  Maybe that's because I
don't know better.

My impression of cache buffers chains waits is processes fighting over a
buffer.  Am I wrong?  With the larger buffer cache I've been testing,
these waits have nearly gone away during data loads.  

Comments?

-----Original Message-----
From: DEEDSD@xxxxxxxxxxxxxx [mailto:DEEDSD@xxxxxxxxxxxxxx] 
Sent: Tuesday, June 15, 2004 8:27 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: [Fwd: Re: I may never see this again. SGA]





This system is a wonderful example of something having 'an infinite
capacity to wait'.

My best solution is to club the consultants that suggested default
parallel
degrees between 8 and 16 be placed on the tables, then club the
developers
that allowed it.  Following the clubbing, immediate sacking is
recommended.
Then, cut down the default parallelism to a reasonable level if people
still insist on using parallel query, then redesign the ~550 tables that
have 180+ partitions each into a good logical and physical design and
hire
developers that know what they are doing to fix the application.

After all that is done, the PX Deq waits and cache buffers chains waits
will take care of themselves....

I think you know the database of which I speak, Joe...


 

                          <jtesta@xxxxxxxxxx>

                                                   T

                          Sent by:                 To:
<oracle-l@xxxxxxxxxxxxx>                                 
                          oracle-l-bounce@freelis  cc:

                          ts.org

                                                   bcc:

                                                   Subject:
[Fwd: Re: I  
                                                   may never see this
again.  SGA]                                
                          06/14/2004 04:41 PM

                          Please respond to

                          oracle-l

 

 






Ok i'll bite, whats the solution for the PX Deq and Cache Buffer chains
waits?

joe



original message below>
>

 Bah.

 On a 24-CPU sun box w/96 GB of memory, one 2 TB database.  You should
 see the PX Deq and cache buffers chains waits!!  Completely obscene.
 It's a train wreck.  But, we have to do what the customers demand...

 Connected to:
 Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production With
 the Partitioning, OLAP and Oracle Data Mining options
 JServer Release 9.2.0.4.0 - Production

 SQL> show sga

 Total System Global Area 7.2311E+10 bytes
 Fixed Size                   835056 bytes
 Variable Size            2499805184 bytes
 Database Buffers         6.9810E+10 bytes
 Redo Buffers                 319488 bytes





----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------



----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

"The sender believes that this E-Mail and any attachments were free of any 
virus, worm, Trojan horse, and/or malicious code when sent. This message and 
its attachments could have been infected during transmission.  By reading the 
message and opening any attachments, the recipient accepts full responsibility 
for taking proactive and remedial action about viruses and other defects. The 
sender's business entity is not liable for any loss or damage arising in any 
way from this message or its attachments."

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: