Current Log corruption solution example

Last Thursday, a set of redo logs were added. After the alter system switch logfile was run, the database suddenly went down. Check the log and find the following error:

Errors in file F: "lczhis" dump "bdump" lczhis_arc0_2468.trc:

ORA-19504: failed to create file "F:" lczhis "ARCHIVE" arc00425055776657082840.arc"

ORA-27040: file create error, unable to Create File

OSD-04001: Invalid logical block size (operating system 512)

 

Arc0: Error 19504 creating archive log file to 'f: "lczhis" ARCHIVE "arc00425055776657082840.arc'

Arch: archival stopped, error occurred. Will Continue retrying

Thuoct 16 17:38:26 2008

Errors in file F: "lczhis" dump "bdump" lczhis_arc0_2468.trc:

ORA-16038: log 2 sequence #282840 cannot be archived

ORA-19504: failed to create file ""

ORA-00312: Online log 2 thread 1: 'e: "redo" redo02.log'

 

Thuoct 16 17:38:30 2008

Errors in file F: "lczhis" dump "bdump" lczhis_lgwr_2384.trc:

ORA-00366: Log 1 of thread 1, checksum error in the file header

ORA-00312: Online log 1 thread 1: 'f: "lczhis" redo "redo01.log'

 

I tried to start up the database and the result failed. The following error is reported:

 

Alter database open

Thuoct 16 17:39:11 2008

Beginning crash recovery of 1 threads

Parallel recovery started with 3 processes

Thuoct 16 17:39:11 2008

Started redo Scan

Thuoct 16 17:39:11 2008

Errors in file F: "lczhis" dump "udump" lczhis_ora_880.trc:

ORA-00366: Log 1 of thread 1, checksum error in the file header

ORA-00312: Online log 1 thread 1: 'f: "lczhis" redo "redo01.log'

Check the database and find the current log.

Then we will launch 18 martial arts classes, such:

SQL> startup Mount

SQL> alter database clear logfile group 1;

SQL> alter database clear Unarchived logfile group 1;

SQL> recover database using backup controlfile until cancel;

SQL> alter session set events '10015 trace name adjust_scn level 1 ';

SQL> alter database open resetlogs;

Even implicit Parameters

_ Allow_resetlogs_upload uption = true

_ Uploupted_rollback_segments = true

_ Offline_rollback_segments = true

 

All of them end with a failure, and the following error is reported:

Media recovery Log F: "lczhis" ARCHIVE "arc00425055776657082841.arc

Errors with Log F: "lczhis" ARCHIVE "arc00425055776657082841.arc

ORA-308 signalled during: Alter database recover continue default...

Thuoct 16 22:34:05 2008

Alter database recover continue default

Arch: Warning. Log sequence in archive filename wrapped

To fix length as indicated by % s in log_archive_format.

Old log archive with same name might be overwritten.

Thuoct 16 22:34:05 2008

Media recovery Log F: "lczhis" ARCHIVE "arc00425055776657082841.arc

Errors with Log F: "lczhis" ARCHIVE "arc00425055776657082841.arc

ORA-308 signalled during: Alter database recover continue default...

Thuoct 16 22:34:05 2008

Alter database recover cancel

ORA-1547 signalled during: Alter database recover cancel...

Thuoct 16 22:34:44 2008

Alter database recover database until cancel

Thuoct 16 22:34:44 2008

Media recovery start

Parallel recovery started with 3 processes

Thuoct 16 22:34:56 2008

Arch: Warning. Log sequence in archive filename wrapped

To fix length as indicated by % s in log_archive_format.

Old log archive with same name might be overwritten.

ORA-279 signalled during: Alter database recover database until cancel...

Thuoct 16 22:35:36 2008

Alter database recover logfile 'f: "lczhis" redo "redo01.log'

Thuoct 16 22:35:36 2008

Media recovery Log F: "lczhis" redo "redo01.log

Thuoct 16 22:35:36 2008

Errors in file F: "lczhis" dump "udump" lczhis_ora_1860.trc:

ORA-00367: Checksum error in Log File Header

ORA-00334: Archived log: 'f: "lczhis" redo "redo01.log'

 

Errors with Log F: "lczhis" redo "redo01.log

ORA-367 signalled during: Alter database recover logfile 'f: "lczhis" redo "redo01.log '...

Thuoct 16 22:35:36 2008

Alter database recover cancel

ORA-1547 signalled during: Alter database recover cancel...

Thuoct 16 22:36:46 2008

Insomnia on Friday night. I plan to switch the logfile and back up it again. This is good. For 8 years of data, I have failed to try the available methods on the Internet. It is not difficult to say that the current log is damaged. How can this problem be solved. Call an expert in Shenyang and plan to use the last straw DUl.

I suddenly thought of a problem. When I used the San, it seems that when the Lun exceeds 2 TB, the database creation on the Lun will fail. The reason is that the redo log cannot be created. Is this the reason? I remember the problem was solved by the original manufacturer of the disk array.

Use ultraedit to open the damaged redo log 1 and redo logs of other databases, and find the problem,

Figure 1

Figure 2

The storage addresses of SCN are different. I checked the logs of several databases and found that they are normal in Figure 2. This shows why I failed to fix the database in this disk array, the redo log and archive log cannot be created for the disk array.

Hurry up and ask San colleagues to drag a lun with no more than two TB to my database, copy all the databases to the new Lun, modify the drive letter, and change the original F disk to D, changing the new lun to F, and then using the above martial arts, still failed. The data of 1.3t was copied for a whole day, and the result failed. Do you really want to use DUl?

I copied the one I backed up after I found that the database was down. Instead, I decided to copy the original database directly and try again. The process is as follows:

1. Copy all the files in the original database down to the new Lun.

2. Delete all log files

3. SQL> startup Mount

4. SQL> recover database using backup controlfile until cancel;

5. SQL> cancel

6. SQL> alter database open resetlogs;

It's so excited that the database is open.

As to the cause of the first failure to use the new Lun, it is estimated that the database file backed up at that time is incorrect.

Backup is more important than everything.

If the budget permits, try to buy a disk array from a large factory. The cheap goods have been tested less, which is really harmful.