"It is good practice to perform an orderly shutdown (NORMAL, TRANSACTIONAL, or IMMEDIATE) before performing the cold backup. However, you will still obtain a consistent cold backup if you perform a SHUTDOWN ABORT. And I have had no issues restoring from such a backup in the past. But just to be safe, I always recommend an orderly shutdown.
I have had some instances that take a very long time for an orderly shutdown. For those cases, I perform a SHUTDOWN ABORT, STARTUP RESTRICT and then a SHUTDOWN IMMEDIATE. This way, I can ensure an orderly shutdown has been performed, and the instance terminates much more quickly than if I did not do the SHUTDOWN ABORT."
The red italics are mine and I completely disagree with that part of the author's comment. If the database was open to users, then a shutdown abort (in general) does NOT leave the datafiles in a consistent state (that's why it's so fast to abort the instance).
The author then "had no issues restoring from such a backup in the past." That's because he must have copied the online redo logs as well as the datafiles into the backup. If the datafiles and online redo logs are then restored from the backup, starting up the instance will initiate auto-recovery using the restored online redo logs. If there are enough redo log entries in the online logs to fully recover the datafiles, then the database will open. So the fact that the database opens doesn't mean that the datafiles in the backup were consistent, only that Oracle had silently recovered the database during the startup process. If the online redo logs were not restored from backup, then the datafiles would remain inconsistent and "alter database open" will fail. (Unless you are very lucky)
Complicating this is Oracle's recommendation never to copy online redo logs as part of a backup strategy. This is because, if you are performing an online backup (where the database is open to users throughout the duration of the backup), then you're supposed to backup the archived redo log files (along with the datafiles of course). When properly done, all the redo generated during the time required to copy the datafiles are dumped into the archived logs, so that's why you don't copy the online logs.
But if you're performing a cold backup, there's no harm in backing up the lot. Just remember that if the database is in archivelog mode, and you want to use that backup (cold or hot) later on, say to recover from media failure holding the database files, then do not accidentally restore the online redo logs from the backup on top of (overwriting) your current, live online redo logs. If you do that, you will likely lose the only copy of the latest redo data that you need to perform a full recovery all the way up to the point of failure. In fact, many dba's cite this as yet another good reason not to copy the online redo logs during a backup. Furthermore, if your cold backup is consistent (because the database was shutdown immediate, normal or transactional), the online redo logs can be recreated after restoring the database and opening it with reset logs. So again, you do not need to copy the online redologs during backup.
Like the author, I used to cold-backup dev/test databases running in noarchivelog mode as,
Script 1
shutdown abort
startup
shutdown immediate
backup
But is it really necessary to restart the database and then shut it down with immediate? Put it another way, is it really necessary to get a consistent backup of the datafiles in order to be able to restore and recover the backup later? No, it isn't. Consider: If the "startup" in script 1 always suceeds, then that proves that you can always recover from the shutdown abort. So just backup the datafiles and redo logs straight away after the abort. Later, if the backup is restored by the dba, all files will be in the state they were in after the abort. Will the dba's startup work? Yes, just as it did when the script ran. In other words, the more you believe script 1 works, the more evidence you have that it can be replaced. All you need to do is "shutdown abort" and copy all the files (with the redo logs). But knowing dba's, they'll always do it the "safest" way, ie with script 1.
Is there ever a chance that an aborted, noarchivelog mode database, will fail to startup after an abort? I've never seen it happen, but of course that doesn't mean it won't.
No comments:
Post a Comment