cancel
Showing results for 
Search instead for 
Did you mean: 

Recover Production DB after shutdown abort...

former_member199632
Participant
0 Kudos

Hello,

Due to power failure our production database goes down

We have issued shutdown abort

So , when starting back the database , i think we need to perform the recovery.

Please let me know, Will SMON process do the recovery automatically

or else

what are the steps we need to execute to get the DB to the most recent state.

DB is in archive log mode

regards,

zerandib

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hello,

>

> Due to power failure our production database goes down

> We have issued shutdown abort

>

> So , when starting back the database , i think we need to perform the recovery.

>

> Please let me know, Will SMON process do the recovery automatically

> or else

> what are the steps we need to execute to get the DB to the most recent state.

>

> DB is in archive log mode

>

> regards,

> zerandib

The system will start automatic recovery. But, it would be better to shutdown the database and startup again after the sucessful recovery. As an additional information, before you execute "shutdown abort" command, it will be good to execute "alter system checkpoint;" command too.

For example, check the database "alert_<SID>.log" and see the error, below;

Completed crash recovery at
 Thread n: logseq nnn, block nnnn, scn nnnnnnnnnn
 nnn data blocks read, nnn data blocks written, nnn redo blocks read

Best regards,

Orkun Gedik

Edited by: Orkun Gedik on Jun 21, 2011 8:25 AM

Answers (2)

Answers (2)

Former Member
0 Kudos

Hello zerandlib,

the Oracle documentation is really helpful on such topics:

The system monitor process (SMON) performs recovery, if necessary, at instance startup.

You don't have to worry about database consistency, a shutdown abort is not worse than a shutdown immediate and no manual intervention is necessary. The database knows best what actions are required.

- with shutdown immediate you spend the time with rolling back uncommited transactions before the shutdown

- with shutdown abort you spend the time with rolling back uncommitted transactions during recovery

Either way, the time you spend is almost identical.

I do not understand why one should perform a checkpoint before a "shutdown abort" or restart the instance after the automatic recovery as Orkun suggested. Never needed such extras.

Regards,

Mark

Former Member
0 Kudos

Hi Mark,

>> I do not understand why one should perform a checkpoint before a "shutdown abort" or restart the instance after the automatic recovery as Orkun suggested. Never needed such extras

"alter system checkpoint" writes out dirty buffers for this instance to minimize instance recovery, which is good. Because of this reason, it will be better to execute this command before executing the "shutdown abort" command. So, when you execute this command, you don't need a instance recovery at the startup of the database instance.

This is the first. Secondly, I stop and start the database one more time after the recovery and check alert<SID>.log to see any errors, if it is exits.

I hope that I clarified the issue.

Best regards,

Orkun Gedik

achmad_dimyati5
Participant
0 Kudos

Hi Zerandib,

Shutdown immediate basically stop any new transactions and wait until on progress transactions to finish and make sure write everything from dirty buffers, put proper checkpoint into control file, etc. It's consistent state.

Shutdown abort is kill the Oracle processes. So it don't care any dirty buffers, on the middle writing to datafiles, online logs and etc. If you database is in heavy load before shutdown abort, potentially you will have an issue with inconsistencies data (the most common problem is LUW transaction) especially if the database server already having issue with H/W performance (storage, swapping, high load CPU).

Best Regards,

Achmad

Former Member
0 Kudos

Hi

You can follow below steps.

1. Start DB in mount mode.

2. Shutdown immediate

3. Start DB again

If you found any error please see alert<SID>.log file.

Regards,

Nirav