Sunday , December 22 2024

Creating Recovery Catalog

There’s a need to creating a Recovery Catalog so that the backups taken from Primay or Physical Standby database can be used among each other.

Oracle best recommended also recommends that the server where the Recovery Catalog will be different from the servers in the Data Guard Environment.

Let’s Test

1. We connect to SQLPLUS on the server to be used for Recovery Catalog.

2. We check if the connection is correct.

3. The current datafiles in the catalog server are queried.

4. We create a new tablespace to hold the Recovery Catalog information.

5. We create a Recovery Catalog user.

6. The RECOVERY_CATALOG_OWNER Role is assigned to the user.

7. We connect to the Catalog database with RMAN.

8. The catalog is created.

9. We connect the primary database to be TARGET.

10. The primary database is REGISTERed to the catalog.

With this operation, it copies the information in the Control File of the RMAN Primary database to the Recovery Catalog tables. Backup information is now in both Control File and Recovery Catalog.

Thus, in case of a problem in Control File, I will be able to access Control File information from Recovery Catalog.

At this stage I do not REGISTER the Physical Standby database. In the future, when using CONFIGURE DB_UNIQUE_NAME parameter, this database will be REGISTER automatically.

11. All databases registered to Recovery Catalog are listed.

12. Tablespaces of primary database are listed.

13. All archive logs in the primary database are listed.

14. All configurable RMAN parameters for the primary database are listed.

15. We are editing the Backup Retention Policy.

16. We determine when archive logs will be deleted.

17. Which service to use is specified in TNSNAMES to connect to the primary database.

When RMAN will RESYNC the Databases in the Catalog, it must be connected to the databases remotely. For this reason, it is necessary to specify which service to connect to these databases.

18. In order to connect to the Physical Standby database, which service will be used is specified in TNSNAMES.

19. We list the databases connected to the catalog.

Although there is no REGISTER operation for the Physical Standby Database, 2 databases appear in the catalog. The reason for this is that as we said before, only the REGISTER operation of the Primary database is mandatory.

Standby Databases are automatically REGISTERed with Configure parameters.

20. We list the Tablespaces of the Physical Standby Database.

21. Connects to the Physical Standby database as TARGET.

22. We list the current RMAN parameters for the Physical database.

23. We edit the Backup optimization parameter.

The way to resolve this error is to either connect to the database where the parameter will be edited as TARGET as specified, or to set the DBID. We set the DBID as follows.

The DBID is learned.

It connects to the catalog.

The DBID is set.

A parameter is set for testing purposes.

The value of the parameter is displayed.

We query whether the parameter has changed in the other database in the Catalog.

Although the DBIDs of the Primary and Physical Standby database are the same, I could not understand why only the Primary was changed.

Loading

About Onur ARDAHANLI

Leave a Reply

Your email address will not be published. Required fields are marked *