Re: Tuning RMAN: what is rsr_l0key?
- From: "Rajeev Prabhakar" <rprabha01@xxxxxxxxx>
- To: oracle-l <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 12 Oct 2007 11:15:23 -0400
So, in case someone is facing the same rman performance issue
for 10.2.0.3 on linux x86-64 platform, the patch is 6081556.
-Rajeev
#-------------------------------------------------------------------------
# Interim Patch for Base Bugs: 6081556
#-------------------------------------------------------------------------
#
# DATE: June 14, 2007
# -------------------------------
# Platform Patch for : 226 - Linux x86-64
# Product Version # : 10.2.0.3
# Product Patched : RDBMS
#
# Bugs Fixed by this patch:
# -------------------------
# 6081556:TRACKING BUG FOR INVENTORY OF DG RMAN BUGS ON TOP OF 10.2.0.3
# 5998546:MLR ON TOP OF 10.2.0.3 FOR INVENTORY OF RMAN BUGS
# 5219484:CATALOG RESYNCS ARE VERY SLOW - ROUT TABLE HAS 6 MILLION ROWS +
# 5899994:RESYNC OF CATALOG ON DATABASES WHICH WERE STANDBY BEFORE TAKE A
VERY LONG TIME
# 5063635:GAP OCCURED AFTER ORA-00600 [KCCDAGF_3] IN STANDBY ARC
# 5742127:BACKUP SOMETIMES FAILS WITH INTERNAL ERROR IF DATAFILE GROWS
DURING BACKUP
On 10/12/07, Rajeev Prabhakar <rprabha01@xxxxxxxxx> wrote:
>
> Charles
>
> From what I could see, the problemetic query that you mentioned earlier
> has been clearly identified as a bug 5965453 (On Apr-3rd-07) by oracle
> support on rhas for 10.2.0.3.
>
> -Rajeev
>
>
> On 10/12/07, Charles Schultz <sacrophyte@xxxxxxxxx> wrote:
> >
> > Since I was not able to get a definitive answer about what rsr_l0key is,
> > I did some investigation. This is not rocket science, but I want to
> > share it just in case anyone else is curious.
> >
> > Apparently, rsr_l0key only has relevance when row_level = 2 (also when
> > row_type = 'RECURSIVE OPERATION'). When that is the case, rsr_l0key is the
> > level 0 key, where rsr_pkey is the level 1 key and rsr_key is the level 2
> > key. I think level 2 is the max, at least it is in my database. This is the
> > only case where nvl(rsr_pkey,-1) != nvl(rsr_l0key, -1), or to put it in
> > english, when the parent key is not exactly the same as the level 0 key,
> > even if they are both null.
> >
> > I am not exactly sure why the rc_rman_status view wants to union in all
> > the null level 0 keys. It seems like you would grab all the regular rsr
> > keys, and if you want parent information, go get it with a hierarchy or
> > something.
> >
> > However, I am even more perplexed about the original query. Why select a
> > session key using a very generic timestamp that has nothing to do with your
> > session?
> >
> > Where are those rman developers when you need to ask completely inane,
> > innocuous and inconsequential questions. =)
> >
> > On 10/11/07, Charles Schultz <sacrophyte@xxxxxxxxx > wrote:
> > >
> > > Thanks to those that responded. I thought to make a "group" reply to
> > > answer you all at once, but also to make this info available to anyone
> > > else.
> > > Unfortunately, I have not learned anything else about rsr_l0key; the jury
> > > is
> > > still out for that one.
> > >
> > > However, after looking over my SR and hearing back from some of you,
> > > we will be applying bug patch 5620640 over the weekend and hopefully that
> > > will help.
> > >
> > > On 10/11/07, Charles Schultz <sacrophyte@xxxxxxxxx > wrote:
> > > >
> > > > We are having some serious performance problems with the RMAN
> > > > catalog; Oracle suggested that we upgraded to 10.2.0.3 but I think
> > > > that has only moved the bottlenecks to different parts of the
> > > > architecture.
> > > > Right now, we are getting killed by this rman query:
> > > > SELECT NVL (MAX(SESSION_KEY ), 0 ) FROM RC_RMAN_STATUS WHERE
> > > > SESSION_STAMP < :B1
> > > >
> > > > Our RC_RMAN_STATUS has ~500 k rows. Looking at the view, there is a
> > > > union for rows were rsr.rsr_l0key is null. A third of our rows have
> > > > a null value for that column. What is rsr_l0key? It is not documented.
> > > >
> > > > I am sure our problem is related to volume, but I am not convinced
> > > > that this should be the problem. I mean, come on, this is a measly
> > > > 500,000 rows.
> > > > We are in the progress of creating a colocated catalog to partition
> > > > the load a little. But I am still curious about the internals of rman,
> > > > especially since it is not documented.
> > > >
> > > > --
> > > > Charles Schultz
> > >
> > >
Other related posts:
