Oracle Database Administration for Microsoft SQL Server DBAs part 16 potx

If another database is to have the catalog, the connect
catalog string will have the database as part of the
string: rman/rmanpswdRMANCAT
RMAN> connect catalog rman/rmanpswd
connected to recovery catalog database
RMAN> create catalog
recovery catalog created
RMAN> register database;
database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
RMAN>
After the catalog is created, the databases can be registered with the
catalog. The target database that is connected is the one that is registered
with the catalog. Now the target database is ready for backups.
You can configure RMAN for the default backup type, where the backup
files should be written, the format of the backup file, retention policies,
compression, encryption, and control file autobackup. The tape drivers and
encryption options are part of the Oracle Secure Backup product. Other
vendors provide drivers to write directly to tape and encryption, and Secure
Backup will also integrate directly with RMAN.
Looking at the configuration for RMAN is just like looking at the
parameters in the Oracle database, but from the RMAN command line.
RMAN> show default device type;
RMAN configuration parameters for database with
db_unique_name MMDEV1 are:
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
## Change the default device from disk to tape
RMAN> configure default device type to sbt;
new RMAN configuration parameters:
CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE';

new RMAN configuration parameters are successfully stored
These configuration settings can be part of a script. If they are set in a
script, the script settings will overwrite any defaults that are set up for that
database in RMAN.
132
Oracle Database Administration for Microsoft SQL Server DBAs
Here are some examples of setting the defaults for the backup directory,
file format, type of backup, and retention policy:
example to configure channel to write to disk using
the diskgroup format
RMAN> configure channel device type disk format '+dgroupbkup1';
examples of two different backup types
RMAN> configure device type disk backup type to backupset;
RMAN> configure device type disk backup type to
compressed backupset;
example to configure retention policy
RMAN> configure retention policy to recovery window of 7 days;
RMAN> ## use recovery window or redundancy (but not both)
RMAN> ## configure retention policy to redundancy 3;
In the example, the disk format is configured to be used with ASM and a
disk group that has been set up as a backup disk group. For a regular file
system, the format can also be set as /orabkup/ora_d%_%T.bak, which
will define the backup with the name of the database and a date in the file
system directory.
The example uses the backupset backup type. Another type is copy,
which will do an image copy of the database. The copy backup type is
allowed only for writing the copy to disk; it does not work for tape backups.
When allocating a channel as type disk in a script, these parameters
become part of that allocation. Unless you want to overwrite the defaults,
they do not need to be mentioned each time a backup is run.

For the retention policy, the setting of the recovery window sets the
number of days between the current time and the earliest point of recovery,
which doesn’t matter if there are incremental or full backups in between.
But those backups will be marked obsolete when they hit the number of
days set here. This example sets the window to seven days, which makes
sure that the database can be recovered within the past week. The retention
policy’s redundancy setting indicates the specific number of full backups to
be kept. The example sets redundancy to 3, which will keep three full
backups; it doesn’t matter how many days are in between backups.
The same configurations that were demonstrated here in the command
line can be done through OEM’s Backup Settings. Figure 6-1 shows the
Chapter 6: Database Backup, Restore, and Recovery
133
Device tab, where you set the backup location and type. Figure 6-2 shows
the Policy tab, where you set the retention policies. As you can see in
Figure 6-2, you can set up the retention policies by date or number of
backups to be retained. The Policy tab also includes an area to exclude
tablespaces from whole backups, which is useful for tablespaces that might
be in read-only mode or archived tablespaces that might not need to be
included in every full backup.
134
Oracle Database Administration for Microsoft SQL Server DBAs
FIGURE 6-1.
OEM Backup Settings, Device tab
Backup Options
Table 6-1 shows some common backup types and how to run them in SQL
Server and RMAN.
Your backup strategy should include full and incremental backups. It
should also make sure all of the needed pieces are backed up properly.
For incremental backups, a base backup (full backup) is needed first. The

cumulative database backup option in RMAN backs up all of the changes
since the base, or level 0, backup. The incremental backup backs up the
differences between the incremental backups. The advantage of having a
cumulative backup is that only the last cumulative backup would need to
be restored to recover the database. With incremental backups, all of them
need to be available to restore. Of course, an incremental backup will use
less disk or tape, and it usually takes less time to run.
Chapter 6: Database Backup, Restore, and Recovery
135
FIGURE 6-2.
OEM Backup Settings, Policy tab
In SQL Server, the system databases, as well as master, msdb, and
model, need to be backed up. Similarly, in Oracle, the control files, system
datafiles, and parameter files for the Oracle database need to be backed up.
In SQL Server, the tempdb database is not part of backups; in Oracle, the
temporary tablespace is not included. The undo tablespace does contain
uncommitted changes, but with the newer versions of RMAN, only the
uncommitted changes that haven’t been written out to the datafiles are
backed up.
Full backups will include all of the datafiles in the Oracle database,
including system datafiles, but not the control files. As discussed in Chapter 3,
the control files have information about the changes and archive logs needed
for recovery. Without a current control file, the recovery up to the latest
point could be difficult. You may run backups of the control files outside
136
Oracle Database Administration for Microsoft SQL Server DBAs
Backup Type SQL Server Command Oracle (RMAN) Command
FULL backup database backup database
Files or file
groups

backup database db1
filegroup ='db1file1'
to disk…
backup as
backupset datafile
'/u01/data/
users01.dbf';
Tablespaces backup tablespace
system, users;
Logs (transaction
and archive)
backup log db1 to
disk …
backup archivelog
all;
Incremental
backups/base
backup
Backup database db1
to disk='S:\bkups\
db1.bak' with init
Backup incremental
level 0 database;
Incremental
backups/
differential
backups
Backup database db1
to disk='S:\bkups\
db1.bak' with

differential
Backup incremental
level 1 cumulative
database;
Backup incremental
level 1 database;
TABLE 6-1.
Backup Options in SQL Server and Oracle
the full backup, or after backups of the full or transaction logs, you can
include the control files to make sure the information is captured. Backups
of parameter files might not be as important, but you need to have a copy in
case changes must be reverted.
Backup Examples
Allocating more channels is like using multiple devices and writing in
parallel. For example, if you have a couple of tape drives available, this
would allow you to take full advantage of the multiple drives and speed up
the backup.
> rman target rman/rmanpwdrmancat
RMAN> run {
RMAN> allocate channel disk1 device type disk;
RMAN> allocate channel disk2 device type disk;
RMAN> backup database plus archivelog;
RMAN> backup current controlfile;
RMAN> }
Just as you would run transaction log backups multiple times a day with
SQL Server, with Oracle, the archive logs need to be backed up more than
once a day. The number of transactions and size of disk space available to
hold the logs will determine how often.
> rman target rman/rmanpwdrmancat
RMAN> run {

RMAN> allocate channel disk1 device type disk;
RMAN> allocate channel disk2 device type disk;
RMAN> backup archivelog all delete all input;
RMAN> }
Running archive log backups helps you to avoid filling up the space
allocated to the logs. The preceding example will back up any archive logs
and then delete them from this space, because they are now included in a
backup set. This will keep the file system to a manageable size for archiving.
OEM Backup Jobs
With OEM, you can configure backups and schedule them as jobs in the
database. OEM will generate the RMAN script and display it for your
review. This provides a good way to gain a better understanding of the
backup options and RMAN commands.
Chapter 6: Database Backup, Restore, and Recovery
137
Figure 6-3 shows the options for customizing a backup job in OEM.
If the database is running in NOARCHIVELOG mode, only the full cold
backup is available (as well as any files that might be in the flash/fast
recovery area, as discussed later in this chapter). If it’s in ARCHIVELOG
138
Oracle Database Administration for Microsoft SQL Server DBAs
When You Run Out of Archive Space
If the archive log space fills up, the database will just hang, with the error
“archiver error connect internal until freed.” Knowing the command-
line RMAN commands is important in this situation. Chances are that
the connection through OEM will not be available because of the
limited connections allowed to the database as it is waiting for archive
log backup space to be freed up.
Moving archive logs to another location will free up space to allow
the archive process to continue to run until the files can be backed up

and purged. However, after archive logs are moved or deleted, RMAN
may fail to run the backup because expected files are not there. So,
before you run the backup, you should perform a cross-check to verify
which files are available and what has been backed up. The cross-
check will also resynchronize the catalog with the files that are present
in the backup directory or tape. It will expire the backups in the catalog
that are no longer available.
## validate archive logs are available
RMAN> crosscheck archivelog all;
## validate database backupsets available
RMAN> crosscheck database;
So, you’ve moved archive logs to another location to free up the
space, completed the cross-check, and then run the backup. But there
are still logs in another location that have not been backed up. If there
is now space in the archive log directory, you can move those files
back, perform a cross-check, back them up, and then delete them. If
the archive files are just deleted without being backed up, recovery will
not be possible.
All of this bouncing around of the archive files is to prevent the
database from being put into a hung state, waiting to be able to archive
logs again. A better approach is to plan the available space and make
sure that the archive logs are backed up to prevent filling up the space.
mode, there are more options, including those to back up tablespaces,
datafiles, archive logs, and recovery files.
Next, you set up the schedule for the backup, as shown in Figure 6-4.
As typical for other database jobs, you can run the backup as a one-time job
immediately or later, or make it a repeating job.
The final step, shown in Figure 6-5, shows the RMAN script and provides
an opportunity to edit the script, or even copy it to modify and run outside
the scheduler. Submit the job to save and schedule the backup, or run the

backup if it’s a one-time job.
You can also use OEM to create a restore point, which is useful when
you’re performing a task against the database for data changes, application
upgrades, or even database upgrades. The restore point marks a time to
recover to if the upgrade goes awry. Although you could also get the
information from the logs and database about the last change or current
archive log sequence, having a defined point to roll back to makes the
Chapter 6: Database Backup, Restore, and Recovery
139
FIGURE 6-3.
Customizing a backup job in OEM
140
Oracle Database Administration for Microsoft SQL Server DBAs
FIGURE 6-4.
Scheduling a backup job in OEM
FIGURE 6-5.
Reviewing the RMAN script in OEM
restore process easier. Figure 6-6 shows an example of setting the restore
point in OEM.
Restoring and Recovering Databases
What good are backups if you can’t use them to restore the database? Oracle
provides several ways to restore all or parts of a database. But before we look
at the various restore methods, let’s consider why you might need to use them.
We’ll examine some of the failures and consider ways to recover the database.
I say “recover,” rather than “restore,” because in recovery, the system needs to
go back to where it was, and this might not mean restoring the entire database.
What Can Go Wrong?
Understanding the different ways a database can fail and reasons for a
restore can help in planning a backup strategy. So, what can go wrong?
■

Hardware failures/firmware issues
■
User error
Chapter 6: Database Backup, Restore, and Recovery
141
FIGURE 6-6.
Creating a restore point in OEM