Tagged: RMAN Toggle Comment Threads | Keyboard Shortcuts

  • Mustafa 1:25 am on December 6, 2016 Permalink | Reply
    Tags: , , noarchivelog, , RMAN   

    12c: Backup NOARCHIVELOG database using RMAN 

    In NOARCHIVELOG mode the database can only be backed up when the database is closed/mounted and in a consistent mode. We can simply do that by putting the database is MOUNT mode and initiating backup as shown below.

     
  • Mustafa 6:41 pm on November 23, 2010 Permalink | Reply
    Tags: , , Recovery, RMAN, RMAN TSM TDPO TIVOLI BACKUP RECOVERY ORACLE, TDPO, Tivoli, TSM   

    Database Lost! Recover It! 

    The last thing you ever want is your departmental head standing right behind you, gazing looking for answers and quick answers.A good Oracle DBA can always obviate such sticky situations by adhering to the principles of a good backup and recovery strategy.I happened to take up this challenging task on my own, and fixing things up of whose nuts and bolts I wasn’t aware of, something which was obscure and nebulous. Never being afraid of the outcome, I thought I must give it a try, after all even a failure would help me increase my knowledge.

    The major task put ahead was configuring Tivoli to work seamlessly with RMAN. A DBA in normal circumstances has nothing to do with Media Management Layer but in my case it was an aberration, where I had to roll up my sleeves. Moving forward, configuring RMAN wasn’t an onerous task but Tivoli lived equally up to it. I would be explaining mainly how restoring and recovering a database works, paying more emphasis on it as a backup is of no use if you cannot perform a recovery from it. The first main task is that your backup strategy must be intact and documented. For which I wrote shell scripts, keeping in mind the following conditions,

    • At the start of every year a full whole database backup must be taken
    • At the start of every month a full whole database backup must be taken
    • At the start of every week an incremental level 0 backup must be taken
    • For every weekday an incremental level 2 backup must be taken

    Keeping the following in mind I prepared a simple korn shell script which would backup my Real Application Cluster database onto tape using RMAN. Having my backup strategy in place, with the backups being written to tape and also being reported by RMAN, it was even more important that I test out its integrity when the need arises. To do so the whole database was to be restored and recovered on a whole new machine, moving from RAC to single node. My first steps involved taking the backup of the recovery catalog database (I had created my recovery catalog in a new database rather than creating it in the production database a schema for some axiomatic reasons) and then restoring the whole cold backup on the new server (skipping the details). With the recover catalog fired up, I created the file structure so that while no mounting the database with the parameter file, I could bring the database to a state from where I can start restoring my controlfile. With my database in nomount state, I proceeded with connecting my target database and recovery catalog using RMAN which showed that the target database is in nomount state, as it should be as I have no database which will be constructed from the backup on the tape device. After which I performed the following steps on the RMAN prompt

    RMAN> run
    {
    allocate channel d1 type ‘sbt_tape’ parms ‘ENV=(TDPO_OPTFILE=/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt)’;
    restore controlfile;
    }

    anybody having knowledge of the related subject would certainly say it is going to work. But to my astonishment this did not bear any fruit

    allocated channel: d1
    channel d1: sid=159 devtype=SBT_TAPE
    channel d1: Data Protection for Oracle: version 5.4.1.0
    Starting restore at 03-JAN-08
    channel d1: starting datafile backupset restore
    channel d1: restoring control file
    channel d1: reading from backup piece df_643023858_9_1
    ORA-19870: error reading backup piece df_643023858_9_1
    ORA-19507: failed to retrieve sequential file, handle=”
    df_643023858_9_1″, parms=””
    ORA-27029: skgfrtrv: sbtrestore returned error
    ORA-19511: Error received from media manager layer, error text:
    ANS1088E (RC124) File space ‘*’ does not exist
    failover to previous backup
    channel d1: starting datafile backupset restore
    channel d1: restoring control file
    channel d1: reading from backup piece df_642914172_3_1
    ORA-19870: error reading backup piece df_642914172_3_1
    ORA-19507: failed to retrieve sequential file, handle=”
    df_642914172_3_1″, parms=””
    ORA-27029: skgfrtrv: sbtrestore returned error
    ORA-19511: Error received from media manager layer, error text:
    ANU2614E Invalid sequence of function calls to Data Protection for
    Oracle
    failover to previous backup
    released channel: d1
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of restore command at 01/03/2008 12:24:34
    RMAN-06026: some targets not found – aborting restore
    RMAN-06024: no backup or copy of the control file found to restore

    Having no idea what Filespace errors meant from the MML, I started looking up my tdpo.opt file on this and the server which had failed. Both where same /adsmorc and also a select statement from dsmadmc TSM client is showed me the same

    tsm: TSMSERVER>select * from backups where node_name=’MY_NODE’ and LL_NAME=’df_643023858_9_1′
    ANR2963W This SQL query may produce a very large result table, or may
    require a significant amount of time to compute.
    Do you wish to proceed? (Yes (Y)/No (N)) Y
    NODE_NAME: MY_NODE
    FILESPACE_NAME: /adsmorc
    FILESPACE_ID: 1
    STATE: ACTIVE_VERSION
    TYPE: FILE
    HL_NAME: //
    LL_NAME: df_643023858_9_1
    OBJECT_ID: 7980035
    BACKUP_DATE: 2008-01-03 09:46:57.000000
    DEACTIVATE_DATE:
    OWNER:
    CLASS_NAME: DEFAULT

    With the backup piece on the tape with available state it further convoluted my nascent knowledge about TSM. Fighting with all odds I gave it another shot with some IBM assistance I came to know that in order to restore a backup on a new server the following must be the same as of the server on which the backup was taken (in our case the corrupted or lost database). To insure that following parameters in tdpo.opt must match

    • TDPO_NODE describes the nodename
    • TDPO_FS describes the filespacename
    • TDPO_OWNER describes the ownerships of the object on UNIX machine can be verified from the above query through the TSM client

    After fixing these three on the restoration and recovery server in the tdpo.opt file the restore operation went successful which lent some relieve, as things moved in the right direction. Now after the restoring the controlfile and mounting the database it was time to restore and recover the database itself.

    run
    {
    allocate channel d1 type ‘sbt_tape’ parms ‘ENV=(TDPO_OPTFILE=/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt)’;
    sql ‘alter database mount’;
    restore database;
    recover database;
    sql ‘alter database open resetlogs’;
    }

    It gave me an error which was asking about the current logfiles’ archive but that won’t be necessary at the moment. With the database all fired up I was pretty much convinced that things aren’t going to be that bad if I am put to the test.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel