| What's the recommended guideline on backing up a recovery catalog? [message #395911] |
Fri, 03 April 2009 01:27  |
kytemanaic
Messages: 55
Registered: February 2009
|
Member |
|
|
while I understand "Benefits of Using the Recovery Catalog as the RMAN Repository" as stated in
http://download-uk.oracle.com/docs/cd/B10501_01/server.920/a96566/rcmquick.htm#442214
as well as things to take note if using control file as the sole rman repository,
as stated in "Monitoring the Overwriting of Control File Records" in http://download-uk.oracle.com/docs/cd/B10501_01/server.920/a96566/rcmrepos.htm#446924
I do not understand why in Backup and Recovery Advanced User's Guide
http://download.oracle.com/docs/cd/B14117_01/server.101/b10734/rcmrepos.htm
"Back Up the Recovery Catalog Often"
Even if you have to restore the recovery catalog database using a control file autobackup, you can then use the full record of backups in your restored recovery catalog database to restore the target database without using a control file autobackup for the target database.
=>probably implies that we can use another recovery catalog let's call it backupbackup to restore the recovery catalog
"Choosing the Appropriate Method for Physical Backups"
Follow these guidelines when developing an RMAN backup strategy for the recovery catalog database:
* Run the recovery catalog database in ARCHIVELOG mode so that you can do point-in-time recovery if needed.
* Set the retention policy to a REDUNDANCY value greater than 1.
* Back up the database onto two separate media (for example, disk and tape).
* Run BACKUP DATABASE PLUS ARCHIVELOG at regular intervals, to a media manager if available, or just to disk.
* Do not use another recovery catalog as the repository for the backups.=> this contradicts the previous statement
* Configure the control file autobackup feature to ON.
so may I know what's the recommended guideline on backing up a recovery catalog? should we use another recovery catalog to keep the rman repositories of the the main primary catalog or just use a control file autobackup feature to keep the repositories of the main primary catalog?
thanks
|
|
|
|
| Re: What's the recommended guideline on backing up a recovery catalog? [message #395953 is a reply to message #395911] |
Fri, 03 April 2009 05:21  |
 |
Mahesh Rajendran
Messages: 10707
Registered: March 2002
Location: oracleDocoVille
|
Senior Member
Account Moderator |
|
|
Quoting the same URL you have pointed.
| Quote: | Exporting the Recovery Catalog Data for Logical Backups
Logical backups of the RMAN recovery catalog created with one of Oracle's export utilities can be a useful supplement for physical backups. In the event of damage to the recovery catalog database, you can quickly reimport the exported recovery catalog data into another database and rebuild the catalog this way.
|
Seems you missed the above piece advice.
Though I would backup everything in every other possible method, when it comes to RMAN catalog
I just export them.
Exported dumps are NOT real backups but just a method to move the data logically.
>>should we use another recovery catalog to keep the rman repositories of the the main primary catalog or just use a control file autobackup feature to keep the repositories of the main primary catalog?
Another recovery catalog is not required.
Practically you will be ending up paying more $$$ in licenses.
Just keep the the primary catalog in a separate node other than the databases it is backing up.
It is upto to you to run the archived log mode.
RMAN catalog database is not a transactional database. The records will be written only at specific times (scheduled backup). Do a backup/export after the all your backups are done.
If you will be using multiple schema for multiple target databases you can export individual schema.
I would also just do a weekly cold RMAN backup on catalog database.
If you are relying on exported dumps, be advised that it is not a real backup.
If you loose catalog, you have to create a database and import back.
One real advantage with exporting catalogs is that, since exported dumps are OS independent,
You have the flexibility of importing the catalog to any existing database in any OS and get things going.
This is handy in case of real disaster.
[Updated on: Fri, 03 April 2009 05:25] Report message to a moderator |
|
|
|
| Re: What's the recommended guideline on backing up a recovery catalog? [message #396057 is a reply to message #395953] |
Fri, 03 April 2009 12:03 |
kytemanaic
Messages: 55
Registered: February 2009
|
Member |
|
|
Hi Mahesh thanks for the very thorough explanation and suggestion.
since using controlfile autobackup cannot have multiple incarnation, from
http://download-uk.oracle.com/docs/cd/B10501_01/server.920/a96566/rcmquick.htm#442214
"Benefits of Using the Recovery Catalog as the RMAN Repository"
You can store metadata about multiple incarnations of a single target database in the catalog. Hence, you can restore backups from any incarnation.
I need to test my understanding the scheduled logical export that u suggested is one way of having different incarnations of the recovery catalog?
I mean once alter database open RESETLOGS for the recovery catalog, recovery catalog cannot be restore to previous incarnations, except maybe to import an earlier logical export, right?
thanks
|
|
|
|
| Re: What's the recommended guideline on backing up a recovery catalog? [message #396065 is a reply to message #396057] |
Fri, 03 April 2009 12:42 |
|
Mahesh Rajendran
Messages: 10707
Registered: March 2002
Location: oracleDocoVille
|
Senior Member
Account Moderator |
|
|
>>logical export that u suggested is one way of having different incarnations of the recovery catalog?
Not exactly. We are dealing with two different concepts here.
1)Logical export as a backup method.
2)Using multiple rman users(schema in rman catalog database) for various operations.
It is more of a redundant method very useful if you are dealing with multiple databases with multiple incarnations.
Actually, you can reset the database to look into a previous incarnation.
http://download.oracle.com/docs/cd/B19306_01/backup.102/b14194/rcmsynta050.htm#i85086
Let me explain.
I backup several production databases (Prod_A, Prod_B, Prod_C).
Each database is backed up by a specific rman user (backup_A,backup_B,backup_C) having seperate catalogs (schema) in the same RMAN database.
Each production database may be duplicated into test,dev,uat,special closing like month-end,year-end, whatever the developer / functional folks ask for.
So I use a specific rman user(schema) for each of the above operation.
It is not a must. Just a little more convenient (requires one time setup work)
For example
I backup PROD_A using rman user backup_A. After backup i sync
the information to restore_A.
For realtime restoration purposes, I would use restore_A.
I use an rman user clone_A to clone production where ever / wheneever I want (sync before clone).
Say the Finance folks need a part of the database for their testing work. So I might have an
rman user clone_A_finance which would clone the specific tablespaces they want.
After each duplication/clone the user will be looking only into the database that was just restored.
This way I keep different incarnations (based on functionality) in separate schema inside rman database and never have to worry about messing up restores/resetting the incarnation.
The original users backup_A and restore_A have the information all the time, no matter
how many time the production database is be cloned / restore for test/dev purposes.
Infact the duplication procedures are scripted and automated and in some cases, the users can just
execute a shell script that would duplicate the production database to their area.
recovery catalog is very useful if you are backing multiple databases and use multiple operations
like clone/restore to another node with TSPITR etc.
As said, none of the above is a must.
It is just something I did for my environment (several databases of all size upto 4TB, several OS) and several times duplicated for test/dev every month and everything is scripted.
All I (or a specific user) have to do is to call the script to do a particular job,specify the
date and time for TSPITR.
Hope that helps.
[Updated on: Fri, 03 April 2009 12:44] Report message to a moderator |
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
