Skip to main content

Registering The Database to RMAN catalog database:



Registering The Database to RMAN catalog database:

Need to start RMAN as follows:

RMAN target=sys/password@database_to_backup

rcvcat=sys/password@recovery_catalog_database

Another variation on the command, if the recovery catalog and the database were on the same server, might be as shown:

oraenv
ORACLE_SID = [KKUY] ? KKUY

RMAN rcvcat=sys/password@recovery_catalog_database

RMAN> connect target

Recovery Manager: Release 8.0.5.1.0 - Production

RMAN-06005: connected to target database: KKUY
RMAN-06008: connected to recovery catalog database

Use the below command to register the database.

RMAN>register database;

Want to verify if a database is registered in the recovery catalog. To do this, connect to RMAN and issue the command LIST INCARNATION OF DATABASE.

RMAN> list incarnation of database;

RMAN-03022: compiling command: list
RMAN-06240: List of Database Incarnations
RMAN-06241: DB Key Inc Key DB Name DB ID      CUR Reset SCN   Reset Time
RMAN-06242: ------ ------  ------- -------    --- ---------   ---------
RMAN-06243: 222   939     KKUY 25791345 YES 1            01-APR-00
RMAN-06243: 1      2       DGHIU  8758787693 YES 756987987 FEB-00


Verify the DBID connect to the database. To double check.

SQL> select to_char(dbid) from v$database;
TO_CHAR(DBID)
----------------------------------------
25791345


Resyncing And Resetting The Recovery Catalog:

Often, the recovery catalog requires resyncing. Many operations resync the recovery catalog implicitly. Other times, you may need to resync the recovery catalog by issuing the following command from RMAN:

RMAN>resync catalog;

The recovery catalog should be resynced with the target database often, particularly if there are many archive log switches or if changes are made to the structure of the database. Generally this will occur as a result of a backup operation (full backup sets or archivelog backup operations). The catalog resync process is important mostly to allow for a proper control file recovery to occur, if needed. Although recovery is still possible even if the catalog was not resynced, it just becomes more labor intensive because you must manually add the new structures by using the RMAN CATALOG command.

RMAN performs two types of resyncing: full recyncs and partial resyncs. Full resyncs are done whenever you manually resync the catalog through RMAN and at the end of any backup through RMAN. Full resyncs update the recovery catalog with all control file information that has changed since the last resync. This includes changes to the physical architecture of the database.

Partial resyncs update the catalog with the following information only:

Redo log

Backup set

Datafile copy information

Oracle recommends that you resync the catalog at intervals of no less than the control_file_record_keep_time parameter in the init.ora of the target database. This ensures that the recovery catalog is resynced before Oracle clears out the control files of the target database of information older than the time in days specified by the parameter.

A separate operation from resyncing, Resetting the recovery catalog is necessary in the cases of database recovery that end in the use of the ALTER DATABASE OPEN RESETLOGS command. The RESET command creates a new incarnation of the database, which is required if the online redo logs are reset. You must create a new incarnation because the archive log sequence numbers are reset and because the database ID is changed. You can also use the RESET command to reset to a prior incarnation if required during a recovery operation. You do this using the TO INCARNATION <NUM> clause of the RESET DATABASE command.

Thank You!
Labels:

Comments

Post a Comment

Popular posts from this blog

ORA-39014: One or more workers have prematurely exited.ORA-00018: maximum number of sessions exceeded

ERROR: I was Performing a full database import and during the import I faced the below error. ORA-39014: One or more workers have prematurely exited. ORA-39029: worker 6 with process name "DW07" prematurely terminated ORA-31672: Worker process DW07 died unexpectedly. Job "SYSTEM"."SYS_IMPORT_FULL_04" stopped due to fatal error at 00:59:40 ORA-39014: One or more workers have prematurely exited. SOLUTION:  Run the import with fewer parallel processes, like PARALLEL=2 instead of 8. I was able to run the import successfully. NOTE 1: This errors occurs when there are less session allocation in the database. check the session,process parameters and increase them accordingly. To avoid such errors again. NOTE 2 : Note: Increasing processes parameter increases the amount of shared memory that needs to be reserved & the OS must be configured to support the larger amount of shared memory. So here we first need to increase the Memory & SG...
Post a Comment
Read more

ORA-01143: cannot disable media recovery - file 1 needs media recovery

I got a request from the client - To flashback the database to the existing restore point & disable flashback and archive log mode for database UATB. Here I came a cross error - ORA-01143. I followed the below steps. 1. SQL> select name from v$database; NAME ------------ UATB 2. SQL> SELECT NAME FROM V$RESTORE_POINT WHERE GUARANTEE_FLASHBACK_DATABASE='YES' ORDER BY TIME; NAME --------- UATB_COPY Here I'm going to restore the database to the above restore point. NOTE: The flashback database restore has to be done in MOUNT stage of the database. SQL> select name from v$database; NAME --------- UATB SQL> shut immediate; Database closed. Database dismounted. ORACLE instance shut down. SQL> startup mount ORACLE instance started. Total System Global Area  612368384 bytes Fixed Size                  1250428 bytes Variable Size             167775108 bytes ...
2 comments
Read more