Oracle Database Recovery - Research Proposal Example

of the of the 12 March Recovering Oracle The Oracle database includes a number of interconnected parts that are used for recovering a database that can be processed via elimination. This can be done by identifying the elements that are not able to work properly and then separating them from working elements. In addition, the recovery process follows the guidelines that are previously present and works without considering the backup methodologies. A flowchart is present that contains several steps and elements that will help to ease the recovery procedure. Step 1: Startup Mounting Initially, in order to verify the conditions present in a typical Oracle database we need to mount first. The mounting technique helps a database to read files without opening them. The Oracle tries to initialize each and every control files available in the initORACLE_SID.ora file, if the files are replicated. The any control file is broken the mounting techniques fails. In order to configure a database, first we need to run svrmgrl, and secondly connect it to the database and finally enter (Preston, 1999): startup mount. “$ svrmgrl SVRMGR > connect internal; Connected. SVRMGR > startup mount; Statement processed” If the above procedure accomplished then the output must seems to be like this (Preston, 1999): “SVRMGR > startup mount; ORACLE instance started. Total System Global Area 5130648 bytes Fixed Size 44924 bytes Variable Size 4151836 bytes Database Buffers 409600 bytes Redo Buffers 524288 bytes Database mounted” The mounting of the database if turn successful then step 10 must be performed. On the contrary, if the mounting process fails than the output seems like this (Preston, 1999): “SVRMGR > startup mount; Total System Global Area 5130648 bytes Fixed Size 44924 bytes Variable Size 4151836 bytes Database Buffer to s 409600 bytes Redo Buffers 524288 bytes ORACLE instance started. ORA-00205: error in identifying controlfile, check alert log for more info” If the mounting process of the database fails to succeed than continue to Step 2. Step 2: All related Control Files are not available? If the mounting of database fails to succeed than there is no need to worry. This is because the control files can be simply restored if the files are replicated. Moreover, these files can easily be recreated if required. The core element regarding data and information portrays impact on more than one control files that are missing. This is due to the fact that Oracle abandons the mounting files that come across failure. Hence, the files are missing if the mounting procedure fails. Therefore, before taking any action, first we need to determine the seriousness of the problem. This can be done by researching on the situation. Initial research includes the names of the missing control files by doing configORACLE_SID.ora file subsequently to the word control files. It looks somewhat like this (Preston, 1999): “control_files = (/db/Oracle/a/oradata/crash/control01.ctl, /db/Oracle/b/oradata/crash/control02.ctl, /db/Oracle/c/oradata/crash/control03.ctl)” (Rajan, 2006 ) The control file name that is criticized by Oracle should be found. This can be found by searching for this phrase control file that is maintained in the alert logs. Moreover, the alert log can be found in particular location such as ‘background_dump_dest’ and ‘configinstance.ora’ file. In general, it is present in the file named as ORACLE_BASE/ORACLE_SID/admin/bdump’directory. A file named as ‘alert_ORACLE_SID.log’ must be present in directory. The error looks like this (Preston, 1999): alter database mount exclusive ORA-00202: controlfile: '/db/a/oradata/crash/control01.ctl' ORA-27037: unable to obtain file status SVR4 Error: 2: No such file or directory” The name of all the control files along with crashed file names, it is relatively easier to analyze the complexity of the issue. This can be achieved by listing control files with their comparison with the size and time of any change and modification. In the current scenario, the control files are replicated to 3 locations that is a daily practice every day. The scenarios are mentioned as: The corrupt or damaged file is not available and one of the file is available. If the missing file pertains to Oracle, it is not difficult to fix it. We can consider that the file is associated with Oracle, the corrupt file is present but it is available on the system. Likewise, it is difficult to predict that the file is corrupt, as self-judgment is preferred. However, before perusing any further steps, backup copies should be made for all control files. Within the shell, all the 3 control files should be copied to the two locations. After copying the files safely, database mounting should me made again, as mentioned in Substitute Missing Control File i.e. step 3. Although, if there is a presence of all redo log files, than the next step will be to initiate ‘create control file’ script, as mentioned in further steps. By initiating this script, the control files are regenerated to all the three sites in an automated manner. The whole database must be rebuilt or recreated, in case of corruption of control files. The corrupt files are present in different sizes. In addition, the backup system is running the backup control file to trace command that is executed on a standard basis. Moreover, the command output is in the form of an SQL script that will rebuild or restore the control files in an automated process. In case of ‘backup control file to trace’ command execution, continue to Steps four till Seven. If it is not running, then continue to Step Eight. Step 3: Substitute Lost Control File In order to replace the control files that contains dissimilar time and date, simply copy the paralleled control file copies to the location and name of the corrupt file. The details are mentioned below. Now after completing this procedure, mounting of database can be performed again. Alert log is mentioned below (Preston, 1999): alter database mount exclusive ORA-00202: controlfile: '/db/a/oradata/crash/control01.ctl' ORA-27037: unable to obtain file status SVR4 Error: 2: No such file or directory Before copying any file, it is suggested to make backups for all the control files. After that, control file should be copied to the corrupt control file’s location. Finally, after completing this step, go to Step 1 and start the mounting procedure. The control files contain dissimilar dates and sizes and there is also a possibility that good control files are not present. In this case, utilize the “create control file” script is the best option. In order to utilize this option “create control file” script, continue to the Steps 4 and 7. If this is not possible then try to make backup files for all the control files. Now try to copy each and each version associated with control file to new location. Every time a new control file is copied to different locations therefore, it is better to return toward step 1. For instance, suppose that there are 3 control files are available: /a/control1.ctl, /b/control2.ctl and /c/control3.ctl. The alert log elaborates that this /c/control3.ctl is corrupted and therefore  /a/control1.ctl and /b/control2.ctl contains different modifications. The following steps should be performed. Initially, backup duplicates of all files are created (Preston, 1999): $ cp /a/control1.ctl /a/control1.ctl.sav $ cp /b/control2.ctl /b/control2.ctl.sav $ cp /c/control3.ctl /c/control3.ctl.sav Secondly, copy one file to all the locations. Skip control3.ctl, because it's apparently damaged. Moreover, try to start with control1.ctl (Preston, 1999): $ cp /a/control1.ctl /b/control2.ctl $ cp /a/control1.ctl /c/control3.ctl At this time effort startups mounting (Preston, 1999): $ svrmgrl SVRMGR > connect internal;  Connected. SVRMGR > startup mount alter database mount exclusive ORA-00202: controlfile: '/a/control3.ctl' ORA-27037: unable to obtain file status The above mentioned error pronounces that the file to facilitate was replicated to all locations is also corrupt. At this instant try the second file, control2.ctl (Preston, 1999): $ cp /b/control2.ctl /a/control1.ctl $ cp /b/control2.ctl /a/control3.ctl Finally try to perform a startup mounting (Preston, 1999): SVRMGR > startup mount; ORACLE instance started. Total System Global Area 5130648 bytes Fixed Size 44924 bytes Variable Size 4151836 bytes Database Buffers 409600 bytes Redo Buffers 524288 bytes Database mounted. It emerges that control2.ctl was a high-quality control file replica. If the mounting of database is performed successfully than Step 10 should be performed. Step 4: Health status of all Data Files and Redo Logs is good? Before performing Step 6, the Steps 4 and 5 should be performed successfully. However, in Step 7 the “create control files” script that is mentioned only works if all the data files and online reconstruct a log that is in working condition. The data files that are stored can be of older version but this can be forwarded to media recovery. In addition, for the “create control file” script related to work, the online reconstruct log must be in progress. Each and every data file includes a System Change Number (SCN) that communicates in a positive online reconstruct logs. In fact, in case of a data file that demonstrates that SCN is present in current situation than the online reconstruct logs, the control files reconstruct process will terminate. Step 5: Recovery of Corrupt Data Files or Redo Logs In order to recover the corrupt data files or online reconstruct logs, the instructions are mentioned below. If all the data files or online reconstruct logs are not damaged than this step is avoided and preceded to creating control files. Now after the control files are recreated Step 6 must be performed. In order to find out the location of data files and online reconstruct logs following command on the mount must be performed (Preston, 1999): SVRMGR > connect internal;  Connected. SVRMGR > select name from v$datafile; (Example output below) SVRMGR > select group#, member from v$logfile; (Example output below) Figure B contains sample output from these commands: SVRMGR > select name from v$datafile; NAME -------------------------------------------------------------------------------- /db/Oracle/a/oradata/crash/system01.dbf /db/Oracle/a/oradata/crash/rbs01.dbf /db/Oracle/a/oradata/crash/temp01.dbf /db/Oracle/a/oradata/crash/tools01.dbf /db/Oracle/a/oradata/crash/users01.dbf /db/Oracle/a/oradata/crash/test01.dbf 6 rows selected. SVRMGR > select group#, member from v$logfile; MEMBER -------------------------------------------------------------------------------- 1 /db/Oracle/a/oradata/crash/redocrash01.log 3 /db/Oracle/c/oradata/crash/redocrash03.log 2 /db/Oracle/b/oradata/crash/redocrash02.log 1 /db/Oracle/b/oradata/crash/redocrash01.log 2 /db/Oracle/a/oradata/crash/redocrash03.log 3 /db/Oracle/c/oradata/crash/redocrash02.log 6 rows selected. SVRMGR > All the reconstructed logs that are present in at least one group are damaged. The Step 6 needs to include the “create control file” script and al the rebuild logs. In fact, even one log group is corrupted than it is not possible to rebuild the control file. Now only alternative way is to proceed to Steps 23 and 24. (Oracle Db 10G Rman Backup & Recovery, 2006) The complete recovery for the whole database is followed by an alter database open reset logs. If the rebuild logs are all accurate, and all control files are misplaced than proceed to Step 6. In addition, if the database becomes unlocked for some other reason. Step 6: Is "create control file" Script available? The Step 4 and Step 5 must be performed before this step. The svrmgrl l command alter database backup control file to trace generates a trace file that includes a “create control file” script. Step 7: Initialize the 'create controlfile' Script Initially, the trace file must be discovered that enclose the script. The guidelines for the accomplishment of this step are mentioned in step 6. Now the file is uncover we need to copy it to another filename for example rebuild.sql. Finally, edit the file, delete everything present above this phrase # The following commands will create, and also delete anything after the SQL command Step 8: Restoration of Control Files and Preparation of Database for Recovery The step 8 is required when the steps from 2 to 7 fails. Work Cited Oracle Db 10G Rman Backup & Recovery. McGraw-Hill Education (India) Pvt Limited, 2006. Print. Preston, W. C. Unix Backup & Recovery. O'Reilly Vlg. GmbH & Company, 1999. Print. Rajan, C. Oracle 10g Database Administrator II: Backup/Recovery & Network Administration. Course Technology Ptr, 2006. Print. Read More