Parnassusdata Software Database Recovery Team

Service Hotline:  +86 13764045638 E-mail: service@parnassusdata.com

APPLIES TO:

Oracle Database - Personal Edition - Version 10.2.0.1 and later

Oracle Database - Enterprise Edition - Version 10.2.0.1 and later

Oracle Database - Standard Edition - Version 10.2.0.1 and later

Information in this document applies to any platform.

***Checked for relevance on 01-JUL-2015***

PURPOSE

This article explains the various scenarios for ORA-01157 and how to avoid them.

SCOPE & APPLICATION

This article is intended for Oracle Support Analysts, Oracle Consultants and 
Database Administrators.
 

TROUBLESHOOTING STEPS

How to Recover from a Lost Datafile in Different Scenarios

In the event of a lost datafile or when the file cannot be accessed an ORA-01157
is reported followed by ORA-01110. 

Besides this, you may encounter error ORA-07360 : sfifi: stat error, unable to 
obtain information about file. A DBWR trace file is also generated in the 
background_dump_dest directory.  If an attempt is made to shutdown the database 
normal or immediate will result in ORA-01116, ORA-01110 and possibly ORA-07368.

This article discusses various scenarios that may be causing this error and the  
solution/workaround for these.

Throughout this note we refer to "backups" but if you have a valid physical standby database 
you may also use the standby database's datafiles to recover the primary database.

Datafile not found by Oracle

- Unintentionally renamed or moved at the Operating System (OS) level.
  Simply restore the file to its original location and recover it

- Intentionally moved/renamed at OS level.
  You are re-organising the datafile layout across various disks at the OS. 
  After moving/renaming the file you will have to rename the file at database 
  level, and recover it.

Note:115424.1 How to Rename or Move Datafiles and Logfiles

Datafile damaged/deleted

If the file is damaged/deleted and an attempt is made to start the database 
will result in ORA-01157, ORA-01110. Then depending upon the type of datafile 
lost different action needs to be taken. Check for a faulty hard disk. The 
file may have gone corrupt due to faulty disk. Replace the bad disk or create 
the file on a non-faulty disk.

Lost datafile could be in one of the following:

1. Temporary tablespace
   
   If the datafile belongs to a temporary tablespace, you will have to simply offline
   drop the datafile and then drop the tablespace with including contents option.
   Thereafter, re-create the temporary tablespace.

   Note.184327.1 Common Causes and Solutions on ORA-1157 Error Found in Backup & Recovery

2. Read Only Tablespace
   
   In this case you will have to restore the most recent backup of the read-only 
   datafile. No media recovery is required as read-only tablespaces are not 
   modified. Note however that media recovery will be required under the following conditions: 

   a. The tablespace was in read-write mode when the last backup was taken
      and was made read-only afterwards.

   b. The tablespace was in read-only mode when last backup was taken and
      was made read-write in between and then again made read only

   In either of the above cases you will have to restore the file and do a media 
   recovery using RECOVER DATAFILE statement. Apply all the necessary archived redo 
   logs until you get the message "Media Recovery Complete".

   Note.184327.1 Common Causes and Solutions on ORA-1157 Error Found in Backup & Recovery

3. User Tablespace
   
   Two options are available:

   a. Recreate the user tablespace.
      If all the objects in the tablespace can be re-created (recent export is 
      available; tables can be re-populated using scripts; SQL*Loader etc)
      Then, offline drop the datafile, drop the tablespace with including 
      contents option. Thereafter, re-create the tablespace and re-create 
      the objects in it.

   b. Restore file from backup and do a media recovery.
      Database has to be in archivelog mode.If the database is in NOARCHIVELOG 
      mode, you will only succeed in recovering the datafile if the redo to be 
      applied to it is within the range of your online redo logs.

   Note.184327.1 Common Causes and Solutions on ORA-1157 Error Found in Backup & Recovery

4. Index Tablespace
   
   Two options are available:

   a. Recreate the Index tablespace
      If the index can be easily re-created using script or manual CREATE INDEX
      statement, then best option is to offline drop the datafile,drop the 
      index tablespace, and re-create it and recreate all indexes in it.

   b. Restore file from backup and do a media recovery.
      If the index tablespace cannot be easily re-created, then restore the 
      lost datafile from a valid backup and then do a media recovery on it.

   Note.184327.1 Common Causes and Solutions on ORA-1157 Error Found in Backup & Recovery

5. System (and/or Sysaux) Tablespace
   
   a. Restore from a valid backup and perform a media recovery on it

   b. Rebuild the database.
      If neither backup of the datafile nor the full database backup is 
      available, then rebuild database using full export, user level/table 
      level export, scripts, SQL*Loader, standby etc. to re-create and 
      re-populate the database.

   Note.184327.1 Common Causes and Solutions on ORA-1157 Error Found in Backup & Recovery

6. Undo Tablespace
   
   While handling situation with lost datafile of an undo tablespace you need to
   be extra cautious so as not to lose active transactions in the undo segments. 

   The preferred option in this case is to restore the datafile from backup and 
   perform media recovery.

      i.  If the database was cleanly shutdown.
          Ensure that database was cleanly shutdown in NORMAL or IMMEDIATE mode.
          Update your init file with "undo_management=manual"
          Restart the database
          Drop and recreate the undo tablespace
          Update your init file with "undo_management=auto"
          Restart the database

      ii. If the database was NOT cleanly shutdown.
          If the database was shutdown aborted or crashed, you may not be able to drop 
          the datafile as the undo segments may contain active transactions. 
          You will need to restore the file from a backup 
          and perform a media recovery. 

7. Lost Controlfiles and Online Redo Logs
   
   If the datafiles are in a consistent state, not needing media recovery, but you have lost 
   all the controlfiles and online redologs, then while 
   attempting to create controlfile using scripts will complain of missing 
   redologs. In this case use RESETLOGS option of the create controlfile 
   script and then open the database with RESETLOGS option.

8. Lost datafile and no backup
   
   If there are no backups of the lost datafile then you can re-create the 
   datafile with the same size as the original file and then apply all the 
   archived redologs written since original datafile was created to the new
   version of the lost datafile.
 

 
   Note:1060605.6 Lost datafile and no backup.