Re: Using PQ in FTS

  • From: "Frits Hoogland" <frits.hoogland@xxxxxxxxx>
  • To: john.kanagaraj@xxxxxxxxx
  • Date: Wed, 28 Mar 2007 04:02:42 -0500

If mixed access (meaning both buffered and direct access) is done on objects
where DML is happening, it can result in buffer busy waits because extents
needs to be checkpointed before direct access can occure.

Seen a great deal of buffer busy waits in 9.2.0.6/linux where concurrent DML
queries got downgraded to serial due to the parallel automatic tuning.

This is probably true for higher versions (because of how PX is implemented)
of the database, but haven't tested it.

frits

On 3/27/07, John Kanagaraj <john.kanagaraj@xxxxxxxxx> wrote:


Amir,

Have a look at http://oracledoug.com/px.html - Be aware that you set
PQ's init.ora parameters properly, specially to limit the number of PQ
servers: Otherwise, you might end up choking on CPU on unbound
usage...

John

On 3/26/07, Hameed, Amir <Amir.Hameed@xxxxxxxxx> wrote:
>
>
> No, PQ used by batch jobs.
>
>
>  ________________________________
>  From: Arul Ramachandran [mailto:contactarul@xxxxxxxxx]
> Sent: Monday, March 26, 2007 1:08 PM
> To: Hameed, Amir
> Cc: oracle-l@xxxxxxxxxxxxx
> Subject: Re: Using PQ in FTS
>
>
> I was going to say unintended block cleanouts.. but then glanced
Jonathan
> Lewis' book page 30 where it mentions 'segment checkpoint', that sounds
> almost like block cleanouts....
>
> I suppose you did not mean PQ will be used by OLTP queries...
>
>
> Arul
>
>
>
> On 3/23/07, Hameed, Amir <Amir.Hameed@xxxxxxxxx> wrote:
> > Folks,
> > If there are statements where FTS on large tables is unavoidable due
to
> > the logic in the statements, is there a downside of using PQ to scan
> > those tables? Jonathan has mentioned one caution on page 30 of his
book
> > but are there any other issues that one must be aware of ? The RDBMS
> > version are 9.2.0.6 and 10.2.0.2.
> >
> > Thanks
> > Amir
> >
> > --
> > //www.freelists.org/webpage/oracle-l
> >
> >
> >
>
>
>
> --
> Arul


--
John Kanagaraj <><
DB Soft Inc
Phone: 408-970-7002 (W)

** The opinions and facts contained in this message are entirely mine
and do not reflect those of my employer or customers **
--
//www.freelists.org/webpage/oracle-l

Other related posts:

  1. Home
  2. oracle-l
  3. Archive
  4. 03-2007