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 control files and Online Redo Logs

If the datafiles are in a consistent state, not needing media recovery, but you have lost

All the control files 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: Please put the restore and recovery from backup as the first and prefer

Option for case 2 - 6.

Note:1060605.6 Lost datafile and no backup.

DBRECOVER Recovery Options

For Oracle incidents, start with the DBRECOVER for Oracle trial to verify table visibility, row previews, and export readiness on copied datafiles. For MySQL and InnoDB incidents, DBRECOVER for MySQL is free software and can inspect.ibd files, ibdata1, and database directories locally.

When the case is urgent, preserve the original files first, work from copies, and contact paid emergency support with the database version, platform, error messages, file list, and recovery objective.

Archive ParnassusData Blog Migration Archive