Re: Interpreting USED_UREC from V$TRANSACTION

  • From: David Fitzjarrell <oratune@xxxxxxxxx>
  • To: "Dave.Herring@xxxxxxxxxx" <Dave.Herring@xxxxxxxxxx>, "Oracle-L \(oracle-l@xxxxxxxxxxxxx\)" <oracle-l@xxxxxxxxxxxxx>
  • Date: Fri, 6 Jul 2012 10:42:02 -0700 (PDT)

One possibility is the value generated is too large for a signed integer 
variable causing the value to go negative -- it was a problem a while back in 
one of the Solaris kernels (and Linux, I believe) where an uptime of greater 
than 260+ days caused counters to go negative.   
David Fitzjarrell


________________________________
From: Herring Dave - dherri <Dave.Herring@xxxxxxxxxx>
To: "Oracle-L (oracle-l@xxxxxxxxxxxxx)" <oracle-l@xxxxxxxxxxxxx> 
Sent: Friday, July 6, 2012 11:20 AM
Subject: Interpreting USED_UREC from V$TRANSACTION

Folks,
I'm monitoring a VERY large rollback operation  and could use some help in 
understanding conflicting values for USED_UREC in V$TRANSACTION.

This is for 11.2.0.3 on RHEL 5.6.  The transaction was  a DROP COLUMN against a 
1.3 TB table which I believe ran out of undo after 50+ hrs.  The SQL was 
generated from a data modeling tool and even after warning about runtimes they 
wanted the command run exactly as generated.

Now that the DROP COLUMN command has been rolling back for 5 days, I'm getting 
pretty confused on what V$TRANSACTION is telling me, specifically USED_UREC.  
Periodically over the last few days I've been querying this view and the values 
decreased way below zero and are now back about 800 million.  In all cases each 
check a little later showed the values were decreasing so I knew it was still 
rolling back:

Snapshot Date          USED_UREC
02-JUL-12 10:32:12      390,963,088
03-JUL-12 18:41:54      -903,130,274
06-JUL-12 12:57:17      784,607,392

As the value for USED_UREC decreased near 0 I figured that'd be it, but then it 
seemed to go indefinitely below 0, then some point in the past 24 hrs. the 
value was reset about 800 million.  Like I said, repeated checks so the value 
to be decreasing and also a DECODE(BITAND(t.flag,128), 0, NULL, 'Rollback') 
returns "Rollback".

So how can the value go negative and then jump back to 800 million?  I'm pretty 
sure it didn't "wrap" and transactions can't span undo segments.  This also 
makes it VERY difficult to figure out how long this will take.

The best I've come up with is comparing "redo entries" stat from AWR before the 
rollback with "rollback changes - undo records" stat in AWR during this 
rollback process.  Should they eventually be equal, assuming little to no other 
activity on the DB?

DAVID HERRING
DBA
Acxiom Corporation
EML  dave.herring@xxxxxxxxxx<mailto:dave.herring@xxxxxxxxxx>
TEL    630.944.4762
MBL  630.430.5988
1501 Opus Pl, Downers Grove, IL 60515, USA
WWW.ACXIOM.COM<http://www.acxiom.com/>


[cid:image001.png@01CD5B6F.7DC25E40]<http://www.facebook.com/acxiomcor>  
[cid:image002.png@01CD5B6F.7DC25E40] 
<http://www.linkedin.com/groupRegistration?gid)0173>  
[cid:image003.png@01CD5B6F.7DC25E40] <http://twitter.com/acxio>

[Description: cid:image004.png@01CB84F1.26214350]

***************************************************************************
The information contained in this communication is confidential, is
intended only for the use of the recipient named above, and may be legally
privileged.

If the reader of this message is not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.

If you have received this communication in error, please resend this
communication to the sender and delete the original message or any copy
of it from your computer system.

Thank You.
****************************************************************************


--
//www.freelists.org/webpage/oracle-l

--
//www.freelists.org/webpage/oracle-l


Other related posts: