Simple REDO file corruption error ORA-00333 REDO log read Block Error

Source: Internet
Author: User

Simple REDO file corruption error ORA-00333 REDO log read Block Error
I. fault description

First, the REDO file required for instance recovery is damaged.

Ii. solution 1. Use the following CLEAR command for non-current REDO or current REDO but no active transactions:

Use the CLEAR command to recreate the log file SQL> alter database clear logfile group 3;

If the log group is not archived, use SQL> alter database clear unarchived logfile group 3;

Because the REDO is required for the current instance recovery and is not archived, it is not feasible to use the CLEAR command. 2. There is no backup. If there is a backup, refer to the following:

Copy the full backup of a valid database and do not completely restore the database.

Until SCN recovery or until cnacel recovery can be used to obtain the nearest scn.

Recover database until cancel

Select auto first, restore the available archived logs as much as possible, and then try again

Recover database until cancel

The input cancel is incomplete, that is, it is restored twice. For example:

SQL> recover database until cancel;
Auto
......
SQL> recover database until cancel;
Cancel;

Use alter database open resetlogs to open a database

Note:

In this way, the recovered database is consistent and incomplete, and transaction data in the current online log is lost.

This method is suitable for archiving databases and full backup of available databases.

After the recovery is successful, remember to make a full backup of the database again.

It is recommended that online log files be stored on different disks to avoid this situation, because any data loss is not allowed in production.

3. Modify the implicit parameter _ allow_resetlogs_upload uption

_ Allow_resetlogs_upload uption = TRUE

Restart the database and use until cancel to restore the database.

SQL> recover database until cancel;
Cancel

If an error occurs, ignore it and send it.

SQL> alter database open resetlogs;

After the database is opened, immediately execute a full export

Shutdown database, remove _ all_resetlogs_corrupt parameter 2. Reference EYGLE: ORA-00600 kcratr1_lostwrt solution and Principle Analysis
Ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [kcratr1_lostwrt], [], [], [], [], [], [], [], []
Current SQL statement for this session:
Alter database open
This error is not difficult to solve, but the specific cause is a bit interesting.
Metalink has only one key explanation for this error:
When an instance is restarted following an instance crash, Oracle carries out some checks against the last block that was written to disk prior to the instance crash.
If Oracle finds an old block, then this suggests a lost write and the error is raised.
This statement means that when the instance is started after the crash, Oracle will check the last data block written before the crash and check whether it is consistent through the control file. If the block is Old, the Final write operation is lost.

This is a very quick and clever judgment. If there is a write loss, it is necessary to introduce restoration.

Detailed information is recorded in the trace file:
Last BWR afn: 6 rdba: 0x18f9590 (blk 1021328) ver: 0x0001. 5c21fd6e. 01 flg: 0x04
Disk version: 0x0001. 5c1ec4f0. 04 flag: 0x04
Note: The last data block written to the control file is file6 block 1021328, the SCN version is 5c21fd6e, And the SCN recorded on the data file is 5c1ec4f0, the latter is Old, less than the former, which indicates that the write operation is lost.

Can it be restored? The following information is also recorded in the trace file:
Thread checkpoint rba: 0x00dfeb. 00000002.0010 scn: 0x0001. 5c1ee5b7
On-disk rba: 0x00dfeb. 0001_1f. 0000 scn: 0x0001. 5c2266d6
The SCN of the thread checkpoint is 5c1ee5b7, And the SCN of On-Disk Rba is 5c2266d6, which can be deduced to exceed 5c21fd6e and can be recovered.

So the problem is:
SQL> startup mount;
SQL> recover database;
SQL> alter database open;
Generally, the recovery can be completed. if, unfortunately, your On-Disk Rba is insufficient to restore the lost write operation, the problem will be serious.

Reference: http://blog.itpub.net/25964700/viewspace-709097/ http://www.eygle.com/archives/2010/05/ora-00600_kcratr1_lostwrt.html

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.