Databases Reference
In-Depth Information
Creating a Global Stored Script
Problem
You want to create a global-stored script that can be called for any target database.
Solution
Stored scripts are stored in the catalog database, and you can call them by name when you want to execute. Here is
the RMAN command segment to create a global script called
gs_arc_disk_bkup
:
RMAN> create global script gs_arc_disk_bkup
2> comment 'Global Script to Backup Arc Logs Delete Input'
3> {
4> allocate channel c1 type disk
5> format 'C:\oraback\%U.rman';
6> backup
7> archivelog
8> all
9> delete input;
10> release channel c1;
11> }
created global script gs_arc_disk_bkup
Note that the syntax to create a global script is the same as a local script with one exception: the presence of the
clause
global
before the
script
keyword.
How It Works
Global scripts are available to more than just the target database to which you were originally connected. After a
global script is created, you can connect to any target database and execute the script. So, a natural question is, when
is a global script beneficial?
A global script, as the name implies, lets you write once and execute anywhere. So, there is the biggest benefit.
You do not need to write scripts for each database, and thus you save on coding and QA costs.
On the other hand, a one-size-fits-all script may not be possible or desirable in all cases. For instance, consider a
full backup script. The parameters, such as
MAXPIECESIZE
and so on, will be different for each database, obviating the
usefulness of a single global script.
So, when are these global scripts really useful? Generic, repetitive, non-database-dependent activities are the
most suitable for global scripts. Common examples are listing or deleting archived logs, cross-checking backups, and
subsequently deleting expired backups.
Not
■
the restrictions that apply to local scripts apply to local ones as well. these restrictions are described in the
“how it Works” section of recipe 9-7.
