Databases Reference
In-Depth Information
the database. If you're using a consistent backup, you can open a whole-database backup without recovery and
without using the open resetlogs command. If you're using inconsistent backups, however, you must use archived
redo logs to make the data current and synchronize the SCNs across the data files.
The key fact here is that the recovery process will make your inconsistent backups consistent again by using the
data from the archived redo logs and the online redo log files to apply all the necessary changes across the data files to
make them all consistent with reference to a single SCN.
If you're running the database in noarchivelog mode, the recommended approach to backing up the database
is to shut down the database cleanly first and then to back up all the data files. If you're using RMAN to perform an
offline backup, the database must be mounted before you can actually perform the RMAN backup. This is because
RMAN needs to update the target database control file.
When you follow the approach suggested in the previous paragraph, you'll be backing up a consistent database.
It's not recommended that you back up an inconsistent database resulting from an abrupt shutdown using the
shutdown abort command, for example.
If you're running the database in archivelog mode, you can back up a whole database in any of the following ways:
Closed and consistent
Closed and inconsistent
Open and inconsistent
The ability to back up a database while it is open and in use is a key benefit of running a database in archivelog mode.
Recovery Types
There are several methods of recovering data, and to a large extent the particular recovery strategy you adopt will
depend on your backup strategy. For example, if you are operating in noarchivelog mode, then in most cases you can't
go perform a complete recovery. You can restore only the latest backup and will lose all the data that was entered
since the time of the backup. In the following sections, we'll briefly describe the major recovery techniques you can
use. Similarly, the flashback database technique offers a much faster means of restoring a database to a previous point
in time than traditional media recovery, but of course, you can't avail yourself of this wonderful feature if you haven't
configured and used a fast recovery area (to store the flashback logs).
Database Recovery and Consistent vs. Inconsistent Backups
If you shut down your database using either shutdown normal ( same as the shutdown command), shutdown immediate ,
or shutdown transactional , you'll have a consistent database. A shutdown following each of the previously mentioned
variations of the shutdown command will result in the following actions:
All uncommitted changes are rolled back first.
The contents of the database buffer cache are written to the data files on disk.
All resources, such as locks and latches, are released.
Since the database was cleanly shut down, when you restart the database, there is no need for an instance
recovery, which is the main implication of performing and using a consistent backup.
If you shut down your database using either the shutdown abort or shutdown force command or if there is an
instance failure, you'll end up with an inconsistent database, wherein the database is said to be in a “dirty” state. Once the
shutdown command is issued or the instance is terminated abruptly for some reason, the following things will be true:
Any committed changes are
not rolled back automatically.
Changes made to the database buffers aren't written to the data files on disk.
All resources, such as locks and latches, are still held and aren't released.
 
Search WWH ::




Custom Search