Database REcovery

[carl airiel]

My problem is that my db server running on
HP-UX had a crash. The system got a panic message on /etc/shutdownlog. After restarting the server and the database thryu a package(Cluster).My database is now running. But on my ORacle logs(bdmp) it states that it has encountered a ora error 1113. Error during recovery. What can I do about this one. Can I used an Incomplete recovery?

REgards,
Allan

[Oviwan]

Hi

Check this link:
http://www.dbaoncall.net/references/er_1113.html

Regards & Good Luck

[Eric Antunes]

Hi Allan,

Incomplete recovery should only be used in the following situations:

- User error;
- Complete recovery failed because of missing archivelog file(s);
- Recovering from a control file backup;
- Loss of all redo logs and datafiles.

Are you in one of the previous situation?

Best Regards,,

Eric Antunes

[Patti Johnson · Accepted solution]

Is it possible that you were doing an online backup when the system crashed?
Check the alert log - if a tablespace is in backup mode when the db crashed it will think the file was restored from backup and requires media recovery. If this was the case you can issue
alter database end backup; <-- if 9.2
or
for each datafile
alter datafile 'file_name' end backup;

Query v$backup to for status = 'ACTIVE' to be sure.

Otherwise post the alter.log here.

Patti

[Indira Aramandla]

Hi Allan,

ORA-01113. See the associated messages for a description of the problem in the alert log.
Does it say file needs media recovery.....something like that.

The reason for this is an attempt was made to open a datafile that is in need of media recovery. The workaround would be to first apply media recovery to the datafile identified in the message.

The other reason could be that the system or file was backed up before the archiver process (ARCH) was able to archive the current log file and therefore the system or file was slightly out of sync.

You need to find out which one of the redo log files are current and apply it manually to the system tablespace file.

Issue the following SQL statement to recovery system

1. SQL> Shutdown immediate

2. SQL> Startup mount

3. SQL> SELECT member FROM v$$log l, v$logfile f
WHERE l.group# = f.group# AND
l.status = 'CURRENT';

4. SQL> Recover database until cancel (The system will suggest an archive log that does not exist)

Apply the log member from the select statement in step 3 above. Give it the full path as it appears on the select statement.

Alter database open resetlogs;

The system should respond with "Statement processed". At this point the database is open. Cycle (shutdown/start) the instance and check for errors in the alert log. You should also take a backup of the system as soon as possible since the database incarnation number has changed and the log sequence numbers have been reset.



Indira A

[carl airiel]

Hi Patti Johnson,
You are correct!I overlooked the alert.log files. I did not notice that it was on a hotbackup state. Thank you very much.

To All,
Thank you for the inputs. I have appreciated all your suggestions. Thank you very much.

Regards,
Allan

[Simon Wickham_6]

Hi,

Try to Recover datafile ''; (this requires archive logs). Restore the database from backup and reapply any archive log files.

If the database is a standby database then check the procedure for copying the file in the first place. A common mistake is to perform a hot backup of a database but without issuing a â alter tablespace ... begin backup ... end backupâ for the tablespace in question.

Once the media error has been recovered from the database can be opened normally (i.e. â startupâ or â alter database openâ ).

Regards,
Simon