University Oracle Database Lab: Implementing RMAN Backups for DB101

This lab assignment focuses on Oracle database backup and recovery using the Recovery Manager (RMAN) utility. The objective is to understand and implement different backup strategies for the DB101 database. The lab covers hot backups (inconsistent backups taken while the database is op...Read More

Week Three Lab
For this week we will continue to use DB101 as our target database.
The goal for this week’s lab is begin to understand more fully how BACKUPS run within
RMAN. There a number of different ways that backups can be run and scheduled.
With the advent of the Oracle 12c Multitenant architecture there are additional factors that need
to be considered. If your database includes a CONTAINER database and PLUGGABLE
databases, there are
Backing up an enterprises database so that they are available for a possible database restore and
recovery is at the core of the duties of the DBA. The DBA must ensure that databases are backed
up are regular intervals, and validated so that the DBA knows that with certainty that these
backups can be used to restore the database.
In this lab we will look the various types of backups that can be employed in an overview backup
strategy.
In today’s computing environment applications are frequently required to run in a 24x7 mode.
Consequently, the databases that constitute the backend of these applications cannot be taken
down to backup the database in a consistent manner. This portion of the lab will walk you
through the inconsistent or hot backup.
The RMAN utility allows for the use the many of the commands hat we looked in the previous
lab, to backup the database, archived log and other database structures.
Whenever we log into the Oracle database we need to set our environment so that all of the
Oracle environmental variables are set, so that we can connect to the correct Oracle database. For
the purposes of our labs we will be using using two databases, DB101 (our target database) and
RMANCAT (the database containing the RMAN CATALOG schema)
1. Completing a HOT backup of the database.
2. Once you have logged into the server with the Oracle shell account, set the Oracle
environmental variables and the ORACLE_SID variable to the target database.
3. There is a a file in the Oracle Home directory, /home/oracle, named profile. The content
of this file contains variables such as ORACLE_HOME and PATH. This path needs to be
sourced she the shell has the variables set. This is completed at the OS level.
$ . profile
You can check to see if the environment is set up properly by typing the ENV command.

$ env
The ORACLE_SID is set separately since we have two databases running on this server.
$ export ORACLE_SID=db101
4. Now we need to initialize the RMAN utility and connect to the TARGET and
CATALOG.
$ rman
Recovery Manager: Release 12.1.0.2.0 - Production on Sat Oct 10 16:39:39 2015
Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved.
RMAN>
At this point we have only stared up RMAN. We have no connection to the target
database or the RMAN catalog. Note here that the name of the ORACLE_SID or the
DBID may not match your environment. As long as you have connected properly to your
TARGET database you should be able to run the lab objectives properly.
Now connect to your TARGET database.
RMAN> connect target
connected to target database: SPOCK (DBID=3181554993)
In the previous lab, we looked at important ORACLE files. One of these files was the
TNSNAMES.ORA files. To connect the CATALOG we will be using an alias set in that
file. (10 points)
RMAN> connect catalog rmanowner/R1d3c0l0@rman
5. Now you are connected to RMAN, your target database and the RMAN catalog. We are
now ready to complete many of the tasks require to both backup and maintain our
environment.
While you are still connected to RMAN backup your database. This first backup will be
very straightforward, without any of the options that are available to Oracle. (10 points)
RMAN> backup database;

This command, without any options will backup the database to its default location the
FLASH RECOVERY AREA. Backups can take a significant amount of disk space,
which as a DBA you are responsible for maintaining effectively. One of the ones to
manage the location of the backup sets is to user the FORMAT option.
Using the FORMAT option backup the database again.
RMAN> backup format '/db_backup/db101/bk_%s_%p_%t' database; (10 points)
This FORMAT command will direct RMAN to backup to the new location and
name the Backupsets so the names are more easily read and understood.
This backup is INCONSISTENT, since it is considered a HOT backup, taken
while database is OPEN.
6. As stated earlier, the RMAN utility can be used to backup other database structures, not
simply backing up the entire database. The REDO LOG files are a record of transactions
that occur in the database. If the database is running in ARCHIVELOG mode, it will
save the ARCHIVED LOG FILES to a designated location. If not properly maintained,
the ARCHIVED LOG FILES can build up, taking up disk space and if not backed up and
removed from DISK, Oracle can stop operating, waiting for enough space to archive the
REDO LOGS.
The command to backup the ARCHIVED LOG FILES is similar to the backup command
for the database.
In your environment issue the command to backup the ARCHIVED LOG FILES. (10
points)
RMAN>backup format '/db_backup/db101/arch_%s_%p_%t' archivelog all delete
input;
Notice the difference between this command and the previous database backup
command. The FORMAT command has name the backupset will contain the prefix of
“arch” so the Backupsets can be distinguished from the backupsets of the database. What
has been added to the command is also “all delete input”. This option tells RMAN to
backup the the ARCHIVED LOG FILES and then delete them from disk. These files no
longer need to reside on disk, but are still important to the RECOVERY process.
7. While, in most case, the database will need to be backed up while still operating, there
will be occasions in which the database will be backed up while it is shutdown. This
backup is considered CONSISTENT, since all buffered data has been written to disk.

In this next case we will do a COLD backup of the database, one that is taken after the
database has been shutdown cleanly.
Many of the commands that are run in the SQLPLUS utility, can also be run in RMAN.
These include the SHUTDOWN and STARTUP commands.
In your environment issue the SHUTDOWN command with the IMMEDIATE option.
RMAN> shutdown immediate
Paste your output here:
The database needs to be in the MOUNT state so that RMAN can connect and complete
the backup process.
RMAN> startup mount;
Paste your output here:
Now issue the same backup command issued to complete the HOT backup. (10 points)
RMAN> backup database format '/db_backup/db101/bk_%s_%p_%t' database;
Paste your output here:
Now the database needs to be opened so that it is ready to complete transactions.
RMAN> alter database open; (10 points)
Paste your output here:
8. We have been completing FULL DATABASE BACKUPS. There will be instances in
which the database will need to be backup INCREMENTLY. Meaning that FULL
database backups are take alternatively with INCREMENT backups. A drawback of
INCREMENT backups is that they do not capture any changes that have occurred in the
database since the last backup.
By default, RMAN makes full backups. A full backup of a data file includes every
allocated block in the file being backed up. A full backup of a data file can be an image
copy, in which case every data block is backed up. It can also be stored in a backup set,
in which case data file blocks not in use may be skipped.

RMAN can create multilevel incremental backups. Each incremental level is denoted by
a value of 0 or 1. A level 0 incremental backup, which is the base for subsequent
incremental backups, copies all blocks containing data. The only difference between a
level 0 incremental backup and a full backup is that a full backup is never included in an
incremental strategy. Thus, an incremental level 0 backup is a full backup that happens to
be the parent of incremental backups whose level is greater than 0. Incremental backups
are differential by default.
In order to speed up the INCREMENTAL backup process enable block change tracking:
(10 points)
SQL> select * from v$block_change_tracking;
If block change tracking is not enabled, then:
SQL> alter database enable block change tracking using file <specify a file name here>;>
Put the file with the rest of your data files and name it something like
block_change_tracking.dbf. This feature has little overhead. The block change tracking
file is, on average, 1/30,000 the size of the data blocks to be tracked. You can have a very
large database before worrying about this file taking up much space.
To do the weekly level-0 backup on Sunday, type the following: (10 points)
RMAN> backup incremental level 0 database tag=weekly_level_0;
To do the daily level-1 backup, type the following: (20 points)
RMAN> backup incremental level 0 database tag=weekly_level_1;
Do the daily backup every day besides Sunday if you’re doing a weekly level 0 on
Sunday. If you’re doing a monthly level 0 (for example, on the first of the month), run the
daily level 1 every other day of the month. Basically, if you’re doing a level 0 on a given
day, there’s no need to do a level 1.
A level 0 backup must exist for each data file in the BACKUP command as the base
backup for an incremental strategy. Level 0 backups must not have status
UNAVAILABLE. If no level 0 backup exists, then RMAN makes a level 0 backup
automatically.
Sufficient incremental backups taken since level 0 must exist and be available such that
the incremental backup to be created is usable.

Finally, as we conclude this lab we are going to do some maintenance in our VM environment.
We want to do this so that we fill up our disk with backups. If there is no disk space left over,
then RMAN will throw an error and abort the backup process. We will ALWAYS want to use
RMAN to complete this process. If you remove backups from disk via UNIX command line, you
will need to update your CATALOG Metadata so that we is in the repository records and what is
on disk are the same.
So we will need to do 2 things to complete this process. First we will want to set
REDUNCDANCY level in the RETENTION POLICY to 2. This will allow two FULL backups
on disk.
1. First log into the TARGET and CATALOG in RMAN.
2. Now issue the command SHOW ALL
Now reset the RETENTION POLICY and paste your results. (20 points)
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
Now issue the DELETE command. You can do this interactively or with the
NOPROMPT option. Command these commands and paste your results. (10 points)
RMAN> delete obsolete;
Or
RMAN> delete obsolete noprompt;
Will later look at how this can be run automatically. In most enterprise environments
your will use the Oracle Enterprise Manager to schedule these jobs. You can also run
these in scripted CRONJOBS in a Unix environment.