Local Script is linked with target database and global script is registered in recovery catalog so that every database can use it from catalog. If mention Global, then it stored in recovery catalog. Connect RMAN to target database and recovery catalog -- create a full backup script used default setting of show all command. You are commenting using your WordPress. You are commenting using your Google account.
Global scripts, on the other hand, are not tied up to a specific instance but are available for any instance which is a part of that catalog where this script is stored. That is why they are called global scripts. There is one difference in the making of the global or local scripts and that is the word global while using the create script words. Create a local script first. For making the local script, ensure that the same named script in the local database catalog is not be already present. For the global script, the name must not be used by any of the scripts in the catalog.
To see the contents of the scripts, use the print script command. Now print your script to see what it contains:. When you create a stored script with substitution variables, you must provide example values at create time. Note: A virtual private catalog has read-only access to global scripts. Creating or updating global scripts must be done while connected to the base recovery catalog.
Specifies the name of the script. Quotes must be used around the script name when the name contains either spaces or reserved words.
Associates an explanatory comment with the stored script in the recovery catalog. Specifies commands to include in the stored script.
Also, do not store the catalog database on the same disks as the target database. To illustrate why data separation is advised, assume that you store the catalog for database prod1 in prod1. If prod1 suffers a total media failure, and if the recovery catalog for prod1 is also stored in prod1 , then if you lose the database you also lose the recovery catalog. At this point the only option is to restore an autobackup of the control file for prod1 and use it to restore and recover the database without the benefit of any information stored in the recovery catalog.
Logical backups of the RMAN recovery catalog created with the Data Pump Export utility can be a useful supplement for physical backups. In the event of damage to a recovery catalog database, you can use Data Pump Import to quickly reimport the exported recovery catalog data into another database and rebuild the catalog.
Restoring and recovering the recovery catalog database is much like restoring and recovering any other database with RMAN. You can restore the control file and server parameter file for the recovery catalog database from an autobackup, then restore and perform complete recovery on the rest of the database.
If you are in a situation where you are using multiple recovery catalogs, then you can also use another recovery catalog to record metadata about backups of this recovery catalog database. If recovery of the recovery catalog database through the normal Oracle recovery procedures is not possible, then you must re-create the catalog.
Examples of this worst-case scenario include:. A recovery catalog database that has been backed up, but cannot be recovered because the datafile backups or archived logs are not available. You have the following options for partially re-creating the contents of the missing recovery catalog:. Any metadata from control file records that aged out of the control file is lost.
To minimize the likelihood of this worst-case scenario, your backup strategy should at least include backing up the recovery catalog.
This technique is described in "Backing Up the Recovery Catalog". As explained in "About Stored Scripts" , you can store scripts in the recovery catalog. This section explains how to create and manage stored scripts. Stored scripts can be local or global. A local script is associated with the target database to which RMAN is connected when the script is created, and can only be executed when you are connected to that target database.
A global stored script can be run against any database registered in the recovery catalog, if the RMAN client is connected to the recovery catalog and a target database. Any command that is legal within a RUN command is permitted in the stored script. The following commands are not legal within stored scripts: RUN , , and. When specifying a script name, RMAN permits but generally does not require that you use quotes around the name of a stored script.
If the name begins with a digit or is an RMAN reserved word, however, then you must put quotes around the name to use it as a stored script name. Consider avoiding stored script names that begin with nonalphabetic characters or that are the same as RMAN reserved words. Consider using a naming convention to avoid confusion between global and local stored scripts.
To use commands related to stored scripts, even global scripts, you must be connected to both a recovery catalog and a target database instance. If GLOBAL is not specified, then a local script must not already exist with the same name for the same target database. You can also create a script by reading its contents from a text file. Otherwise, a syntax error is signalled, just as if the commands were entered at the keyboard.
If no errors are displayed, then RMAN successfully created the script and stored in the recovery catalog. If you are replacing a local script, then you must be connected to the target database that you connected to when you created the script. If the script does not already exist, then RMAN creates it. If no local script with this name is found, then RMAN searches for a global script by the same name and executes it if one is found. Your script uses the automatic channels configured at the time you execute the script.
This command requires a RUN block, as shown in the following example:. The preceding command invokes a local script if one is with the name specified. If no local script is found, but there is a global script with the name specified, then RMAN executes the global script. The following example uses substitution variables for the name of the tape set, for a string in the FORMAT specification, and for the name of the restore point.
Connect RMAN to a target database which must be mounted or open and recovery catalog, specifying the initial values for the recovery catalog script.
The following example executes the recovery catalog script named quarterly. Use the LIST For example, run the following command to list the names of all global and local scripts that can be executed for the currently connected target database:. To list the names of all scripts stored in the current recovery catalog, including global scripts and local scripts for all target databases registered in the recovery catalog, use the following form of the command:.
For each script listed, the output indicates which target database the script is defined for or whether a script is global. For example, suppose you enter the following command:. You must connect to a recovery catalog, which contains the stored script, and target database, to which the script will apply, when starting the RMAN client. If local and global stored scripts are defined with the same name, then RMAN always executes the local script.
This section describes various management and maintenance tasks. After you have created a recovery catalog and registered your target databases, you need to maintain this catalog. You must perform this type of maintenance regardless of whether you use RMAN with a recovery catalog. Other types of maintenance, such as upgrading a recovery catalog schema, are specific to use of RMAN with a recovery catalog.
If you use a recovery catalog in a Data Guard environment, then special considerations apply for backups and database files recorded in the catalog. When RMAN performs a resynchronization , it compares the recovery catalog to either the current or backup control file of the target database and updates the catalog with metadata that is missing or changed. Most RMAN commands perform a resynchronization automatically when the target control file is mounted and the catalog is available.
In a Data Guard environment, RMAN can perform a reverse resynchronization to update a database control file with metadata from the catalog. Resynchronization of the recovery catalog ensures that the metadata that RMAN obtains from the control file stays current.
Resynchronizations can be full or partial. In a partial resynchronization , RMAN reads the current control file of the target database to update changed metadata about new backups, new archived redo logs, and so on. RMAN does not resynchronize metadata about the database physical schema. In a full resynchronization , RMAN updates all changed records, including those for the database schema.
RMAN performs a full resynchronization after structural changes to database adding or dropping database files, creating new incarnation, and so on or after changes to the RMAN persistent configuration.
RMAN creates a snapshot control file , which is a temporary backup control file, when it performs a full resynchronization. The database ensures that only one RMAN session accesses a snapshot control file at any point in time. RMAN creates the snapshot control file in an operating system-specific location on the target database host.
You can specify the name and location of the snapshot control file, as explained in "Configuring the Snapshot Control File Location". This snapshot control file ensures that RMAN has a consistent view of the control file. Because the control file is intended for short-term use, it is not registered in the catalog. RMAN records the control file checkpoint in the recovery catalog to indicate the currency of the catalog. In this case RMAN performs both a normal resynchronization, in which metadata flows from the dgprod3 control file to the catalog, and a reverse resynchronization.
In a reverse resynchronization, RMAN uses the persistent configurations in the recovery catalog to update the dgprod3 control file. The following sections describe situations requiring a manual catalog resynchronization. For example, the target database may be in New York while the recovery catalog database is in Japan. You may not want to make daily backups of the target database in CATALOG mode, to avoid depending on the availability of a geographically distant database.
Also assume that you do the following:. Back up the database infrequently for example, hundreds of redo logs are archived between database backups. Generate a high number of log switches every day for example, switches between catalog resynchronizations. In this case, you may want to manually resynchronize the recovery catalog regularly because the recovery catalog is not updated automatically when a redo log switch occurs or when a redo log is archived.
The database stores metadata about redo log switches and archived redo logs only in the control file. You must periodically resynchronize in order to propagate this information into the recovery catalog. How frequently you need to resynchronize the recovery catalog depends on the rate at which the database archives redo logs. The cost of the operation is proportional to the number of records in the control file that have been inserted or changed since the previous resynchronization.
If no records have been inserted or changed, then the cost of resynchronization is very low; if many records have been inserted or changed, then the resynchronization is more time-consuming.
As explained in "Manually Resynchronizing the Recovery Catalog" , you can resynchronize the standby database manually to update the control file of the standby database. Your goal is to ensure that the metadata in the recovery catalog is current. Because the recovery catalog obtains its metadata from the target control file, the currency of the data in the catalog depends on the currency of the data in the control file.
You need to make sure that the backup metadata in the control file is recorded in the catalog before it is overwritten with new records.
Thus, you must ensure that you resynchronize the recovery catalog with the control file records before these records are erased. Otherwise, control file records could be reused before they are propagated to the recovery catalog. An extra week is a safe margin in most circumstances. One problem can arise if the control file becomes too large. The size of the target database control file grows depending on the number of:.
In this case, the database writes a message to the alert log. Oracle Database Administrator's Guide for more detailed information on other aspects of control file management. The following variation resynchronizes the control files for all databases in the Data Guard environment:.
Instead, it updates the catalog metadata for the database whose unique name has been or will be changed. For example, enter the following commands:. The following example changes the database unique name from standby database prodsf1 to prodsf2 :. When a database is unregistered from the recovery catalog, all RMAN repository records in the recovery catalog are lost.
The database can be registered again, but the recovery catalog records for that database are then based on the contents of the control file at the time of reregistration.
Stored scripts, which are not stored in the control file, are also lost. This scenario assumes that you are not using the recovery catalog to store metadata for primary and standby databases.
0コメント