It might not get reset, but it's not a public information
and the behavior of it can change from one version to another .
It is unclear and undefined what happens when the number of transactions
on a rollback segments reaches the MAXVALUE. There are several
possibilities:
a) It wraps around
It's nice to see people appreciate learning something new!
-Original Message-
Sent: Friday, February 15, 2002 1:55 PM
To: Multiple recipients of list ORACLE-L
It might not get reset, but it's not a public information
and the behavior of it can change from one version to another .
It
Hi G_DBA ,
The transaction id (which is recorded in the ITL) consists of 3 components.
Undo Segment Number, Slot Number and Wrap Number.
THe max value of the wrap number is limited by UB4MAXVAL. (Approx 4G in
numbers) and once it reaches the MAXVAL the rollback segment is considered
as DEAD.
How long does a database have to remain running in order for a rollback
segment to go to the happy hunting grounds? Have you ever seen such an
event? A simple instance restart will cure that disease. Anyway, the only
thing that I can envision to cause this is to have an OLTP database with
Gogala,
Not quite true.A simple restart will NOT cure that disease. The WRAP# is
visible as KTUXESQN in the X$KTUXE. You can check that value by restating
the instance. You can simply drop the rollback segment and force the
instance to use the other rollback segements, but not by restarting..:)
That was my question also. I am agree with Gogala, after bouncing database
no of wraps goes to 0(zero). This is normal behaviour with 7.3.4 to 8.1.7
databases. Unfortunately our databases are bounced everyday for snapshot
backup and I saw this behaviour everyday...
Regards
Rafiq
Reply-To:
Thanks for the correction. I was looking some other column.
I am sorry for the mistake.
Best Regards,
K Gopalakrishnan
Bangalore, INDIA
-Original Message-
Mladen
Sent: Thursday, February 14, 2002 2:42 PM
To: Multiple recipients of list ORACLE-L
Number of wraps gets reset with the
Gogala,
THe column you are looking is not the actual one. I have overlooked your
post and thought you are right. Now I have decided to test myself and here
is the result.
SQL select max(ktuxesqn) from X$KTuxe;
MAX(KTUXESQN)
-
956
SQL startup force
