
Features and Architecture
This chapter describes the main features and components of the Enterprise Backup Utility, and briefly discusses the system architecture.
Topics covered in this chapter are:
Introduction
An Oracle database consists of datafiles, control files, parameter files, log files, and archived log files (when using log archiving). The Enterprise Backup Utility provides an effective mechanism to back up, restore, and recover all types of Oracle7 database files. EBU only supports Oracle7 Databases.
Enterprise Backup Utility automatically locates the tablespaces, datafiles, control file(s), and archived log files associated with the database for all backup and restore operations.
EBU maintains the configuration information on target databases in a catalog on a separate Oracle7 Server. When you are ready to perform a backup or restore, the utility retrieves the physical details about the database structure from the EBU Catalog.
Database Restore vs. Database Recovery
A database restore is an essential part of database recovery, but not synonymous with it. Database recovery allows you to reconstruct a damaged database and return it to a consistent state that it had prior to damage. Restoring is the processing of rebuilding corrupted or lost files from backup copies.
After restoring a database, you must apply other recovery steps to bring the database to a consistent point-in-time prior to the point of failure or damage.
Note: Restoring is only necessary after media failure. If you are performing instance recovery, you need not restore the database files. The Oracle7 Server reads the online redo log files and automatically performs instance recovery.:
|
Performance
Multiple datafiles or tablespaces can be backed up simultaneously to multiple devices in parallel. This fast, parallelized backup reduces the time required to perform backups.
During restores, EBU automatically uses the most recent backup available for each file, minimizing the amount of recovery that is necessary. Data can also be restored in parallel from multiple devices to facilitate speedy restoration.
Error Checking
EBU performs block header validation each time it is invoked to make a backup of a datafile. These checks are performed automatically for all tablespaces and datafiles for the database being backed up. Optionally, EBU can perform per-file checksums of a file's contents.
When performing backups, the Enterprise Backup Utility checks for any inconsistency in the configuration of the database and, if online, updates the EBU Catalog if the configuration information does not match.
Upon restore, the utility checks data block headers to ensure there are no gaps, verifies that data block numbers correspond to actual datafiles, and performs a checksum on each file (if checksumming was enabled during backup).
Report Generation and Job Administration
The Enterprise Backup Utility includes a EBU Catalog management utility, ebutool, that allows you to generate reports on information on target databases and their corresponding backup and restore operations. It also administrates EBU jobs.
Enterprise Backup Utility Architecture
Component Layers
Figure 1-1, "Component Layers in the Enterprise Backup Utility" illustrates the component layers in Enterprise Backup Utility architecture.
Figure 1-1 Component Layers in the Enterprise Backup Utility
Table 1-1 Component Layers in the Enterprise Backup Utility
Figure 1-2 Architecture of the Enterprise Backup Utility
Figure 1-2, "Architecture of the Enterprise Backup Utility" illustrates only a single database being backed up or restored onto one media device. On Unix systems, the Enterprise Backup Utility executables must be installed on a one-per-oracle software owner basis. Figure 1-3, "Single EBU Instance with Two Parallel Data Streams" illustrates a single ebu control process with two spawned I/O processes, streaming to two media devices, using the asynchronous I/O (AIO) model.
Figure 1-3 Single EBU Instance with Two Parallel Data Streams
Understanding EBU Job Steps
Steps steps common to all EBU jobs:
- Argument checking
- Syntax checking of job script
- Catalog verification
- Verifies that all the EBU catalog tables are present and its version match the version required for the code
- Instance Manager verification
- If a brd is not running a new one is started
- If a brd exists, it is notified to be active for this job
- Target Database verification
- EBU attemtps to connect to the target database
- If a register job or online backup, the connection should be possible to an open database
- If an offline backup or restore that requires it to be idle, the database is started in exclusive mode
- Configuration verification for target database
- If -noauto was used, if the configuration is out of date, the job indicates it and fails.
- This phase exists for backup and register jobs, does not exist for restore jobs
- Update configuration if needed (for register and online backup)
Register jobs:
- Only the common phases (above) are performed
Backup jobs (excluding BACKUP CATALOG):
- Common phases
- Job building phase is initiated
- All files to be backed up are listed
- Tablespaces with offline datafiles are reported as skipped
- Offline datafiles not included with INCLUDE_DBFILE are reported as skipped
- I/O phase
- I/O parameters are displayed
- Backup file sets (BFS) are scheduled and sent to media manager for backup
- Any error during the I/O phase causes the job to be stopped immediately
- If the I/O phase has failed, the BFS's currently running are cancelled
- End job target database verification
- For offline backups it checks that the database has not been opened during the backup, if an open is detected, the database objects job fails
- For online backups, the Logical Sequence Number of archivelogs are reported, and System Commit Number
- Database Object job is finished
- If this is an online job, a PARTIAL success is possible if at least one BFS was backed up succesfully.
- For offline backups, any I/O error, will cause all BFS's to be removed, no partial success is possible for offline backups
- In case of Target Database failure, BFS's with files in the same tablespace as one of the files in the cancelled BFS's are removed from the media manager, as its correctness cannot be guaranteed when the END BACKUP command was not performed correctly.
- If Archivelogs are being backed up by a implicit (ARCHIVELOG=NONE was not used) or explicit directive (ARCHIVELOG), a new job is created. This job only has two phases:
- Job building phase for archive logs
- I/O phase
- I/O parameters are displayed
- BFS's are scheduled and sent to media manager for backup
- Any error during the I/O phase causes the job to be stopped immediately
- If the I/O phase fails, the BFS's currently running are cancelled
- Job finalization
- If any I/O error was detected, all BFS's are removed from the media manager's catalog, it is not possible to have partial success for archivelog backups.
- If EBU Catalog is being backed up, either explicitly (CATALOG) or implicitly (when CATALOG=NONE is not used), an additional new job is created and has two steps:
- Catalog job building
- A sequence is assigned to the backup
- Backup of EBU Catalog to temporary file
- I/O phase
- I/O parameters are displayed
- The BFS is scheduled and sent to media manager for backup
- Any error during the I/O phase causes the job to be stopped immediately
- If the I/O phase has failed, the BFS is removed from the media manager's catalog.
If all jobs (as many as three depending on whether archived logs and the backup catalog are also backed up) are succesful, the overall job status will be succesful. If one or more Warnings were issued, the job will be succesful with Warnings. Depending on the kind of error and in what job phase, the job might continue with Warnings or stop altogether.
Backup Catalog job
Common phases up to and including Instance Manager verification are peformed, then it proceeds as described in the above sub-step for the case of catalog backup.
Restore jobs (Excluding RESTORE CATALOG)
- Common phases up to and including Target Database Verification are performed. No configuration checking is attempted.
- Job building phase is initiated
- BFS's containing the required files are obtained from the EBU catalog and they are displayed.
- After the database job building the archivelog job building phase is initiated
- A list of all possible archivelogs is constructed based on the kind of job and START_LSN, END_LSN settings
- Archivelogs already present in disk are skipped
- Archivelogs to be restored are displayed
- I/O phase
- I/O parameters are displayed
- BFS's are scheduled and sent to media manager for restore
- Any error during the I/O phase causes the job to be stopped immediately
- If the I/O phase has a failure, the BFS's currently running are cancelled and the job finishes immediatly after
- Rename phase
- Only if RENAME was specified and REMAP/REMAP_PATH was used.
- All datafiles are renamed at the Oracle7 Server level
- Recover phase
- Only if RECOVER was specified.
- If the database is idle, it is mounted exclusively
- RDBMS recovery is performed
- If recovery is succesful the database is open
- All offline tablespaces are placed online
- If the database was idle, the database is shutdown
Restore Catalog:
- Database name is verified to match parameters used
- A search for the latest EBU catalog backup is done by consulting the media manager's catalog
- If a backup of the EBU catalog is not found in the previous 7 days to the requested date (default is today). The job is stopped.
- If a previous catalog is detected in the database
- The EBU catalog is deleted
- A new empty catalog is created
- I/O phase
- The BFS containing the backup of the catalog is restored into a temporary file
- If any error is detected, the job stops
- EBU Catalog loading
- The temporary file is read and the EBU catalog objects are recreated. If any error is detected, EBU will try to drop the catalog so to signal that this is not a good catalog
- The new catalog should not be used until no errors are reported from the Catalog loading.
- EBU will leave the temporary file in its location in case a new restore attempt is needed, in this case the I/O phase will not be performed, EBU will use the temporary copy on disk.
New Features in Release 2.2
The following features are new or significantly modified in release 2.2 of the Enterprise Backup Utility.
Available with Oracle 7.3.4
GUI Interface through OEM - Backup Manager, EBU Sub-System
Consult the documentation for Enterprise Manager for additional information on the Backup Manager component.
Oracle Parallel Server Aware
- All instances need to be registered in catalog.
- Backups and Restores can be done from any node.
- Verifies all instances are down for offline backup/restore.
National Language Enabled
- Support for multibyte tablespace names.
- Messages translated into multiple national languages.
NT Availability
- EBU Release 2.2 is supported on the NT operating system platform.
- Oracle Enterprise Manager (Backup Manager) 1.3.6 GUI front end
- Legato Storage Manager (LSM) included with the Oracle7.3.4 Enterprise Server with support for up to 4 local tapes drives.
Restore Ease of Use
- Addition of REMAP_PATH for ease of re-mapping datafiles to new locations when restoring.
- User controlled renaming after re-mapping .
- Success/Failure at backup file set (BFS) level (vs. Job) for online backups.
- User controlled backup of datafiles with block header corruption.
- Automatic report of logical and physical corrupted blocks
- Patches block header to allow backup.
- Report of block patches.
- User selectable I/O model (asynchronous I/O or Shared Memory) to maximize performance and minimize overhead. (This is an operating system dependent feature, some ports might only offer one model.)
- Simplified scripting (use of environment settings)
- ORACLE_HOME (taken from the environment)
- ORACLE_SID (taken from the environment)
- DB_NAME (optional)
- New executable name: ebu
- Compatibility executable obackup which translates pre-2.2 scripts for new ebu interface.
- Automatic Registration
Archivelog Improvements
- Backup of archivelogs by default during offline backup.
- Separate job ID for archivelog backup to reduce chance of deleting the archivelogs by the user.
- Multiple archivelog files in a single BFS to improve backup performance.
- Multiple copies of archivelogs. The default is one and the maximum is four.
- A new command to restore a specific archivelog BFS.
- Command to determine what BFS contain a specific archivelog.
- New END_LSN for specifying the end range for archivelog restore.
- Detection of missing archivelogs for backup.
- Handling of offline datafiles and tablespaces.
Logging to Console and EBU log file
- Can be disabled with '-s' option.
EBU, RMAN, and Oracle8
EBU supports backing up 7.1.6 onward up to the last Oracle7 release. RMAN takes
its place with Oracle8 and beyond databases. RMAN cannot back up Oracle7 databases and
EBU cannot back up Oracle8 databases. Backups taken with one cannnot be restored
with the other (EBU and RMAN are not compatible).