Oracle7 Enterprise Backup Utility Administrator's Guide Go to Product Documentation Library
Library
Go to books for this product
Product
Go to Contents for this book
Contents
Go to Index
Index



Go to previous file in sequence Go to next file in sequence

Managing and Troubleshooting


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:

Enterprise Backup Utility Privileges

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)

Database Security

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 EBU Parameter File

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.

Table 8-1 Enterprise Backup Utility Parameters
Parameter Name   Type   Default   Description  

DISK_IO_SIZE

 

INTEGER

 

16

 

Number of database blocks per disk I/O.

Minimum/Maximum: 8/32768

 

TAPE_IO_SIZE

 

INTEGER

 

32

 

Number of database blocks per tape I/O. (Must be a power of 2)

Minimum/Maximum: 8/32768

 

BUFFER_SIZE

 

INTEGER

 

128

 

Size of Enterprise Backup Utility internal shared buffer area; specified in number of database blocks. (Must be a power of 2)

Minimum/Maximum: 32/NA

 

TAPERETRY_PERIOD

 

INTEGER

 

30

 

Number of seconds between retries to obtain tape drive

 

TAPERETRY_COUNT

 

INTEGER

 

100

 

Number of times to retry to obtain tape drive

 

The EBU Instance Manager

Each Enterprise Backup Utility instance is monitored by an Instance Manager.

Invoking the 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).

Instance Manager Functions

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.

Instance Manager Operation

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.

Stopping and Restarting the 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.


warning:

Never abnormally terminate the brd processes.

 

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.

Instance Manager Environment Variables

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.

BRD_TOT_TIME

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

BRD_SAMP_TIME

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 

BRD_ERR_TIME

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 

BRD_RETRIES

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.

 

Troubleshooting for EBU

The following features are available with the Enterprise Backup Utility to assist in troubleshooting:

Enterprise Backup Utility Error and Diagnostic Manual

Every EBU-related message is documented in the Enterprise Backup Utility Error and Diagnostic Manual. Messages are classified as four types:

Informational Messages

Informational messages require no action and are only for users' information.

User Errors

User errors are caused by user inputs, with syntax errors being the most common. Correct the error then retry the procedure.

Operating System Errors

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

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).

EBU Log File

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.

Instance Manager Log

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.

EBU Trace File

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.

Low Level Debugging

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.

 

Frequently Asked Questions (FAQ)

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:

Table 8-2 Frequently Asked Questions About the Enterprise Backup Utility
Question   Answer  

EBU is installed on the same host as the catalog database, the target database is installed on a different host, and EBU failed to back up the target database when run from catalog database host. What is wrong?

 

EBU must run on the same host as the target database. EBU does not support remote backup and restore of the target databases. EBU does, however, support media management software capability to back up to remote devices.

 

Does EBU support Oracle Parallel Server?

 

As of EBU 2.2, operations on a Parallel Server configuration can be performed on any of the registered nodes for a database.

EBU supports Oracle Parallel Server. However, EBU does not take advantage of the Parallel Server environment: it does not distribute load among nodes.

Because Parallel Server architecture partitions archive logs for different nodes, EBU must access these archived log files through NFS mounted file systems. Installation-wise, NFS mounting of all archive directories with READ/WRITE permission is the only extra step you must perform when installing EBU on an Oracle Parallel Server system.

When using EBU in a Parallel Server system, you must include all archivelog directories in your backup/restore scripts explicitly.

EBU operations on a cluster must always be performed from the same node, as backups taken from different nodes cannot be aggregated into a single restore job.

 

What is the difference between EBU 2.0.12.3 and 2.0.12.4?

 

Release 2.0.12.3 has a bug for raw device support. In release 2.0.12.4, the bug is fixed.

Release 2.0.12.3 is bundled with Oracle7 on some platforms in release 7.3.2. Release 2.0.12.4 was provided as both standalone product, and as a patch for 2.0.12.3 bundled with Oracle7 release 7.3.2.2.

2.0.12.3 is only available on Sun SPARC Solaris, and should not be used.

 

EBU returns error code 5602. What is wrong?

 

This can usually be traced back to underlying network problem. Making sure that the target username/passworrd@connect string can communicate with the target database is a good way to verify if there is a network problem. Otherwise, fix the network problem and retry the connection.

If you are trying to connect with user/password@connect_string syntax, try to connect as just user/password or as INTERNAL.

 

EBU returns EBU-7xxx errors. Who should I contact to get them resolved?

 

EBU-7xxx errors are passed back to EBU by the media management software. Please contact your respective Media Management Vendor for support.

 

(Unix) After ebu is killed using kill -9, the utility cannot perform any operations immediately. What is wrong?

 

Users should never terminate ebu by kill -9. Use the ebutool canceljob=<jobid> command, instead. The kill command abruptly interrupts EBU operations, forcing it to take a relatively long time to recover. In the interim, attempts to run ebu fail due to the recovery in progress. If you examine the log file, there are probably entries with "Failed job xx with SYSTEM tablespace locked", or "Inconsistent internal state". These messages are usually the result of kill -9.

Recovery from a kill -9 command is relatively simple: just wait. Make sure the brd process is running. If it is not running, start a normal ebu job, even if it fails. Monitor the EBU_HOME/log/brd.log file until "Finished cleaning job xx" appears, before continuing any EBU operations.

 

Why is EBU unable to find files, even though they are present in the database?

 

This is not a problem in release 2.1 (except with the recover operation). In release 2.0 it is caused most likely by the ORACLE_HOME environment variable in the target database having a slash '/' at the end. For example, instead of /u01/orahome, ORACLE_HOME is set to /u01/orahome/. This causes all datafile names to have a '//' in their full pathnames. Since EBU strips the extra '/' from the user's input, it does not recognize the files being equal.

The workaround is to run ebutool -fixfilenames (EBU 2.2). This command performs the following steps:

  1. Shuts the database down immediately (if open).
  2. Starts up and mount the database (if not already mounted).
  3. Issues ALTER DATABASE RENAME FILE '...' to '...' statements to the database.
  4. Brings up the database (if it was open before step 1)..

 

I can connect to the backup catalog database using SQL*Plus, but EBU is unable to connect to the catalog database. What is wrong?

 

EBU does not assume that the TNS_ADMIN environment variable is set to the catalog database. As a result, EBU must be able to locate a tnsnames.ora file in the target database environment that identifies the catalog database. The tnsnames.ora file can be in one of the following places:

  • ORACLE_HOME/network/admin/
  • in the user's home directory as a dot file (.tnsnames.ora)

Other possible solutions include:

You are trying to connect as the root user (particularly if you are trying to register a database using the media management vendor interface).

  • You may be using SQL*Net with Secure Network Services (SNS), but not have relinked EBU with SNS. Check the cli.trc files for trace information on encryption and secure services. If necessary, relink EBU with SNS and retry the connection.

 

Contacting Worldwide Support

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"

 




Go to previous file in sequence Go to next file in sequence
Prev Next
Oracle
Copyright © 1997 Oracle Corporation.
All Rights Reserved.
Go to Product Documentation Library
Library
Go to books for this product
Product
Go to Contents for this book
Contents
Go to Index
Index