Shulou(Shulou.com)05/31 Report--

This article will explain in detail what are the four situations about the loss of Redo. The editor thinks it is very practical, so I share it for you as a reference. I hope you can get something after reading this article.

one。 Description:

1. The current log mentioned below refers to the log status as CURRENT,ACTIVE, and the non-current log refers to the log status as INACTIVE.

two。 Regardless of archiving and non-archiving modes, Redo loss is the same in both modes.

two。 4 situations in which Redo is lost:

The first case: non-current log, close normally.

The second case: non-current log, abnormal shutdown.

The third case: the current log is closed normally.

The fourth case: the current log is not normally closed.

three。 Treatment method:

The first and second cases are handled in the same way, just clear the log file directly.

SQL > alter database clear logfile group 3

SQL > alter database clear unarchived logfile group 3ram / if the online Redo of the INACTIVE status has not been archived, add the keyword unarchived to complete the clear operation. (all ACTIVE,INACTIVE may not finish archiving. You can check the v$log.archived field whether the archiving is completed.)

Example:

SQL > startup mount

The ORACLE routine has been started.

Total System Global Area 263639040 bytes

Fixed Size 1384012 bytes

Variable Size 167772596 bytes

Database Buffers 88080384 bytes

Redo Buffers 6402048 bytes

The database is loaded.

SQL > select group#,thread#,status,archived from v$log

GROUP# THREAD# STATUS ARCHIV

-

1 1 CURRENT NO

3 1 ACTIVE NO

2 1 INACTIVE YES

SQL > alter database clear logfile group 3

Alter database clear logfile group 3

*

An error occurred on line 1:

ORA-01624: log 3 is required for emergency recovery of instance orcl (thread 1)

ORA-00312: online log 3 thread 1: e:\ APP\ ORADATA\ ORCL\ REDO03.LOG'

SQL > alter database clear logfile group 2

The database has changed.

The way to deal with the third situation:

SQL > startup mount

SQL > recover database until cancel

SQL > alter database open resetlogs

Example 1:

SQL > shutdown immediate

The database has been closed.

The database has been uninstalled.

The ORACLE routine has been closed.

SQL > startup mount

The ORACLE routine has been started.

Total System Global Area 263639040 bytes

Fixed Size 1384012 bytes

Variable Size 167772596 bytes

Database Buffers 88080384 bytes

Redo Buffers 6402048 bytes

The database is loaded.

SQL > alter database open resetlogs

Alter database open resetlogs

*

An error occurred on line 1:

ORA-01139: the RESETLOGS option is valid only after an incomplete database recovery

SQL > recover database until cancel

Complete the media recovery.

SQL > alter database open resetlogs

The database has changed.

Example 2 (the second treatment for the third case):

SQL > shutdown immediate

The database has been closed.

The database has been uninstalled.

The ORACLE routine has been closed.

SQL > startup mount

The ORACLE routine has been started.

Total System Global Area 263639040 bytes

Fixed Size 1384012 bytes

Variable Size 167772596 bytes

Database Buffers 88080384 bytes

Redo Buffers 6402048 bytes

The database is loaded.

SQL > select group#,thread#,status,archived from v$log

GROUP# THREAD# STATUS ARCHIV

-

1 1 CURRENT NO

3 1 INACTIVE YES

2 1 INACTIVE YES

SQL > alter database clear logfile group 2

The database has changed.

SQL > alter database clear logfile group 3

The database has changed.

SQL > alter database clear unarchived logfile group 1

The database has changed.

Here the Redo log filegroup of CURRENT can be clear unarchived.

SQL > alter database open

The database has changed.

If the Redo log file is missing, a new Redo log file will be created in the original location after the clear operation is completed.

The way to deal with the fourth situation:

1. Restore and restore data through backup.

two。 By modifying the parameters in the parameter file

_ allow_resetlogs_corruption=TRUE

To force the database to start. Select file#,checkpoint_change#,fuzzy from v$datafile_header

FILE# CHECKPOINT_CHANGE# FUZ

-

1 1165820 YES

2 1165820 YES

3 1165820 YES

4 1165820 YES

FUZZY bit in datafile header means that there may have been writes into a datafile after the last checkpoint. E. g. There may be changes written to datafile with higher SCN than checkpoint_change# stored in datafile header (seen from v$datafile_header.checkpoint_change#).

FUZYY indicates fuzziness, which means that the data file is in a fuzzy state. After the last CHECKPOINT, the data on the file may have been modified, but it has not been updated to the file (or the file does not know it). You need to read the log information to determine.

SQL > select file#,checkpoint_change#,last_change# from v$datafile

FILE# CHECKPOINT_CHANGE# LAST_CHANGE#

1 1165820

2 1165820

3 1165820

4 1165820

Since the database is open, the termination SCN is empty. The content of SCN can be found in the article: http://space.itpub.net/23135684/viewspace-627343

SQL > shutdown immediate

The database has been closed.

The database has been uninstalled.

The ORACLE routine has been closed.

SQL > startup mount

The ORACLE routine has been started.

Total System Global Area 313860096 bytes

Fixed Size 1384352 bytes

Variable Size 155189344 bytes

Database Buffers 150994944 bytes

Redo Buffers 6291456 bytes

The database is loaded.

SQL > select file#,checkpoint_change#,fuzzy from v$datafile_header

FILE# CHECKPOINT_CHANGE# FUZ

-

1 1166324 NO

2 1166324 NO

3 1166324 NO

4 1166324 NO

In the case of a normal database shutdown, the FUZZY field should be NO, indicating that no obscure SCN is stored in the data file.

SQL > select file#,checkpoint_change#,last_change# from v$datafile

FILE# CHECKPOINT_CHANGE# LAST_CHANGE#

1 1166324 1166324

2 1166324 1166324

3 1166324 1166324

4 1166324 1166324

The terminating SCN of normally shutting down the database should be the same as starting SCN. FUZZY equals NO, and the termination SCN of the database equals startup SCN equals the datafile SCN, so the database can be considered to be shut down normally, and there is no need to perform an instance recovery or Crash recovery before opening the database.

SQL > alter database open

The database has changed.

SQL > shutdown abort

The ORACLE routine has been closed.

SQL > startup mount

The ORACLE routine has been started.

Total System Global Area 313860096 bytes

Fixed Size 1384352 bytes

Variable Size 155189344 bytes

Database Buffers 150994944 bytes

Redo Buffers 6291456 bytes

The database is loaded.

SQL > select file#,checkpoint_change#,fuzzy from v$datafile_header

FILE# CHECKPOINT_CHANGE# FUZ

-

1 1166327 YES

2 1166327 YES

3 1166327 YES

4 1166327 YES

The database instance is shut down abnormally, and the value of the FUZZY field is YES.

SQL > select file#,checkpoint_change#,last_change# from v$datafile

FILE# CHECKPOINT_CHANGE# LAST_CHANGE#

1 1166327

2 1166327

3 1166327

4 1166327

The database instance is shut down abnormally, and the termination SCN is still empty. Then, you must use archived Redo logs to complete instance recovery or Crash recovery before the database is opened.

This is the end of this article on "what are the four situations in which Redo is lost?". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.