Ok Jeremiah,
I'll warrent that Redo sequence# is a uneven measuring stick.
Longest since last restart - 6/22/01
Oldest - 7/24/96
Highest SCN- a pokey 366 802 309
What kind of environment gets you to a 13-digit SCN?
Mike
-Original Message-
My stats:
: Redo sequence# poll
Ok Jeremiah,
I'll warrent that Redo sequence# is a uneven measuring stick.
Longest since last restart - 6/22/01
Oldest - 7/24/96
Highest SCN- a pokey 366 802 309
What kind of environment gets you to a 13-digit SCN?
Mike
-Original
recipients of list ORACLE-L [EMAIL PROTECTED]
cc:
Subject:RE: Lite: Redo sequence# poll
Ok Jeremiah,
I'll warrent that Redo sequence# is a uneven measuring stick.
Longest since last restart - 6/22/01
Oldest - 7/24/96
Highest SCN- a pokey
]
cc:
Subject:RE: Lite: Redo sequence# poll
Ok Jeremiah,
I'll warrent that Redo sequence# is a uneven measuring stick.
Longest since last restart - 6/22/01
Oldest - 7/24/96
Highest SCN- a pokey 366 802 309
What kind of environment gets you
, Michael T [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
03/12/02 08:28 AM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
cc:
Subject:RE: Lite: Redo sequence# poll
Ok Jeremiah,
I'll warrent that Redo sequence# is a uneven
I think you can **artificially** force a database to reach the SCN to
0xfff. by using the event ADJUST_SCN.
This bumps the SCN to one billion if set at level 1. So
running them in a
loop will bump the SCN to the max value.
THis event generally used to bump the SCNs if there is a
John,
alter session set events 'immediate trace name ADJUST_SCN level 1' bumps
the current SCN By one billion. I have used this event once while recovering
a Tera Byte database where LGWR crashed and all the data files were
inconsistent.
And also there is an undocumented paramter something
Gopal,
You sure like to play with fire... Don't you ??
Thanks for the info, though.
:)
- Kirti
-Original Message-
Sent: Tuesday, March 12, 2002 9:23 PM
To: Multiple recipients of list ORACLE-L
John,
alter session set events 'immediate trace name ADJUST_SCN level 1' bumps
Since people with undersized logfiles will come out on top, how about
comparing current SCNs instead?
select max(ktuxescnw * power(2, 32) + ktuxescnb) from x$ktuxe;
Also longest time since last startup would be interesting to see.
Thanks to Steve Adams and http://www.ixora.com.au for the
Details, Michael, details.
3.5 years uptime?
Platform, versions, HW configuration, memory, etc.
Inquiring minds want to know.
Jared
Hand, Michael T [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
03/11/02 11:33 AM
Please respond to ORACLE-L
To: Multiple recipients of list
Jared,
Sorry if the Uptime got you going. I didn't mean to imply 7x24 no db
shutdown or crashes but operational time with out the need for a recovery w/
resetlogs. With that in mind it has been a stable platform over that 3.5
years.
DEC/Compaq Alpha 8100; 6-12Gb RAM; 5 disk mirror sets
My stats:
Longest time since last restart (uptime) - 08/30/2001 (v$instance -
startup_time)
Oldest database - 11/05/1999 (v$database - created)
High SCN - 5551718526045
All not very impressive. Who has better?
--
Jeremiah Wilton
http://www.speakeasy.net/~jwilton
On Mon, 11 Mar 2002,
Hi Jeremiah and list,
Since people with undersized logfiles will come out on top, how about
comparing current SCNs instead?
Nice catch, but when distributed databases are involved, the following
applies:
Internal Operations Each committed transaction has an associated system
change
number
13 matches
Mail list logo