You are on page 1of 18

Restore and Recovery

Contents
 Restore and recovery options using SAPDBA
 SAPDBA functions and their limitations

Objectives
At the end of this unit, you will be able to:
 Analyze the physical database structure using SAPDBA
 Recover the database using the SAPDBA function
Partial Restore and Complete Recovery
 Reset the database using the SAPDBA function Reset Database
 Perform a point in time recovery using the SAPDBA function
Full Restore and Recovery

 SAP AG 1999
 In an Oracle database, various kinds of errors can occur that require the database administrator (DBA)
to take action. The different types of database error are:
 Statement errors, such as an attempt to enter incorrect data in a table. Oracle terminates the
statement with an error message, and performs a statement rollback.
 Process errors, such as termination of the connection between a work process and a server process.
PMON rolls back the open transaction, and releases occupied resources.
 Instance errors, such as when a background process fails. The next time an instance is started, a
consistent status is restored by means of automatic instance recovery.
 User errors, such as when a user accidentally enters the SQL statement drop table.
 Media errors, such as a head crash, or accidental deletion of a database file.
 If user and media errors occur, the DBA must take action. This unit describes both of these error types
and the appropriate repair scenarios.
 To help you determine exactly when to apply Oracle tools, the SAPDBA functions and their limitations
are discussed in detail in this chapter.
 For further information about database errors, see the R/3 Online Documentation on database
administration.
Scenarios: Introduction

10 38
10 38 Control files
10 38

Offline and online


9 10 11 12 ... 36 37 38
redo log files

10 38
10 38 Data files
10 38

Full backup
Legend:
Log sequence number 9

 SAP AG 1999

 In an R/3 System with an Oracle database, most data files have the status online and read/write. For a
functioning, consistent database, all data files as well as the control files must therefore be synchronous
– that is, they must match in terms of time.
 Oracle creates synchronization data using time stamps. Time stamps are integers that are increased
during certain database actions, and entered in all data and control file headers by the log writer or
checkpointer process at the checkpoint.
 An example of synchronization data is the log sequence number (LSN), which is increased by 1 during
every log switch. At a more sophisticated level, Oracle can define synchronization on transaction level
using the system change number (SCN), which is increased, for example, after the COMMIT in a
change transaction, or at the checkpoint.
 The scenario shown in this slide (and the following three slides) depicts a database that has been saved
completely and error-free at time LSN=10. At time LSN=38, a media or user error damages the
database so extensively that the database instance breaks down or the database is inconsistent. The
offline and online redo log files that were created between the beginning of the backup and the
occurrence of the error are available.
 Scenario: Because of a head crash, data has been lost during business operation. The database is
inconsistent, and is no longer running properly.
 A partial restore and complete recovery is performed to get the database running properly again, and
to recover the database to its status just before the error occurred.
 During a restore, database files are copied from the backup medium back to the disk. During a partial
restore and complete recovery, only the required minimum of data is copied. The database files that are
to be copied back can be combined from different backups. Because the database files are no longer
synchronous after a partial restore, the database is inconsistent and will not run properly after the copy-
back procedure has terminated.
 To synchronize the files, the database evaluates the synchronization data that has been saved in the file
headers. The database requests all offline redo log files that have accumulated since the “oldest”
database file (in logical terms), in uninterrupted sequence. During a recovery, all data changes logged
by these offline redo log files are replicated in the files that have been copied back. With a partial
restore and complete recovery, all changes are performed again until all data files are at the same SCN
(a procedure called media recovery). When the database is subsequently started up, during the instance
recovery, all transactions that are not committed are taken back, using the rollback segments, which are
likewise recovered. The database is now consistent, capable of running, and back to its data status just
before the error occurred.
Scenario: Database Reset

open

10
10 Control files
10

10 11 ... 37 38
Offline and online
9
redo log files
10 11 ...

10
10 Data files
10

Full restore

 SAP AG 1999

 Scenario: During an upgrade, extensive software or hardware problems have arisen. As a result, the
upgrade must be terminated. The database is inconsistent, and is no longer running properly.
Fortunately, a full offline backup was performed immediately before the upgrade.
 A database reset is performed to get the database running properly again, and to reset the database to
its status immediately before the upgrade.
 The database is reset using a full restore. With a full restore, all data files as well as the older online
redo log files and control files are copied back from the backup medium. Since these files must
originate from the same valid offline backup, the database is consistent and ready to run after the copy-
back procedure has terminated. Therefore, a recovery is not required; the database can be started up at
once.
 After the database startup, new offline redo log files are generated which, at the technical level, “fit”
the full backup as precisely as the old offline redo log files. If an additional full restore is required, you
risk making a recovery possible in two different logical directions.
 A database reset always results in data loss. The data that has been generated between the full backup
and the problem situation is lost. Of course, the database as such does remain consistent.
Scenario: Point in Time Recovery

mount Open resetlogs

25 1
10 25 1
10 Control files
25 1
10

26 ... 37 Offline and online


10 11 ... 25
redo log files
1 2 ...
Incomplete
24
recovery
10 25 24 1
10 25 1 Data files
10 25 1

Full restore

 SAP AG 1999

 Scenario: During an upgrade, a user accidentally enters the command drop table. As a result, the
upgrade must be terminated. A full backup is available, but was not performed immediately before the
upgrade process began.
 A point in time recovery is performed to get the database running properly again, and to reset the
database to the status at a certain point in time before the upgrade. From that point on, the data is
recovered up to a certain point, for example, up to the start of the upgrade, or up to the table drop.
 Initially, all data files are replaced by copies of online/offline backups, using a full restore. The
termination point of the recovery determines whether the control files should also be replaced. All data
files and online redo log files are entered in the control files with specified paths. The control files
must reproduce this file structure at the operating system level according to the status of the structure at
the end of the recovery procedure.
 During the recovery phase, the changes to the dataset are performed again. Incomplete recovery refers
to the end point of recovery, which can be anywhere between the end of the copied backup and the last
entry in the current online redo log. The recovery end point can be defined by the redo log file
sequence number, or by specifying either a point in time or an SCN.
 After a point in time recovery, the database is normally opened using alter database open
resetlogs, unless a complete recovery is performed. Since a recovery cannot be performed after
using open resetlogs, a whole backup must be triggered immediately.
How to Handle Problems

 Do not make any rash decisions


 Analyze the problem in detail
 Create a problem-solving strategy
 Before restoring any files, check:
 What is causing the problem
 Whether there is enough disk space to save and restore files
 Whether a hardware extension is necessary
 The file system and mount points
 The availability of backups
 The availability of offline redo log files

 SAP AG 1999

 If a database problem occurs, you must analyze the problem and create a problem-solving strategy.
 To analyze the database problem, check the database alert log and the trace files belonging to the
background processes in directory $ORACLE_HOME/saptrace/background.
 Your problem-solving strategy depends on the answers to the following questions: What is the status of
the database – available or not available? Is this a user error or a media error? Which files are
corrupted? Which file types (data files, control files, online redo log files) are affected? Is software or
hardware mirroring available?
 To be on the safe side (and time permitting), perform a full offline backup before the files are copied
back, using BRBACKUP or operating system (OS) backup tools.
 In the event of a hard disk problem, such as a head crash, hardware must be replaced. In this unit, we
assume that, at the OS level, a file system has been created and mounted at the old location.
 If you followed the backup cycle recommended by SAP, you will have a number of database backups
and offline redo log file backups for a restore and recovery. Your problem-solving strategy will
determine which backup and offline redo log files are copied back, and how they need to be applied.
 Do not make any rash decisions. If you make mistakes or act carelessly, you can drastically aggravate
the restore and recovery situation. The costs incurred by a consulting session provided by SAP or an
SAP partner are negligible compared to the business consequences of data loss, even for a single day of
production operation.
 The SAPDBA function partial restore and complete recovery replaces lost data files by using
appropriate backups, and subsequently recovers the restored data file status using redo log files. To be
able to use this function, your online redo log files and control files must be valid. The partial restore
and complete recovery procedure consists of six phases that are executed either manually or
automatically, in a predetermined sequence – that is, a particular phase can only be selected after the
previous one has been completed successfully (status: finished or not needed).
 In the Check Database phase, the status of all files in the database (that is, the control files, online redo
log files, and data files) as well as the tablespace status (online/offline; online backup mode) are
checked. Check Database can be executed regularly with the database running; thus, it provides an
overview of the physical status of the database.
 In the Check Database phase, SAPDBA refers to entries in Oracles V$Views (such as V$DATAFILE,
V$RECOVER_FILE). If an error is detected during this phase, a safe check must be performed – that
is, the database must be shut down (initially using shutdown immediate; if this is unsuccessful,
SAPDBA suggests shutdown abort). Next, to update the V$Views, the database is set to status
mount. SAPDBA logs any recorded errors in data files in directory sapreorg with the suffix (rcv) for
recovery. A safe check is a prerequisite for any subsequent restore and recovery activities.
 Missing sapdata directories are not created automatically; rather, they are mount points. However,
missing subdirectories are created automatically.
 In the Find Backup Files phase, backups are determined using the entries in the BRBACKUP summary
log file back<SID>.log (return code 0 or 1). The associated detail logs show whether the required data
files were in the backup. The data files can be compiled from various backups. To minimize the
subsequent recovery time, SAPDBA always suggests the most recent backup.
 In the Restore Backup Files phase, the data files are restored to their original location. If only index
files are missing, SAPDBA can recreate and build up these files using Database Dictionary
information.
 In the Find Offline Redo Log Files phase, the offline redo log files required for a complete recovery are
determined. The BRARCHIVE summary log file arch<SID>.log lists the tapes where the offline redo
log files have been saved. You can choose between a first or second backup (for example, when saved,
with brarchive -cds). SAPDBA takes existing online redo log files and offline redo log files in saparch
into consideration. After the appropriate backups have been found for all required offline redo log files,
the Find Archive Files phase ends with the status finished.
 In the Restore Offline Redo Log Files phase, the offline redo log files that have been found are read
(from tape) back to directory saparch.
 In the Recover Database phase, SAPDBA creates recovery scripts in a subdirectory of sapreorg. Using
these scripts, a control file is saved, and a recover database statement (that is, a complete recovery) is
transmitted to Oracle. The SAPDBA message Recover database terminated successfully indicates that
the database has been recovered completely.
Partial Restore and Complete Recovery Limitations

Problem Solutions

No data or offline redo  Perform a database reset


log file backups available  Perform a point in time
recovery

No BRBACKUP/BRARCHIVE  Use the SAPDBA function


Logs logs available Restore individual files

init<SID>.* No init<SID>.*  Restore these files from


files available tape using command
brrestore -n init_ora

 Copy one of its mirrors


Control files damaged

Online redo log files damaged  See R/3 Online Help

 SAP AG 1999

 The SAPDBA function partial restore and complete recovery can be used to restore lost data and to
handle the most frequently occurring database problems. In some cases, however, partial restore and
complete recovery requires additional manual tasks, or the use of Oracle tools.
 If there are no appropriate data backups, or if all offline redo log files generated since the last backup
are not available, you cannot run a partial restore and complete recovery. In this case, you must
perform a database reset or a point in time recovery up to the last existing offline redo log file.
 If other database files are corrupted, in addition to data files, the partial restore and complete recovery
function terminates and you must restart this function once the additional error has been resolved.
 If the BRBACKUP/BRARCHIVE logs cannot be found, you can restore them from the last backup
using the SAPDBA function Restore individual files.
 If the files init<SID>.dba and init<SID>.ora cannot be found, you can restore them from tape. At the
command prompt, enter brrestore -n init_ora.
 If init<SID>.sap has been lost, SAP tools can no longer access the tape drive. In this case, adapt a
sample init<SID>.sap (directory SAP-EXE), or use OS command cpio to restore it from the third
position on a BRBACKUP or BRARCHIVE tape.
 If a control file is damaged, you can copy one of its mirrors.
 If all the control files or online redo log files are lost, see R/3 Online Help, section DBA Oracle.
 When you perform a database reset, the database is reset to its previous consistent status – that is, its
status at the time of a full backup. To determine the last possible full backup, SAPDBA is guided by
the entries in the BRBACKUP summary log file back<SID>.log and the associated detail logs.
 Resetting the database always involves data loss. Therefore, SAP recommends performing a full offline
backup before resetting the database. (If the database is running properly, use SAP tools; otherwise,
use operating system tools.)
 The SAPDBA function Reset Database can be selected with a full offline backup (choose Restore
database and startup open or Restore database and startup mount), or a full online consistent backup
(choose Restore database using online consistent backups).
 Depending on the function chosen, SAPDBA sets the database ether to status open (that is, no reset
logs) or to status mount. If the database has status mount, you can recover data using Oracle tools, such
as the Server Manager. If the database has the status open, you cannot perform a retroactive recovery.
For a retroactive recovery, use Restore database and startup mount instead of Restore database and
startup open.
 With a database reset using a full offline backup, the data files, control files, and online redo log files
are overwritten using the appropriate (taped) backups. For security reasons, these files are copied
immediately to a subdirectory of sapreorg. (To enable these copies to be made, the database must have
the status mount.)
 When you perform a database reset using a full online consistent backup, the database is reset to a
consistent status from the end (point in time) of the full backup.
 With a database reset using a full online consistent backup, data files, control files, and offline redo
log files are overwritten by the appropriate (taped) backups. Therefore, you must save all offline redo
log files in saparch using BRARCHIVE and perform a full backup before you reset the database using
Online_Cons. During this process, note the messages displayed by SAPDBA.
 After a full restore, during a point in time recovery (recover database using backup
controlfile until cancel), only the offline redo log files created during the online consistent
backup are restored and applied. No other point in time can be chosen. The database is then started
using option resetlogs. The online redo log files are newly initialized or newly created. Data cannot be
recovered after opening the database with the option resetlogs, therefore, you must perform a backup.
None of the backups performed before the database reset using online consistent backups can be used
for a partial restore and complete recovery. Note: After a successful database reset, any offline redo
log files that have been restored should be deleted manually from saparch.
 If SAP tools have been used, reworking is required after a database reset. Since log tables SDBAH and
SDBAD are reset to an obsolete status, BRBACKUP may request tapes that have been released (in
logical terms), but which are physically still locked. BRARCHIVE may not recognize the new offline
redo log files as needing to be saved. For more details, see R/3 Online Help, chapter DBA Oracle.
 After a successful database reset, the data files can be searched for corrupt blocks, using the Oracle
tool DB_VERIFY.
 With a full restore and recovery, the database is reset to a consistent status between the (end) point in
time of the full backup, and the current point in time. This SAPDBA function corresponds to the point
in time recovery.
 A full restore and recovery usually involves data loss. Therefore, SAP recommends that you perform a
full offline backup before any full restore and recovery. (If the database is running properly, use SAP
tools; otherwise, use operating system tools.) In addition, all offline redo log files in saparch should be
saved using BRARCHIVE.
 A full restore and recovery can be performed using SAPDBA if the database can be set to status mount
or open. First, a full online (or, if applicable, Online_Cons), or a full offline backup must be selected.
Again, SAPDBA is guided by the BRBACKUP summary log file back<SID>.log and the
corresponding detail logs. Next, enter the recovery end point. For a complete recovery, enter NOW. The
offline redo log file backups required for this point in time recovery are determined using the entries in
the BRARCHIVE summary log file arch<SID>.log.
 Under Show Status, SAPDBA indicates whether the intended recovery is allowed (status: allowed). A
recovery may be rejected if:
 No full backup has been specified, or the required offline redo log files have not been found
 The recovery to be run contains a tablespace reorganization with data files
 The selected backup is dated before the last time the database was opened using the option resetlogs.
 For security reasons, the current online redo log files and a control file are copied to a subdirectory of
sapreorg. All data files are restored from the backup medium (full restore). The control files may also
be restored, depending on whether a tablespace was extended at the recovery time point.
 After a full restore, SAPDBA can replicate the tablespace extension in the database, using alter
database add data file... Information about file specifications is contained in directory sapreorg in the
SAPDBA logs struct<SID>.log and reorg<SID>.log. After a tablespace extension, or after moving
data files to another location, ensure you back up the newly changed structure.
 The offline redo log files required for the indicated recovery time point are restored to directory
saparch. Using a recovery script, the database is recovered to the desired point in time (recover
database until time xxyyzz [using backup controlfile]).
 If recovery was incomplete, the database must be opened using the option resetlogs. Using the Oracle
tool DB_VERIFY, the database can be searched for corrupt data blocks. In addition, SAPDBA
automatically goes to the backup menu, since the database has been opened using resetlogs.
 The copied offline redo log files should be deleted from directory saparch. If you have used SAP tools,
reworking is required after an incomplete recovery. For more details, see R/3 Online Help, chapter
DBA Oracle.
Unit Summary

Now you are able to:


 Analyze the physical database structure using
SAPDBA
 Recover the database using the SAPDBA function
Partial Restore and Complete Recovery
 Reset the database using the SAPDBA function
Reset Database
 Perform a point in time recovery using the SAPDBA
function Full Restore and Recovery

 SAP AG 1999

You might also like