oracle rman recovery catalog - ghdrako/doc_snipets GitHub Wiki

obraz

By default, RMAN stores all backup and recovery operational history in the database’s control file and retains it for seven days. To retain the backup and restore operational information for longer than the default timeframe, you can increase the CONTROL_FILE_RECORD_KEEP_TIME parameter value to a longer period, but no more than 365 days.

SHOW PARAMETER CONTROL_FILE_RECORD_KEEP_TIME
ALTER SYSTEM SET CONTROL_FILE_RECORD_KEEP_TIME=60 SCOPE=BOTH;

RMAN recovery catalog is essentially a copy of the RMAN information retained in the database’s control file, and it stores the metadata of database backup and recovery operations for a much longer period of time.

Another advantage of the recovery catalog is that if you were to lose all copies of your database’s control files, you can still restore and recover the database using the information stored in the catalog, including the control file.
Additionally, you can develop RMAN scripts and store them in the catalog to use with different databases.
Finally, if you are using Oracle Data Guard as your disaster recovery solution and plan to offload your backup processing to run against a corresponding physical standby database, a recovery catalog is required to capture all backup information to enable the primary database to leverage those backups. Required for Data Guard enviroment

select * from rcver;

upgrade catalog;

During the upgrade itself, no targets should be performing a backup to the catalog. Otherwise you may encounter issues caouse need to restore catalog from backup and perform upgrade once again.

You must use a recovery catalog to manage RMAN metadata for all physical databases, both primary and standby databases, in the Data Guard environment. RMAN uses the recovery catalog as the single source of truth for the Data Guard environment.

Steps

Create Tablespace and users

create tablespace recoverytbs;
create user rman identified by oracle temporary_tablespace temp default tasblespace recoverytbs;
grant recovery_catalog_owner to rman;

Connect to recovery catalog

rman catalog rman/oracle@orcpdb

Create the catalog schema

RMAN> create catalog;

rman target / catalog  rman/oracle@orcpdb
RMAN> register database;
RMAN> report schema;
RMAN> show all;

Register database

RMAN registers the physical standby database and also performs a full resynchronization using the standby control file.

RMAN> CONNECT TARGET sbu@dgprod2
RMAN> CONNECT CATALOG rco@catdb
RMAN> REGISTER DATABASE;

% rman TARGET / CATALOG rco@catdb;
STARTUP MOUNT;
REGISTER DATABASE; # database must be Mount or open
REPORT SCHEMA; # verify registration

Virtual Private Catalogs

By default, all of the users of an RMAN recovery catalog have full privileges to read, select, insert, update, and delete any metadata in the catalog.

Each virtual private catalog is owned by a database schema user which is different than the user who owns the recovery catalog.

script register

RMAN> CREATE SCRIPT backup_inc_1 {
2> BACKUP INCREMENTAL LEVEL 1 DATABASE;
3> BACKUP ARCHIVELOG ALL;
4> DELETE NOPROMPT OBSOLETE;
5> }
RMAN> PRINT SCRIPT backup_inc_1;
RUN {
2> EXECUTE SCRIPT backup_inc_1;
3> }

RMAN czasami ma problemy z wydajnością podczas odczytywania i edytowania katalogu odzyskiwania. Zjawisko to objawia się długim czasem oczekiwania na rozpoczęcie tworzenia kopii zapasowej. Przyczyną są źle zoptymalizowane instrukcje SQL. Informacje o tym, jak radzić sobie z tymi problemami, można znaleźć w metalinku. Bezpiecznym i szybkim obejściem, jest następujące polecenie na początku skryptu RMAN w wersji 19c

RMAN> SQL "ALTER SESSION SET OPTIMIZER_MODE=RULE";