Oracle7 Enterprise Backup Utility Administrator's Guide | ![]() Library |
![]() Product |
![]() Contents |
![]() Index |
This chapter discusses the mechanisms available to you for managing the performance and operation of the Enterprise Backup Utility.
The topics covered in this chapter are:
To preserve database security, the EBU executable in UNIX operating systems is setuid to the Oracle software owner, so that it can read the datafiles. Also protections to the executable should be set such that only users belonging to the dba group can execute EBU, this is accomplished by doing:
$ chmod $EBU_HOME/bin/ebu 4550
(This note applies only to UNIX)
EBU must be able to connect to the target database to perform the following operations during register, backup , and restore jobs:
The backup user - the database user under which all EBU operations are performed needs to be able to use SYSDBA commands like startup and shutdown
Additional Information:
"See "Authorizing Target Database Backups" for more information on the backup user. |
The Enterprise Backup Utility parameter file is not the same as the RDBMS parameter file, initsid.ora. The EBU parameter file allows you to set utility parameters specifying the operation and performance characteristics of the utility. You can use a parameter file to specify any or all of the EBU parameters. For parameters left unspecified, the utility uses its default settings.
The parameter file is a convenient way to specify values for EBU parameters, but you can also specify parameters individually in command scripts.
The EBU parameter file can be any file. The utility uses its default settings for any parameters not specified in the file or command script. To specify a parameter file, add the line param= full_pathname to the command script.
A parameter file should have only three types of statement lines:
No statement line can be longer than 1024 characters.
Table 8-1, "Enterprise Backup Utility Parameters" describes the EBU parameters that can be set.
Each Enterprise Backup Utility instance is monitored by an Instance Manager.
Each host (in Unix, host and oracle software owner running backup/restore operations) must have its own Instance Manager (in Unix, however, you need only one Instance Manager process per oracle software owner, per host. If there is one Instance Manager process running on the host machine already, the Enterprise Backup Utility does not start a second, unless the second instance is running under a different oracle software owner).
The Instance Manager monitors the Enterprise Backup Utility (ebu) instances in progress and manages system resources in the case of an instance failure.
For example, if an online backup abnormally terminates, the Instance Manager notifies the Oracle7 Server of the termination of the job by issuing an ALTER TABLESPACE END BACKUP statement.
The Instance Manager (brd process) monitors the active ebu instances by checking the entries in the runtime tables in the EBU Catalog. When a new ebu instance is started, it checks the EBU Catalog for an active brd. If none is found, or if the previous brd has been terminated abnormally, a new brd is started; otherwise the running brd is simply alerted to the new ebu instance.
Once started (or signalled to continue), brd connects to the EBU Catalog database and looks for jobs that have not finished. If an abnormally terminated job is found, brd cleans it up. If no active jobs are found, brd suspends itself for a user-configurable period (BRD_SAMP_TIME), then checks again for unfinished jobs.
The Instance Manager performs the above cycle until the configurable number of retries (BRD_RETRIES) have been performed without finding any unfinished jobs. The Instance Manager then disconnects from the backup catalog database and suspends itself for a configurable amount of time. If no new ebu instances are started before brd reaches the end of its suspension time it terminates. If brd is awakened by a new EBU instance, brd behaves as if it has just been started up.
Before the brd process cleans up a job in the Backup Catalog, it signals the third-party media management product to clean up the corresponding job in its catalog. brd will not clean EBU's backup catalog until the media manager catalog is cleaned successfully or 10 failed attempts have been made to clean the media manager catalog.
How closely the Instance Manager monitors EBU is a tradeoff between the resources it will use and how quickly an aborted job should be cleaned up.
Once the Instance Manager disconnects from the backup catalog, the catalog database can be brought down and up as necessary. The connection to the catalog will not be restored until a new EBU instance spawns an Instance Manager.
If you need to terminate a brd process, do so with the ebutool -stopbrd command, which requests that brd gracefully exit. The brd process will try to update its catalog entry and finish logging its action to the log file.
At times it may be desirable to awaken a running brd without starting a new EBU job. This can be accomplished by using the ebutool -wakebrd command. This reactivates a suspended brd, just as if a new EBU instance had been started.
The following environment variables allow the user to configure the Instance Manager as desired. The Instance Manager uses its defaults for values not specified.
Once started, the Instance Manager utilizes the same values for the duration of its run. To start an Instance Manager with different values, you must shut down the current Instance Manager, set the environment variables as desired, and start another EBU job.
Once the Instance Manager becomes idle, it waits BRD_TOT_TIME seconds for any activity by EBU before it exits. The Instance Manager does not remain connected to the backup catalog for the entire BRD_TOT_TIME. After BRD_ERR_TIME * BRD_RETRIES, the Instance Manager disconnects from the catalog.
Default value: 60*60*48
To set it to 5 minutes, for example, enter the following:
setenv BRD_TOT_TIME 300
The Instance Manager checks the backup catalog for any active jobs each BRD_SAMP_TIME seconds.
Default value: 300
To set it to 30 seconds, for example, enter the following:
setenv BRD_SAMP_TIME 30
If the Instance Manager receives an error during cleanup operations, such as media vendor error while cleaning up a job, it waits BRD_ERR_TIME seconds before continuing attempting to clean up the failed job again.
Default Value: 15*60
To set it to 180 seconds, for example, enter the following:
setenv BRD_ERR_TIME 180
The Instance Manager looks for active jobs BRD_RETRIES number of times before going to sleep for BRD_TOT_TIME seconds.
Default value: 3
To set it to 5 tries, for example, enter the following:
setenv BRD_RETRIES 5
Increasing the number of retries and decreasing the time intervals will cause the Instance Manager to use more CPU resources, but will also clean up any problems more quickly.
Conversely, decreasing the number of retries and increasing the time intervals is a preferred strategy when performing unattended backups or in case there is a need to reduce CPU use by the Instance Manager.
Note: Once the retries are exhausted, the only way brd looks at jobs is if another EBU job starts or if manually kick started, which might delay the cleanup of aborted jobs. |
The following features are available with the Enterprise Backup Utility to assist in troubleshooting:
Every EBU-related message is documented in the Enterprise Backup Utility Error and Diagnostic Manual. Messages are classified as four types:
Informational messages require no action and are only for users' information.
User errors are caused by user inputs, with syntax errors being the most common. Correct the error then retry the procedure.
Operating system errors are issued when EBU cannot continue due to errors returned from system calls. One common cause is running out of memory. Consult platform-specific manuals and contact operating system vendors if more help is needed for operating system errors.
Internal errors are generated when EBU cannot continue due to Media Management Layer errors, or Oracle errors, including RDBMS, SQL*Net, and EBU. If the message does not provide enough information to resolve the problem, further assistance can be obtained by contacting the organization indicated in the "Contact" section. For example, media management product related errors are caused or encountered by media management software, though the error is actually reported by EBU. In this case the media management vendor should be contacted for additional support. Typically, media management errors are reported by EBU as EBU-7xxx errors (i.e. error numbers in the 7000-7999 range).
Oracle Corporation recommends that you always activate logging for EBU, by supplying log="file" in command scripts. The log file contains detailed information about operations and error messages when errors occur. When an existing file is specified, EBU concatenates the new log information with it, so a history of EBU operations is maintained.
The log file is the starting point for troubleshooting. A careful read-through of the log file usually reveals where the problems are.
In addition to the user-designated EBU log file, the Instance Manager logs its operations in the EBU_HOME/log/brd.log file. When an EBU operation is interrupted, the Instance Manager takes care of recovering the utility to normal condition. Actions the Instance Manager might take include releasing memory used by EBU processes, deleting the backup file set of a failed backup, or bringing the backup catalog to a consistent state.
The brd.log file records the error recovery process of the Instance Manager, and any errors received during its operation.
Tracing can be activated by specifying trace="file" in the command script. When enabled, without specifying EBU_DEBUG in the environment, the trace file is almost identical to the log file, except for I/O statistics and extended diagnostics for some errors. Unless detailed I/O statistics are required or you are diagnosing a problem, it is not necessary to use the trace file.
In addition to normal trace information, more detailed trace information can be printed by setting the environment variable EBU_DEBUG to the desired "debug flag".
The following values could be used for EBU_DEBUG:
Several options can be set by separating them with commas or the plus sign (+):
EBU_DEBUG=CONFIGURE,BRD,SQL,LEVEL=9
The format: 0x######## can be used, under direction from an Oracle Support representative.
To debug all components at the maximum level, set EBU_DEBUG to ALL. Setting tracing to the maximum level severely affects EBU performance and generates an enormous quantity of output. Do not use EBU_DEBUG in this fashion unless instructed by an Oracle Support representative.
For example:
To debug only the CATALOG code with medium level tracing, set EBU_DEBUG as foloows:
EBU_DEBUG=CATALOG,LEVEL=6
To debug the backup catalog and all I/O at a minimum level, set the flag to:
CATALOG,IO,LEVEL=3
Some messages are printed whenever a trace file is being used, and others which are printed depending on the level. Setting EBU_DEBUG to LEVEL=15 displays all messages not associated with particular operations.
When LEVEL=n is not specified and EBU_DEBUG is set, LEVEL=15 is the default.
Note: Make sure you unset EBU_DEBUG when you are done diagnosing a problem, as this affects performance of your backups/restores, since EBU will spend a lot of time tracing dianostic messages. |
Following is a list of frequently asked questions about the Enterprise Backup Utility. These are the most commonly encountered questions from customers. The majority are installation-related:
If you are unable to resolve a problem, please make sure you have the following information at hand before contacting Oracle Worldwide Support:
Additional Information:
Detailed information on how to contact Support is given in the preface of this guide. See "Technical Support Information" |
![]() ![]() Prev Next |
![]() Copyright © 1997 Oracle Corporation. All Rights Reserved. |
![]() Library |
![]() Product |
![]() Contents |
![]() Index |