Hi Arun !
Thanks for your support. And you are very true about
that.'the deeper you go.. the more mysterious it
gets.'
I am getting a rough idea aboout what is going inside
the RBS and redos after spending a couple of hours in
that dump. Will post the results to list so that some
one can validate and tell whether it is right or not.
And coming to your Q: My understanding about CR is any
data select (or query) which results in SCN check is
recorded as CR Read. So what you are seeing is right
and selects does increse the CR stats.
Have a nice day !!
- arun <arun_k_c_at_hotmail.com> wrote:
> U said the right thing steve I cant believe why
> people dont appreciate the
> hard work the other man does,If u dont know the
> answer dont please keep
> mmm,and let others answer the Q's ,we are slogging
> our butts here to
> understand what this bloody oracle, the deeper we go
> the more mysterious it
> get and its challenging,
> Please do not write what ever u feel.
> This is one group from where i learnt so much myself
> and i cant accept some
> stupid answers.
> Okay smart guy forget debugging the dumps can u tell
> me the answer for the
> following
>
> I ran the following query to identify the number of
> versions of a block .
> The Block 40462, File#16 has 23 versions in CR mode.
> My question is why is
> there 23 versions of BLOCK - 40462, FILE# 23 when
> there are no
> updates,deletes,inserts going on in that table. This
> is a static table and
> is in the KEEP POOL. Only selects are occuring
> against this table since DB
> startup.
> select count(*),file#,block#,status from v$bh
> group by file#,block#,status having count(*) > 5
> order by 2,3,1;
>
> COUNT(*) FILE# BLOCK# STAT
> ---------- ---------- ---------- ----
> 9 1 20178 cr
> 8 10 740 cr
> 23 16 40462 cr
> 17 16 40636 cr
> 8 16 114167 cr
> 7 21 73310 cr
> 6 29 13946 cr
> 14 67 35295 cr
> 10 67 35316 cr
> 10 67 35321 cr
> 12 67 35326 cr
>
> COUNT(*) FILE# BLOCK# STAT
> ---------- ---------- ---------- ----
> 6 79 30775 cr
> 6 79 30798 cr
> 6 79 30799 cr
> 6 79 30802 cr
> 10 89 34845 cr
> 8 89 34846 cr
> 8 89 34847 cr
> 8 116 100846 cr
> 8 125 31107 cr
> 7 127 26887 cr
> 8 135 6994 cr
>
> 22 rows selected.
>
> I ran a query to identify which objects are present
> in which pool. If the CR
> blocks of the objects in the KEEP buffer pool are
> created in DEFAULT buffer
> pool , I am not seeing any blocks belonging to the
> above object FILE 16
> BLOCK 40462 any where in the DEFAULT buffer pool.
> Can U tell me where I am going wrong ?
>
>
>
>
> ----- Original Message -----
> To: "Multiple recipients of list ORACLE-L"
> <ORACLE-L_at_fatcity.com>
> Sent: Saturday, November 25, 2000 12:30 PM
>
>
> > Hello San,
> >
> > Maybe. I read a lot of dumps, and it does "waste"
> time. But the knowledge
> that
> > it gives me often saves time during crises when
> there is no time to waste.
> >
> > @ Regards,
> > @ Steve Adams
> > @ http://www.ixora.com.au/
> > @ http://www.christianity.net.au/
> >
> >
> > -----Original Message-----
> > Sent: Saturday, 25 November 2000 13:31
> > To: Multiple recipients of list ORACLE-L
> >
> >
> > U R wasting UR time
> >
> > San
> > --
> >
> > On Fri, 24 Nov 2000 02:35:37
> > K Gopalakrishnan wrote:
> > >Hi !
> > >
> > >This is definitely not a week end question...:)
> > >
> > >I have dumped some redo blocks and undo blocks
> for a
> > >transaction.. Now the part 2. How do i decrypt ?
> > >
> > >Any one there to help us?
> > >
> > >-----------------------------
> > >index undo for leaf key operations
> > >KTB Redo
> > >op: 0x02 ver: 0x01
> > >op: C uba: 0x00800801.0059.67
> > >Dump kdilk : itl=2, kdxlkflg=0x1 sdc=426409604
> > >indexid=0x40012b block=0x0040668c
> > >mark leaf row deleted
> > >key :(9): 04 c3 03 0f 44 03 c2 11 51
> > >keydata/bitmap : (6): 00 40 66 79 00 8f
> > >*-----------------------------
> > >* Rec #0x2 slt: 0x61 objn: 64(0x00000040)
> objd: 64
> > >tblspc: 0(0x00000000)
> > >* Layer: 11 (Row) opc: 1 rci 0x01
> > >Undo type: Regular undo Last buffer split: No
> > >Temp Object: No
> > >Tablespace Undo: No
> > >rdba: 0x00000000
> > >*-----------------------------
> > >KDO undo record:
> > >KTB Redo
> > >op: 0x02 ver: 0x01
> > >op: C uba: 0x00800801.0059.68
> > >KDO Op code: DRP xtype: XA bdba: 0x00406754
> hdba:
> > >0x004000cf
> > >itli: 1 ispac: 0 maxfr: 4863
> > >tabn: 0 slot: 333(0x14d)
> > >*-----------------------------
> > >* Rec #0x3 slt: 0x61 objn: 109(0x0000006d)
> objd:
> > >109 tblspc: 0(0x00000000)
> > >* Layer: 10 (Index) opc: 22 rci 0x02
> > >Undo type: Regular undo Last buffer split: No
> > >Temp Object: No
> > >Tablespace Undo: No
> > >rdba: 0x00000000
> > >------------------------------
>
Have a nice day !!
Best Regards,
K Gopalakrishnan,
Received on Tue Nov 28 2000 - 00:04:01 CST
