Release 2 (9.2)
Part Number A96572-01
 Home |
 Book List |
 Contents |
 Index |
 Master Index |
 Feedback |
| Oracle9i User-Managed Backup and Recovery Guide Release 2 (9.2) Part Number A96572-01 |
|
This chapter describes the new user-managed backup and recovery features of Oracle9i Release 2 (9.2) and provides pointers to additional information. New features information from previous releases is also retained to help those users migrating to the current release.
The following sections describe the new features in user-managed backup and recovery:
This section contains these topics:
Oracle9i Release 2 (9.2) includes the following new features for backup and recovery that improve database availability and manageability.
This feature allows server processes to generate redo in parallel, thereby increasing the throughput of update-intensive workloads. When the parallel redo feature is enabled, Oracle generates redo logs in a new format. Releases prior to Oracle9i Release 2 (9.2) cannot apply redo logs in this new format. Hence, if you are attempting to apply parallel logs in a release prior to Oracle9i Release 2 (9.2), then you must temporarily upgrade to Oracle9i Release 2 (9.2), recover the database, and then downgrade to the prior release.
| See Also:
"About User-Managed Media Recovery Problems" to learn how to troubleshoot parallel redo problems, and Oracle9i Database Performance Tuning Guide and Reference to learn how to enable and disable the feature |
Oracle9i Release 1 (9.0.1) includes the following new features for backup and recovery that improve database availability and manageability.
The ALTER DATABASE END BACKUP statement takes all datafiles currently in backup mode out of backup mode. The purpose of this feature is to allow a crash recovery script to restart a database without intervention even though the failure occurred during an online backup. Previously, if the database crashed during an online backup, then each tablespace has to be taken out of backup mode individually, or media recovery had to be performed on the database.
If database media recovery encounters a problem, Oracle stops and leaves the database in a consistent state. You can then open the database read-only or with the RESTLOGS options.
The SQL*Plus RECOVER ... TEST statement can perform a trial recovery in memory without affecting the physical database. This feature enables you to test backup and recovery strategies without actually applying changes to the files on disk. Also, if you are troubleshooting media recovery problems, trial recovery lets you foresee what problems might occur if you were to continue with normal recovery.
Use the RECOVER statement with the ALLOW ... CORRUPTION clause to permit recovery to corrupt blocks during datafile media recovery. After recovery completes, you can use RMAN to perform block media recovery on the corrupted blocks. Hence, this feature can shorten recovery time and increase database availability.
You can specify multiple conversion pairs in the DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT initialization parameters.
The LOG_ARCHIVE_DEST_n initialization parameter can archive to up to 10 locations.
This section contains these topics:
Oracle8i Release 2 (8.1.6) contains a number of internal improvements that provide more robust protection against data corruption.
Logical data corruptions are typically caused by application errors and are difficult to repair because these corruptions are in the redo logs. You can prevent most logical corruptions by enabling block checking, which can detect and roll back changes that corrupt the database. Block checking is improved in these ways:
SYSTEM tablespace, regardless of the setting of the DB_BLOCK_CHECKING initialization parameter.If block checking is turned on, then the database writer process performs block checking immediately before writing a block to disk. This check enables Oracle to catch some corruptions when they are still in memory and automatically repair corrupted blocks before they are written to disk.
Typically, Oracle detects physical I/O corruptions by storing a checksum in each data block. Oracle release 8.1.6 always performs checksum calculations in the SYSTEM tablespace, regardless of the DB_BLOCK_CHECKSUM parameter setting.
If the calculated checksum does not match the stored checksum when Oracle reads the control file or redo logs, then Oracle rereads the data from either a different log or the same member in more situations than previous Oracle releases. Hence, Oracle has a second chance to find a good copy of the data and repair any physical data corruption.
The following backup and recovery features are new in release 8.1.5:
You can temporarily suspend and then resume database operations without shutting down the database. While the database is suspended, you can make online backups of split mirrors.
You can use transportable tablespaces to perform tablespace point-in-time recovery (TSPITR).
The LOG_ARCHIVE_DEST_n (where n is an integer from 1 to 5) initialization parameter can archive to up to 5 locations.
|
 Copyright © 2002 Oracle Corporation. All Rights Reserved. |
|