What is a CATALOG and what is the benefit?
The catalog option at a glance is that the backup repository outside the control file is also in a special schema of another database. What gives us this?
Backup data is also stored outside the control file, so if you lose it, we can restore the backup.
We are able to restore backups in NOMOUNT mode, which would normally not be possible.
We have ready-made scripts and share them between databases.
How to create a CATALOG in theory?
We need to create a user in another database and give it to the CONNECT, RESOURCE role of RECOVERY_CATALOG_OWNER.
Create a special table structure for storing backup data and scripts in this user schema
Register the database, ie add the appropriate entries in the above schema.
Synchronize the control file repository and CATALOG (which happens automatically when registering the database).
In one created CATALOG we can register multiple databases.
And in practice?
Create a user and give it the appropriate permissions
In the first place, in the database in which the CATALOG is to be found, we create the user. We give it three roles:
Here I have a user named rman with rman password. Of course, your user name may be different.
We will need to connect to the database where our CATALOG is located at the RMAN level, so any connection data we need to add to the tnsnames.ora file so that the database name is recognized. My catalog database will be recognized under the name CATALOG.
Next, we need to run RMAN and connect to our database and to the base schema where our additional repository is located, ie to the schema we just created. Note that during the connection we point to which base we connect to for what purpose. By combining with the terms TARGET, we point to RMAN that this database will be backed up, restored, cataloged, or duplicated. In any case, this is our basic base on which we want to perform the action. The database that contains our new repository is linked using the CATALOG clause. This way, when we write a “register database” RMAN will know which database is the base for which we create the directory, and which serves as the repository.
After properly connecting to both databases, we create all the necessary tables in which the backup information will be stored. We make this a “CREATE CATALOG” clause. RMAN knows in which schema these tables are created based on information given to it during the connection. Tables will be created in the schema to which we connect using the CONNECT CATALOG clause. We only do this once in a schema, regardless of how many bases the repository will use. Once created, we can register multiple databases.
The next step is to register the database in the directory. We do this by the REGISTER DATABASE clause. Rman will add entries to the tables in the schema with the database to which we are connected as a target database. If you want to register more databases, disconnect and connect to the next database using CONNECT TARGET and the database. You will no longer need to rebuild the structure with the “CREATE CATALOG” command, but only register the database with the “REGISTER DATABASE” command.
Uncle Good Council: You can also create a catalog from a technical point of view in the database for which you create the directory. From a practical point of view, this is pointless 🙂 Think – if there was a failure of this base and so we could not raise it, then to such a directory we would not connect 🙂 To create such a directory you do not need any commercial Oracle license. You just need a base Express Edition on a computer with Pentium III :). After all, these are just a few tables with entries in the schematic to which we are going to connect over the network. That’s all!
Note that the repository is automatically synchronized during database registration. This means that all backup information is copied from your control file to the schema. You can always resynchronize it when needed (refer to it later) with the “resync catalog” command.
Now let’s take a look at the possibilities of such a directory.
Restoring the database in nomount mode
If we encounter a database failure such that the database does not rise higher than the NOMOUNT mode, we do not have access to the backup information contained in the control file. Of course, we always have an autobackup control file or a unified control file (if we did).
In this case, I perform a database restore in nomount mode. Of course, to be successful, I have to be connected to the target database and directory.
We recover the database we already have in mount mode. After the restore is completed, we go to mount mode and recover.
If for various reasons (network problems, server hardware problems with the directory etc) it was not possible to connect to the database for some time, all activities are connected only to the target database. The backup information will only be in the control file.
When the connection to the directory is again possible, we connect to the target database and to the directory and synchronize the repositories with the “resync catalog” command.
After this operation, the backup information will be copied to the directory that was made without connection to it.
Unregister database from directory
At any time we can opt out of the catalog option and deregister the database. To do this, we connect to the target database and directory, and then execute the “unregister database” command.
Deleting a directory
The directory can also be deleted along with the repositories of all the databases in it.
With a directory, we can also create toolbars. Without a directory the ability to store scripts was limited to saving them in files. With a directory, we can create scripts and store them in it. This means that all scripts are in one place and are accessible from anywhere we are able to connect to the directory.
Scripts can be global or local. Global is available for all databases registered in the local directory, only for one database.
Generally, scripts are created with the command create [global] script. In the above illustration I created a script to recover the tablespace of the victim. The command sequence that I would type individually or in the run block was closed in the script. This is a local script.
I only have one tablespace in one database, so I created a script available only for this database.
Below I create a universal script for playing the whole database. It has no different elements for different bases, so I can use it to generate any base. Note that we have a GLOBAL clause. This makes the script accessible to all registered bases in the directory.
I can also create a script based on the file:
The contents of the file will be read and labeled “incremental”.
To run the script I use the “execute” command. Invoking scripts must always be covered by the “run” block.
On startup, RMAN will look for a local script, even if there are two scripts with that name – local and global. If we wanted to call a global script:
You can also print scripts using the print command. If we had two scripts with the same name (one global and one local) and we would like to run this global, we also use the GLOBAL clause:
We can delete scripts using the delete script command. So far, if we had two scripts (local and global) with the same name, RMAN would by default delete the local one. We can also use the GLOBAL clause: