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

The EBU Catalog


This chapter discusses the EBU Catalog component of the Enterprise Backup Utility.

Topics covered in this chapter are:

Information Stored in the EBU Catalog

The EBU Catalog is a set of tables stored in an Oracle7 database, separate from all target databases. It can store information on multiple target databases, making it a central repository of configuration information for an entire enterprise.


Caution:

Oracle Corporation makes the following recommendations regarding the EBU Catalog:

  • The EBU Catalog and the EBU Catalog database should be used for no purpose other than storing information for the Enterprise Backup Utility.
  • The EBU Catalog database should be on a different machine than all target databases to prevent the catalog from being affected by host failures that impact target databases.
  • You should have only one EBU Catalog per enterprise, although EBU supports having multiple EBU Catalogs.
 

Structural Information

The EBU Catalog maintains a history of the following structural information about all target databases:

Runtime Information

The EBU Catalog also stores runtime information on backup and restore jobs in progress In case of the failure of a job, the information is used to perform cleanup operations on the target database, as well as the EBU Catalog. The following runtime information is stored:

Updating Information for Target Databases

The EBU Catalog must contain information on the current physical structure of the target database(s), and therefore should be updated following any structural change to a target database. EBU does this automatically in all cases except offline backups. (See "Autoregistration".)

Types of changes which must be reflected in the EBU Catalog include:

Sizing of Catalog Database

The size of the EBU catalog is proportional to:

There is other information stored in the backup catalog, but this information will comprise by far the largest part of backup catalog space usage.

The ebutool Utility

The ebutool utility is a tool for accessing and managing information in the EBU Catalog. It allows you to query information stored in the EBU Catalog and delete "old" backup information, keeping the catalog to a manageable size.

Job Administration

Ebutool is also used to administer jobs. There are three basic operations over jobs:

Before EBU 2.2, it was required that Cancel and Invalidate were put in a script and then be submitted as a job. As of EBU 2.2, Cancel and Invalidate are incorporated into ebutool. Both commands no longer need the creation of a script and are achieved by using command line switches to ebutool.

Cancellation

Cancel is used for running jobs that for one reason or another need to be stopped, or for failed jobs that are not being properly cleaned by the Instance Manager (brd). To cancel a job, use:

ebutool -canceljob=<jobid>

Invalidation

Invalidate is used for jobs that completed correctly as far as EBU is concerned, but for some external reason should be marked as failed (for example, the tape where the backup was performed has been physically lost. Only backup jobs that finished successfully (or were partially successful) can be invalidated. Otherwise, errors are flagged during the execution of the invalidation. Once a job is invalidated, the BFS's that comprised the job are removed from the Media Manager Catalog and can no longer be used for restore operations as the job will be marked as an unsuccessful job. To invalidate a successful job, use:

ebutool -invalidatejob=<jobid>

Deletion

Deletion of a specific job is accomplished by using:

ebutool -deljobid=<jobid>

While Invalidate can only be used for successful backup jobs, job deletion can be performed for any kind of job in any final state. If the job had BFS's that finished correctly, all the BFS's are marked as removed from the Media Manager Catalog and all the EBU catalog records of the job are removed completely from the EBU catalog. Implicitly, once a backup job is removed, it is not possible to use any of its BFS's for restore operations.

Deletion of a job should be used with caution, as it is irreversible. Once the BFS's are marked as removed from the media catalog, even if the EBU catalog is restored from a previous backup (thus recreating the job records), the Media Manager might be unable to restore the BFS's that have been marked as removed.

Another way to delete jobs is through the use of:

ebutool -db_name=<db_name> ...-purgejobs=<all|# of days>

In the case of using <# of days>, all jobs before the specified number of days are deleted from the backup catalog for the specified database. The deletion is all encompassing, all kind of EBU jobs (register, backup, restore) are deleted, without regard to its outcome. In the case of successful backup jobs, the BFS's are marked as removed from the Media Manager catalog. Therefore, even if the EBU catalog is restored from a previous backup (See next sections), thus recreating the job records, the Media Manager might be unable to restore the BFS's that have been marked as removed. Both types of deletion require interactive console acknowledgement or -force as their outcome is irreversible. This is to prevent accidental deletion of jobs from the EBU catalog by an automated task gone haywire or other circumstance.

Usage

The usage for ebutool is shown below:

ebutool 
        { 
            -db_name=<database> 
 		           [-sid=<oracle sid>]
            [-host=<hostname>]
                {
                    -configuration[={all|current}]        |
                    -bfslist[={all|current}]              |
                    -tslist[={all|current}]               |
                    -filelist[={all|current}]             |
                    -whatbfs=<file (full pathname)>       |
                    -delconf={all|<# of confs to keep>}   |
                    -purgejobs={all|<days older>} 
                } 
                [-at='MM/DD/YYYY HH24:MI:SS'] 
        |   -dblist 
        |   -job={all|<jobid>} 
        |   -migrate 
        |   -cretrgtusr 
        |   -canceljob=<jobid>
        |   -invalidatejob=<jobid>
        |   -deljobid=<jobid>  
        |   -catalog={all|<# of days back>}
        |   -fixfilelist
        |   -stopbrd
        |   -wakebrd
        |   -help 
        } 
        [{-ofile=<output file>}|<output file>]


Note:

Do not insert spaces between command switches and the corresponding specifiers. The syntax is shown with newlines for clarity only.

 

Keywords

Table 7-1 Keywords Used in the ebutool Utility
Keyword   Description  

-db_name

 

Specifies the target database name. Case sensitive; do not use quotation marks.

 

-sid

 

Specifies the oracle sid for the database in case there are multiple databases with the same name.

 

-host

 

Specifies the host name for the database in case there are multiple databases with the same name and oracle_sid.

 

-configuration

 

Obtains a list of the current registered configuration. Also returns a list of files for which a backup job is not found. Current configuration is the default; all configurations can be specified using -configuration=all.

 

-bfslist

 

Returns the current configuration and a list of all backup jobs performed on the configuration. For each job, details of the job and Backup File Sets (BFS) are reported. Current configuration is default; all configurations can be obtained using -bfslist=all.

 

-tslist

 

Returns current configuration and a list of tablespaces. For each tablespace completely backed up by a job, the job number is displayed. If no backup job has completely backed up a tablespace, a "No Backup Jobs Found" message is reported instead. Current configuration is the default mode; all configurations can be obtained using -tslist=all.

 

-filelist

 

Returns the current configuration and a list of each file. For each file, the BFS and backup job number are displayed. If no backup is found for a particular file, returns the message "No Backup Jobs Found."

 

-whatbfs

 

Returns the names of the BFS's that contain the specified file for the given database. This is expecially useful in conjunction with the restore bfs command to retrieve a specific copy of an archivelog file.

 

-delconf

 

Deletes "old" configurations from the EBU catalog. When a configuration is deleted, all information about it and the backup jobs performed is removed. When the jobs are deleted, the media manager removes the BFS's from the media. Once a configuration is deleted, no restore to points-in-time covered by the configuration is possible. Cannot be used with -at.

 

-purgejobs

 

Deletes jobs for the specified target database. When jobs are deleted, the media manager removes the BFSs from the media. All jobs for the specified database can be purged, or just those more than x days old.

 

-at

 

'MM/DD/YYYY HH24:MI:SS' gives configuration information for the specified time. When used with -configuration=all, returns all configurations starting with the specified time. Can also be used with any of the "list" command options (-bfslist, -tslist and -filelist).

 

-dblist

 

Returns current configuration for all target databases. Useful for determining the contents of the EBU Catalog prior to generating more detailed reports.

 

-job

-job=all

 

Returns a listing for the jobID number specified. Job details and the BFS's comprising the job are listed. -joball will list all jobs in the catalog for all target databases.

 

-migrate

 

Migrates information stored in one release of an EBU Catalog (such as an EBU 2.0 or 2.1 catalog) to another EBU Catalog (such as an EBU 2.2 Catalog). See "All EBU Installations are Upgraded Together", and "Target Databases are Upgraded at Different Times" for details on migrating from an earlier EBU release.

 

-cretrgtusr

 

Creates the EBU backup user in the target database. See "Authorizing Target Database Backups" for details on this user.

 

-canceljob=jobID

 

Replaces the cancel command of 2.1, cancel is no longer a valid command for ebu, ebutool needs to be used with this option to cancel a running job or force the invalidation of a failed job that brd has not been able to clean up. Cancels an active job and cleans up its resources, based on the jobID number. To find the jobID for a job you want to cancel, look at the log file or query the table OBK_RT_JOB_BR.

 

-deljobid=jobID

 

Deletes a specific job, based on the jobID number.

 

-invalidatejob=jobID

 

Invalidates a backup in both the EBU and media management catalogs. Typically used when a backup has become unavailable, e.g. a lost tape. Must be run from the host that created the backup.

 

-catalog

 

Used to obtain a report of catalog backups recorded in the EBU catalog.

 

-help

 

Returns a screen with ebutool utility syntax.

 

-ofile=output_file

 

Specifies the name of the output file. The output file is formatted at 66 lines per page. If no output file is specified, the output of ebutool goes to standard error.

 

-wakebrd

 

Ensures that the brd process is running.

 

-stopbrd

 

Shuts down the brd process.

 

-fixfilenames

 

Allows EBU to rename datafiles and logfiles in a canonical format appropriate for your operating system environment, so as to avoid problems with filenames that are non-standard, e.g. using '/' as a path separator or mixed case on NT, or using '//' on UNIX. It does not relocate your database files, it merely normalizes the format of the filenames appropriate for EBU's file name translation functions. If filenames are not normalized to remove constructs like the aforementioned, then the recover and rename operations will fail. In order to normalize filenames, EBU must shutdown the database, if it is open. After this one-time procedure (per-target), the instance will be restored to its prior state. This procedure may be required again if datafiles are added whose names are not normalized to standard pathnames.

 

Backing Up and Restoring the EBU Catalog

EBU 2.1 and 2.2 automate the backup and restore of the EBU Catalog.

Catalog Backup

Each backup operation - database or subset, online or offline - backs up the EBU catalog. The catalog backup file is written to the media device, after the BFS's from the target database backup. In the EBU catalog database, only the contents of catalog tables are backed up: no physical files are backed up.

Catalog backup is the default, but it can be disabled by the catalog=none specifier in the backup command script. The EBU catalog can also be backed up alone by using the backup catalog command.

Additional Information:

See Figure A-1, "Backup SyntaxBackup Arguments Syntax" for command syntax.

 

EBU tags successful catalog backups with sequence numbers which can be used for identifying the backup more quickly. The sequence number is incremented for each catalog backup per day. The sequence for each day resets to zero, and has an upper limit of 1000. The sequence number is recorded in the log file of the backup job.

If the catalog backup should fail, the backup of the target database is still marked as successful, but the backup job completes with a warning that the catalog backup failed.

No other backup or restore operations can be run when a catalog backup or restore is taking place.

Catalog Restore

In the case of the loss of the backup catalog, the backups of the backup catalog can be used to restore it. For the catalog restore operation, it is not necessary to have a catalog. EBU automatically figures out which is the latest backup of the EBU catalog performed in the last seven days from the current date and uses it to restore the EBU catalog.

The EBU catalog can be restored using the restore catalog command. By default, restore catalog restores the most current EBU catalog backup and overwrites the existing EBU catalog in the catalog database.

When restore catalog is used in a command script, EBU connects to the database specified in the EBU_HOME/admin/catalog.ebu file and checks the DB_NAME of the database against the db_name you specified in the command script. If the two names are not identical, EBU aborts. This means that if you are restoring the catalog to a different database, you must first update the catalog.ebu file.

EBU allows the catalog to be restored to a different database by using the AS specifier in the restore catalog script.

If the database names match, or the as= specifier matches the name of the database to which EBU has connected, EBU looks for a backup catalog schema. If one is found, it is dropped and a new empty one is created, thus losing all previous information in the backup catalog. After (re)creating the backup catalog, the BFS containing the backup catalog is restored from the media into a file. This file is placed by default in the EBU_HOME/admin directory, but can be directed to a different directory by using the tempdir specifier of the restore command.

Once the file with the backup of the catalog is on disk, EBU proceeds to read the information contained in the file and starts recreating the backup catalog. The time spent in recreating the EBU catalog will be directly proportional to the amount of information that needs to be recreated. The catalog database should have enough space so that all the schema can be recreated. Any errors during the loading phase will leave an incomplete EBU catalog that should not be used until the restore completes successfully.

Sometimes, it might be desirable to restore a backup of the EBU catalog which is not the latest. Due to the loss of the EBU catalog, this operation cannot be performed as it is done for the database objects where a to= specifier is used to indicate the precise point-in-time to which to restore. Instead, the date of the backup and a sequence number during that day should be used to indicate what backup of the EBU catalog to use. ebutool -catalog can be used (before the loss of the EBU catalog) to obtain the available dates/sequence of the backups, that later on can be used to perform this poing-in-time restore.

When the catalog is restored to a point in time, all jobs executed after that point in time will be lost, and restore from those jobs will not be possible. Furthermore the catalog of the Media Manager will be out of sync with the EBU catalog, unless a copy of the Media Manager's backup catalog at the same point in time has been restored simultaneously.

Note that even if previously deleted jobs are recreated by the restore to a point in time of the catalog, unless vendor-specific measures had been taken to update the Media Manager catalog, restore from these deleted jobs might not be possible, as the BFS's would have been marked as deleted in the Media Manage's Catalog as well.

Additional Information:

For command syntax, see "Restore Catalog".

 

Creating or Upgrading the EBU Catalog

EBU release 2.2 requires release 2.2 of the EBU Catalog. There are three possible scenarios for creating or upgrading the catalog:

Additional Information:

Each of these scenarios is discussed in detail in "Setting Up the EBU Catalog".

 




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