A nice story about RMAN.


          The story begins,  when one of my associate DBAs did an RMAN restoration & recovery 2 days back. 

           Here, I need to mention the exact date, time and the backup schedules also. 

Similar to every organizations' backup policy, we too take full backup (FB) on saturday night and Incremental backup (IB) on other days. 

    Now the main story:

          The DBA restores the  Prod DB backup on DEV DB and recovers it such a way, that DEV mush have data upto 30th Dec 2016. He started his work on 2nd Jan 2017, after the day's IB.

          The command executed was:

rman auxiliary =/ << EOF
run {
set until time 'TO_DATE('2016-12-30 22:00:00', 'YYYY-MM-DD HH24:MI:SS')';
allocate auxiliary channel c1 type disk;
allocate auxiliary channel c2 type disk;
allocate auxiliary channel c3 type disk;
allocate auxiliary channel c4 type disk;
duplicate target database to 'TEST'
BACKUP LOCATION '' NOFILENAMECHECK
pfile=$ORACLE_HOME/dbs/initDEV.ora;
}
EXIT;
EOF

Have you found any problems or  syntax errors on this script ?
If yes, then Hats off to You. You are a seasoned DBA.

The restoration went fine except few errors messages.

RMAN-01009: syntax error: found "integer": expecting one of: "newline, ;"
RMAN-01009: syntax error: found "auxiliary": expecting one of: "channel"

The DBA thought there was an issue with "auxiliary channel" definition. Since the restoration and later recovery are went fine without any warnings/errors, he let the process continue. 

The work completed and he returned the DB to end-user. 

Next morning, he received a customer complaint saying, there are latest data in  the DB, which are older than 30th Dec 2016. 

Now, comes the another problem. 

There's no log file saved for the RMAN recovery op, to verify and prove everything that happen is  right.

The whole team were breaking  their head to see what went  wrong. 

Good  that the restored DB is DEV. We had a day's time to rectify the issue. 

But how could rman can restore till 2nd Jan '17 , while the command set the restoration point till "30th Dec 2016, 2200hrs" ?

I'll post the root cause on  tomorrow's post. 




  Find below few useful scripts for  Performance  Management:: # Important MOS notes for TRACING: There are several ways to trace a particul...