Oracle Physical Structure Fault Process: Oracle Physical Structure Fault refers to various database failures caused by the damage of each physical file constituting the database. These faults may be due to hardware failures, or may be caused by human malign. Therefore, we must first determine the cause of the problem. If it is a hardware failure, first solve the hardware problem. We can further process it in the premise of no hardware issues. Control file corruption: The control file records important configuration information about Oracle, such as database name, character set name, location of each data file, location of log files, etc. The damage to the control file will cause the database to abnormally shut down. Once the control file is missing, the database cannot be started, which is a more serious error. You can locate damaged control files by querying the log files of the database. The log file is located in $ oracle_base / admin / bdump / alert_orcl.ora. Corrupted a single control file: 1. Make sure the database is closed, if you do not use the following command to close the database: SVRMGRL> Shutdown Immediate; 2. View initialization file $ Oracle_base / admin /pfile/initorcl.ora, determine all the paths of all control files. 3. Use the operating system command to overwrite the correct control files. 4. Restart the database SVRMGRL> StartUp with the following command; 5. Perform the database full backup with an appropriate method. Damage to all control files: 1. Make sure the database has been turned off, if you do not use the following command to close the database: SVRMGRL> Shutdown Immediate; 2. Restore the most recent control file from the corresponding backup result. For points that do not use the library backup, you can restore the nearest control file backup to the corresponding directory directly from the tape; for the corresponding RMAN script to recover the most recent control files for the corresponding RMAN script with the corresponding RMAN script. 3. Use the following command to create a script that generates a database control file: SVRMGRL> Startup Mount; SVRMGRL> Alter Database Backup ControlFile To TRASETLOGS; 4. Modify the TRACE file generated by the third step to create some statements about the creation of control files Copy and make some modifications so that it can reflect the latest database structure. Assuming the generated SQL file name is CreateControl.sql. Note: The specific path of the Trace file can be determined after the end of the 3) step, after steping, view $ Oracle_base / admin / bdump / alert_orcl.ora file to determine. 5. Recreate the control file with the following command: SVRMGRL> Shutdown Abort; SVRMGRL> Startup Nomount; Svrmgrl> @ createControl.sql; 6. In the appropriate method, the database is fully backed up. Redo-saving log files corrupted: all the increase, deletion, and change of the database will record the logs. If the currently activated redo log file is corrupted, it will cause the database to abnormally shut down. Non-activated redo logs will eventually change due to log switching to activated redo logs, so corrupted non-activated redo logs will eventually lead to an exception of the database. Only one member of each group of logs in IPAS / MSwitch is only considering the case where the log group corruption is considered in the following analysis, regardless of the case where a single redo log member is damaged.
Determining the location of the damaged log and its status: 1. If the database is available: SVRMGRL> SELECT * FROM V $ log; 2. If the database is already extremely termination: SVRMLGR> Startup Mount; SVRMGRL> SELECT * FROM V $ logfile; SVRMGRL> Select * from v $ log; where the logfile status is INVALID indicates that this group log file has been corrupted; the log status is inactive: Represents the redo log file in an inactive state; ACTIVE : Represents the redo log file in an active state; CURRENT: Indicates that the redo log is the log file currently being used. Damaged log files are inactive: 1. Delete the corresponding log group: SVRMGRL> ALTER DATABASE DROP logfile group group_number; 2. Recreation of the corresponding log group: SVRMGRL> ALTER DATABASE Add log file group group_number ('log_file_descriptpion ", ... Size log_file_size; damaged log file is active and is a non-current log: 1. Clear the corresponding log group: SVRMGRL> ALTER DATABASE CLEAR UnarchiveD logfile group group_number; corrupted log file is the current activity log file: Clear the corresponding command Log Group: SVRMGRL> ALTER DATABASE CLEAR UNURCHIVED LOGFILE GROUP_NUMBER; if you fail, you can only do any time point-based incomplete recovery. Open the database and perform database full backup with the appropriate method: SVRMGRL> ALTER DATABASE OPEN; some data file corruption: If the damaged data files belong to non-System tablespace, the database can still be operable to operate, just damaged data files. Can not access. At this time, the damaged data file can be recovered separately in the database opening state. If the data file corruption of the SYSTEM table space will be extremely terminated. At this time, the database can only be opened in a mount method, and then restore the data file. You can determine whether the current corrupted data file is a system table space by viewing a database log file. Data file corruption in non-SYSTEM tables: 1. Determine corrupted file name: SVRMGRL> SELECT NAME FROM V $ datafile where status = 'invalid'; 2. Influine status to the corrupted data file: SVRMGRL> ALTER DATABASE DATAFILE 'DATAFILE_NAME 'OFFLINE; 3. Converted from the corresponding backup result to recover the nearest backup of this data file. For points that do not use the library backup, you can recover directly from the tape; for the corresponding RMAN script to the corresponding RMAN script with the point backup. 4. Restore data files: SVRMGRL> ALTABASE recover datafile 'file_name'; 5. Make Database file online: SVRMGRL> ALTER DATABASE DATAFILE 'DATAFILE_NAME' Online; 6. In the proper method, the database is fully backed up. Data file corruption in the SYSTEM table space: 1. Start database SVRMGRL> Startup Mount; 2. Restore the nearest backup of this data file from the corresponding backup result.
For points that do not use the library backup, you can recover directly from the tape; for the corresponding RMAN script to the corresponding RMAN script with the point backup. 3. Restore System Table Space: SVRMGRL> ALTABASE Recover DataFile 'DataFile_name'; 4. Open Database: Svrmgrl> ALTER DATABASE OPEN; 5. Perform database full backup with an appropriate method. Table space damage: If the SYSTEM table space has been damaged, the database can still be operable in the open state, just corrupted tablespaces cannot be accessed. This can be recovered separately in the database opening state. If the system tablespace is damaged, the database system will terminate. At this time, the database can only be opened in a mount, and then restore the tablespace. You can determine if the current corrugated table space is system table space. Non-system tablespace corruption: 1. Will damage the tablespace in the OFFLINE Status: SVRMGRL> ALTER TABLESPACE 'TABLESPACE_NAME' OFFLINE; 2. From the corresponding The backup result is set to recover the nearest backup of this table space. For points that do not use the library backup, you can recover directly from the tape; for the corresponding RMAN script to the corresponding RMAN script with the point backup. 3. Recovery tablespace: SVRMGRL> ALTABASE Recover TableSpace 'tablespace_name'; 4. Make Table Space Online: SVRMGRL> ALTER TABLESPACE 'TABLESPACE_NAME' Online; 5. Database full backup with the appropriate method .stem tablespace corruption: 1. Start the database SVRMGRL> Startup Mount; 2. Convert the nearest backup of the System tablespace from the corresponding backup result. For points that do not use the library backup, you can recover directly from the tape; for the corresponding RMAN script to the corresponding RMAN script with the point backup. 3. Restore System Table Space: SVRMGRL> ALTER DATABASE Recover TableSpace System; 4. Open Database: SVRMGRL> ALTER DATABASE OPEN; 5. Perform database full backup with an appropriate method. All files in the entire database are corrupted: the damage of all files across the database is typically happening when the shared disk array cannot be recovered. In this case, the database can only be recovered. If the archive directory of the database is already lost, the database is not possible to perform full recovery, and there will be the loss of user data. No site with library backup: 1. Pack each file into the corresponding directory on the tape. 2. Open the database in Mount; SVRMGRL> Startup Mount; 3. Recovery Database: SVRMGRL> Recover Database Until Cancel; 4. Open Database: SVRMGRL> ALTER DATABASE OPEN RESETLOGS; 5. In the appropriate method, the database is fully backed up. Some scenes with library backup: 1. Open the database in a Nomount mode: SVRMGRL> Startup Nomount; 2. Database soft recovery by the corresponding RMAN script. $ RMAN cmdfile = hot_database_restore.rcv3. Open Database: SVRMGRL> ALTER DATABASE OPEN RESETLOGS; 4. Perform database full backup with an appropriate method.
There are some classic emergency processes that have recent database completely cold backup: Data file, archive reconciliation logs and control files are lost or corrupted at the same time: No new Archives: Conditions and assumptions: Since the last mirror backup No new archive log (s); archivelog mode; synchronized DataFile (S) and Control File (S) copy recovery steps: 1. DataFile (s) and control file copying the mirror ) CC back to the original location: $ cp /backup/good_one.dbf /orig_loc/bad_one.dbf$ cp /backup/control1.ctl /disk1/control1.ctl2 to mount option to start the database:. $ svrmgrlsvrmgrl> connect internalsvrmgrl> startup mount3 Recovery database: SVRMGRL> Recover Database Using Backup ControlFile Until Cancel; *** Media Recovery Complete (Must on the Cancel) 4. RESET The logfiles: SVRMGRL> ALTER DATABASE OPEN Resetlogs; 5. Turn off the database and make a total storage cold backup. Status: Conditions and assumptions: Since the last image backup, new archive log (s); archivelog mode; synchronous DataFile (S) and the mirror (cold) copy of Control File (s); Archive log (s) is available.
Recovery steps: 1. If the database is not closed, first close it: $ SVRMGRLSVRMGRL> Connect InternalSvrmgrl> Shutdown Abort2. Cart backup file back to the original location: All Database Files All Control Files (no Archive (s) or Redo (S) In the case of the Control File, there is no meaning) All ON-Line Redo logs (not archives) init.ora file (option) 3. Start database: $ SVRMGRLSVRMGRL> Connect InternalsVRMGRL> Startup Data File, Relief Logs and Control Files are lost or corrupted: condition and assumptions: ArchiveLog mode; Mirror (cold) copy of all lost files; Archive log (s) can be used to recover steps (if not fully recovered): 1. If the database has not been Close, first close it: $ SVRMGRLSVRMGRL> Connect INTERNALSVRMGRL> ShutDown Abort2. Copy backup file back to the original location: All Database Files All Control Files All on-line redo logs (not archives) init.ora file (options) 3 Start the database, not open: SVRMGRL> Startup Mount4. Do not fully database recovery, Application All from the last image (cold) backup accumulated Archives: SVRMGRL> Recover Database Until Cancel Using Backup ControlFile; ..... ....... Cancel5. RESET The logfiles: SVRMGRL> ALTABASE OPEN RESETLOGS; 6. Turn off the database and make a full storage cold backup.
Data files and control files are lost or corrupted at the same time: condition and assumptions: ArchiveLog Mode; Synchronous DataFile (S) and Cold Copy of Control File (s); Archive log (s) Available Recovery steps: 1. Cold copy DataFiles (s) and Control File (s) Cc back Original location: $ cp /backup/good_one.dbf /orig_loc/bad_one.dbf full of cp /backup/control1.ctl /disk1/control1.ctl2. Start the database with the mount option: $ svrmgrlsvrmgrl> connect internalsvrmgrl> startup mount3 to the old control file to restore the database:. svrmgrl> recover database until cancel using backup controlfile; *** media recovery complete (to be completed in the application after the last archive log cancel) 4 Reset the. Logfiles (not illegal to start): SVRMGRL> ALTER DATABASE OPEN RESETLOGS; Relivery logs and control files are lost or corrupted at the same time: condition and assumptions: Control Files is missing or corrupted; archivelog mode; mirror with Control Files (cold Copy Recovery Steps: 1. If the database is not closed, first close it: $ SVRMGRLSVRMGRL> Connect Internalsvrmgrl> Shutdown AbortsVRMGRL> EXIT2. Copying Copying Copying Copying CONTROL FILE: $ CP / Backup / . control1.ctl /disk1/control1.ctl3 start the database does not yet opened: $ svrmgrlsvrmgrl> connect internalsvrmgrl> startup mount4 drop broken redo log (negative hardware failure):. svrmgrl> alter database drop logfile group 2; 5 again. Create REDO LOG: SVRMGRL> ALTER DATABASE Add Logfile Group 2 '/ Orig_LO C / log2.dbf 'size 10m; 6. Recovered databases in the old Control File: Svrmgrl> Recover Database Until Cancel Using Backup ControlFile; (must be cancel immediately) 7. RESET the logfiles: SVRMGRL > ALTER DATABASE OPEN RESETLOGS; 8. Close the database and do a full storage cool backup only when archive recovery log is lost or corrupted: according to different environments and conditions: a. Master BACKUP All DataFiles (if system The general hot spare or RMAN hot backup is used. Do not make backups, let the database run, until the next backup cycle is backed up again. This is an error that needs to be recovered before the next backup cycle arrives before the next backup period.
Note: Adventure Advance: If an error requires a database recovery, you can only restore the operation site before the problem archive log. From another perspective, if there is a problem with Archive log (s), it does not have any problems if it does not require recovery. Oracle Logic Structure Fault Process Method: The fault of logical structures generally refers to the situation of important data loss due to human misoperation. In this case, the database physical structure is complete and consistent. For this situation, it is not suitable for the full recovery of the original database, and we generally use three methods to restore user data. This way can be used using an Exp / IMP tool to recover user data: if the lost data has a backup used for an EXP command, you can use this way. 1. Create a temporary user in the database: SVRMGRL> CREATE USER TEST_USER IDENTIFIED BY TEST; SVRMGRL> GRANT Connect, Resource to Test_use; 2. Pour the lost data in the file in the file backup, pour the test user in the user : $ IMP System / Manager file = export_file_name Tables = (LOST_DATA_TABLE_NAME ...) fromuser = LOST_DATA_TABLE_OWNER TOUSER = TEST_USER CONSTRAINT = N; 3. Use the corresponding DML statement to restore the lost data from the test user to the original user. 4. Remove the test user: SVRMGRL> DROP user test_user casced; use logminer to restore user data: logminer is an Log Analysis Tool provided by Oracle. It can analyze the online online log, archive log, and can obtain historical records of the various DML operations of the database, and the fallback information of various DML operations. Based on these users, they can re-join the data lost due to false operation. 1. Verify that the UTL_FILE_DIR parameter of the database has been set, if not, you need to add this parameter to the initialization parameter file of Oracle, then restart the database. In the following example, it is assumed that UTL_FILE_DIR = '/ OPT / ORACLE / DB01'; 2. Create the data dictionary information required to create logminer, assume the generated data dictionary text file is DICT.ra: SVRMGRL> EXECUTE DBMS_LOGMNR_D.BUILD (Dictionary_FileName => Dict .ora ', Dictionary_location =>' / opt / oracle / db01 '); 3. Determine the range of logs or archive logs that need to be analyzed. This can determine the approximate log range according to the time of user misoperation. Assume that the user's misoperable log file is /opt/oracle/db02/oradata/orcl/redo3.log and archive log '/opt/oracle/arch/orcl/orclarc_1_113.ora'.
