Emergency fault handling method for Oracle database system _oracle

The Oracle tutorial you are looking at is an emergency troubleshooting approach to Oracle database systems.

An Oracle physical structure failure is a variety of database failures that result from corruption of each physical file that constitutes a database. These failures may be caused by a hardware failure or by a human error. So we first need to determine the cause of the problem, if it is a hardware failure first to solve the hardware problem. In the absence of hardware problems, we can follow the following processing side to further processing.

Control file corruption:

The control file records important configuration information about Oracle, such as database name, character set name, individual data files, location of log files, and so on. Controlling file corruption can cause the database to shut down abnormally. Once the control file is missing, the database does not start, which is a more serious error.

To corrupt a single control file:

1. Make sure that the database is turned off without using the following command to close the database:

Svrmgrl>shutdown immediate;

2. View initialization file $oracle_base/admin/pfile/initorcl.ora, and determine the path to all control files.
　
3. Overwrite the wrong control file with the other correct control file with the operating system command.

4. Restart the database with the following command:

svrmgrl>startup;

5. Use the appropriate method for database full backup.

Damage to all control files:

1. Make sure that the database is turned off without using the following command to close the database:

Svrmgrl>shutdown immediate;

2. Restore the most recent control files from the corresponding backup result set. For points that do not take a library backup, the closest control file backup can be recovered directly from the tape to the appropriate directory, and the appropriate Rman script is used to restore the most recent control file for points with a library backup.

3. Use the following command to create a script that produces a database control file:

Svrmgrl>startup Mount;

Svrmgrl>alter database backup controlfile to trace noresetlogs;

4. Modify the trace file generated in step three to copy and modify some of the statements about creating the control file so that it can reflect the latest database structure. Assume that the resulting SQL file name is createcontrol.sql.

Attention:

The exact path of the trace file can be determined by viewing the $oracle_base/admin/bdump/alert_orcl.ora file after performing the 3rd step.

5. Recreate the control file with the following command:

Svrmgrl>shutdown abort;

Svrmgrl>startup Nomount;

Svrmgrl> @createcontrol. sql;

6. Use the appropriate method for database full backup.

Redo log file corruption:

The database of all the increase, deletion, change will be recorded in the Redo log. If the currently active redo log file is corrupted, it causes the database to shut down abnormally. Inactive redo logs end up with log switching becoming active redo logs, so corrupted inactive redo logs can eventually cause the database to terminate abnormally. Each group of redo logs in Ipas/mswitch has only one member, so in the following analysis only the corruption of the Redo log group is considered, regardless of the corruption of individual redo log members.

Determine the location of the corrupted redo log and its status:

1. If the database is in a usable state:

SELECT * from V$logfile;

Svrmgrl>select * from V$log;

2. If the database is terminated abnormally:

Svrmlgr>startup Mount;
Svrmgrl>select * from V$logfile;
Svrmgrl>select * from V$log;

Where the logfile state is invalid to indicate that the log file has been corrupted; log state is inactive: The Redo log file is inactive; active: Indicates that the Redo log file is in the active state ; Current: Indicates that the redo log is the log file that is currently in use.

The corrupted log file is not active:

1. Delete the corresponding log group:

Svrmgrl>alter database drop logfile Group group_number;

2. Re-create the corresponding log group:

Svrmgrl>alter Database Add log file group Group_number (' Log_file_descritpion ', ...) ) Size log_file_size;

The corrupted log file is active and is not in the current log:

1. Clear the corresponding log group:

Svrmgrl>alter Database Clear unarchived logfile Group Group_number;

The corrupted log file is the current active log file:

To clear the appropriate log group with a command:

Svrmgrl>alter Database Clear unarchived logfile Group Group_number;

If the purge fails, you can only do incomplete recovery based on Point-in-time.

Open the database and use the appropriate method for full database backup:

Svrmgrl>alter database open;

[NextPage]

Partial data file corruption:

If the corrupted data file belongs to a non-system tablespace, the database can still be open for operation, except that the corrupted data file is inaccessible. In this case, the corrupted data file can be recovered separately in the database open state. The database system terminates abnormally if the data file in the system table space is corrupted. The database can only be opened in Mount mode before the data file is restored. You can view the database log file to determine whether the currently corrupted data file belongs to the system tablespace.

Previous page