Database Reference
In-Depth Information
of the database flushes the information from memory and writes it to the datafiles. Thus,
when the database is shut down normally, everything is in synch. The database datafiles,
the online redo logs, and the database control file all “agree” with each other that things
are perfectly normal.
However, if you were to issue a SHUTDOWN ABORT command, or pull the plug on
the database server and then plug it back in, the database would be in an inconsistent state
at that point. The datafiles would all be at different “states.” One datafile might reflect
the data as it looked an hour ago; another datafile might reflect the state of the data as it
looked five minutes ago. It's a good bet that none of them are anywhere near current. In
this case, the database is said to be in an inconsistent state. Thus, any backup of this data-
base would be an inconsistent backup.
A consistent backup of a database requires only a copy of the database data files to
be recoverable. Though a copy of the online redo logs and the control file would be nice
too, they are not required. By definition, a database in NOARCHIVELOG mode must be
backed up using a consistent database. We discussed manual consistent backup and restore
of Oracle databases in the previous chapters of this topic. We will discuss using RMAN to
perform consistent backup and recovery in this and the next chapter of this topic.
NOARCHIVELOG mode and consistent backups are a bit of a bummer since you have
to take the database down to get you want. Thus most organizations put their databases in
ARCHIVELOG mode, which may be backed up using a consistent or inconsistent backup.
We have already discussed configuring the database for ARCHIVELOG mode operations,
so you are halfway to understanding inconsistent backups already.
An
inconsistent backup
is a backup that is taken where either some or all of the database
datafiles, the database control files, and the database online redo logs are out of synchroniza-
tion (which is pretty much all the time when the database is running). An inconsistent backup
means that the image being backed up is not going to be consistent to a single point in time.
For example, assume you are backing up a running database. Further assume that
the backup of datafile 13 (which contains some HR data) might take place at 2 p.m. The
backup of datafile 14 takes place an hour later at at 3 p.m.
In this case, the copy of datafile 13 on the backup media will look like it did at 2 p.m. The
copy of datafile 14 will look like it did an hour later. So, those two files are going to represent
completely different temporal states of the database. Also keeping in mind that the Oracle
database does not immediately write data changes to the datafiles, it's quite possible that
the backup image of datafile 13 looks like the database would have looked at noon, while the
backup image of datafile 14 is an image of the database as it looked at 1 p.m. In other words,
the database datafiles are out of synchronization.
Generally, this situation isn't a problem because Oracle reads the most current data blocks
out of memory. It really does not care which copy of the data block is on disk, as long as the
most current copy of that data block is in memory. However, when the database is shut down
abnormally, the memory is cleared and the result is a bunch of messy database datafiles that
are inconsistent. Hence, the name, inconsistent backup.
While this might sound like a terrible situation, the reality is that most database backups
are inconsistent backups. The DBA backs up the database datafiles while the database is run-
ning. The DBA (using RMAN or the SQL command line) also backs up all of the redo logs
generated from the point that the backup started until the time that the backup was completed.
Search WWH ::
Custom Search