If another database is to have the catalog, the connect catalog string will have the database as part of the string: rman/rmanpswdRMANCAT RMAN> connect catalog rman/rmanpswd connected to recovery catalog database RMAN> create catalog recovery catalog created RMAN> register database; database registered in recovery catalog starting full resync of recovery catalog full resync complete RMAN> After the catalog is created, the databases can be registered with the catalog. The target database that is connected is the one that is registered with the catalog. Now the target database is ready for backups. You can configure RMAN for the default backup type, where the backup files should be written, the format of the backup file, retention policies, compression, encryption, and control file autobackup. The tape drivers and encryption options are part of the Oracle Secure Backup product. Other vendors provide drivers to write directly to tape and encryption, and Secure Backup will also integrate directly with RMAN. Looking at the configuration for RMAN is just like looking at the parameters in the Oracle database, but from the RMAN command line. RMAN> show default device type; RMAN configuration parameters for database with db_unique_name MMDEV1 are: CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default ## Change the default device from disk to tape RMAN> configure default device type to sbt; new RMAN configuration parameters: CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE'; new RMAN configuration parameters are successfully stored These configuration settings can be part of a script. If they are set in a script, the script settings will overwrite any defaults that are set up for that database in RMAN. 132 Oracle Database Administration for Microsoft SQL Server DBAs Here are some examples of setting the defaults for the backup directory, file format, type of backup, and retention policy: example to configure channel to write to disk using the diskgroup format RMAN> configure channel device type disk format '+dgroupbkup1'; examples of two different backup types RMAN> configure device type disk backup type to backupset; RMAN> configure device type disk backup type to compressed backupset; example to configure retention policy RMAN> configure retention policy to recovery window of 7 days; RMAN> ## use recovery window or redundancy (but not both) RMAN> ## configure retention policy to redundancy 3; In the example, the disk format is configured to be used with ASM and a disk group that has been set up as a backup disk group. For a regular file system, the format can also be set as /orabkup/ora_d%_%T.bak, which will define the backup with the name of the database and a date in the file system directory. The example uses the backupset backup type. Another type is copy, which will do an image copy of the database. The copy backup type is allowed only for writing the copy to disk; it does not work for tape backups. When allocating a channel as type disk in a script, these parameters become part of that allocation. Unless you want to overwrite the defaults, they do not need to be mentioned each time a backup is run. For the retention policy, the setting of the recovery window sets the number of days between the current time and the earliest point of recovery, which doesn’t matter if there are incremental or full backups in between. But those backups will be marked obsolete when they hit the number of days set here. This example sets the window to seven days, which makes sure that the database can be recovered within the past week. The retention policy’s redundancy setting indicates the specific number of full backups to be kept. The example sets redundancy to 3, which will keep three full backups; it doesn’t matter how many days are in between backups. The same configurations that were demonstrated here in the command line can be done through OEM’s Backup Settings. Figure 6-1 shows the Chapter 6: Database Backup, Restore, and Recovery 133 Device tab, where you set the backup location and type. Figure 6-2 shows the Policy tab, where you set the retention policies. As you can see in Figure 6-2, you can set up the retention policies by date or number of backups to be retained. The Policy tab also includes an area to exclude tablespaces from whole backups, which is useful for tablespaces that might be in read-only mode or archived tablespaces that might not need to be included in every full backup. 134 Oracle Database Administration for Microsoft SQL Server DBAs FIGURE 6-1. OEM Backup Settings, Device tab Backup Options Table 6-1 shows some common backup types and how to run them in SQL Server and RMAN. Your backup strategy should include full and incremental backups. It should also make sure all of the needed pieces are backed up properly. For incremental backups, a base backup (full backup) is needed first. The cumulative database backup option in RMAN backs up all of the changes since the base, or level 0, backup. The incremental backup backs up the differences between the incremental backups. The advantage of having a cumulative backup is that only the last cumulative backup would need to be restored to recover the database. With incremental backups, all of them need to be available to restore. Of course, an incremental backup will use less disk or tape, and it usually takes less time to run. Chapter 6: Database Backup, Restore, and Recovery 135 FIGURE 6-2. OEM Backup Settings, Policy tab In SQL Server, the system databases, as well as master, msdb, and model, need to be backed up. Similarly, in Oracle, the control files, system datafiles, and parameter files for the Oracle database need to be backed up. In SQL Server, the tempdb database is not part of backups; in Oracle, the temporary tablespace is not included. The undo tablespace does contain uncommitted changes, but with the newer versions of RMAN, only the uncommitted changes that haven’t been written out to the datafiles are backed up. Full backups will include all of the datafiles in the Oracle database, including system datafiles, but not the control files. As discussed in Chapter 3, the control files have information about the changes and archive logs needed for recovery. Without a current control file, the recovery up to the latest point could be difficult. You may run backups of the control files outside 136 Oracle Database Administration for Microsoft SQL Server DBAs Backup Type SQL Server Command Oracle (RMAN) Command FULL backup database backup database Files or file groups backup database db1 filegroup ='db1file1' to disk… backup as backupset datafile '/u01/data/ users01.dbf'; Tablespaces backup tablespace system, users; Logs (transaction and archive) backup log db1 to disk … backup archivelog all; Incremental backups/base backup Backup database db1 to disk='S:\bkups\ db1.bak' with init Backup incremental level 0 database; Incremental backups/ differential backups Backup database db1 to disk='S:\bkups\ db1.bak' with differential Backup incremental level 1 cumulative database; Backup incremental level 1 database; TABLE 6-1. Backup Options in SQL Server and Oracle the full backup, or after backups of the full or transaction logs, you can include the control files to make sure the information is captured. Backups of parameter files might not be as important, but you need to have a copy in case changes must be reverted. Backup Examples Allocating more channels is like using multiple devices and writing in parallel. For example, if you have a couple of tape drives available, this would allow you to take full advantage of the multiple drives and speed up the backup. > rman target rman/rmanpwdrmancat RMAN> run { RMAN> allocate channel disk1 device type disk; RMAN> allocate channel disk2 device type disk; RMAN> backup database plus archivelog; RMAN> backup current controlfile; RMAN> } Just as you would run transaction log backups multiple times a day with SQL Server, with Oracle, the archive logs need to be backed up more than once a day. The number of transactions and size of disk space available to hold the logs will determine how often. > rman target rman/rmanpwdrmancat RMAN> run { RMAN> allocate channel disk1 device type disk; RMAN> allocate channel disk2 device type disk; RMAN> backup archivelog all delete all input; RMAN> } Running archive log backups helps you to avoid filling up the space allocated to the logs. The preceding example will back up any archive logs and then delete them from this space, because they are now included in a backup set. This will keep the file system to a manageable size for archiving. OEM Backup Jobs With OEM, you can configure backups and schedule them as jobs in the database. OEM will generate the RMAN script and display it for your review. This provides a good way to gain a better understanding of the backup options and RMAN commands. Chapter 6: Database Backup, Restore, and Recovery 137 Figure 6-3 shows the options for customizing a backup job in OEM. If the database is running in NOARCHIVELOG mode, only the full cold backup is available (as well as any files that might be in the flash/fast recovery area, as discussed later in this chapter). If it’s in ARCHIVELOG 138 Oracle Database Administration for Microsoft SQL Server DBAs When You Run Out of Archive Space If the archive log space fills up, the database will just hang, with the error “archiver error connect internal until freed.” Knowing the command- line RMAN commands is important in this situation. Chances are that the connection through OEM will not be available because of the limited connections allowed to the database as it is waiting for archive log backup space to be freed up. Moving archive logs to another location will free up space to allow the archive process to continue to run until the files can be backed up and purged. However, after archive logs are moved or deleted, RMAN may fail to run the backup because expected files are not there. So, before you run the backup, you should perform a cross-check to verify which files are available and what has been backed up. The cross- check will also resynchronize the catalog with the files that are present in the backup directory or tape. It will expire the backups in the catalog that are no longer available. ## validate archive logs are available RMAN> crosscheck archivelog all; ## validate database backupsets available RMAN> crosscheck database; So, you’ve moved archive logs to another location to free up the space, completed the cross-check, and then run the backup. But there are still logs in another location that have not been backed up. If there is now space in the archive log directory, you can move those files back, perform a cross-check, back them up, and then delete them. If the archive files are just deleted without being backed up, recovery will not be possible. All of this bouncing around of the archive files is to prevent the database from being put into a hung state, waiting to be able to archive logs again. A better approach is to plan the available space and make sure that the archive logs are backed up to prevent filling up the space. mode, there are more options, including those to back up tablespaces, datafiles, archive logs, and recovery files. Next, you set up the schedule for the backup, as shown in Figure 6-4. As typical for other database jobs, you can run the backup as a one-time job immediately or later, or make it a repeating job. The final step, shown in Figure 6-5, shows the RMAN script and provides an opportunity to edit the script, or even copy it to modify and run outside the scheduler. Submit the job to save and schedule the backup, or run the backup if it’s a one-time job. You can also use OEM to create a restore point, which is useful when you’re performing a task against the database for data changes, application upgrades, or even database upgrades. The restore point marks a time to recover to if the upgrade goes awry. Although you could also get the information from the logs and database about the last change or current archive log sequence, having a defined point to roll back to makes the Chapter 6: Database Backup, Restore, and Recovery 139 FIGURE 6-3. Customizing a backup job in OEM 140 Oracle Database Administration for Microsoft SQL Server DBAs FIGURE 6-4. Scheduling a backup job in OEM FIGURE 6-5. Reviewing the RMAN script in OEM restore process easier. Figure 6-6 shows an example of setting the restore point in OEM. Restoring and Recovering Databases What good are backups if you can’t use them to restore the database? Oracle provides several ways to restore all or parts of a database. But before we look at the various restore methods, let’s consider why you might need to use them. We’ll examine some of the failures and consider ways to recover the database. I say “recover,” rather than “restore,” because in recovery, the system needs to go back to where it was, and this might not mean restoring the entire database. What Can Go Wrong? Understanding the different ways a database can fail and reasons for a restore can help in planning a backup strategy. So, what can go wrong? ■ Hardware failures/firmware issues ■ User error Chapter 6: Database Backup, Restore, and Recovery 141 FIGURE 6-6. Creating a restore point in OEM . outside 136 Oracle Database Administration for Microsoft SQL Server DBAs Backup Type SQL Server Command Oracle (RMAN) Command FULL backup database backup database Files or file groups backup database. useful for tablespaces that might be in read-only mode or archived tablespaces that might not need to be included in every full backup. 134 Oracle Database Administration for Microsoft SQL Server DBAs FIGURE. Similarly, in Oracle, the control files, system datafiles, and parameter files for the Oracle database need to be backed up. In SQL Server, the tempdb database is not part of backups; in Oracle, the temporary