What is the RMAN Catalog? – The RMAN catalog is a schema created in a separate database from your target databases (i.e. the databases that you backup) using the CREATE CATALOG command. You should first create the username (RMAN is a good choice) and tablespace to hold the schema objects: create tablespace rcat datafile ‘/u01/oradata/RMANCAT/rcat01.dbf’ size 128m autoextend on next 128m maxsize 2g ; CREATE USER rman IDENTIFIED BY backup TEMPORARY TABLESPACE temp DEFAULT TABLESPACE rcat QUOTA UNLIMITED ON rcat ; Then, create the catalog using RMAN: $ rman catalog rman/backup RMAN> create catalog ; The schema is essentially comprised of the same information regarding the database backups which is stored in the database controlfiles of the target databases. When a backup, recovery, clone, or even a show command is run with the nocatalog option, you will see this message: using target database control file instead of recovery catalog Whether using a catalog or not, the RMAN utility provides for reporting on backups. However, that same information can be found in the V$ views. The V$ views are what Oracle calls “fixed views” and are stored in the controlfile. If all you have available to you is a controlfile, you can mount the database and query those views. Oracle even has a view that tells you which views are available. The following list pertains to backup information: SQL> r 1 select name 2 from v$fixed_table 3 where name like ‘V$%’ 4 and name like ‘%BACKUP%’ 5* order by 1 NAME – V$BACKUP V$BACKUP_ARCHIVELOG_DETAILS V$BACKUP_ARCHIVELOG_SUMMARY V$BACKUP_ASYNC_IO V$BACKUP_CONTROLFILE_DETAILS V$BACKUP_CONTROLFILE_SUMMARY V$BACKUP_COPY_DETAILS V$BACKUP_COPY_SUMMARY V$BACKUP_CORRUPTION V$BACKUP_DATAFILE V$BACKUP_DATAFILE_DETAILS V$BACKUP_DATAFILE_SUMMARY V$BACKUP_DEVICE V$BACKUP_PIECE V$BACKUP_PIECE_DETAILS V$BACKUP_REDOLOG V$BACKUP_SET V$BACKUP_SET_DETAILS V$BACKUP_SET_SUMMARY V$BACKUP_SPFILE V$BACKUP_SPFILE_DETAILS V$BACKUP_SPFILE_SUMMARY V$BACKUP_SYNC_IO V$RMAN_BACKUP_JOB_DETAILS V$RMAN_BACKUP_SUBJOB_DETAILS V$RMAN_BACKUP_TYPE V$UNUSABLE_BACKUPFILE_DETAILS 27 rows selected. To ensure that enough information regarding your backups is maintained in the controlfile, you should set the initialization parameter, control_file_record_keep_time, to some value greater than what your RMAN retention policy is. Even if you don’t set a retention policy, I would recommend setting this parameter to 31. This ensures that a month’s worth of backup information will be available to you in your controlfile. Within RMAN, you also need to “set controlfile autobackup on.” This ensures that the current controlfile is backed up the end of your backup. This is the controlfile that you will want to restore if a database recovery becomes necessary.
Pogledajte cijeli odgovor
Contents
What is the difference between using recovery catalog and control file?
Your goal is to ensure that the metadata in the recovery catalog is current. Because the recovery catalog obtains its metadata from the target control file, the currency of the data in the catalog depends on the currency of the data in the control file.
You need to make sure that the backup metadata in the control file is recorded in the catalog before it is overwritten with new records. The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter determines the minimum number of days that records are retained in the control file before they are candidates for being overwritten.
Hence, you must ensure that you resynchronize the recovery catalog with the control file records before these records are erased. As described in “Resynchronizing the Recovery Catalog and CONTROL_FILE_RECORD_KEEP_TIME”, you should perform either of the following actions at intervals less than the CONTROL_FILE_RECORD_KEEP_TIME setting:
Make a backup, thereby performing an implicit resynchronization of the recovery catalog Manually resynchronize the recovery catalog with the RESYNC CATALOG command
So, to ensure the currency of the information in the recovery catalog, the frequency of resynchronizations should be related to the value for the CONTROL_FILE_RECORD_KEEP_TIME initialization parameter. One problem can arise if the control file becomes too large. The size of the target database control file grows depending on the number of:
Backups that you perform Archived redo logs that the database generates Days that this information is stored in the control file
As explained in Oracle Database Backup and Recovery Basics, if the control file grows so large that it can no longer expand because it has reached either the maximum number of blocks or the maximum number of records, then the database may overwrite the oldest records even if their age is less than the CONTROL_FILE_RECORD_KEEP_TIME setting.
- In this case, the database writes a message to the alert log.
- If you discover that this situation occurs frequently, then reducing the value of CONTROL_FILE_RECORD_KEEP_TIME and increase the frequency of resynchronizations.
- Note: The maximum size of the control file is port-specific.
- Typically, the maximum size is 20,000 Oracle blocks.
Refer to your platform-specific Oracle documentation for more information.
Pogledajte cijeli odgovor
Can you use RMAN without recovery catalog?
Unregistering a Target Database When Not in a Data Guard Environment – This scenario assumes that you are not using the recovery catalog to store metadata for primary and standby databases. To unregister a database:
- Start RMAN and connect as TARGET to the database to unregister. Also connect to the recovery catalog. It is not necessary to connect to the target database, but if you do not, then you must specify the name of the target database in the UNREGISTER command. If multiple databases have the same name in the recovery catalog, then you must create a RUN block around the command and use SET DBID to set the DBID for the database.
- Make a note of the DBID as displayed by RMAN at startup. For example, RMAN outputs a line of the following form when it connects to a target database that is open: connected to target database: PROD (DBID=39525561)
- As a precaution, it may be useful to list all of the backups recorded in the recovery catalog using LIST BACKUP SUMMARY and LIST COPY SUMMARY, This way, you can recatalog backups not known to the control file if you later decide to reregister the database.
- If your intention is to actually delete all backups of the database completely, then run DELETE statements to delete all existing backups. Do not delete all backups if your intention is only to remove the database from the recovery catalog and rely on the control file to store the RMAN metadata for this database. The following commands illustrate how to delete backups: DELETE BACKUP DEVICE TYPE sbt; DELETE BACKUP DEVICE TYPE DISK; DELETE COPY; RMAN lists the backups that it intends to delete and prompts for confirmation before deleting them.
- Run the UNREGISTER DATABASE command. For example: UNREGISTER DATABASE; RMAN displays the database name and DBID, and prompts you for a confirmation: database name is “RDBMS” and DBID is 931696259 Do you really want to unregister the database (enter YES or NO)? yes When the process is complete, RMAN outputs the following message: database unregistered from the recovery catalog
Can we use same target database as catalog?
How to register target database? – Connect RMAN to the target database and recovery catalog database and register the database. The target database must be either open or in mounted. For example: $ rman TARGET / CATALOG rman/rman @catdb RMAN> REGISTER DATABASE; RMAN creates rows in the catalog tables to contain information about the target database. It copies all the pertinent data from the controlfile into the catalog tables, synchronizing the catalog with the control file. You can register multiple target databases in a single recovery catalog. RMAN uses the DBID to distinguish one database from another. Therefore do NOT register cloned databases created without using RMAN duplicate or whose DBID wasn’t changed using NID within the same catalog schema.
Pogledajte cijeli odgovor
Should you place recovery catalog in the same DB?
RMAN Backup and Managing the Recovery Catalog – As has been seen in previous chapters, RMAN uses the control file of the target database to store its metadata information by default. The target databases control file is updated with every operation of RMAN. But there are some capabilities of RMAN which do not come alive by just using the control file. By using the recovery catalog, it is possible to store the repository data of RMAN for different databases, thereby centralizing metadata for all databases. It is also possible to store metadata of multiple incarnations of each database to be able to restore from any incarnation. It is also possible to create RMAN scriptsin the recovery catalog and use them in different databases. Furthermore, the recovery catalog stores metadataof backups longer than the control file does. If you keep the metadata of RMAN backups in control files and lose them due to media failure, it means that you have lost all metadata about backups. This metadata you can only regain by restoring a controlfile backup which would not have metadata about database and archivelog backups made after the controlfile backup itself. In this case, the recovery becomes difficult. From the following table, you can see the difference between storing metadata of RMAN backups in the recovery catalog and the control file: Table 8.1: Recovery Catalog Vs Control File This chapter will show how you can create and manage the recovery catalog. Creating the Recovery Catalog Although it is advisable to create the recovery catalog in the same version as the target database, this is not strictly necessary, as in the case of a single recovery catalog serving a mix of 9i, 10g and 11g databases! In this case, the recovery catalog must be created in a database that is running the same version as the highest version of the target databases. However, a catalog in a 9i or 10g database cannot be used to backup an 11g target. The RMAN Compatibility Matrix is included in the RMAN documentation and available on Oracles support site. Since the recovery catalog is capable of holding backup-related metadata longer than the target databases control file, this essentially depicts that the storage should be persistent compared to the control file. In Oracle, the persistent storage lies only in the form of datafiles managed via tablespaces. The same goes for the recovery catalog as well, which is going to be managed within a dedicated tablespace that will be used for it only. Recovery catalog creation demands the creation of its owner which would be used to manage it. Although Oracle does not prevent creating the recovery catalog schema in the target database, such an implementation would be unacceptable. It is recommended that you create this schema on a different database that resides at the remote host. If you create this schema on the same database, then if you lose the database, you lose all backup metadata as well. If you create this schema in a different database in the same host, then again due to the media failure, you can lose all hard drives, thus lose the backup metadata. Therefore, it is recommended that this schema be put in a different database that resides on a different server. In order to create the recovery catalog, you need to create a user, i.e. a separate schema to hold the metadata of backups, and then create a catalog which holds RMAN backup metadata of registered databases. Following are the main steps in creating the recovery catalog: 1. Create a tablespace that holds backup metadata 2. Create a user that owns the catalog 3. Grant recovery_catalog_owner privilege to that user 4. Using RMAN executable, connect to the catalog database 5. Use create catalog command to create a recovery catalog Now, connect to the second database where you want to create the catalog and create a separate tablespace for the recovery catalog as follows: [email protected]>create tablespace rcat_ts datafile ‘/u01/oracle/product/10.2.0/db_1/oradata/RC/rcat_ts.dbf’ size 400m; Tablespace created. Then create a user which should own the recovery catalog and make the previous tablespace be the default tablespace of this user: [email protected]>create user rcat_owner identified by rcat temporary tablespace temp default tablespace rcat_ts quota unlimited on rcat_ts; User created. Note: The SYS user cannot own the recovery catalog. The recovery catalog ownermust have the role recovery_catalog_owner granted to him. So grant this role to the user in addition to the normal roles of connect and resource as follows: [email protected]>grant recovery_catalog_owner to rcat_owner; Grant succeeded. [email protected]>grant connect, resource to rcat_owner; Grant succeeded. Once this part is over, the next step is to actually create a recovery catalog connecting with the user that owns it and run the create catalog command. You have two options to connect to the recovery catalog. Either connect directly from the OS: $ export ORACLE_SID=rc $ rman catalog rcat_owner/rcat connected to recovery catalog database RMAN> Or run rman executable and connect to the catalog database using the connect catalog command: $ rman RMAN> connect catalog rcat_owner/rcat connected to recovery catalog database RMAN> Now, using the create catalog command, create a catalog on that database: RMAN> create catalog; recovery catalog created RMAN> You have successfully created the recovery catalog. To check the objects that were created after running the create catalog command, connect to the recovery catalog database and query the dba_segments table: [email protected]>select count(*) from dba_segments where owner=’rcat_owner’; count(*) – 132 [email protected]> As you see, by running the create catalog command, RMAN created objects to hold metadata information of the databases that registered in that catalog.
Pogledajte cijeli odgovor
 |