Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd Logo
Upload

Welcome to Scribd!

  • 21 views

    Backup Sets, Backup Pieces and Incremental Backups

    Uploaded by

    Atthulai

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd

    Backup Sets, Backup Pieces and Incremental Backups

    Uploaded by

    Atthulai
    21 views3 pages

    Original Title

    ORACLE RMAN

    Copyright

    © © All Rights Reserved

    Available Formats

    DOCX, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    21 views3 pages

    Backup Sets, Backup Pieces and Incremental Backups

    Uploaded by

    Atthulai

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    of 3

    RMAN

    RMAN is the Oracle supplied DBMS backup utility and like any other integrated utility, it 'understands'
    how the database fits together and so is a much safer way to backup a database than to simply shut it
    down then backup the underlying flatfiles. As well as permitting database backups while the database is
    active, RMAN does a lot of data validation to ensure that a backup is complete and can be used to restore
    a good copy of a database. Most RMAN facilities are managed by DBAs but RMAN usually interfaces
    with Storage products like Spectrum Protect (TSM) or NBU for backend storage, so it is necessary to
    have an understanding of how RMAN works in case you get problems with that interface.
    As well as database files, a database depends on other types of files, such as network configuration files,
    password files, and the contents of the Oracle home. These files are not backed up with RMAN and so
    must be backed up with your standard backup and recovery tool.
    RMAN calls the users databases 'Target Databases' or in other words, the target database is the
    database that RMAN is backing up, restoring, or recovering. Data about backups is usually held in a
    Recovery Catalog, which is just another database and it can contain backup information about multiple
    target databases. This information will include stuff like Backup sets, Image copies, archived redo logs,
    target database schemas and configuration settings.
    Oracle uses the terminology consistent backups and inconsistent backups for databases. A consistent
    backup occurs when the database is shut down and so is in a consistent state.
    A backup made when the database is open is inconsistent. Oracle backs up both the database and the
    relevant parts of the redo logs, so when a database is restored from an inconsistent backup, Oracle will
    apply any pending changes from the redo logs. The term 'inconsistent' is a little bit misleading, as
    inconsistent backups are sound, acceptable and frequently used. The beauty of inconsistent backups is
    that you do not have to shut the database down to run them, which is invaluable in today's 24*7 world.
    The only issue is that RMAN will fail the backup if the database is in NOARCHIVELOG mode, a quite
    common type of failure that needs a DBA to fix.

    Backup Sets, Backup Pieces and Incremental backups


    It is worth knowing how RMAN uses Backup Sets and Backup Pieces, so you have some idea what the
    various RMAN log messages mean.
    A backup set contains the data from one or more datafiles, archived redo logs, or control files or server
    parameter file to create a complete backup of a database.
    A backup set contains one or more binary files called backup pieces. By default a backup set will contain
    one backup piece, but a backup can be split into multiple pieces using multiple channels in parallel, each
    of which produces one backup piece. The backup pieces are the files that you see recorded in your
    backup software and each backup piece has a uniquely generated name. As every backup piece has a
    unique name, your backup software just needs to keep one backup version of each file.
    By default, RMAN makes full backups. Image Copies are full backups that contain a backup of every data
    block, whereas a full backup that is stored in a backup set may skip datafile blocks that are not in use.
    Full backups are the default, but RMAN can take incremental backups, where only those data blocks that
    have changed since a previous backup are copied.. A backup set is an RMAN-specific proprietary format,
    whereas an image copy is a bit-for-bit copy of a file. By default, RMAN creates backup sets.
    RMAN has another backup process, called 'The Flashback Database' that is designed to provide fast
    recovery to a point in time backup. It appears to work by rolling back log data, rather than by using any
    hardware flashcopy feature. Flashback Database uses its own flashback logs, which are stored in a fast
    recovery area.
    Flashback Database is controlled with RMAN commands or SQL statements, so it is not something a
    storage person would be directly involved in. However, its use is limited to logical errors, as it relies on the
    availability of the database files and the redo logs - in other words, it will not help if you get a physical disk
    failure. It could require quite a bit of extra storage, especially if DBAs want the ability to flash back for
    several days
    .

    RMAN and Spectrum Protect (TSM)


    It is common practice for RMAN to hand over the management of physical storage to a backup and
    recovery product like Spectrum Protect (TSM) or NBU. RMAN calls this product a media manager and
    allocates 'channels' or paths to the storage using commands like this.

    allocate channel t1 type 'sbt_tape'


    parms 'ENV=(TDPO_OPTFILE=/u01/app/oracle/admin/Spectrum Protect
    (TSM)_rman/db1_tdpo.opt)';

    In this case, RMAN is using Spectrum Protect (TSM) as the media manager. Note that the channel type is
    sbt_tape, but Spectrum Protect (TSM) can direct the backup to a disk storage pool. RMAN is looking for
    Spectrum Protect (TSM) information in a tdpo_opt file. Typical information in that file will include:

    DSMI_DIR          /usr/tivoli/Spectrum Protect (TSM)/client/api/bin64


    DSMI_ORC_CONFIG   /usr/tivoli/Spectrum Protect (TSM)/client/ba/bin/dsm.oracle.opt
    TDPO_NODE        Spectrum Protect (TSM)_oracle_node

    These three lines tell RMAN where to find the Spectrum Protect (TSM) code, the location of the Spectrum
    Protect (TSM) options file used for an oracle backup, and the name of the Spectrum Protect (TSM) client
    node for the oracle backup. Obviously, all of these file paths may be different in your installation.
    Another essential piece of information is the link to the Spectrum Protect (TSM) library drives. Oracle
    expects to find this information in $ORACLE_HOME/lib/libobk.a and Spectrum Protect (TSM) usually
    holds it in /usr/Tivoli/Spectrum Protect (TSM)/client/oracle/libobk64.a so you need a symbolic link from the
    Oracle library to the Spectrum Protect (TSM) library. A missing link is the most common cause of errors
    like

    RMAN-00571: =============================== ============================


    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ============================ ===============================
    RMAN-03009: failure of allocate command on c1 channel at 11/30/2001 13:57:18
    ORA-19554: error allocating device, device type: SBT_TAPE, device name:
    ORA-27211: Failed to load Media Management Library
    Additional information: 25

    Controlling Backup Retentions


    RMAN needs to control backup retentions, so it can ensure that the backup information that it holds in it's
    catalog matches the backups held externally. For Spectrum Protect (TSM), the common practice is to use
    a copy group that holds only one version of an active backup indefinitely, and no deleted backups. This
    works because every backup file has a unique name. Spectrum Protect (TSM) then lets RMAN delete the
    backups when they are not required. For this to happen, the 'Backup Delete Allowed' parameter on the
    client definition should be set to Yes - if you set it to 'NO', then your backups will be retained forever!
    Within RMAN a database backup retention of 21 days would be set with the command

    CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 21 DAYS;

    and when the backup is older than 21 days, RMAN will signal Spectrum Protect (TSM) to delete the
    backup. If you have configured Spectrum Protect (TSM) correctly and old backups are still not being
    deleted, then check that your RMAN backup script contains commands like these to actually clean up old
    backups.
    .
     run {
       crosscheck backupset;
       report obsolete;
       delete obsolete;
         }

    We often get requests for special oracle database backup retentions, but these are also controlled by
    RMAN. Special backups can be retain for longer than the default cycle using the RMAN command
    'CHANGE BACKUPSET TAG ... KEEP UNTIL ...' , usually controlled and issued by your DBA.

    Oracle Storage
     Oracle Files
     Oracle RMAN
     Oracle RAC
     Dataguard
     Oracle ASM

    Lascon updTES
    I retired 2 years ago, and so I'm out of touch with the latest in the data storage world. The Lascon site has
    not been updated since July 2021, and probably will not get updated very much again. The site hosting is
    paid up until early 2023 when it will almost certainly disappear.
    Lascon Storage was conceived in 2000, and technology has changed massively over those 22 years. It's
    been fun, but I guess it's time to call it a day. Thanks to all my readers in that time. I hope you managed
    to find something useful in there.
    All the best
    DISCLAIMER - By entering and using this site, you accept the conditions and limitations of use
    Click here to see the Full Site Index       Click here to see the Cookie Policy       Click here to see
    the Privacy Policy                             ©2019 and later, A.J.Armstrong

    You might also like