| Oracle7 Enterprise Backup Utility Administrator's Guide |  Library |
 Product |
 Contents |
 Index |
| Oracle7 Enterprise Backup Utility Administrator's Guide | Library |
Product |
Contents |
Index |
The topics covered in this chapter are:
Additional Information: See Also: "Authorizing Target Database Backups" ![[*]](jump.gif)
for more information on the backup user.
The parameter file is a convenient way to specify values for obackup 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 can have only three types of statement lines:
Table 8 - 1 describes the EBU parameters that can be set.
Parameter Name
Type
Default
Description
INTEGER
16
Number of database blocks per disk I/O. Minimum/Maximum: 8/32768
INTEGER
32
Number of database blocks per tape I/O. Minimum/Maximum: 8/32768
INTEGER
128
Size of Enterprise Backup Utility internal shared buffer area; specified in number of database blocks. Minimum/Maximum: 32/NA
INTEGER
100
Number of seconds between retries to obtain tape drive
INTEGER
100
Number of times to retry to obtain tape drive
Table 8 - 1. Enterprise Backup Utility Parameters
shared memory = BUFFER_SIZE x BLOCK_SIZE x parallel
BUFFER_SIZE must be a power of 2, and must be at least equal to the greater of DISK_IO_SIZE and TAPE_IO_SIZE. Size the buffer according to the shared memory resources you wish to allocate to it.
For example, if an online backup fails in progress, the Instance Manager notifies the Oracle7 Server of the termination of the job by issuing an ALTER TABLESPACE END BACKUP statement.
Once started (or signalled to continue), brd connects to the backup catalog database and looks for jobs that have not finished. If an abnormally terminated job is found, brd cleans it up. If active jobs are found, brd suspends itself for a user-configurable period, then checks again for unfinished jobs.
The Instance Manager performs the above cycle until the configurable number of 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 obackup instances are started before brd reaches the end of its suspension time it terminates. If brd is awakened by a new obackup 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. Even if the media management product does not confirm it has cleaned up its own catalog, brd will clean up the backup catalog after a set time.
How closely the Instance Manager monitors obackup is a tradeoff between the resources it will use and how quickly an aborted job should be cleaned up. Since the Instance Manager runs for long periods of time, you may want it to run at a lower priority. The Instance Manager nice value is configurable.
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 obackup instance spawns an Instance Manager.
Warning: Never use the kill -9 pid command to terminate EBU jobs.
At times it may be desirable to "kick-start" brd without running a new obackup instance. This can be done using the kill(1) command with the -USR1 argument. For example:
kill -USR1 pid
This reactivates a suspended brd, just as if a new obackup instance had been started.
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 obackup job.
Default value: 60*60*48
To set it to 5 minutes, for example, enter the following:
setenv BRD_TOT_TIME 300
Default value: 300
To set it to 30 seconds, for example, enter the following:
setenv BRD_SAMP_TIME 30
Default Value: 15*60
To set it to 180 seconds, for example, enter the following:
setenv BRD_ERR_TIME 180
Maximum value: 20
Default value: 10
To set it to run at normal priority, for example, enter the following:
setenv BRD_NICE_VAL 0
Default value: 3
To set it to 5 tries, for example, enter the following:
setenv BRD_RETRIES 5
If you increase the number of retries and decrease the time intervals, the Instance Manager will 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 if you are performing unattended backups or want to reduce CPU use by the Instance Manager.
Note: Once the retries are exhausted, the only way brd looks at jobs is if another obackup job starts, which delays the cleanup until that job is completed.
Informational messages require no action and are only for users' information.
User errors are caused by user inputs, 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, sbt-related errors are caused by media management software, in which case the media management vendor should be contacted for additional support.
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 $OBK_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, helping users understand when an EBU command can be executed again, following Instance Manager cleanup of the errors.
The debug flag is a four byte quantity (ub4). The four least significant bits are used to indicate debugging level. This must be set to a level other than zero (1 through f) to generate debugging output. The remaining bits are used to indicate various components of EBU to be traced. (The maximum debugging level is 9, so only 4 bits out of 32 are required.)
The debug flag lets you specify the exact components for which you want to generate trace information, and the degree of detail you want. Table 8 - 2 lists components and their corresponding debug flags.
EBU Component
Debug Flag
Level of Debugging Output
0x0000000[1-f]
Parser (brcy, brcjy)
0x00000010
Job building (brcj)
0x00000020
brcdb functions (brcdb)
0x00000040
Control trace (brc, brccmd)
0x00000080
Runtime phase (brcr, brcrs)
0x00000100
Signal handling (brcri)
0x00000200
Configure (brccfg)
0x00000400
brd (brd, brcbrd)
0x00000800
brio (brio)
0x00001000
brdk (brk)
0x00002000
brtp (brt)
0x00004000
Buffer management (brb, brbs)
0x00008000
Messaging (brsc)
0x00010000
Other brs miscellaneous functions (brs*)
0x00020000
Buffer management semaphore operations
0x00040000
UPI calls
0x00080000
Media Management Layer
0x04000000
Backup catalog (brct*)
0x80000000
Table 8 - 2. EBU Components and Debugging Flags
To debug all components at the maximum level, set OBK_DEVDBG to 0xffffffff. Setting tracing to the maximum level severely affects EBU performance and generates an enormous quantity of output. Do not use OBK_DEVDBG in this fashion unless instructed by a member of the EBU development team.
For example:
Q: 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?
A: 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.
Q: Does EBU support Oracle Parallel Server?
A: EBU supports Oracle Parallel Server. However, EBU does not take advantage of the Parallel Server environment: it does not distribute load among nodes, does not function as the "backup" process of another EBU process as the RDBMS Server processes do. EBU runs on only one node of the Parallel Server environment. In summary, EBU runs in the Parallel Server environment as if it were running in a single host system.
A: Release 2.0.12.3 has a bug for raw device support. In release 2.0.12.4, the bug is fixed.
A: This can usually be traced back to underlying network problem. Making sure EBU can communicate with the catalog database is a good way to verify the utility does not have network problem. A simple way to do this is by running the following command from the shell prompt:
sqlplus `cat $OBK_HOME/admin/catalog.obk`
A: OBK-sbt errors are passed back to EBU by the media management software. Please contact your respective Media Management Vendor for support.
Q: After obackup is killed using kill -9, the utility cannot perform any operations immediately. What is wrong?
A: This is not a problem in release 2.1. 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.
2. Start up and mount the database.
3. Issue the ALTER DATABASE BACKUP CONTROLFILE TO TRACE command.
4. Edit the trace file in the directory specified by USER_DUMP_DEST, "fixing" the names of the database files.
5. Save your changes into a new file.
6. Shut the database down normally.
7. Change the value of ORACLE_HOME so that it does not have an ending slash.
8. Execute the saved script using Server Manager or SQL*DBA. This opens the database with the new database file names.
Q: OBK-2227, "Error initializing shared memory buffer; probably out of memory," appears, even though enough shared memory is available on the system. Why?
A: The error results because the memory for the EBU buffer cannot be allocated in a single shared memory segment. Reconfigure the UNIX kernel to allow shared memory segments larger than the value of the EBU parameter BUFFER_SIZE.
Q: I can connect to the backup catalog database using SQL*Plus, but EBU is unable to connect to the catalog database. What is wrong?
A: 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:
|
Prev Next |
 Copyright © 1996 Oracle Corporation. All Rights Reserved. |
Library |
Product |
Contents |
Index |