There are two significant changes in Oracle Database 11g in the way you manage the RMAN recovery catalog:
The following sections show how to merge recovery catalogs as well as introduce the new virtual private catalog feature.
Merging Recovery Catalogs
It’s common for DBAs to create multiple recovery catalogs,each for a different Oracle version,in order to store RMAN data for multiple Oracle databases.In some companies,DBAs even separate development/QA and production recovery catalogs.
The management of the multiple recovery catalogs often gets to be a problem. Oracle Database 11g lets you designate a single catalog schema for all your Oracle databases by using the new import catalog command to import a recovery catalog schema into another recovery catalog schema.
You can merge an entire recovery catalog, or just the meta data pertaining to a specific database or databases,into another recovery catalog.Before Oracle Database 11g, there was no way to combine contents from one recovery catalog to another without having to actually use the export and import utilities to perform a data migration between two recovery catalogs.
To illustrate the recovery catalog merging feature,we’ll use multiple recovery catalogs, one of which will serve as the destination target, meaning the recovery catalog into which you want to merge one or more other recovery catalogs.
In Oracle Database 11g, you can merge recovery catalogs with the new import catalog command.In the following example,the destination recovery catalog schema is located in the recovery catalog database rman11.The list incarnation command shows that there are currently two databases (ELEVEN and ORCL11) registered in this recovery catalog:
There is also a Release 10.2 recovery catalog schema called rman10, owned by another user, with one database (TENNER) registered in it, as shown by the following list incarnation command:
Our goal is to merge the Release 10.2 recovery catalog into the Release 11.1 recovery catalog, creating a consolidated recovery catalog schema with all three databases registered in it. Here are the steps to do this:
If you now run the list incarnation command on the source recovery catalog (rman10),you’ll find that the single database that was part of that catalog is no longer registered in it, the metadata about the database having been imported to the rman11 recovery catalog. Here are the results of running the list incarnation command on the source recovery catalog:RMAN> list incarnation;
The reason you don’t see any databases registered in the source database now is because RMAN automatically unregisters all databases from the source recovery catalog once it imports the databases from that catalog into the destination recovery catalog. If you want to retain the data bases in the source catalog and don’t want RMAN to automatically unregister the databases after importing the metadata for those databases, use the no unregister clause with the import catalog command, as shown here:RMAN> import catalog rman1/rman1@rman10 no unregister;
The previous command uses the no unregister clause to direct RMAN to retain the imported database IDs in the source recovery catalog. By default,the imported database IDs are auto matically removed upon their import into the destination recovery catalog.
Importing a catalog into another and merging it with the destination catalog takes place without you having to connect to a target database.You simply need to connect to the source and destination recovery catalogs from the RMAN client.
The import catalog command will import the metadata for all the databases that are currently registered in the source catalog schema into the desti nation catalog schema.If you’d rather import a specific database or a set of databases from the source recovery catalog,you may do so by using a slightly different form of the import catalog command,specifying either the DBID or database name of the database(s) you want to import:
If a database is registered in both the source and destination target recovery catalogs,first un register that database from one of the catalogs before proceeding.You can’t perform an import when a database is simultaneously registered in both the source and destination catalogs.
You can issue the import catalog command only if the source database’s version is identical to the version of the RMAN client you’re using.If the source recovery catalog schema is from a lower version than that of the RMAN client, you must first upgrade the lower version recovery catalog schema using the upgrade catalog command. If the source recovery catalog schema belongs to a higher version, you must perform the import with an RMAN executable of a higher version as well.
Here are some additional points to remember about using the import catalog command:
Moving a Recovery Catalog to Another Database
You can use the import catalog command to move the recovery catalog from one database toanother. Here are the steps to move a recovery catalog to a different database:
The import catalog command imports the source recovery catalog contents into the new recovery catalog.
Virtual Private Catalogs
It’s common to encounter situations where certain users may require access to the recoverycatalog so they can view some metadata,but you are compelled to give them access to the entire recovery catalog.That is, there was no way to give just partial access to the recovery catalog.In Oracle Database 11g,you can restrict access to the recovery catalog by granting access to only a subset of the metadata in the recovery catalog.
The subset that a user has read/write access to is termed a virtual private catalog,or just virtual catalog.The virtual private catalog feature lets you separate responsibilities between individuals in an organization, thus ensuring compliance with a basic security requirement.You can create a virtual private catalog for a specific group of users or for groups of databases.Before this release,any user you granted access to a recovery catalog automatically had access to the entire metadata stored in there.That is,the user could view data from all the databases registered in the recovery catalog.The owner of the centralized base recovery catalog can now create restricted users, limiting the metadata they can access from the base catalog.
The central or source recovery catalog is now also called the base recovery catalog.There is no set limit on the number of virtual private catalogs you can create on a base recovery catalog. A virtual private catalog is nothing but a set of synonyms and views on the base recovery catalog.
The main recovery catalog owner grants privileges to the owner of each virtual catalog,which enables the virtual catalog owner to either connect to a target database or register it themselves(if they are granted the register database privilege).After this point,there is virtually no difference between how you use a virtual private catalog and the centralized base catalog.The sole difference is that a virtual private catalog owner can access only those databases for which they have been given access, while the base catalog owner can access all the registered data bases in the base recovery catalog.
Creating a Virtual Private Catalog
Creating a virtual private catalog involves two steps.First you must create a user who will own the new virtual catalog. Next you must create the virtual private catalog.You then grant the new user restricted access to the base recovery catalog by giving the user read/write access to the user’s own RMAN metadata, which is what a virtual private catalog is.The following example shows you how to create a virtual private catalog:
The grant catalog for database command grants recovery catalog access for the databases test1 and test2 to the user virtual1, who is the new virtual catalog owner you created. Note that instead of the database names, you can use the DBID for a database as well.
The new user virt_user1 owns the virtual catalog created by the previous command. Since the base recovery catalog owner has granted rights (with the grant catalog command)for the two databases, test1 and test2, the user virt_user1 will see only those two databases registered in the new virtual catalog the user has just created.You can confirm that the user virt_user1 can access only the test1 and test2 databases and not all the registered databases in the base recovery catalog by issuing the list incarnation command, as shown next.
However,the base recovery catalog owner can see all databases in the main catalog by issuing the list incarnation command,as shown here:RMAN> list incarnation;List of Database Incarnations
The user virt_user1 can create local RMAN stored scripts within this virtual catalog. However,the user will have only read privileges on any global scripts in the base recovery catalog.The virtual catalog owner virtual1 can use the virtual private catalog to store the metadata for all backups of a database.Here’s an example that shows how to do this:
In the previous example,you connect to the target database first and then connect to the base recovery catalog but specify the virtual1 schema in the connect catalogcommand.This means the backup metadata is stored in the recovery catalog owner virtual1’s schema,that is,in the virtual private catalog.
Managing Virtual Private Catalogs
The grant command lets you grant two important virtual recovery catalog–related privileges—catalog for database and register database. The catalog for database privilege,which you’ve seen earlier, lets you grant recovery catalog access to a specific database that you can denote by either the database name or its DBID.Note that one of the catalog operations granted is the ability to register and unregister the database from the recovery catalog.
The base recovery catalog owner can optionally grant a virtual recovery catalog owner the right to register new target databases in the recovery catalog by specifying the register database clause with the grant command. Here’s an example:RMAN> grant register database to virt_user1;
The register database clause implicitly grants the catalog for database privilege as well.The virtual private catalog owner can register new databases by issuing the register database command. The databases that the virtual private catalog owner thus registers are also registered in the base recovery catalog.
The base recovery catalog owner can always unregister a database that has been registered by a virtual catalog user from the base recovery catalog and thus from the virtual recovery catalog, which is nothing but a subset of the base recovery catalog.Just as the grant command lets the base catalog owner grant various pri vileges to the recovery catalog users,the revoke command makes it possible to take those rights away.
The base recovery catalog owner can revoke a virtual catalog user’s access to a specific database by using the revoke catalog command and specifying the database name after first connecting to the base recovery catalog.You specify the catalog for database clause within the revoke command to remove recovery catalog access to a database from a user,as shown in the following example:
Note the following about the revoke command:
Of course, the previous command revokes all privileges on the virtual private catalog, meaning both the catalog and register privileges that have been granted to the virtual recovery catalog user.The base recovery catalog owner can revoke just the ability to register new databases from a virtual private catalog owner by using the revoke command in the following manner:RMAN> revoke register database from virtual_user1;
When you issue the previous command, the virtual catalog owner can’t register new databases in the recovery catalog.However,the virtual catalog owner will continue to have the catalog privilege for all registered data bases.The catalog privileges include the privilege to register and un register those databases for which the catalog for database privilege was granted.
Dropping a Virtual Private Catalog
Virtual private catalog owners can drop the private recovery catalog they own by issuing the drop catalog command.Here’s an example showing how to drop a virtual private catalog:
All the metadata pertaining to the virtual catalog owner is deleted from the base recovery catalog when you issue the drop catalog command.
Virtual Private Catalogs in Earlier Oracle Database Releases
The drop catalog command shown in the previous section works only if you’re using an Oracle Database 11g or higher RMAN executable.If you’re using an Oracle Database 10g or earlier RMAN executable,you must execute the following command as the virtual recovery catalog owner to drop the virtual catalog:SQL> rman.dbms_rcvcat.drop_virtual_catalog;
In the previous command, rman is the owner of the base recovery catalog. Similarly, if you’re using an Oracle Release 10.2 or earlier of RMAN,you first connect to the base recovery catalog as the virtual catalog owner and execute the create_virtual_catalog procedure shown here:
If all your target databases are from Release 11.1 or newer, you don’t need to perform the procedure shown here. Contrary to what the name of the procedure indicates,the procedure doesn’t create a virtual private catalog.You’ll need to execute the procedure before you can work with a target database that be longs to an older release.
Oracle 11g Related Interview Questions
|Oracle 10g Interview Questions||Oracle 9i Interview Questions|
|Oracle 8i Interview Questions||Informatica Interview Questions|
|PL/SQL Interview Questions||Oracle 11g Interview Questions|
|SQL Interview Questions||Oracle apps Interview Questions|
|Sybase Interview Questions||Oracle Apps ERP Interview Questions|
|Oracle 7.3 Interview Questions||Oracle Access Manager Interview Questions|
|Oracle Application Framework Interview Questions||Oracle Apps DBA Interview Questions|
Oracle 11g Related Practice Tests
|Oracle 10g Practice Tests||Oracle 9i Practice Tests|
|Oracle 8i Practice Tests||Informatica Practice Tests|
|PL/SQL Practice Tests||Oracle 11g Practice Tests|
|SQL Practice Tests||Oracle apps Practice Tests|
|Sybase Practice Tests||Oracle Apps ERP Practice Tests|
|Oracle 7.3 Practice Tests|
Oracle 11g Tutorial
Installing, Upgrading, And Managing Change
Database Diagnosability And Failure Repair
Backup And Recovery
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.