alert log entries not sequential

From: Adams, Matthew (GE Consumer & Industrial) <MATT.ADAMS_at_GE.COM>
Date: Mon, 23 Aug 2004 13:11:56 -0400
Message-ID: <9E0E38DB4ACFAA4593AD6C4A45C9D5F003C5C9B9@LOUMLVEM01.e2k.ad.ge.com>

During the debacle this weekend, I did come across something interesting. Below I've attached a section of the alert log file from the instance that experienced difficulties. This is the first time I've ever seen entries in the alert.log file not be in chronological order. Database opened normally at 2:15:25
Entries show a shutdown abort at 2:32:14, when the veritas cluster failed over to the other node, but a few lines later, it's reported tablespaces were put into backup mode at 2:18:15

Anybody know what might account for this fact?

(I've already solved the corruption issues in question, I'm really just interested in how Oracle could put these lines in this particular order.)

Attached Alert.log -------

Sun Aug 22 02:15:25 2004
Completed: alter database open=20
Sun Aug 22 02:31:12 2004
Thread 1 advanced to log sequence 15339
Current log# 2 seq# 15339 mem# 0: =
/db1_fsi1/oracle/fs/dbs/redo2fsi1.log
Current log# 2 seq# 15339 mem# 1: /redos_fs1pkg/dbs/fsi1/redo2fsi1.log Sun Aug 22 02:31:12 2004
ARC0: Beginning to archive log# 3 seq# 15338 ARC0: Completed archiving log# 3 seq# 15338 Sun Aug 22 02:32:14 2004
Shutting down instance (abort)
License high water mark =3D 2
Instance terminated by USER, pid =3D 12911 lter tablespace RBS begin backup
Completed: alter tablespace RBS begin backup Sun Aug 22 02:18:15 2004
alter tablespace SYSTEM begin backup
Completed: alter tablespace SYSTEM begin backup Sun Aug 22 02:18:15 2004
alter tablespace TEMP begin backup
Completed: alter tablespace TEMP begin backup Sun Aug 22 02:18:15 2004
alter tablespace TOOLS begin backup
Completed: alter tablespace TOOLS begin backup

********************* ATTENTION: ********************=20

The controlfile header block returned by the OS has a sequence number that is too old.=20 The controlfile might be corrupted.
If this has occurred in a background process,=20 then the instance will be aborted.
PLEASE DO NOT ATTEMPT TO START UP THE INSTANCE=20 without following the steps below.
RE-STARTING THE INSTANCE CAN CAUSE SERIOUS DAMAGE=20 TO THE DATABASE, if the controlfile is truly corrupted. In order to re-start the instance safely,=20 please do the following:
(1) Save all copies of the controlfile for later=20

analysis and contact your OS vendor and Oracle support.
(2) Mount the instance and issue:=20

ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
(3) Unmount the instance.=20
(4) Use the script in the trace file to

RE-CREATE THE CONTROLFILE and open the database.=20

Sun Aug 22 02:38:23 2004
Errors in file /oracle/fs1pkg/8.1.7/rdbms/log/fsi1_ora_13773.trc: ORA-00600: internal error code, arguments: [kccchb_1], [87478], [87469], = [0], [87469], [0], [], []
<More very very bad stuff follows, deleted for brevity>

Matt Adams - GE Appliances - matt.adams_at_appl.ge.com If C gives you engouth rope to hang yourself, then C++ gives you enough rope to hang yourself, your dog, your co-workers, and everyone in your neighborhood.

Please see the official ORACLE-L FAQ: http://www.orafaq.com

To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line.

--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Received on Mon Aug 23 2004 - 12:07:46 CDT