Stopping recovery on standby
[oracle@ip-10-0-1-79 ~]$ sqlplus / as sysdba
SQL*Plus: Release 188.8.131.52.0 Production on Sun Jul 7 12:56:24 2013
Copyright (c) 1982, 2013, Oracle. All rights reserved.
[oracle@testdb1 oracle]$ rsp / as sysdba SQL*Plus: Release 184.108.40.206.0 Production on Mon Aug 6 12:50:04 2012 Copyright (c) 1982, 2011, Oracle.
Prompted by a recent interview I wanted to perform a little test with RMAN, and incrementally updated backups. I created a 220.127.116.11.5 database on my Linux (OEL 5.5) test system and refreshed my understanding of this most useful rman feature (which is for another post).
So after I was happy with the working of the incrementally updated image copies I decided to see if I could restore my database with those. Time to use “drop database”, which removes spfile, data files, temp files and the control files. Tabula rasa!
But it didn’t matter I thought: I have controlfile/spfile autobackups and fully recovered image copies plus all the archived logs in the FRA. What could possibly go wrong? Well it took me 30 minutes to get the database back.
This one is to be filed under the “little things I didn’t really know until now” section: RMAN duplicate. Be honest to yourself: would you have known the answer to this question: what happens to tablespaces which are read-only on the source during an RMAN duplication (not for standby)?
I have started my career as a DBA on Oracle 18.104.22.168, and at the time not everyone fully embraced RMAN. OK, RMAN made it really hard at the time to fall in love with it. So when we “cloned” our production database to development, the following steps were followed:
I’ve recently run into an issue where the recovery catalog views (RC_xxx) in an 22.214.171.124 catalog may contain inaccurate information. We have a client with multiple databases all of which are backed up using RMAN. Rather than reading the logfile of each and every backup, each and every day I wrote a small script to [...]
ASM BUG DUPLICATE
Unknown to me anyway until just this week.
Some time ago I read a post about RMAN on Oracle-L that detailed what seemed like a very good idea.
The poster's RMAN scripts were written so that the only connection while making backups was a local one using the control file only for the RMAN repository.
#eeeeee; border: 1px dashed rgb(153, 153, 153); color: black; font-family: Andale Mono,Lucida Console,Monaco,fixed,monospace; font-size: 12px; line-height: 14px; overflow: auto; padding: 5px; width: 100%;">
rman target sys/manager nocatalog
After the backups were made, a connection was made to the RMAN catalog and a SYNC command was issued.
The reason for this was that if the catalog was unavailable for some reason, the backups would still succeed, which would not be the case with this command: