Data Recovering from One Inactive Online Redo Log Missing

If only one member of an inactive online redo log group has been lost, you can use the recovery procedure described in Recovering from Current Online Redo Log Missing. Experienced users can correct this error without shutting down the database. For more information, see the Oracle documentation.

The recovery procedure is different when the database pauses because a redo log switch to an online redo log file was unsuccessful. None of the members in this inactive online redo log group can be read or written to.

If the problem is temporary (for example, incorrect access rights), you only need to correct it, and you can then use the group again. If the files have been destroyed, however, the group can not be used again.

No data is lost, providing the missing redo log file was fully backed up and the backup can be read for media recovery.

Procedure

1. Shut down the database with this SQLPLUS command:

   shutdown abort

   ABORT is needed because the database system cannot perform a proper shutdown, due to the damaged group.

2. Find out which file is missing, and check the ALERT and trace files for the reason why the redo log files were lost.

3. Mount the database with these SQLPLUS commands:

   connect / as sysdba

   startup mount

4. If you were running the database in ARCHIVELOG mode and archiving of the damaged online redo log group was not complete, you have to temporarily switch to NOARCHIVELOG mode before deleting the defective group, because otherwise the system does not let you delete the files:

   alter database noarchivelog;

5. Delete the damaged online redo log files in one of the following ways:

   • As a group:

     alter database drop logfile group ;

   • As individual files:

     alter database drop logfile member '' [,''];

6. Create the new online redo log files (to replace the damaged ones, which you just deleted):

   alter database add logfile ''[,''] to group ;

7. If the database was set to NOARCHIVELOG mode during these actions, change it back to ARCHIVELOG mode:

   alter database archivelog;

8. If you were running the database in ARCHIVELOG mode, and the archiving of the online redo log group was not complete at the moment the problem occurred, it is essential that you now perform a backup of the entire database. If you do not, the offline redo log chain has a gap, which means that – in the event of another media error – only an incomplete recovery is possible.

Finishing an Incomplete Recovery

This section describes the measures you need to take after an incomplete recovery in the following cases:

• Case 1

  Restore of a complete offline backup and subsequently opening the database, without performing a complete recovery of the database

• Case 2

  Restore of a complete online or offline backup and subsequent point-in-time recovery of the database (with ALTER DATABASE OPEN RESETLOGS)

Prerequisites

There are the following possible problem situations:

• Situation A

  The information about the last backups and volumes used in database tables SDBAH and SDBAD has been lost, because neither item is current in the database. As a result, during the next backup, BRBACKUP prompts you to mount volumes (based on the automatic volume management) that are logically free, but are physically locked.

• Situation B

  The current log sequence number was reset during a incomplete recovery.

  • To a smaller value in case 1

  • To the value 1 in case 2

  BRARCHIVE does not find the newly written offline redo log files after the restore, because offline redo logs with these log sequence numbers have already been saved. The summary BRARCHIVE log arch.log still contains entries for successful backup runs of these offline redo log files and, as a result, BRARCHIVE does not detect the new offline redo log files as files requiring backup.

Procedure

Depending on the situation and case, proceed as follows:

• Situation A

  Using the detail BRBACKUP log, you can find out which volume was the last one used. Based on the information on the volume pool in initialization profile init.sap (parameter backup_volumes), you can determine which volume to use for the next backup. Explicitly name this volume when you start the next backup:

  brbackup -v ,,...

• Situation B

  Make sure the old offline redo log files in the backup directory are renamed.

• Case 1

  The current log sequence number can be seen in the detail BRBACKUP log of the backup you used to restore the data. Find the line Current log sequence (message BR0116I). Then change the log sequence number in the last line of the summary BRARCHIVE log arch.log, which starts with #ARCHIVE, to the value: <(determined current log sequence number) - 1>.

  Example

  #ARCHIVE. 86 /oracle/C11/saparch/C11arch_86 1995-04-18 15.55.55

  Current log sequence number: 30

  Change the entry to:

  #ARCHIVE. 29 /oracle/C11/saparch/C11arch_86 1995-04-18 15.55.55

  After the backup, reset the changes in this line. Note that new lines have been added.

  End of the example.

• Case 2

  Change the log sequence number in the last line of the summary BRARCHIVE log arch.log, which starts with #ARCHIVE, to zero (0).

  Example

  #ARCHIVE. 86 /oracle/C11/saparch/C11arch_86 1995-04-18 15.55.55

  Change the entry to:

  #ARCHIVE. 0 /oracle/C11/saparch/C11arch_86 1995-04-18 15.55.55

  After the backup, reset the changes in this line. Note that new lines have been added.

  End of the example.

BRARCHIVE automatically recognizes the resetting of log sequence numbers if the database is opened when BRARCHIVE is started. In this case, the actions described in situation B are not necessary.

Note

In general (as after all recovery operations), delete from the disk offline redo log files that were restored from tape to disk after the recovery. If you used it for recovery, BRRECOVER automatically performs this action .

Automating the Data Recovery

You can control whether you want to perform a manual (autorecovery off) or an automatic recovery (autorecovery on).

Procedure

Enter the appropriate SQLPLUS command before you enter the recover command.

• set autorecovery on

  The required offline redo log files are automatically applied without requiring any user entry. The names and paths of the offline redo log files are derived from the init.ora parameters log_archive_dest and log_archive_format, which means that required offline redo log files must first be restored under the appropriate names. For more information, see Setting Up Archiving.

  If the files cannot be imported under log_archive_dest, you can override the source specified in archive_log_dest by entering the following command:

  set logsource =

  This means the files are now expected in the directory identified under logsource.

• set autorecovery off

  The applying of the individual redo log files must be initiated by the user (default value).

  In the process, Oracle automatically suggests a file derived from log_archive_dest (or logsource) and log_archive_format.

  Choose RETURN to accept this value.

  You can also explicitly enter the name of the redo log files by entering:

  • cancel to interrupt or cancel the recovery

  • auto to continue the recovery in automatic mode from this point

  • from to change the log source

Data Recovering from Current Online Redo Log Missing

A member of the group - or the entire group - of current online redo log files (that is, the redo log files in which the database changes are currently being recorded) is lost.

Use the entries in the ALERT file and in the LGWR trace file to analyze the error situation. You must check all sources of information for possible LGWR errors. Even if an error allows the instance to continue running (for example, at least one member of the current group can be written to, errors only in the other members), the error should be corrected as soon as possible.

If you have not been mirroring the online redo log files, as supported by Oracle (and have also not been using hardware-based mirroring), the risk of losing online redo log entries is significantly higher. To be able to perform a full recovery, only the entries from the current online redo log file are necessary. Use mirroring to guard against complete loss of the online redo log files. If the mirrored online redo log files are available, you can use these later to perform a complete recovery of the database. Otherwise you can only recover the database to the point of the missing redo log entries (that is, an incomplete recovery with loss of data).

For this reason, we strongly recommend once again that you make use of the Oracle options for mirroring the online redo log files.

Prerequisites

You must meet the following requirements:

• You used the Oracle option for mirroring the online redo log files (or have hardware-based mirroring), and therefore have at least one copy of each online redo log file (SAP default: two copies of the online redo log files).

• Apart from the one member of the current online redo log group, no other files have been damaged.

  If further files have been damaged, restore the missing files and the missing active redo log and follow the recovery procedure for the category of the missing file (control file or files of the system, user, or index tablespaces).

Procedure

1. If the database system is still active, use the SQLPLUS command shutdown abort to shut it down.

2. Determine the reason why the current online redo log files were lost by examining the ALERT and trace files.

3. Replace the missing online redo log files with a mirrored copy.

4. Start the database with the SQLPLUS command startup.

   The system automatically performs an instance recovery.

   Note

   If all members of the current redo log group have been lost, you can only perform an incomplete partial recovery. For more information, see the documentation on your Oracle database system or Performing Incomplete Recovery.

Complete Database Recovery with BR*Tools

You can use BR*Tools for Oracle to perform a complete database recovery. BRRECOVER performs the recovery.

Note

This section discusses how to perform a complete database recovery.

For more information about how to approach a complete database recovery, see Complete Database Recovery.

End of the note.

Prerequisites

• Make sure you have set the necessary BRRECOVER parameters in the initialization profile init.sap, because BRTOOLS uses these when it calls BRRECOVER.

• BRRECOVER calls BRRESTORE as necessary to perform restore functions.

• BRRECOVER calls SQLPLUS as necessary to apply offline redo log files.

Process

1. You start BRGUI or BRTOOLS.

2. You choose Restore and recovery Complete database recovery .

   You can do one of the following:

   • Set the required entries now and run the recovery in unattended mode

   • Wait for BRRECOVER to prompt you during the recovery, that is, run the recovery in attended mode

   Recommendation

   We recommend you to run the recovery in attended mode.

   End of the recommendation.

3. If you want to run the recovery in unattended mode, you select force in Confirmation mode (confirm).

4. To start the recovery, you choose Continue.

   BRRECOVER starts the recovery. You perform the following steps with BRRECOVER.

   Note

   If you are using attended mode, BRRECOVER guides you through the recovery, prompting you as necessary.

   End of the note.

5. You check the status of the database files.

6. You select database backups.

7. You restore data files.

8. If required, you restore and apply an incremental backup.

9. You restore and apply the online redo log – that is, archivelog – files.

10. You open the database.

11. You check the results in the BRRECOVER and BRRESTORE logs:

    • BRRECOVER logs:

      • The summary log recov.log displays the return code.

      • The detail log v.crv displays the progress.

    • BRRESTORE logs for the restore functions:

      • The summary log rest.log displays the return code

      • The detail log r. displays the progress.

    For more information about how to view the logs, see Showing Logs with BR*Tools.

Recovering from User Tablespace Missing

You use this recovery procedure if:

• One or more data files are missing from a tablespace.

• A user tablespace does not contain data from the Oracle Data Dictionary, active rollback segments, or temporary segments.

• Oracle issues error messages when a user attempts to access the involved tablespace. Error information is also written to the database ALERT and trace files.

  Caution

  If only one user tablespace is lost, you can perform a manual tablespace recovery without shutting down the database. However, note that user tablespaces are used intensively in the SAP system, and this procedure is therefore only recommended for experienced database administrators. The loss of a user tablespace often has similar consequences for the SAP system as the loss of the SYSTEM tablespace, because the effects of the loss of this one tablespace are very complex.

  End of the caution.

A complete recovery of the database is possible if you have a backup copy of the corresponding tablespace files and of all redo log files written since the backup.

Prerequisites

• If you use an SAP database, you shut down the SAP system before starting the recovery procedure. Tables are used so intensively in the SAP system that it is generally impossible to set the affected tablespace to OFFLINE without terminating the activities of many users.

• This procedure describes the recovery procedure when the database is closed. For more information on recovery options with an open database, see the Oracle documentation.

Procedure

1. If it is running, shut down the database system with this SQLPLUS command:

   shutdown abort

   You have to shut down the database with ABORT because the missing files cannot be closed.

2. Inspect the ALERT and trace files to determine the cause of the problem.

   The problem is often that an entire disk has crashed, and you need to recover more than one tablespace.

3. Use the log files from the SAP tools BRBACKUP and BRARCHIVE to find the volumes that contain the following files:

   • Last backup of the lost tablespace files

   • Offline redo log files of all instances backed up since the last backup

   It is important to identify the location of the lost files. This information appears at the start of the detail log of the BRBACKUP backup that you are using.

4. Restore only the damaged or lost files. You can minimize the time required for recovery by only restoring the missing or damaged files.

   You also have to restore the backed-up redo logs of all instances that are required for the recovery. To do this, use BRRESTORE.

5. Mount the database with these SQLPLUS commands:

   connect / as sysdba

   startup mount

6. If you were not able to restore backed-up files to their original directories or if you had to change file names, update the control file.

   Use the following command to change a path:

   alter database rename file '' to '';

   See Updating the Control File.

7. If the data files of the database were set to status OFFLINE when the error occurred, change the status of the files in the control file to ONLINE.

   To find the relevant files, search for “offline” in the ALERT file or check the v$datafile view:

   select * from v$datafile

   Change the status of a data file in the control file with this SQLPLUS command:

   alter database datafile '' online;

   See Updating the Control File.

8. Start the recovery with this SQLPLUS command:

   recover database;

   When prompted to do so, enter the paths of the offline redo log files that you need to apply.

   The system processes online redo logs automatically.

   We do not discuss here the alternatives - recover tablespace and recover datafile - since SAP recommends shutting down the database when an error occurs. The recover database command only performs the actions necessary to recover the damaged files. Therefore, it does not take much longer than the recover tablespace and recover datafile commands.

   For information on recover tablespace and recover datafile, see the Oracle documentation.

9. When the message recovery complete is displayed, start up the database system with this SQLPLUS command:

   alter database open;

For more information, see the Oracle documentation.

Note:

In most cases, you can use BRRECOVER to correct media errors affecting the data files of a user tablespace. For more information, see Complete Database Recovery with BR*Tools.

Procedure documentationRecovering from Index Tablespace Missing

Generally, Oracle treats an index tablespace just like a user tablespace. Therefore, you can use the recovery procedure for a user tablespace. The procedure below describes an additional recovery option for SAP databases.

Procedure

1. Shut down the database with this SQLPLUS command:

   shutdown immediate

   If this fails, use:

   shutdown abort

2. Find out which data file is affected by the media error, using the information in the ALERT and trace files.

3. Mount the database with these SQLPLUS commands:

   connect / as sysdba

   startup mount

4. Set the data files to OFFLINE:

   alter database datafile '' offline;

5. Open the database:

   alter database open;

6. Make sure that the index tablespaces do not contain any tables. You can check this using the Oracle tables DBA_SEGMENTS and DBA_TABLES.

7. Use the corresponding BRSPACE function to create the DDL statements for the affected indexes:

   brspace -f tbreorg -s -d only_ind

8. Drop the affected tablespace, including contents:

   brspace -f tsdrop -t -f

9. Recreate the affected tablespace:

   brspace -f tscreate -t -d index

10. Recreate the indexes with script ddl.sql from subdirectory of sapreorg with this SQLPLUS command:

    SQL> @ddl

The recovery of the index tablespace is complete.

Note:

In most cases, you can use BRRECOVER to correct media errors affecting the data files of a user tablespace. For more information, see Complete Database Recovery with BR*Tools.

Recovering from SYSTEM Tablespace Missing

One or more files of the SYSTEM tablespace has been damaged or lost due to a media error.

Backups of the affected files exist. All offline redo log files that have been written since the last backup are available uninterrupted. The control files and all online redo log files are undamaged.

Prerequisites

Since the SYSTEM tablespace is affected, the recovery must take place with the database closed. If a backup of the missing files and all redo log entries are available, a complete recovery is possible.

Procedure

1. If the database system is still active, shut it down with this SQLPLUS command:

   shutdown abort

   ABORT is required because the loss of individual files from the tablespace means that the changes from SGA can no longer be recorded, and the database cannot be closed properly as a result.

2. Examine the ALERT and trace files to determine the cause of the problem.

3. Use the log files created by the SAP tools BRBACKUP and BRARCHIVE to find the volumes containing the following files:

   • Last backup of the SYSTEM tablespace

   • Offline redo log files of all instances backed up since the last backup

4. Restore the backups of the damaged or lost files and the backed up offline redo log files of all instances, using BRRESTORE.

5. Mount the database with this SQLPLUS command:

   connect / as sysdba

   startup mount

6. If necessary, change the names and paths of the files in the control file. See Updating the Control File.

7. If required, automate the recovery using the autorecovery option. See Automating the Recovery and read the corresponding Oracle documentation.

8. Start the recovery with the following SQLPLUS command:

   recover database;

9. Depending on the recovery mode (autorecovery on/off), the required offline redo log files are either processed automatically or you have to enter their paths and names. The system applies the online redo log files automatically.

10. When the message recovery complete is displayed, open the database again with this SQLPLUS command :

    alter database open;

    Note:

    In most cases, BRRECOVER can be used to correct media errors affecting the data files of a user tablespace. For more information, see Complete Database Recovery with BR*Tools.

Mirroring the Control File

It is essential to mirror the control file in your Oracle database.

If you only have one copy of the control file and lose this copy due to a disk error or other problems, it is probably impossible to completely recover the database. The result is inevitable data loss.

To prevent this happening, create multiple copies of the control file. When the SAP system is installed, the control file is mirrored to at least two additional disks (often three). You can also mirror the control file yourself.

Caution

Always make sure that all the control files are on different disks.

End of the caution.

Prerequisites

The default database profile (init.ora profile) delivered with the system makes sure that the control file and its mirror copies are stored in directories that are mounted on different disks.

Procedure

If necessary, change the standard mirroring of the control file by setting the control_files parameter.

Example

Here is a sample entry in profile init.ora:

control_files = (?/dbs/cntrl.dbf, ?/sapdata1/cntrl/ctrl.dbf,?/sapdata2/cntrl/ctrl.dbf)

The question mark ? is the official Oracle placeholder for the home directory of the database system (for example, /oracle/C11/102_64).

Data Recovering from One Control File Missing

You use this procedure if a copy of the control file cannot be read or written to.

Database activities continue normally until the next update of the control file – that is, until the next checkpoint or redo log file switch – and the database then crashes.

In this case you do not need to perform an explicit recovery of the database. If a copy of the control file exists, the system can perform a recovery automatically.

Procedure

You have the following main recovery options after one of the control files is lost:

• Replace the missing control file

  Find out why the control file was lost. For example, you cannot replace the file when the disk is not available.

  Check the ALERT and trace files of the database system to analyze the error. The error messages will indicate which control file is missing, and may also indicate how it was lost.

  Replace the missing control file as follows:

  1. Shut down the database and exit SQLPLUS.

  2. Copy an existing control file to the desired storage location at operating system level (see parameter control_files in the init.ora profile).

  3. Start SQLPLUS and start up the database.

• Modify the database system

  Check the ALERT and trace files to find out which control file was lost.

  1. Shut down the database and exit SQLPLUS.

  2. Delete the missing file from parameter control_files in profile init.ora (default: /dbs/init.ora).

  3. Start SQLPLUS and start up the database. No other actions are required for recovery.

  This solution is only acceptable if you have at least two copies of the control file. This guarantees that at least one mirror copy of the file still exists, even when one control file has been deleted. The database should always have at least two control files, original and mirror. In the SAP system, the control files are mirrored in three or more directories. For more information, see Mirroring the Control File.

Database Recovery after Media Errors

A media error occurs when a read or write error takes place in a database file due to a physical defect on the disk drive where the file is located. The most frequent physical defect is a head crash, which usually renders all the files on a disk unusable.

In most cases, the database must be recovered after a media error. The recovery strategy depends on the type of damage in the database. You must therefore analyze the error and understand how it was caused before you can continue with the recovery.

Caution

If you are not sure how to perform a recovery, be sure to contact your SAP consultant or an Oracle specialist. Do not attempt a recovery if you are not confident.

An incorrectly performed recovery can lead to irretrievable loss of data in your database. The damage you risk is much more costly than the time you spend on a carefully planned, properly executed recovery of your database.

End of the caution.

In addition to the ALERT and trace files, SAP recommends analyzing the database using Complete Recovery Check the Status of Database Files in BRRECOVER. If defects in the data files of the database are involved, BRRECOVER can often perform the database recovery automatically.

See Restore and Recovery with BR*Tools.

This section provides an overview of the recovery process using Oracle SQLPLUS. The sections below contain examples of the command line operations with SQLPLUS.

If you have followed the SAP recommendations regarding the installation and operation of the database system, you should generally succeed in carrying out a complete recovery after a media error. If, however, in an extreme case your backups of the database and your redo log backups have been damaged too, you might only be able to perform an incomplete recovery.

The procedures required for the following errors are listed in the following:

• Loss of one or all copies of the control file

• Loss of an online or offline redo log file or even an entire online redo log group

• Loss of a system, temporary, user, or index tablespace

• Error in the archiving process for online redo log files using ARCH

These errors are usually media-related (for example, if the archiving directory for the offline redo log files is lost or full).

Database Recovery after Statement Errors

A statement error occurs when an error in executing a database statement occurs in a running program.

If such an error occurs, the database system cancels the incorrect statement and issues an error message. The program containing the error is terminated. Furthermore, the transaction is completely canceled in the database (rollback), an ABAP dump is issued, and a message is usually written to the system log.

A statement error can also occur if an extensive operation entirely fills up the rollback segment. The reason for such an error is generally incorrect programming.

The database administrator does not have to intervene in order to execute a recovery after a statement error.

Database Recovery after User Errors

A user error occurs when a user deletes or falsifies data (for example, deletes a table or program that is required for further system operation), either by mistake or due to lack of knowledge.

You can generally correct such a user error if you can meet the following requirements:

• You exported the object using the SAP tool R3trans, thus backing it up. You can use this copy to restore the condition of the object at the time of the export, taking into account possible database inconsistencies.

• An object from the ABAP Dictionary or the ABAP Repository is involved. The ABAP Dictionary and the correction system both perform version backups of these objects within the SAP system. If you can continue working with that version of the object (ideally, the object has not been changed recently), then you can restore it.

In general, you cannot use the Oracle Export/Import tools to recover a lost SAP object. The reason for this is that the SAP database tables are often shared system-wide. A user cannot import the ATAB (central control table) to recover an individual SAP table, for example, as this risks overwriting the work of other users.

You cannot recover an object by recovering the database either. The recovery of a lost object requires an incomplete recovery up to the moment the user error occurred (point in time recovery). Any changes made to the database from that moment on are lost.

Object documentationTypes of Database Errors

There are a number of errors that affect the operations of an Oracle database or can cause the database to crash. Depending on the type of error, a recovery can either be performed automatically or must be performed by the user or database administrator.

Therefore, you must find out the exact type of error so that you take the appropriate action to correct the error.

Errors can generally be divided into the following categories:

• User errors, see Recovery after User Errors

• Statement errors, see Recovery after Statement Errors

• Process errors, see Recovery after Process Errors

• Instance errors, see Recovery after an Instance Error

• Media errors, see Recovery after Media Errors

Database Recovery with SQLPLUS

Although BR*Tools can in most cases be used to recover a failed database, there are exceptions to this. Therefore, this section describes how to recover the Oracle database system using SQLPLUS functions.

The information here helps you with database recovery after an error in one of the following database components:

• Data files

• Online redo log files

• Control files

  Caution

  An incorrectly performed recovery might lead to irreparable loss of data in your database. We recommend you to always discuss your recovery plan with an experienced database administrator, your SAP consultant, or an Oracle specialist before you start a recovery.

BR*Tools for Oracle DBA

Use

SAP provides the tools BRBACKUP, BRARCHIVE, BRRESTORE, BRRECOVER, BRSPACE, BRCONNECT, and BRTOOLS to manage and protect the data in your Oracle database.

This section describes how to perform Oracle DBA with BR*Tools. For more information on how to work out an approach to Oracle DBA, see Approach to Oracle DBA .

For more information on other tools, including the Oracle tool SQL*Plus, see Other Tools for Oracle DBA.

Although SAPDBA 6.20 for Oracle is still available for Oracle 9i, it is no longer being developed. Therefore, we strongly recommend you to use the BR*Tools instead.

Integration

The BR*Tools are :

● Integrated with BRTOOLS, which is the character-based interface that calls BRBACKUP, BRARCHIVE, BRRESTORE, BRRECOVER, BRSPACE, and BRCONNECT

· Available for the operating systems UNIX and Microsoft Windows

Distinguish between the following:

● BR*Tools is the program package containing BRBACKUP, BRARCHIVE, BRRESTORE, BRRECOVER, BRSPACE, BRCONNECT, and BRTOOLS.

● BRTOOLS is the program that displays the menus from which the other BR programs are called.

As an example, the following graphic shows the integration of the backup, restore, and recovery tools:

Prerequisites

The BR*Tools are installed automatically on the database server in the directory /usr/sap//SYS/exe/run.

We classify BR*Tools as functional, help, batch, and interactive tools:

Tool Types for BR*Tools

Type	Tool	Description
Functional	BRBACKUP, BRARCHIVE, BRRESTORE, BRRECOVER, BRSPACE, and BRCONNECT	Perform actions directly on database files or objects
Help	BRTOOLS and BRCONNECT	● BRTOOLS is the menu program that can call all other functional tools interactively ● BRTOOLS and BRCONNECT are also called internally: ○ BRTOOLS is called by BRBACKUP, BRARCHIVE, and BRRESTORE for backup, restore, and verification. ○ BRCONNECT is called by BRBACKUP to monitor the database during a backup
Batch	BRBACKUP, BRARCHIVE, BRRESTORE, BRCONNECT	Only run on their own in batch, without menus. You can call them interactively with BRTOOLS.
Interactive	BRSPACE, BRRECOVER, BRTOOLS	Run interactively with their own menus. BRSPACE and BRRECOVER can also run in batch mode.

There is a menu in BRCONNECT to change the database password in GUI mode.

Messages and Return Codes for the BR*Tools

Messages

The BR*Tools issue messages in the following form:

BR Message text

NNNN: Sequential number of the message

X: Type of message:

· I: Information

· W: Warning

· E: Error message

The text of the message contains the following variables:

· %s: a string

· %d: an integer

· %f: a real number in floating-point format

In most cases, the SAP tools issue a group of messages, which enables you to precisely analyze the error.

Return Codes

The following return codes are possible:

0	Successful
1	Warnings – all files were processed (for example, backed up or restored)
2	Canceled during the initialization phase by a user or other signal
3	Errors occurred during the initialization phase, processing was not started
4	Canceled by a user or other signal during processing
5	Started, but not completed because errors occurred during processing
6	Internal termination

Quick Mode for BRSPACE

You can use quick mode to skip the higher-level menus in BRSPACE, including the menu to select the object of your chosen function.

You use quick mode from:

• BRGUI or BRTOOLS menus with the title BRSPACE options for

• The command line at operating system level

For quick mode, you must specify at least the function, the object name, and/or the action. The object – for example, a tablespace name if you want to extend a tablespace – varies according to the function that you choose. You can also enter additional options in quick mode.

Note

The alternative to quick mode is main menu mode, in which you only use the menus in BRSPACE to enter the options required to perform a function. Unless you know the object name, we recommend you to use main menu mode.

End of the note.

In quick mode, BRSPACE skips the menus in which you normally specify the function, the action, and/or the object name. They jump directly to the final input menu to let you enter the remaining required parameters and execute the function immediately.

The following graphic illustrates in outline how quick mode works:

Exceptions to quick mode

There are the following exceptions to quick mode:

• Function dbshow to show database information.

  If you do not enter the class of the information to be displayed, you see a menu displaying the different categories of information class:

  Show database instance information

  Show database space information

  Show database object information

  Choose the category and then the class that you require.

  BRSPACE displays the requested information.

• Alter functions:

  • dbalter to alter the database instance

  • dbparam to alter database parameters

  • tsalter to alter tablespaces

  • dfalter to alter data files

  • tbalter to alter tables

  • idalter to alter indexes

  With these functions, you should also enter an action to specify what kind of alter function you require. If you do not enter an action in quick mode, BRSPACE prompts you to select an action before you can continue.

• Multiple Objects

  If you select multiple objects in quick mode, BRSPACE displays a list of objects for confirmation. If the list is not what you require, you can go back and make a new selection.

  Example

  • The following example shows quick mode from the command line:

    brspace -f tsextend -t psapprd

    BRSPACE starts by displaying the input menu for the function Extend tablespace. The field for the object name is filled with your entry.

    You can now enter all required options and execute the function immediately.

  • The following example shows a command line entry for an alter function where the object (here, the database parameter) is specified, but not the action:

    brspace -f dbalter -p audit_trail

    BRSPACE starts by displaying the function main menu for the function that you entered, which is Alter database parameter in this example.

    You must first select the action before BRSPACE can display the input menu to let you execute the function.

  End of the example.

  Note

  When you have finished executing a function and you choose back after starting BRSPACE in quick mode, the quick mode is deactivated and you can choose a new object to execute the function again. If you choose reset program status, BRSPACE restores your original object selection.

  The exception to this is for the functions in segment management, where it makes no sense to display all tables or indexes, because the list would be too long.

recov_type for restore

This parameter specifies the type of database recovery using BRRECOVER.

Syntax: recov_type = complete|dbpit|tspit|reset|restore|apply|disaster

Default: complete

Possible values:

· complete: complete database recovery

· dbpit: database point-in-time (PIT) recovery

· tspit: tablespace point-in-time (PIT) recovery

· reset: whole database reset

· restore: restore of individual backup files

· apply: restore and application of archivelog (that is, offline redo log) files

· disaster: disaster recovery

This parameter corresponds to BRRECOVER –t|-type.

Restore and Recovery with BR*Tools

Use

You can restore and recover your Oracle database with BR*Tools.

This section discusses how to perform restore and recovery.

For more information on the approach to restore and recovery, see Restore and Recovery.

Integration

· BRTOOLS calls the SAP tool BRRECOVER. You can also perform restore and recovery with SQLPLUS, but only if you are an expert.

· Make sure that you have set the necessary parameters for BRRECOVER in the Initialization Profile init.sap.

· You have to have SYSDBA privilege to let BRRECOVER connect to the database. This means that you have to log on as ora (UNIX) or adm (Windows).

· The recovery is normally attended, that is, you have to enter parameters as the recovery runs, when prompted by BRRECOVER.

Features

You can perform the following restore and recovery functions with BR*Tools:

· Complete database recovery

· Database point-in-time (PIT) recovery

· Tablespace point-in-time (PIT) recovery

· Whole database reset

· Restore of individual backup files

· Restore and application of archivelog (that is, offline redo log) files

· Disaster recovery

Activities

...

1. You call the restore and recovery function in BRTOOLS and check the displayed parameters, changing them as required.

The default parameter values, which are set in the initialization profile init.sap, are as follows:

¡ Recovery type is complete database recovery.

¡ Serial recovery for applying offline redo logs, using the Oracle default settings

¡ Interval of 30 days for the displayed backups to be restored. This me ans that only backups from the last 30 days can be selected by default.

¡ Scrolling of 20 lines for the list menus, only relevant for character-mode menus

BRTOOLS only lets you change certain parameters for the backup. If you have to make other changes, you must change the init.sap profile manually and then restart BRTOOLS.

2. If required, you change the default values for the restore and recovery parameters in the initialization profile init.sap and restart BRTOOLS.

3. If required, you choose Restore and recovery ® Reset program status to set the defaults used to the values in the initialization profile init.sap. For certain input values, there is no corresponding parameter in the initialization profile, in which case the default value from the BRTOOLS program is used.

4. You start the restore or recovery.

BRRECOVER takes you through the recovery step by step, displaying sub-menus as required.

5. You check the results in the BRRECOVER logs.

Backup and Database Copy with BR*Tools

Use

You can back up the database files and offline redo log files of your Oracle database with BR*Tools. If you are performing an offline backup of the whole database, the temporary files and online redo log files are also backed up. If you have lost data and want to recover it, the backup files are essential. You can also make a database copy and back up non-database files and directories.

You typically use BR*Tools for a one-off backup of the:

· Database files, such as after a structure change to the database. For example, after moving a data file, you can back up the database to make the recovery procedure easier.

· Offline redo log files. Oracle copies the online redo log files to the archiving directory, so creating the offline redo log files.

For routine backups, we recommend one of the following:

· DBA Planning Calendar to schedule a backup and then view its log

· A scheduler offered by a supplier of the BACKINT interface

· The scheduler cron for UNIX or at for Windows

If you need to recover your database, you must have access to all offline redo log files that have been written since the database backup. Otherwise you can only recover the database to the point in time of the last available redo log. Therefore, you must always back up the offline redo log files after a database backup, and immediately after an online backup.

In production systems, we strongly recommend you to:

· Run the database in ARCHIVELOG mode with automatic archival turned on. For more information, see Setting Up Archiving.

· Make two copies of the offline redo log files. In test systems, one copy is often sufficient.

Integration

· BRTOOLS normally calls the SAP tool BRBACKUP or BRARCHIVE to perform the backup. You can also perform a backup directly by calling BRBACKUP or BRARCHIVE from the command line.

We recommend you to normally use BRTOOLS rather than BRBACKUP or BRARCHIVE. This is because the BRTOOLS menus simplify entry of the correct parameters.

· “Archiver stuck” problem

The Oracle database hangs if it is operated in ARCHIVELOG mode, but the archiving process cannot save the online redo log files because the archiving directory is full. This situation is called “archiver stuck.” If this occurs you must back up the offline redo log files and delete them from the archive directory as soon as possible.

To avoid archiver stuck, back up the offline redo log files regularly to tape. How often you do this depends on the amount of activity in your SAP System. If a lot of redo log entries are written, and the redo log files are frequently switched, be sure to constantly monitor the archive directory. When necessary, save and delete the offline redo log files.

For more information about avoiding "archiver stuck," see SAP Note 316642.

· Make sure the necessary parameters have been set for BRBACKUP and BRARCHIVE in the Initialization Profile init.sap.

· You can back up the offline redo log files regardless of the current status of the database (open or closed) and the SAP system. If you have configured your system according to the SAP recommendations, the Oracle database system saves the online redo log files automatically as offline redo log files. Unless you have changed the standard profile init.ora, the offline redo log files are stored in the archive directory /oraarch. For more information, see Setting Up Archiving.

Features

You can perform the following backup functions with BR*Tools:

· Database backup

· Archivelog backup (that is, backup of the offline redo log files)

· Database copy

· Non-database backup

· Backup of database disk backup

· Verification of database backup

· Verification of archivelog backup

· Additional functions

¡ Update of compression rates

¡ Preparation of RMAN backups

¡ Deletion of database disk backups

¡ Deletion of archivelog disk backups

¡ Controlling of BRARCHIVE run

¡ Initialization of BRBACKUP tape volumes

¡ Initialization of BRARCHIVE tape volumes

BRTOOLS calls BRRESTORE for the verification functions.

Activities

...

1. You call the backup function in BRTOOLS and check the displayed backup parameters, changing them as required.

The default parameter values, which are set in the initialization profile init.sap, are as follows:

¡ For database backup, the default is an offline whole database backup to a local tape device without file compression. This means that the online redo log files and control file are backed up as well as the data files.

¡ For archivelog (that is, offline redo log) file backup, the default is a first copy backup of offline redo log files without deletion to a local tape device without file compression.

BRTOOLS only lets you change certain parameters for the backup. If you have to make other changes, you must change the init.sap profile manually and then restart BRTOOLS.

2. If required, you change the default values for the backup parameters in the initialization profile init.sap and restart BRTOOLS.

3. If required, you choose Backup and Database Copy ® Reset program status to set the defaults used to the values in the initialization profile init.sap. For certain input values, there is no corresponding parameter in the initialization profile, in which case the default value from the BRTOOLS program is used.

4. You start the backup.

If the backup is being made locally or remotely to tapes or disks, then the backup is monitored and an estimation is made of the backup time, based on the elapsed time and the size of the files that still have to be backed up. You also see success or error messages.

5. You check the results of the backup in the BRBACKUP logs or BRARCHIVE Logs.