Академический Документы
Профессиональный Документы
Культура Документы
PURPOSE
Describe various Backup and Recovery Scenarios
RELATED DOCUMENTS
Backup and Recovery HandBook, Intro to DataServer Course Material
Backup and Recovery - an Overview
Backup
a) Consistent backups
A consistent backup means that all data files and control files are consistent
to a point in time. I.e. they have the same SCN. This is the only method of
backup when the database is in NO Archive log mode.
b) Inconsistent backups
An Inconsistent backup is possible only when the database is in Archivelog mode
and proper Oracle aware software is used. Most default backup software can not
backup open files. Special precautions need to be used and testing needs to be
done. You must apply redo logs to the data files, in order to restore the
database to a consistent state.
d) Backup Methods
Essentially, there are two backup methods, hot and cold, also known as online
and offline, respectively.
A cold backup is one taken when the database is shutdown.
A hot backup is on taken when the database is running.
Commands for a hot backup:
1. Svrmgr>alter database Archivelog
Svrmgr> log archive start
Svrmgr> alter database open
2. Svrmgr> archive log list
--This will show what the oldest online log sequence is. As a precaution,
always keep the all archived log files starting from the oldest online log
sequence.
3. Svrmgr> Alter tablespace tablespace_name BEGIN BACKUP
e) Incremental backups
These are backups that are taken on blocks that have been modified since the
last backup. These are useful as they don't take up as much space and time.
There are two kinds of incremental backups
Cumulative and Non cumulative.
Cumulative incremental backups include all blocks that were changed since the
last backup at a lower level. This one reduces the work during restoration as
only one backup contains all the changed blocks.
Noncumulative only includes blocks that were changed since the previous backup
at the same or lower level.
Using rman, you issue the command "backup incremental level n"
f) Support scenarios
When the database crashes, you now have a backup. You restore the backup and
then recover the database. Also, don't forget to take a backup of the control
file whenever there is a schema change.
RECOVERY
=========
There are several kinds of recovery you can perform, depending on the type of
failure and the kind of backup you have. Essentially, if you are not running in
archive log mode, then you can only recover the cold backup of the database and
you will lose any new data and changes made since that backup was taken.
If, however, the database is in Archivelog mode you will be able to restore the
database up to the time of failure.
There are three basic types of recovery:
Redo information is recorded so that all commands that took place can be
repeated during recovery. Rollback information is recorded so that you can undo
changes made by the current transaction but were not committed. The Redo Logs
are used to Roll Forward the changes made, both committed and non- committed
changes. Then from the Rollback segments, the undo information is used to
rollback the uncommitted changes.
In this case, there are several kinds of recovery you can perform, depending on
what has been lost. The three basic kinds of recovery are:
1. Recover database - here you use the recover database command and the
database
must be closed and mounted. Oracle will recover all datafiles that are online.
2. Recover tablespace - use the recover tablespace command. The database can be
open but the tablespace must be offline.
3. Recover datafile - use the recover datafile command. The database can be
open but the specified datafile must be offline.
Note: You must have all archived logs since the backup you restored from,
or else you will not have a complete recovery.
Until you recover the datafiles that contain the rollback segments, you need to
create some temporary rollback segments in order for new transactions to work.
Even if other rollback segments are ok, they will have to be taken offline.
So, all the rollback segments that belong to the datafile need to be recovered.
If all the datafiles belonging to the tablespace rollback_data were lost, you
can now issue a recover tablespace rollback_data.
Next bring the tablespace online and check the status of the rollback segments
by doing a select segment_name, status from dba_rollback_segs;
You will see the list of rollback segments that are in status Need Recovery.
Simply issue alter rollback segment online command to complete.
Don't forget to reset the rollback_segments parameter in the init.ora.
If a media failure should occur before a backup was made after you opened the
database using resetlogs, you will most likely lose data.
The reason is because restoring a lost datafile from a backup prior to the
resetlogs will give an error that the file is from a point in time earlier,
and you don't have its backup log anymore.
1. Make sure that all tablespaces are online and all datafiles are online.
This can be checked through v$datafile, under the status column.
For tablespaces associated with the datafiles, look in dba_tablespaces.
If this doesn't show us anything, i.e., all are online, then
This event will generate a trace file that will reveal information about the
transaction Oracle is trying to roll back and most importantly, what object
Oracle is trying to apply the undo to.
5. Use the following query to find out what object Oracle is trying to
perform recovery on.
6. Drop the offending object so the undo can be released. An export or relying
on a backup may be necessary to restore the object after the corrupted
rollback segment goes away.
7. After dropping the object, put the rollback segment back in the init.ora
parameter rollback_segments, remove the event, and shutdown and startup
the database.
In most cases, the above steps will resolve the problematic rollback segment.
If this still does not resolve the problem, it may be likely that the
corruption is in the actual rollback segment.
If you cannot get the database open, there is no other alternative than
restoring from a backup.
If you have a current control file, then recovery of read only tablespaces is
no different than recovering read-write files.
The issues with read-only tablespaces arise if you have to use a backup control
file. If the tablespace is in read-only mode, and hasn't changed to read-write
since the last backup, then you will be able to media recovery using a backup
control file by taking the tablespace offline. The reason here is that when you
are using the backup control file, you must open the database with resetlogs.
And we know that Oracle wont let you read files from before a resetlogs was
done. However, there is an exception with read-only tablespaces. You will be
able to take the datafiles online after you have opened the database.
When you have tablespaces that switch modes and you don't have a current control
file, you should use a backup control file that recognizes the tablespace in
read-write mode. If you don't have a backup control file, you can create a new
one using the create controlfile command.
Basically, the point here is that you should take a backup of the control file
every time you switch a tablespaces mod