Excerpt by Rampant Author Porus
Homi Havewala, author of
Oracle Enterprise Manager Grid Control by Rampant TechPress.
RMAN preinstall Tasks
A separate
Filer volume will be used for the Oracle RMAN backups. As per
corporate database standards, the backup volume must be mounted
as /U99 at the server level. The entry for the backup mount
point should be present in /etc/vfstab, and the mount
point should appear in the list when the df –k (disk free in
Kilobytes) command is executed at the UNIX prompt. If not,
follow the UNIX-level steps as the root UNIX user, to add the
entry in /etc/vfstab, and then mount the volume as /U99. Also
change the ownership via this command:
chown –R
oracle:dba /U99
This is to ensure that the /U99
backup mount point and all subdirectories (as specified by the
–R argument) under this mount point are owned by the Oracle UNIX
user and DBA UNIX group, so that Oracle RMAN is able to create
backup pieces under this mount point.
The Oracle Enterprise
Manager Agent is preinstalled on each database server that is to
be accessed via Oracle Grid Control.
Setup Steps for RMAN
Log in to the Oracle Grid Control console using the FINADM
login. You are able to see only the targets for which your team
is responsible. Move to the Targets tab, click Databases, and
then select the FIN1P database. This now displays the FIN1P
database home page.
The name of the user logged on to
the console is clearly visible in the topmost bar of the browser
as Oracle Enterprise Manager (FINADM) – Database Instance FIN1P.
Select the Maintenance tab. On this tab, under High
Availability, the options visible are Backup/Recovery,
Backup/Recovery Settings, Oracle Secure Backup, and Data Guard.
Select Backup Settings under Backup/Recovery Settings. At this
point, the Oracle Grid Control login FINADM is asked to log in
to the actual database itself.
Log in as a user with DBA
privileges, to set up and schedule the Oracle RMAN backup. It is
not required to log in with SYSDBA or SYSOPER rights unless the
intention is to start up, shut down, perform complete or
incomplete recovery, change the archive log mode, or perform
other such database administrative work. Connect as NORMAL
instead.
Do not check Save as Preferred Credential, because that would
mean the login would be available without a password to any DBA
who has logged on to the console as FINADM.
Note that this
procedure signifies that there are two levels of security in
Oracle Grid Control—the first level to log in to the console and
the second to log in to the database itself.
Backup
Settings is now displayed as three tabs: Device, Backup Set, and
Policy. Under Device, enter 3 as the Parallelism (concurrent
streams to disk drives). This means that three Oracle RMAN
channels will be used to actually create the backup pieces. This
will increase the speed of the backup, depending on the
structure of the disk subsystem.
The Disk Backup
Location is not specified, so it uses the flash recovery area
set up at the database level for the purpose of the backup. In
this case, we presume that the flash recovery area of the
database has been set up as /U99 as per the corporate standard.
The Disk Backup Type has three radio buttons. You can ask for
either a Backup Set, a Compressed Backup Set, or an Image Copy.
Compressed Oracle RMAN backups were first made available in
Oracle Database 10g. Select this option for the most optimal use
of backup space.
To make sure that the host credentials
work correctly, click Test Disk Backup at the upper corner of
the screen. This runs a physical backup test using Oracle RMAN
and verifies that the actual backup can be physically created at
the disk backup location, which is the flash recovery area—/U99
in this case. The backup test runs and, when completed
successfully, displays the message Disk Backup Test Successful!
at the top of the Backup Settings -> Device tab.
Move to
the Backup Set tab. At this point, nothing is to be changed on
this tab, which specifies the maximum backup piece (file) size
and certain tape settings such as copies of datafile and archive
log backups. These settings are kept at the default.
Move
to the Policy tab. This is where the backup policy is specified,
and it is particularly important for the control of Oracle RMAN
backups.
First check the box to Automatically backup the
control file and server parameter file (SPFILE) with every
backup and database structural change.
This is the
control file and SPFILE autobackup. You can specify the location
of the autobackup or default to the flash recovery area /U99.
Checking this option is highly recommended so that the control
file and SPFILE will be automatically backed up along with every
database or archive log backup. This is especially important
because we are using the nocatalog mode of Oracle RMAN, so the
history of our backups is in the control file. This is also
another reason that the binary SPFILE is recommended for every
database instead of the earlier text PFILE, because the SPFILE
can easily be backed up by Oracle RMAN in this way.
Check
Optimize the whole database backup by skipping unchanged files
such as read-only and offline datafiles that have been backed
up.This is known as backup optimization.
Check Enable block
change tracking for faster incremental backups. This is a new
feature inOracle RMAN 10g that keeps track of all changed blocks
in a small file (approximately 11MB) so that incremental backups
do not need to scan the whole database for block changes, as was
the case in Oracle9i Database. This technique results in a much
faster incremental backup, making a compelling reason to upgrade
to the latest versions of the database.
For the block change tracking file, specify the location and
filename as D:\ORADATA\FIN1P\BLKCHGTRCK.DBF. This must be
specified because the database area is not set for the FIN1P
database.
Under Retention Policy, select Retain at least
the specified number of full backups for each datafileand
specify 1 as the number of backups to retain. This means that
the retention policy is based on redundancy instead of a
recovery window.
The redundancy is specified in terms of
the number of backups to keep at any one time. If a new backup
is made, then the previous backup is marked as obsolete and can
be deleted. The recovery window is specified in terms of the
number of days; backups are retained so that recovery is
possible up to this many days in the past. For example, if a
recovery window of 3 days is specified as the Oracle RMAN
retention policy, it means that all backups necessary to recover
up to the last three days’ worth of data will be retained.
Obviously this setting may need to be changed depending on the
size of the database and the free space available in the backup
mount point /U99 at any time. The DBA needs to closely monitor
this space and change the recovery window if necessary.
The settings are actually saved in the control file of the
database. This can be confirmed by logging in to Oracle RMAN at
the command prompt and looking at the configuration settings via
the show all command:
-- Set the Oracle Sid in Windows
C:\>set %ORACLE_SID%=FIN1P
--
Move to the 11g Oracle Home
C:\>cd C:\app\HaviPoriH\product\11.1.0\db_1\bin
-- Start RMAN in the
nocatalog mode connecting to the setOracle Sid
C:\app\HaviPoriH\product\11.1.0\db_1\BIN>
rman target=/nocatalog
RMAN> show all;
RMAN configuration parameters for database
withdb_unique_name FIN1P are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
# default
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK; #
default
CONFIGURE
CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR
DEVICE TYPEDISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO
COMPRESSEDBACKUPSET PARALLELISM 3;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE
TYPE DISK TO 1;# default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR
DEVICE TYPE DISK TO1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; #
default
CONFIGURE
ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; #
default
CONFIGURE
COMPRESSION ALGORITHM 'BZIP2'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO
NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO'C:\APP\HAVIPORIH\PRODUCT\11.1.0\DB_1\DATABASE\SNCFFIN1P.ORA';
# default
It is possible to click Edit RMAN Script
and modify the script before submitting; however, this prevents
a return to the previous screens in this wizard. Nevertheless,
the Oracle RMAN script is modified manually as follows—with some
extra maintenance commands added to cross-check backups and
archive logs and to delete expired backups and archive logs:
set encryption on for all tablespaces
algorithm 'aes256' identified by '%password';
backup device type disk tag '%tag'
database;
backup
device type disk tag '%tag' archivelog all not backed up delete
all input;
allocate channel for maintenance device type disk;
crosscheck backup;
delete noprompt expired backup;
delete noprompt obsolete device type disk;
crosscheck archivelog all;
delete noprompt expired archivelog all;
release channel;
Click Submit Job. Once the job is successfully
submitted, click View Job to see its progress. The job now
appears under the Jobstab of Oracle Grid Control, under Job
Activity, as a Scheduled job.
At this point, it is
possible to click Backup Script -> Show to display the backup
script used. This shows the Oracle RMAN script wrapped in Perl:
$rman_script="set encryption on for all
tablespaces algorithm 'aes256' identified by '%password';
backup device type disk tag '%tag'
database;
backup
device type disk tag '%tag' archivelog all not backed up delete
all input;
allocate channel for maintenance device type disk;
crosscheck backup;
delete noprompt expired backup;
delete noprompt obsolete device type disk;
crosscheck archivelog all;
delete noprompt expired archivelog all;
release channel;
";
&br_save_agent_env();
&br_prebackup($l_db_connect_string, $l_is_cold_backup,
$l_use_rcvcat, $l_db_10_or_higher, $l_backup_strategy, "FALSE");
my $result = &br_backup();
exit($result);
It is
possible, if so desired, to edit the scheduled job and change
the schedule, the credentials, or the access. In the latter
case, different access levels of View orFullcan be allocated to
different Oracle Grid Control administrators. FINADM is seen as
the owner of the job on this page.
The steps for Prebackup and Postbackup appear to have succeeded.
The step for Backup appears to have failed. Click this step, and
the entire Oracle RMAN output is now displayed.
Recovery Manager:
Release 11.1.0.6.0 - Production on SatJun 14 23:29:03 2008
Copyright (c) 1982, 2007, Oracle. All
rights reserved.
RMAN>
connected to target database: FIN1P
(DBID=3660855775)
using target database control file instead of recoverycatalog
RMAN>
echo set on
RMAN> set encryption on
for all tablespaces algorithm'aes256' identified by *;
executing command: SET encryption
RMAN> backup device type
disk tag '%tag' database;
Starting backup at 14-JUN-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=125 device
type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=123 device
type=DISK
allocated channel: ORA_DISK_3
channel ORA_DISK_3: SID=122 device
type=DISK
channel
ORA_DISK_1: starting compressed full datafilebackup set
channel ORA_DISK_1: specifying datafile(s)
in backup set
input datafile file
number=00001name=D:\ORADATA\FIN1P\SYSTEM01.DBF
channel ORA_DISK_1: starting piece 1 at
14-JUN-08
channel
ORA_DISK_2: starting compressed full datafilebackup set
channel ORA_DISK_2: specifying datafile(s)
in backup set
input datafile file
number=00002name=D:\ORADATA\FIN1P\SYSAUX01.DBF
input datafile file
number=00004name=D:\ORADATA\FIN1P\USERS01.DBF
channel ORA_DISK_2: starting piece 1 at
14-JUN-08
channel
ORA_DISK_3: starting compressed full datafilebackup set
channel ORA_DISK_3: specifying datafile(s)
in backup set
input datafile file number=00005name=D:\ORADATA\FIN1P\EXAMPLE01.DBF
input datafile file number=00003name=D:\ORADATA\FIN1P\UNDOTBS01.DBF
channel ORA_DISK_3: starting piece 1 at
14-JUN-08
RMAN-03009: failure of backup command on ORA_DISK_1channel at
06/14/2008 23:29:35
ORA-19914: unable toencrypt backup
ORA-28365: wallet isnot open
continuing other job steps, job failed will
not be re-run
RMAN-03009: failure of backupcommand on ORA_DISK_2 channel at
06/14/2008 23:29:35
ORA-19914: unable toencrypt backup
ORA-28365: wallet isnot open
continuing other job steps, job failed will
not be re-run
RMAN-00571:=================================================
RMAN-00569: ======== ERROR MESSAGE STACK
FOLLOWS ==========
RMAN-00571:=================================================
RMAN-03009: failure of
backupcommand on ORA_DISK_3 channel at 06/14/2008 23:29:37
ORA-19914: unable toencrypt backup
ORA-28365: wallet isnot open
This error has occurred because the Oracle wallet is not open or
has not been created for the database. To create the encryption
wallet for the FIN1P database, the following lines are first
added to the sqlnet.ora file on the database server:
ENCRYPTION_WALLET_LOCATION=
(SOURCE=(METHOD=FILE)(METHOD_DATA=
(DIRECTORY=C:\app\HaviPoriH\product\11.1.0\db_1)))
The listener for the database is then restarted so that
these changes take effect.
To create a new master key and
begin using encrypted RMAN backups as well as Transparent Data
Encryption (TDE) for the data, issue the following command:
ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "";
Click the Retry button on the Job page for the failed job. The
backup job now executes again, and this time it completes
successfully.
The Oracle RMAN output is seen to first set on encryption
using the AES256 algorithm. This is followed by creation of a
compressed full backup set for the database, and a control file
and SPFILE autobackup. After this, the archive logs are backed
up as a compressed archive log backup set, and the archive logs
are then deleted from disk by Oracle RMAN due to the delete
input clause.
Whenever Oracle RMAN wants to perform recovery, it is able to go
to the archive log backup sets and extract the archive log it
requires. This is one of the great benefits of Oracle RMAN. It
contrasts with the manual recovery that DBAs performed in the
past, extracting the archive logs from backup archives (UNIX
tape archives or “tars”) and placing them where the recovery
mechanism of Oracle could find them and use them.
