Error Analysis:sapdba

Information on all types of database problems can be found in the trace and ALERT files, where the actions in the database are recorded.

• In the ALERT file, important system events and significant error messages are continually collected for the entire system. The ALERT file can inform you, for example, which of the online redo log groups is the current one.

ALERT file: /saptrace/background/alert_.log

• Trace files are created by the individual background and user processes of the database system. Trace files thus offer more detailed information for error analysis than the ALERT file.

Trace files of the background processes: /saptrace/background/_.trc

Trace files of the user processes: /saptrace/usertrace/.trc

The directories where the ALERT and trace files are stored are defined by the init.ora parameters background_dump_destination and user_dump_destination .

The naming conventions for the trace files depend on the operating system. Under UNIX, the name of the trace file contains the operating process number, the ORACLE process number and the ORACLE system ID.

A trace file can contain the following information:

• Date and timestamp

• Version number

• Process information

• Error messages

• Calling stack trace

Dumps from the System Global Area (SGA) and the Program Global Area (PGA).

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.

If you are not sure how to perform a recovery, please contact your SAP consultant or an ORACLE specialist. Do NOT attempt to just "give it a try".

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.

In addition to the ALERT and trace files, SAP recommends using the SAPDBA Check function (Check (and repair) database ® Check database) to analyze the database. If defects in the data files of the database are involved, SAPDBA can often perform the database recovery automatically.

See SAPDBA Database Recovery.

This section is intended to provide an overview of the recovery process using ORACLE utilities. Use the ORACLE utility SVRMGR. The sections below contain examples of the command line operations with SVRMGR.

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 archives have been damaged too, you may only be able to carry out 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

Recovery after an Instance Error

Recovery after an Instance Error

Recovery after Process Errors

A process error occurs when a user process is canceled.

The ORACLE instance is not normally affected by the termination. The ORACLE process monitor (PMON) responds by canceling the database changes made by current transactions and releasing the resources which were used by the process. Work with the database system can then be continued normally.

The database administrator does not have to intervene to carry out a recovery after a process error.

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/4 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.

Recovery after User Errors

A user error occurs when a user deletes or falsifies data (e.g. 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 when the following requirements are met:

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

• An object from the ABAP/4 Dictionary or the ABAP/4 Repository is involved. The ABAP/4 Dictionary and the correction system both perform version backups of these objects within the SAP System. If you can carry on 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 would risk overwriting the work of other users.

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

SAPDBA Troubleshooting

Before an additional file is added, SAPDBA carries out the following checks (if file systems are used):

• Block size: The following block sizes must be identical:

	Block size for
filesystem block size	the file system
filesystem fragment size	the file system fragments
ORACLE block size	the database system

SAPDBA verifies that the above values are identical. If not, it issues a warning message and suggests selecting a new file system. You can ignore the warning and continue, but this is not recommended, as system performance will be affected when the block sizes of the file system and database are different.

Please also note the following:

• The ORACLE database block size is always 8 KB in the R/3 System.
• SAPDBA does not perform the check under the AIX operating system, as the block sizes are always different:

ORACLE block size	4 KB
filesystem block size	8 KB

• For OSF1, the value for
filesystem fragment size is always 1 KB, and is therefore not checked by SAPDBA.

• Disk storage space: SAPDBA checks that there is sufficient storage in the file system proposed for the new file. If not, SAPDBA does not add the file.

If these checks were successful, SAPDBA creates a directory or a symbolic link for the data file. The control file (old and new) is backed up under the directory (directory name: ) belonging to the log file ( .ext ). SAPDBA then creates the data file with ALTER TABLESPACE ADD DATAFILE. If any of these operations fails, SAPDBA is terminated immediately.