RMAN

  • Configuring RMAN’s Backup Retention Policy

    RMAN retention policies allow you to specify how long you want to retain backups. RMAN has two mutually exclusive methods of specifying a retention policy:

    • Recovery window
    • Number of backups (redundancy)

    With a recovery window, you specify a number of days in the past for which you want to be able recover to any point in that window. For example, if you specify a retention policy window of 5 days, then RMAN doesn’t mark as obsolete backups of data files and archive redo logs that are required to be able to restore to any point in that 5-day window:

    RMAN> configure retention  policy to recovery window of 5 days;

    For the specified recovery, RMAN may need backups older than the 5-day window because it may need an older backup to start with to be able to recover to the recovery point specified. For example, suppose your last good backup was made 6 days ago, and now you want to recover to 4 days in the past. For this recovery window, RMAN needs the backup from 6 days ago to restore and recover to the point specified.

    You can also specify that RMAN keep a minimum number of backups. For instance, if redundancy is set to 2, then RMAN doesn’t mark as obsolete the latest two backups of data files and archive redo log files:

    RMAN> configure retention policy to redundancy 2;

    I find that a retention policy based on redundancy is easier to work with and more predictable with regard to how long backups are retained. If I set redundancy to 2, I know that RMAN won’t mark as obsolete the latest two backups. In contrast, the recovery window retention policy depends on the frequency of the backups and the window length to determine whether a backup is obsolete.

    You can report on backups that RMAN has determined to be obsolete per the retention policy, as follows:

    RMAN> report obsolete;

    To delete obsolete backups, run the DELETE OBSOLETE command:

    RMAN> delete obsolete;

    You’re prompted with this:

    Do you really want to delete the above objects (enter YES or NO)?

    If you’re scripting the procedure, you can specify the delete not to prompt for input:

    RMAN> delete noprompt obsolete;

    I usually have the DELETE NOPROMPT OBSOLETE command coded into the shell script that backs up the database. This instructs RMAN to delete any obsolete backups and obsolete archive redo logs, as specified by the retention policy (see the section “Segueing from Decisions to Action,” later in this chapter, for an example of how to automate the deleting of obsolete backups with a shell script).

    The default retention policy is redundancy of 1. You can completely disable the RMAN retention policy via the TO NONE command.

    RMAN> configure retention policy to none;

    When the policy is set to NONE, no backups are ever considered obsolete and therefore cannot be removed via the DELETE OBSOLETE command. This normally is not the behavior you want. You want to let RMAN delete backups per a retention policy based on a window or number of backups.

    To set the retention policy back to the default, use the CLEAR command:

    RMAN> configure retention policy clear;
  • Configuring the RMAN Backup Location

    When you run a BACKUP command for disk-based backups, RMAN creates backup pieces in one of the following locations:

    • Default location
    • FRA
    • Location specified via the BACKUP...FORMAT command
    • Location specified via the CONFIGURE CHANNEL...FORMAT command

    Of these choices, I lean toward the last of them; I prefer specifying a target location via a backup channel.

  • Oracle Database 12C Backup: understanding RMAN

    RMAN is Oracle’s flagship B&R tool. RMAN is provided by default when you install the Oracle software (for both the Oracle Database 12C  Standard Edition and Enterprise Edition). RMAN offers a robust and flexible set of B&R features. The following list highlights some of the most salient qualities:

  • Restore Oracle Database 12c from an RMAN Backup

    How to recovery Oracle 12 from Rman backupWhen you think about architecting your backup strategy, as part of the process you must also consider how you’re going to restore and recover Oracle Database 12c. Your backups are only as good as the last time you tested a restore and recovery. A backup can be rendered worthless without a good restore and recovery strategy. The last thing you want to happen is to experience a media failure, go to restore your database, and then find out you’re missing a file, you don’t have enough space to restore, something is corrupt, and so on.

  • RMAN Recipes for Oracle Database 12c


    Book RMAN Recipes for Oracle Database 12cAuthor: Darl Kuhn, Sam Alapati, Arup Nanda
    Publisher: Apress

    Year:July 16, 2013
    Pages: 796
    Language: english
    Format: PDF
    ISBN: 143024836X

  • RMAN Recipes for Oracle Database 12c: A Problem-Solution Approach


    Книга RMAN Recipes for Oracle Database 12cАвтор: Darl Kuhn, Sam Alapati, Arup Nanda
    Издательство: Apress

    Год:July 16, 2013
    Страниц: 796
    Язык: английский
    Формат:
    ISBN: 143024836X

  • RMAN: Backing Up Archive Redo Logs

    You should back up your archive redo logs in your Oracle Databace on a regular basis. The archivelog files shouldn’t be removed from disk until you’ve backed them up at least once. I usually like to keep on disk any archive redo logs that have been generated since the last good RMAN backup.

  • RMAN: Configuring the Archive Redo Logs’ Deletion Policy

    In most scenarios, I have RMAN delete the archive redo logs based on the retention policy of the database backups. This is the default behavior. You can view the database retention policy, using the SHOW command:

    RMAN> show retention policy;

    CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default

    To remove archive redo logs (and backup pieces) based on the database retention policy, run the following:

    RMAN> delete obsolete;

    As of Oracle 11g, you can specify an archive redo log deletion policy that is separate from that of the database backups. This deletion policy applies to archive redo logs both outside and in the FRA.

    Image Note  Prior to Oracle 11g the archive deletion policy only applied to archive redo logs associated with a standby database.

    To configure an archive redo log deletion policy, use the CONFIGURE ARCHIVELOG DELETION command. The following command configures the archive redo deletion policy so that archive redo logs aren’t deleted until they have been backed up twice to disk:

    RMAN> configure archivelog deletion policy to backed up 2 times to device type disk;

    To have RMAN delete obsolete archive redo logs, as defined by the archivelog deletion policy, issue the following command:

    RMAN> delete archivelog all;

    Image Tip  Run the CROSSCHECK command before running the DELETE command. Doing so ensures that RMAN is aware of whether a file is on disk.

    To see whether a retention policy has been set specifically for the archive redo log files, use this command:

    RMAN> show archivelog deletion policy;

    To clear the archive deletion policy, do this:

    RMAN> configure archivelog deletion policy clear;
  • RMAN: Determining the Location for the Snapshot Control File

    RMAN requires a read-consistent view of the control file for the following tasks:

    • Synchronizing with the recovery catalog
    • Backing up the current control file

    RMAN creates a snapshot copy of the current control file that it uses as a read-consistent copy while it’s performing these tasks. This ensures that RMAN is working from a copy of the control file that isn’t being modified.

    The default location of the snapshot control file is OS specific. On Linux platforms the default location/format is ORACLE_HOME/dbs/snapcf_@.f. Note that the default location isn’t in the FRA (even if you’ve implemented an FRA).

    You can display the current snapshot control file details, using the SHOW command:

    RMAN> show snapshot controlfile name;

    Here is some sample output:

    CONFIGURE SNAPSHOT CONTROLFILE NAME TO

     '/ora01/app/oracle/product/12.1.0.1/db_1/dbs/snapcf_o12c.f'; # default

    For most situations the default location and format of the snapshot control file are sufficient. This file doesn’t use much space or have any intensive I/O requirements. I recommend that you use the default setting.

    If you have a good reason to configure the snapshot control file to a nondefault location, you can do so as follows:

    RMAN> configure snapshot controlfile name to '/u01/O12C/rman/snapcf.ctl';

    If you accidentally configure the snapshot control file location to a nonexistent directory, then when running a BACKUP or COPY command, the autobackup of the control file will fail, with this error:

    ORA-01580: error creating control backup file...

    You can set the snapshot control file back to the default, like this:

    RMAN> configure snapshot controlfile name clear;
  • RMAN: Location of the Autobackup for Control File

    When you enable autobackup of the control file, RMAN creates the backup of the control file in one of the following locations:

    • Default location
    • FRA
    • Location specified via the CONFIGURE CONTROLFILE AUTOBACKUP FORMAT command
  • RMAN: Setting the Autobackup of the Control File

    You should always configure RMAN to back up the control file automatically after running any RMAN BACKUP or COPY command or after you make physical changes to the database that result in updates to the control file (such as adding/removing a data file). Use the SHOW command to display the current setting of the control file autobackup:

  • RMAN: Setting the CONTROL_FILE_RECORD_KEEP_TIME Initialization Parameter

    The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter specifies the minimum number of days a reusable record in the control file is retained before the record can be overwritten. The RMAN metadata are stored in the reusable section of the control file and therefore are eventually overwritten.

    If you’re using a recovery catalog, then you don’t need to worry about this parameter because RMAN metadata are stored in the recovery catalog indefinitely. Therefore, when you use a recovery catalog, you can access any historical RMAN metadata.

    If you’re using only the control file as the RMAN metadata repository, then the information stored there will eventually be overwritten. The default value for CONTROL_FILE_RECORD_KEEP_TIME is 7 days:

    SQL> show parameter control_file_record_keep_time



    NAME                                 TYPE        VALUE

    ------------------------------------ ----------- ---------

    control_file_record_keep_time        integer     7

    You can set the value to anything from 0 to 365 days. Setting the value to 0 means that the RMAN metadata information can be overwritten at any time.

    The CONTROL_FILE_RECORD_KEEP_TIME parameter was more critical in older versions of Oracle, in which it wasn’t easy to repopulate the control file with RMAN information, in the event that metadata were overwritten. Starting with Oracle 10g, you can use the CATALOG command to quickly make the control file aware of RMAN backup files.

    If you run daily backups, then I recommend that you leave this parameter at 7 days. However, if you only back up your database once a month, or if, for some reason, you have a retention policy greater than 7 days, and you’re not using a recovery catalog, then you may want to consider increasing the value. The downside to increasing this parameter is that if you have a significant amount of RMAN backup activity, this can increase the size of your control file.

  • RMAN: Setting the Degree of Parallelism with examples

    You can significantly increase the performance of RMAN backup and restore operations if your database server is equipped with the hardware to support multiple channels. If your server has multiple CPUs and multiple storage devices (disks or tape devices), then you can improve performance by enabling multiple backup channels.

    If you require better performance from backup and restore operations and have hardware that facilitates parallel operations, you should enable parallelism and perform tests to determine the optimal degree. If your hardware can take advantage of parallel RMAN channels, there is little downside to enabling parallelism.

    If you have multiple CPUs, but just one storage device location, you can enable multiple channels to write to and read from one location. For example, if you’re backing up to an FRA, you can still take advantage of multiple channels by enabling parallelism. Suppose you have four CPUs on a server and want to enable a corresponding degree of parallelism:

    RMAN> configure device type disk parallelism 4;

    You can also write to separate locations in parallel by configuring multiple channels associated with different mount points; for example,

    RMAN> configure device type disk parallelism 4;

    RMAN> configure channel 1 device type disk format '/u01/O12C/rman/rman1_%U.bk';

    RMAN> configure channel 2 device type disk format '/u02/O12C/rman/rman2_%U.bk';

    RMAN> configure channel 3 device type disk format '/u03/O12C/rman/rman3_%U.bk';

    RMAN> configure channel 4 device type disk format '/u04/O12C/rman/rman4_%U.bk';

    This code configures four channels that write to separate locations on disk. When you configure separate channels for different locations, make sure you enable the degree of parallelism to match the number of configured device channels. If you allocate more channels than the specified degree of parallelism, RMAN only writes to the number of channels specified by the degree of parallelism and ignores the other channels.

    If you need to clear the degree of parallelism, you can do so as follows:

    RMAN> configure device type disk clear;

    Similarly, to clear the channel device types, use the CLEAR command. This example clears channel 4:

    RMAN> configure channel 4 device type disk clear;
  • RMAN: Specifying the Backup User

    As discussed previously, RMAN requires that you use a database user with SYSDBA privileges. Whether I’m running RMAN from the command line or invoking RMAN in a script, in most scenarios, I connect directly as SYS to the target database. For example, here is how I connect to RMAN from the command line:

  • RMAN: Using a Media Manager

    A media manager is required for RMAN to back up directly to tape. Several vendors provide this feature (for a cost). Media managers are used in large Oracle database environments, such as data warehouses, in which you may not have enough room to back up a database to disk. You may also have a disaster recovery requirement to back up directly to tape.

    If you have such requirements, then you should purchase a media management package and implement it. If you don’t need to back up directly to tape, there’s no need to implement a media manager. RMAN works fine backing up directly to disk.

    Keep in mind that many shops use RMAN to back up directly to disk and then have the system administrator back up the RMAN backups to tape afterward. If you do this, you have to be sure your RMAN backups aren’t running while the tape backups are running (because you may get partial files backed up to tape).

  • RMAN: Using a Recovery Catalog

    RMAN always stores its latest backup operations in the target database control file. You can set up an optional recovery catalog to store metadata regarding RMAN backups. The recovery catalog is a separate schema (usually in a database different from that of the target database) that contains database objects (tables, indexes, and so on) that store the RMAN backup information. The recovery catalog doesn’t store RMAN backup pieces—only backup metadata.

    The main advantages of using a recovery catalog are as follows:

    • Provides a secondary repository for RMAN metadata. If you lose all your control files and backups of your control files, you can still retrieve RMAN metadata from the recovery catalog.
    • Stores RMAN metadata for a much longer period than is possible when you just use a control file for the repository.
    • Offers access to all RMAN features. Some restore and recovery features are simpler when using a recovery catalog.

    The disadvantage of using a recovery catalog is that this is another database you have to set up, maintain, and back up. Additionally, when you start a backup and attempt to connect to the recovery catalog, if the recovery catalog isn’t available for any reason (server down, network issues, and so on), you must decide whether you want to continue with the backup without a recovery catalog.

    You must also be aware of versioning aspects when using a recovery catalog. You need to make sure the version of the database you use to store the recovery catalog is compatible with the version of the target database. When you upgrade a target database, be sure the recovery catalog is upgraded (if necessary).

    RMAN works fine with or without a recovery catalog. For several of the databases I maintain, I don’t use a recovery catalog; this eliminates having to set it up and maintain it. For me, simplicity takes precedence over the features available with the recovery catalog.

    However, if you have good business reasons for using a recovery catalog, then implement and use one. The recovery catalog isn’t that difficult to set up and maintain, and Oracle recommends that you use it.

  • RMAN: Using Backup Sets or Image Copies

    When you issue an RMAN BACKUP command, you can specify that the backup be one of the following:

    • Backup set
    • Image copy

    A backup set is the default type of RMAN backup. A backup set contains backup pieces, which are binary files that only RMAN can write to or read from. Backup sets are desirable because they’re generally smaller than the data files being backed up. If you’re using Oracle 10g Release 2 or higher, RMAN automatically attempts to create backup pieces with unused block compression. In this mode, RMAN reads a bitmap to determine which blocks are allocated and only reads from those blocks in the data files. This feature is supported only for disk-based backup sets and Oracle Secure Backup tape backups.

    If you’re using a database version prior to Oracle 10g Release 2, by default, backup sets are created, using null block compression (sometimes referred to, more aptly, as block skipping). In this mode, RMAN checks blocks in the data file; if the blocks haven’t been used, they aren’t backed up.

    Image Note  RMAN can also create backup sets using true binary compression. This is the type of compression you get from an OS compression utility (such as zip). Oracle supports several levels of binary compression. The BASIC compression algorithm is available without an additional license. Oracle provides further compression features with the Oracle Advanced Compression option (see the section “Configuring Binary Compression,” later in this chapter, for details on how to enable binary compression).

    When you create a backup as a backup set, the binary backup piece files can only be manipulated by RMAN processes. Some DBAs view this as a disadvantage because they must use RMAN to back up and restore these files (you have no direct access to or control over the backup pieces). But, these perceptions aren’t warranted. Unless you hit a rare bug, RMAN is dependable and works reliably in all backup-and-restore situations.

    Contrast the backup set with an image copy. An image copy creates a byte-for-byte identical copy of each data file. The advantage of creating an image copy is that (if necessary) you can manipulate the image copy without using RMAN (as with an OS copy utility). Additionally, in the event of a media failure, an image copy is a fast method of restoring data files, because RMAN only has to copy the file back from the backup location (there is no reconstructing of the data file, because it’s an exact copy).

    I almost always use backup sets for database backups, rather than image copies. Usually, I require some form of RMAN compression (block skipping). The size of the backup to disk is almost always a concern. Backup sets are more efficient regarding disk space consumption. Because backup sets can take advantage of RMAN compression, there is also less I/O involved, compared with an image copy. In many environments, reducing the I/O so as not to impact other applications is a concern.

    However, if you feel that you need direct control over the backup files that RMAN creates, or you’re in an environment in which the speed of the restore process is paramount, consider using image copies.

  • RMAN: Using Block Change Tracking

    This feature keeps track of when a database block changes. The idea is that if you’re using an incremental backup strategy, you can enhance performance, because by implementing this feature, RMAN doesn’t have to scan each block (under the high-water mark) in the data files to determine whether it needs to be backed up. Rather, RMAN only has to access the block change tracking file to find which blocks have changed since the last backup and directly access those blocks. If you work in a large, data warehouse environment and are using an incremental backup strategy, consider enabling block change tracking to enhance performance.

  • RMAN: Using Incremental Backups

    For most of the databases I’m responsible for, I run a daily level 0 backup. I don’t usually implement any type of incremental backup strategy.

    Incremental backup strategies are appropriate for large databases in which only a small portion of the database blocks change from one backup to the next. If you’re in a data warehouse environment, you may want to consider an incremental backup strategy, because it can greatly reduce the size of your backups. For example, you may want to run a weekly level 0 backup and then run a daily level 1 incremental backup.

  • RMAN: Using Incrementally Updated Backups

    Incrementally updated backups are an efficient way to implement an image copy backup strategy. This technique instructs RMAN to first create image copies of data files; then, the next time the backup runs, instead of creating a fresh set of image copies, RMAN makes an incremental backup (changes to blocks since the image copy was created) and applies that incremental backup to the image copies.

    If you have the disk space available for full image copies of your database and you want the flexibility to use the image copies directly, in the event of a media failure, consider this backup strategy.

    One potential disadvantage of this approach is that if you’re required to restore and recover to some point in the past, you can only restore and recover to the point at which the image copies were last updated with the incremental backup.

Page 1 of 2