If an incremental backup strategy has been used, a restore and recover operation will make use of a level 0 incremental backup, then apply any incremental level 1 backups that may be ava
Trang 1This command will locate all cumulative and differential incremental level 1 backups and apply them The NOREDO qualifier is needed to instruct RMAN not to attempt to apply any redo data—because, in noarchivelog mode, there is none to apply
Recovery of a Noncritical File in Archivelog Mode
In an Oracle database, the datafiles that make up the SYSTEM tablespace and the currently active undo tablespace (as specified by the UNDO_TABLESPACE parameter) are considered to be “critical.” Damage to any of these will result in the instance terminating immediately Furthermore, the database cannot be opened again until the damage has been repaired by a restore and recover exercise Damage to the other datafiles, which make up tablespaces for user data, will not as a rule result in the instance crashing Oracle will take the damaged files offline, making their contents inaccessible, but the rest of the database should remain open How your application software will react to this will depend on how it is structured and written
TIP Is it safe to run your application with part of the database unavailable?
This is a matter for discussion with your developers and business analysts, and an important point to consider when deciding on how to spread your segments across tablespaces
If your backups were done with RMAN, the restore and recovery operation of a damaged datafile will be completely automatic RMAN will carry out the restore in the most efficient manner possible, making intelligent use of full and incremental backups and then applying the necessary archive logs If RMAN is linked to a tape library through SBT channels, it will load the tapes automatically to extract the files it needs The restore and complete recovery of a datafile can succeed only if all the archive log files generated since the last backup of the datafile are available Either they must still be on disk in the archive log destination directories, or if they have been migrated
to tape, they must be restored during the recovery operation RMAN will do the extract from a backup set and restore to disk automatically If for some reason an archive log file is missing or corrupted, the recovery will fail, but since archive log destinations and RMAN backup sets can and should be multiplexed, you should never find yourself in this situation If you do, the only option is a complete restore, and an incomplete recovery up to the missing archive, which will mean loss of all work done subsequently
Exercise 16-3: Recover from Loss of a Noncritical Datafile with Database Control First, create a tablespace and a segment within it, and back it
up Then simulate damage to the datafile Diagnose the problem and resolve it The database will stay open for use throughout the whole exercise At various points you will be asked to supply host operating system credentials, if you have not saved them
in previous exercises: give a suitable Windows or Unix login, such as the Oracle owner
Trang 21 Connect to your database as user SYSTEM using SQL*Plus, and create a
tablespace For example, on Windows,
SQL> create tablespace noncrit
datafile 'C:\APP\ORACLE\ORADATA\ORCL\noncrit.dbf' size 2m;
or on Unix,
SQL> create tablespace noncrit
datafile '/app/oracle/oradata/orcl/noncrit.dbf' size 2m;
2 Create a table within the new tablespace and insert a row into it:
SQL> create table ex16 (c1 date) tablespace noncrit;
SQL> insert into ex16 values(sysdate);
SQL> commit;
3 Using Database Control, connect to your database as user SYSTEM
4 From the database home page, take the Availability tab, then the Schedule
Backup link in the Manage section
5 In the Schedule Backup window, select the Tablespaces radio button in the
Customized Backup section Click SCHEDULE CUSTOMIZED BACKUP
6 In the Schedule Backup: Tablespaces window, click ADD
7 In the Tablespaces: Available Tablespaces window, select the radio button for
your new NONCRIT tablespace, and click SELECT
8 In the Schedule Customized Backup: Tablespaces window, click NEXT
9 In the Schedule Customized Backup: Options window, leave everything on
defaults and click NEXT
10 In the Schedule Customized Backup: Settings window, leave everything on
defaults and click NEXT
11 In the Schedule Customized Backup: Schedule window, select One Time
(Immediately) radio button and click NEXT
12 In the Schedule Customized Backup: Review window, study the script and
click SUBMIT JOB to run the backup
13 Simulate a disk failure by corrupting the new datafile On Windows, open
the file with Windows Notepad, delete a few lines from the beginning of the
file, and save it; it is important to use Notepad because it is one of the few
Windows utilities that will ignore the file lock that Oracle places on datafiles
On Unix you can use any editor you please, such as vi Make sure that the
characters deleted are at the start of the file, to ensure that the file header is
damaged
14 Flush the buffer cache, so that the next read of ex16 will need to read
from disk:
alter system flush buffer_cache;
Trang 315 Confirm that the file is damaged by attempting to query the table:
SQL> select * from ex16;
select * from ex16 * ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 7, block # 9) ORA-01110: data file 7: 'C:\APP\ORACLE\ORADATA\ORCL\NONCRIT.DBF'
16 In your Database Control session, take the Availability tab from the database
home page, and then the Perform Recovery link in the Manage section
17 In the Perform Recovery: Type window, take the link for Datafiles With Error.
18 In the Perform Object Level Recovery: Datafiles window, the new datafile will
be listed Select it, and click NEXT
19 In the Perform Object Level Recovery: Rename window, click NEXT
20 In the Perform Object Level Recovery: Review window, click SUBMIT
21 In the Perform Recovery: Result window, study the output of the operation,
as shown in the illustration
22 Confirm that the tablespace and the tables within it are now usable, with no
loss of data
SQL> select * from ex16;
C1 -21-OCT-08
Of the four steps for complete recovery, the first step (taking the damaged file offline) will be automatic if the file is noncritical The following two steps (restore
Trang 4and recovery) are accomplished with RMAN commands, and the final step (bringing
the datafile online) can be done with either SQL*Plus or RMAN The scripts generated
by Database Control automate the entire procedure
If an incremental backup strategy has been used, a restore and recover operation
will make use of a level 0 incremental backup, then apply any incremental level 1
backups that may be available, and then apply redo data to complete the recovery The
logic behind this method (which keeps use of redo to a minimum) is that it is always
faster to apply an incremental backup than to apply redo, because an incremental
backup can be applied in a single sequential pass through the datafile, whereas
applying redo (which consists of change vectors in chronological order) will involve
random access to the datafile The presence or absence of incremental backups does
not lead to any syntactical difference in the use of the RECOVER command; RMAN,
by interrogating its repository, will work out the best way to perform the operation
EXAM TIP RMAN will always apply incremental backups in preference to
applying redo data, if they are available
Recovering from Loss of a Critical Datafile
The datafiles that make up the SYSTEM and currently active undo tablespace are
considered critical by Oracle, meaning that it is not possible to keep the database
open if they are damaged If any portion of the SYSTEM tablespace were not available,
parts of the data dictionary would be missing Oracle cannot function without a
complete data dictionary If parts of the undo tablespace were not available, it would be
possible that undo data required for maintaining transactional integrity and isolation
would not be available, and Oracle can’t take that chance either Therefore, damage to
these datafiles will cause the instance to terminate immediately
TIP The critical datafiles should be on disk systems with hardware redundancy,
such as RAID level 1 disk mirroring, so that in the case of media failure the
files will survive and the database will remain open
If the database does crash because of damage to critical datafiles, as ever, the first
action is to attempt a startup This will stop in mount mode, with error messages
written to the alert log showing the extent of the damage To recover, follow the same
routine as that for a noncritical file, and then open the database The restore and
recover process is identical to that for a noncritical file, but it must be carried out in
mount mode Of the four steps for complete recovery, if the damaged file is a critical
file only the second and third steps are necessary: as the database cannot be opened,
there is no need to take the damaged file offline and bring it back online afterward
EXAM TIP Loss of a critical data file will not mean loss of data, but it will
mean loss of time
Trang 5Incomplete Recovery
An incomplete recovery means losing data The whole database is taken back in time
by a restore of all the datafiles, and then it is not completely recovered Rather than applying all the redo generated since the backup was taken, you deliberately stop the application of redo at some point, to produce a version of the database that is not up-to-date All work done from that point is lost There are only two reasons for performing an incomplete recovery: either complete recovery is impossible or you deliberately decide to lose data
Complete recovery will not be possible unless all archive logs generated from the time of the backup are available, as well as the online redo logs If an archive log is missing or corrupted, then recovery will stop at that point Complete recovery should never fail because of missing archive or online log files, as both file types can and should be multiplexed to different devices, making their total loss impossible, but
it can happen If so, incomplete recovery up to the point at which the missing or damaged redo data occurs is your only option
EXAM TIP Incomplete recovery is necessary if there is a missing archive log,
or if all copies of the current online redo log file group are missing
To decide to lose data deliberately is a course of action taken after user error It may be that a user has committed a transaction that is inappropriate to the business requirements Such errors could include perfectly normal mistakes—we all make mistakes—while using package software, but more commonly they are errors made using tools such as SQL*Plus Omitting a WHERE clause when issuing an UPDATE
or DELETE statement will result in the whole table being affected, not just one row;
if this change is committed, perhaps by exiting from the tool, then the changes are irreversible As far as Oracle is concerned, it is a committed transaction and can never
be rolled back Worse still is issuing DDL commands These include an implicit COMMIT statement It is frighteningly easy, for example, to drop a table or even a schema when you think you are connected to the development database when in fact you are connected to production
Following a user error, you can restore the whole database and recover it up to the point just before the error, thus producing a version of the database without the mistake, but also, without all the correct work done since
TIP There are several “flashback” technologies that may make it possible to
recover from user errors without resorting to an incomplete recovery
EXAM TIP It is not possible to skip the recovery of a bad transaction and
recover all other work
Trang 6A special case of incomplete recovery is recovery of the controlfile Ideally, all
recovery operations will be conducted using the current controlfile, but there are
circumstances when this isn’t possible and a backup of the controlfile must be
restored There are two possible reasons for this: either all copies of the current
controlfile have been lost and it is not possible to run a CREATE CONTROLFILE
command to recreate it, or the current controlfile does not accurately describe the
version of the database you want to restore, typically, because changes such as
dropping tablespaces have occurred since taking the backup
There are four steps for incomplete recovery:
• Mount the database
• Restore all the datafiles
• Recover the database until a certain point
• Open the database with reset logs
The first contrast with complete recovery is that complete recovery can be done
with the database open, unless the damaged files are critical Incomplete recovery can
be done only in mount mode
Second, for a complete recovery, you restore only the damaged datafiles; incomplete
recovery operations begin with a restore of all datafiles The datafiles do not have to
be restored from the same backup, but they must all be older than the point to which
you wish to recover The controlfile will have to be restored as well as the datafiles if
the physical structure of the current database is different from the structure of the
version being restored For example, if a tablespace has been accidentally dropped, the
current controlfile will know nothing about it Restoring the datafiles that make up
the tablespace won’t help: the current controlfile will ignore them, and not include
them in the recovery Do not restore the controlfile unless you have to; it may complicate
matters if you do
The third step is to apply redo from archive and (if necessary) online logs to the
desired point This contrasts with complete recovery, where you apply all the redo to
bring the database right up-to-date; for incomplete recovery, you stop the recovery at
whatever point you want prior to the latest time There are several options for specifying
the point to which you want to recover
Finally, open the database with RESETLOGS This will reinitialize the online redo
log files, creating a new incarnation of the database An incarnation of a database is a
version of the database with a new thread of redo, beginning at log sequence number 1
This is the final contrast with complete recovery After a complete recovery, the database
is exactly as it was before the problem occurred, but after an incomplete recovery it is a
different incarnation Backups and archive logs are specific to an incarnation and those
generated by one incarnation must be kept separate from those generated by a previous
incarnation
EXAM TIP You must be connected AS SYSDBA to do an incomplete
recovery No normal user, and not even a SYSOPER user, can do this
Trang 7Having mounted the database and restored all the datafiles and (if necessary) the controlfile, you have three options for incomplete recovery:
• Until time
• Until system change number (SCN)
• Until log sequence number
The UNTIL TIME option will apply redo to roll the datafiles forward until a particular time The precision is to the second This option would usually be used to correct user error If a user made an irreversible mistake and the time the mistake was made is known, then a time-based recovery to just before the mistake may be the best option
The UNTIL SCN option can be used if the exact system change number when the error was made is known By using advanced tools such as the Log Miner utility or by using the Flashback capability to be detailed in Chapter 19, it may be possible to identify exactly the SCN at which a transaction was committed The recovery can be stopped precisely before the problem, thus losing the minimum possible amount of data The UNTIL SEQUENCE option is used if an archive log file or an online log file group is missing; it will recover all work up to the log switch into the missing file
or group
EXAM TIP The syntax for incomplete recovery differs between SQL*Plus and
RMAN SQL*Plus uses UNTIL CANCEL and UNTIL CHANGE, where RMAN would use UNTIL SEQUENCE and UNTIL SCN They both use UNTIL TIME
By default, RMAN will restore the most recent backup, and apply all available redo Incomplete recovery must modify this behavior: the restore must be from backups that are older than the point in time to which the recovery is to be made, and the recovery must be stopped at that time To ensure that the restore and recover both use the same UNTIL TIME, it is considered best practice to execute both commands within a single run block For example,
1 run {startup mount;
2 set until time = "to_date('27-10-08 10:00:00','dd-mm-yy hh24:mi:ss')";
3 restore database;
4 recover database;
5 alter database open resetlogs;}
This example, with line numbers added for clarity, shows the four steps for
incomplete recovery:
• Line 1 The database must be started in mount mode It is of no significance
whether the preceding shutdown were orderly or an abort
• Line 2 The SET UNTIL command specifies a time that will be applied to
all subsequent commands The example includes a format string that will eliminate any ambiguity in interpreting the date and time An alternative is
Trang 8to rely on matching the NLS_DATE_FORMAT environment variable Note the
use of double quotes around the entire string, and single quotes within it
• Line 3 The RESTORE command will extract datafiles from backups that are
at least as old as the time specified in the SET UNTIL command
• Line 4 The RECOVER command will apply redo from archive log files and
(if necessary) online log files, stopping at the specified time
• Line 5 The RESETLOGS clause instructs Oracle to initialize the online redo
log files and reset the log switch sequence number
An alternative syntax is to specify the UNTIL value with each command For
example,
restore database until time 'sysdate - 7';
recover database until time '27-OCT-08';
The first of these commands instructs RMAN to restore the database from backups
that are at least seven days old The second command will perform an incomplete
recovery up to the beginning of October 27, 2008, assuming that the NLS_DATE_
FORMAT environment variable is set to dd-MON-rr
Autobackup and Restore of the Controlfile
For a complete recovery, it should always be possible to use the current controlfile
The only case where this will not be possible is if all copies have been lost—typically,
because it was not multiplexed and the one copy was damaged The database is critically
dependent on the controlfile: it will crash if the controlfile is damaged RMAN makes
the situation even worse: the RMAN repository, which stores details of all backups, is
stored in the controlfile So if the controlfile is damaged, the database will crash—but
RMAN will not be able to restore it, because the information it needs will not be
available There are two ways around this recursive problem: either use an RMAN
catalog database (as described in Chapter 17) or enable the AUTOBACKUP facility
Because the controlfile is vital not only to the running database but also to RMAN,
an automatic backup can be enabled From the RMAN prompt,
configure controlfile autobackup on;
Having executed this command, every RMAN operation will conclude with an
automatic backup of the controlfile and the spfile into a backup set stored in a
well-known location Then if necessary, with the database in nomount mode, you can
use this:
restore controlfile from autobackup;
This command instructs RMAN to go to the well-known filename in a well-known
location and extract the controlfile from the most recent autobackup The restore will
be to the locations given in the spfile Then mount the database using the restored
Trang 9controlfile, and RMAN will be able to locate the backups needed to restore the rest
of the database The well-known location will be in the flash recovery area if this has been enabled The well-known filename is based on the DBID; the DBID (a ten-digit number) should be part of your most basic documentation, and will have been displayed whenever you connect to the database with RMAN It is also visible as the column DBID in the V$DATABASE view
If the spfile has also been lost, start the instance with a dummy initialization file:
a pfile with just one parameter, DB_NAME Then connect with RMAN, and issue these commands, substituting your DBID number for that given:
set dbid 1234567890;
restore spfile from autobackup;
The restore of an spfile will be to the default location, in $ORACLE_HOME/dbs for Unix or %ORACLE_HOME%\database for Windows Then restart the instance in nomount mode, which will use the restored spfile, and restore the controlfile Mount the controlfile, and RMAN will then have access to its repository and can locate and restore the datafile backups
EXAM TIP The commands restore controlfile from
autobackup and restore spfile from autobackup can be executed in nomount mode All other RMAN commands can be executed only in mount or open mode
Exercise 16-4: Enable Controlfile Autobackup In this exercise, enable the controlfile autobackup facility and observe it in operation
1 Connect to the database with RMAN:
rman target /
2 Confirm that autobackup is not enabled:
show controlfile autobackup;
This will show that autobackup is not enabled.
3 Enable autobackup, and confirm:
configure autobackup on;
show all;
Note that the default format for autobackups is ‘%F’.
4 Carry out a backup operation:
backup datafile 1;
Observe that following the requested backup, there is a second backup set
created for the controlfile and the spfile
5 Determine the location of autobackup of the controlfile and the spfile:
list backup of controlfile;
Trang 10In both cases, the most recent backup set listed will be to a file in the flash
recovery area This can be overridden by configuring a format other than
the ‘%F’ shown in Step 3, but if this is done, the automatic location of the
autobackups will no longer function
This script accomplishes the complete restore and recovery of a database,
assuming that everything was lost:
1 run{startup nomount pfile=dummy.pfile;
2 set dbid=1196323546;
3 restore spfile from autobackup;
4 shutdown abort;
5 startup nomount;
6 restore controlfile from autobackup;
7 alter database mount;
8 restore database;
9 recover database;
10 alter database open resetlogs;}
Taking this script line by line,
1 Start the instance, using a dummy parameter file with just one parameter: DB_NAME.
2 Tell RMAN the DBID of the database on which you are working.
3 Extract the spfile from the most recent autobackup, relying on defaults for its name and
location.
4 Abort the instance, because (having been started with a dummy pfile) it is not of any
further use.
5 Start the instance, using the restored spfiles.
6 Extract the controlfile from the most recent autobackup.
7 Mount the controlfile.
8 Restore all the datafiles.
9 Carry out a complete recovery by applying any incremental backups, followed by archive
log files and online log files.
10 Open the database, and reinitialize the online redo log files A RESETLOGS is always
required after restoring the controlfile.
Exercise 16-5: Perform Incomplete Recovery with RMAN, Using a
Backup Controlfile In this exercise, which continues from Exercise 16-3, you
will drop a tablespace and then perform an incomplete recovery to a time just before
it was dropped This is possibly the most complex operation that may ever be
necessary It must be performed in several stages: first a version of the controlfile that
dates from the time the tablespace existed must be restored, and the database must be
mounted with this controlfile Only then can the rest of the database be restored and
recovered
Before launching RMAN or SQL*Plus, ensure that your operating system date
format is set to a known value For example, on Windows: