12.2 What's New for Oracle8? Oracle8 provides several new table types, including partitioned tables and indexes, nested tables, advanced queue tables, and index-organized tables. Another new feature in Oracle8 is the ability to define object types. Oracle8 also provides the ability to back up all the different objects that can now be created. 12.2.1 The Oracle8 Recovery Manager Within an Oracle8 environment, there is a new facility known as the Recovery Manager (RMAN). The Recovery Manager provides flexibility by allowing you to back up an entire database, individual tablespaces, or individual datafiles. The Recovery Manager starts Oracle server processes for the database to be backed up or restored and can write the backups directly to a storage device, as long as you have your media management software integrated with your Oracle software. The Recovery Manager uses a recovery catalog to store information about its tasks and enables automated restore and recovery operations in parallel, if desired. Reports can be generated of all backup and recovery actions. The Recovery Manager can be accessed either interactively or through batch mode using its command language interpreter (CLI) or through the Oracle Enterprise Manager (see Chapter 13). 12.2.2 The Recovery Catalog The recovery catalog is a repository in which is stored the information about datafile and archive log backup sets and backup pieces, datafile copies, archive redo logs and copies, tablespaces and datafiles, and stored scripts that define sequences of Recovery Manager and SQL scripts.  | The information within the catalog for archive logs should be refreshed (referred to as "resynchronization") frequently. In a situation requiring media recovery, the archive logs that have not been cataloged since the last resynchronization prior to the failure must be cataloged before any recovery can be performed. See the Oracle-supplied documentation for more information on resynchronization of archive logs. | | The Recovery Manager stores information in, and gleans information about, the database backups from their control files. If, for whatever reason, the catalog is destroyed or is otherwise unavailable, you can construct a partial catalog from the control file for a database. If you are using the Recovery Manager to perform backups, you must set the parameter CONTROL_FILE_RECORD_KEEP_TIME in the INIT.ORA parameter file. This parameter contains the number of days a backup entry in the control file should be retained before it is overwritten with new information. The DBA must ensure that the catalog has been resynchronized within that time period to avoid losing backup information. The DBA should also be aware that the control file will grow in size up to the amount of space necessary to store "x" number of days information (where x is the number of days set in the CONTROL_FILE_RECORD_KEEP_TIME parameter). The maximum size allowable for your control file is operating system-dependent. The information about the backups is stored in a Recovery Manager catalog within a database. Therefore, you must ensure that the Recovery Manager repository is also protected, and you must create a backup plan to ensure recovery of the catalog. We suggest that, if you have the resources, you use a separate database to back up the recovery catalog and use the Recovery Manager database to back up the database in which you are storing the recovery catalog backup. You do not have to maintain a recovery catalog, but Oracle recommends that one be kept. Since the backup information is kept in the control file for each database, there is an "operational mode," which can be used for small databases where a recovery catalog would be burdensome. However, this mode does not support point-in-time recovery, stored scripts, and restore and recovery when the control file is lost or damaged. If you choose to not use a recovery catalog, you should maintain more than one control file on separate disks and keep very complete records of your backup activities. 12.2.3 Backups Supported by Recovery Manager Two types of backup are supported using the Recovery Manager: a backup set and an image copy. A backup set can contain either datafiles (a datafile backup set) or archive logs (an archive log backup set). Only one type of file can be stored in a backup set, but many files of that type can be stored within each set. Often, the backup sets are written to tape. One set may not fit completely on one tape. Thus, if backup sets are going to be made and written directly to tape, several tapes will need to be made available for the backup. Backup sets can be created on disk and later stored to tape. The DBA could keep the latest copy of the database backup sets on disk and the older sets on tape. If recovery is required, files must be extracted from the backup sets through restore operations. An image copy is a copy of a single file. This copy can be used in a restore scenario or can be used directly by renaming a datafile within the database to the image copy. However, an image copy must be performed to disk, so be sure to take the amount of disk space required into consideration if you use this form of backup. Image copies can be made from archive logs, datafiles, or controlfiles, but each image copy can contain only one individual file. We recommend that you perform image copies of files to different disks (preferably on different controllers) from the location of the file you are copying. For example, if you are making an image copy of the temp tablespace datafile located on my_disk01, put the image copy on another disk like my_disk02. 12.2.3.1 Types of datafile backups There are two possible types of datafile backups provided with the Oracle8 Recovery Manager full and incremental and four allowable levels of backup storage (discussed in the next section). The difference in the backups is the number of database blocks that are saved off. In a full datafile backup, every block that has ever been changed within a datafile is backed up. Blocks that have never been changed in the datafile are not captured. (Note that this is a different form of backup from the full, file-level backups we discussed in the section "Cold Database Backups.") In a full, file-level backup, all of the blocks in the datafiles are captured not just the changed blocks. From the Recovery Manager, you can make full backups of the following files: -
Datafile -
Datafile copy -
Tablespace -
Control file -
Database -
Archived redo log files An incremental backup captures the blocks in a datafile that have changed since the last backup performed at the same or a lower level. You can perform incremental backups, which only capture the changed blocks, on the following: -
Datafile -
Tablespace -
Database | | You can also include control files in an incremental backup set, but the control files are always saved in their entirety. | | Until Oracle8, when a change occurred to a row in a table and a backup was performed, the entire table's worth of data was captured. The new incremental feature available in Oracle8 enables only the actual changed blocks of a table to be saved. The use of this facility will reduce the amount of storage space required for backups, but may take longer to restore. 12.2.3.2 Using backup levels We said that you could have up to four levels of backup storage. What does that mean exactly? With the new backup utility, you can have multi-level incremental backups. This means you can make a backup of every block that has changed in the database as a baseline starting point. This backup would be termed a level 0 incremental backup. The next backup you would perform would be a level 1 incremental backup. In this backup, only the blocks that changed since the last backup at the same or a lower level would be captured. Thus, in the level 1 backup, you would capture the blocks that had changed since the level backup was performed. You also have the option to make cumulative incremental backups at level 1 and higher. A cumulative incremental backup captures all the blocks that have changed since the last backup at the last lower level was performed. This means you would duplicate the work your incremental backups had done, but you would combine all of the " accumulated " changes into one file. The use of cumulative incremental backups makes the recovery process run more quickly. During a recovery, the Recovery Manager can restore the backup set from tape back to disk. The assumption is, of course, that there will be enough space to support the restoration of files, so it is up to the DBA to ensure that there will be enough empty disk space to accomplish this task. The Recovery Manager allows the DBA to use the different backup levels for different purposes. For example, level (full) could be performed monthly while level 1 (cumulative) could be weekly and level 2 (incremental) could be daily, and so on. Each set of weekly incremental backups would replace the other six daily backups, and each level 1 monthly would replace the four weekly backups. If the backups were being stored on disk, the disk space could be reused on a rotating basis. The DBA is free to decide what each level of backup will contain and how frequently each level is replaced . Figure 12.1 shows a typical backup cycle. Figure 12.1. Using backup levels   | 
