Re: Recovery Solutions - URGENT

[Tim Gorman]

Jay,   If any redo log file is corrupted (i.e. online or archived), nothing has happened to you *yet*.  It is just that every transaction committed by the database now is unrecoverable after the point of corruption.  So, your response is based on your requirements.  If protecting every single transaction is less important than availability/uptime, then you start a hot backup immediately and just hope/pray that it completes successfully.  If protecting every single transaction against loss is more important than availability/uptime, then you shutdown the database immediately and take a full cold backup.  Of course, if you are in NOARCHIVELOG mode, then your only option is the latter.  The key is understanding your businesses priorities first and preparing accordingly.  Too often, DBAs make decisions without asking the users about their requirements.   If the SYSTEM tablespace is corrupted, then your options depend on what types of backups you've been taking most recently.  If you are in ARCHIVELOG mode and have been taking hot or cold backups and have been backing up the archived redo log files, then you have better options.  If you are in NOARCHIVELOG mode and have only been taking cold backups, then you have only one option.  Either way, you'll have to SHUTDOWN the database and then STARTUP MOUNT and RESTORE TABLESPACE SYSTEM.  If you are in NOARCHIVELOG mode, then I suspect that RMAN will fail immediately and instruct you to RESTORE DATABASE instead, as restoring only the corrupted datafiles is not an option.  Or, you may not get a message until you attempt to RECOVER DATABASE.  Read the RMAN Users Guide (available online at http://otn.oracle.com) or Robert Freeman's RMAN book from Oracle Press thoroughly, especially on the topics of RESTORE and RECOVERY.   ---   The main thing is:  don't over-react.  Possible redo log file corruption has not resulted in any loss of availability or data loss just yet.  It represents a potential loss of data, a very serious risk that must be addressed according to the requirements of the business.  Don't assume one way or the other without discussing the options with the business decision-makers first, long before the crisis...   With datafile corruption, whether to the SYSTEM tablespace or any other tablespace, your options depend on your preparation.  If you are running in NOARCHIVELOG mode, then your only option for recovery is to restore the entire database.  If you are running in ARCHIVELOG mode and have been taking proper backups (hot or cold) of the datafiles and archived redo log files, then you can get away with restoring only the corrupted datafile or, in 9i RMAN, in restoring only the corrupted blocks, and then performing recovery from the redo log files.  Remember that successful restore/recovery is dependent on the RMAN recovery repository (whether NOCATALOG or whether using a recovery CATALOG database) having up-to-date and accurate information.  In addition to backups, perform RESYNCHs (if using a recovery CATALOG database) and CROSSCHECKs frequently.  Always perform RESYNCH (if necessary) and CROSSCHECK prior to a RESTORE or RECOVERY command.  Use the reporting capabilities of RMAN to know whether something needs to be backed up or needs to be backed up more often.   Hope this helps...   -Tim ----- Original Message ----- From: [EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L Sent: Monday, February 03, 2003 9:13 PM Subject: Recovery Solutions - URGENT Dear friends, Could someone enlighten me on the steps to be carried out using RMAN and using OS commands for Recovery if : 1. A current redo log file is corrupted. 2. The System TS is corrupted. Thanks for your help in advance. Best Regards Jai