Oracle database system emergency fault handling method

The ORACLE tutorial you are looking at is the Oracle database system emergency troubleshooting method.

Oracle physical structure failure refers to various database failures caused by the corruption of the physical files that make up the database. These failures may be caused by hardware failures or by human error. So we first have to determine the cause of the problem, and if it's a hardware failure we first have to fix the hardware problem. Only if there is no hardware problem can we send the next step to the processor below.

Control file damage:

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. Control file corruption, can cause the database to shut down. Lack of control file, database can not start, this is a serious error.

Damage single control file:

1. Make sure the database is closed if you don't use the following command:

svrmgrl > shutdown immediate;

2. Check the initialization file $ORACLE_BASE admin/pfile/initORCL ora, make sure all the path of the control file.

3. Use operating system commands to overwrite the wrong control files with other correct control files.

4. Restart the database with the following command:

svrmgrl > startup;

5. Make a full backup of the database in an appropriate way.

Corrupt all control files:

1. Make sure the database is closed if you don't use the following command:

svrmgrl > shutdown immediate;

2. Restore the most recent control file from the corresponding backup result set. For the point that has not used the library backup, the latest control file backup can be restored to the corresponding directory directly from the tape. Restore the most recent control file with the appropriate rman script for the point with library backup.

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

svrmgrl > startup mount;

svrmgrl > alter database backup controlfile to trace noresetlogs;

4. Modify the trace file generated in step 3, copy and modify part 1 of the statement about creating the control file so that it can reflect the latest database structure. Assume that the resulting sql file name is createcontrol.sql.

Note:

A specific path Trace files to the execution of the step 3) after the operation the $ORACLE_BASE admin/bdump/alert_ORCL ora files to determine.

5. Recreate the control file with the following command:

svrmgrl > shutdown abort;

svrmgrl > startup nomount;

svrmgrl > @createcontrol.sql;

6. Do a full database backup in the appropriate way.

Redo log file corrupted:

All additions, deletions, and changes to the database will be logged in the redo log. If the currently activated redo log file is corrupted, the database will be shut down abnormally. A deactivated redo log will eventually become an active redo log due to log switching, so a corrupted deactivated redo log will eventually result in an abnormal termination of the database. In ipas/mSwitch, there is only one member per redo log group, so only the redo log group corruption is considered in the following analysis, not the single redo log member corruption.

Determine the location and status of the corrupted redo log:

1. If the database is available:

select * from v $logfile;

svrmgrl > select * from v$log;

2. If the database has been abnormally terminated:

svrmlgr > startup mount;
svrmgrl > select * from v$logfile;
svrmgrl > select * from v$log;

Among them, the state of logfile is INVALID, indicating that this group of log files has been damaged. The state of log is Inactive: means that the redo log file is in an inactive state; Active: means the redo log file is active; Current: represents a redo log for the currently in use log file.

The corrupted log file is in an inactive state:

1. Delete the corresponding log group:

svrmgrl > alter database drop logfile group group_number;

2. Recreate 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 in the active state and is not 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:

Clear the corresponding log group with the command:

svrmgrl > alter database clear unarchived logfile group group_number;

If the cleanup fails, only point-in-time incomplete recovery can be done.

Open the database and do a full backup of the database in the appropriate way:

svrmgrl > alter database open;

[NextPage]

Some data files are corrupted:

If the corrupted data file belongs to a non-system table space, the database can still be opened for operation, but the corrupted data file cannot be accessed. The corrupted data files can be recovered separately while the database is open. The database system terminates abnormally if the data files in the system table space are corrupted. The database can only be opened in Mount and then the data files can be recovered. You can determine whether the currently corrupted data file belongs to the system table space by looking at the database log file.

On 1 page