Re: Dynamic re-mastering in RAC
- From: Anand Rao <panandrao@xxxxxxxxx>
- To: racdba@xxxxxxxxxxxxx
- Date: Wed, 3 Aug 2005 14:36:37 +1000
Hi,
As far as i know, Oracle themselves have not suggested partitioning
for Apps 11i. Oracle 9i Cache Fusion avoids the need to do so. DRM has
nothing to do with Partitioning.
Just because DRM does not happen or happens, why would you want to
constrict application access to one single node?
you could try it and see if there is any benefit (because of lesser
blocks transfer) but i doubt if there will be 'highly significant'
gains that will compel someone to move to application partitioning
very actively.
having said that, it all depends on the application, the
transactions/sec, and the nature of txns, etc. if the same table(s)
and other objects are used by both modules, then block transfer will
surely occur.
There are some apps that do benefit from application partitioning
simply because of the way it is written and the way they access the
tables/indexes. So, my answer would be...test it and see the gains.
make sure you establish a good baseline for the application without
partitioning before you actually run each app or module on one node
only.
regards
anand
On 03/08/05, Sudhi <sudhi@xxxxxxxxxxxxx> wrote:
> don't have any exp on 11i apps. Probably KG or Anand will have more
> comments on this.
>
> Thanks,
> -Sudhi.
>
> Hameed, Amir wrote:
> > In the context of Oracle 11i applications, if the DR is not a good
> > choice in 9i2 then should one consider application partitioning ?
> >
> > Thanks
> > -----Original Message-----
> > From: racdba-bounce@xxxxxxxxxxxxx [mailto:racdba-bounce@xxxxxxxxxxxxx]
> > On Behalf Of Sudhi
> > Sent: Tuesday, August 02, 2005 1:43 AM
> > To: Hameed, Amir
> > Cc: racdba@xxxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
> > Subject: Re: Dynamic re-mastering in RAC
> >
> > One of the reasons is they couldn't fit into the main release of the
> > kernel. Also I would consider the 10g code base to actually implement
> > dynamic re-mastering.
> >
> > Thanks,
> > -Sudhi.
> >
> > Hameed, Amir wrote:
> >
> >>Thanks KG!
> >>Interesting. I just checked in my 9.2.0.6 and 9.2.0.4 databases and
> >>parameter _lm_dynamic_remastering is set to FALSE (the default is
> >
> > TRUE).
> >
> >>Since this is a hidden parameter and therefore is not meant to be set
> >>without Oracle's permission, I wonder why Oracle 9i manuals talk about
> >>Dynamic Remastering if it is not available out-of-the box in 9i2.
> >
> > Also,
> >
> >>is the reason that it is not available out-of-the-box is because the
> >>algorithm in 9i2 is not that effective?
> >>Any thoughts...
> >>
> >>Thanks
> >>Amir
> >>-----Original Message-----
> >>From: racdba-bounce@xxxxxxxxxxxxx [mailto:racdba-bounce@xxxxxxxxxxxxx]
> >>On Behalf Of K Gopalakrishnan
> >>Sent: Monday, August 01, 2005 8:56 PM
> >>To: racdba@xxxxxxxxxxxxx
> >>Cc: oracle-l@xxxxxxxxxxxxx
> >>Subject: Re: Dynamic re-mastering in RAC
> >>
> >>Amir:
> >>
> >>The right answer to your question is it depends. There is no dynamic
> >>remastering in 9i RAC other than in 9204/9205 where the parameter
> >>(only) _lm_dynamic_remastering is set to true.
> >>
> >>In 10gR1 dynamic remastering is set at file level and starting from R2
> >>the dynamic remastering is done at FILE+OBJECT Level. But conditions
> >>are very stringent. For example one instance should touch the blocks
> >>(of that object) 50 times more than the other instance in particular
> >>period (say 10 mins). These touch ratio and time can be tuned by
> >>_gc_affinity_limit and _gc_affinity_time parameters.
> >>
> >>Regards,
> >>Gopal
> >>
> >>
> >>On 8/2/05, Hameed, Amir <Amir.Hameed@xxxxxxxxx> wrote:
> >>
> >>
> >>>Folks,
> >>>Is dynamic re-mastering done at the file-level or at the block level?
> >>
> >>That
> >>
> >>
> >>>is, does an instance master the entire datafile or only those blocks
> >>
> >>that
> >>
> >>
> >>>were repeatedly accessed from its buffer cache in a certain file? Is
> >>
> >>there a
> >>
> >>
> >>>way to identify/tell which file/block is mastered by a certain
> >>
> >>instance?
> >>
> >>
> >>>Thanks
> >>>Amir
> >>
> >>
> >>
> >
>
> --
> Legal Disclaimer: The statements expressed here are of my own and do not
> represent those of Yahoo Inc !
>
>
Other related posts:
