All language subtitles for [SubtitleTools.com] Backup And Recovery Concepts - Learning Oracle 12c [Video]

In this lesson, we're
going to be discussing

what is perhaps the most
important task of an Oracle

DBA, and that's
backup and recovery.

No matter what else happens
with your database in terms

of performance problems
or data errors,

if you can't recover the
loss of media, of data files,

table spaces, the loss
of a database, then

you're going to be in
trouble really, really soon.

And this is the kind
of thing that a DBA

must master and really
must practice in order

to get proficient at it.

So when we talk about
backup and recovery,

we're really talking
about the ability

to recover from a media failure.

So what kinds of things
constitute a media failure?

Well, a media failure
would be something

like the loss of a disk drive.

So we have a database
that's on the D drive

and that drive is lost, or it's
on a D drive that's actually

a RAID group of many different
disks and maybe more than one

of those is lost.

So those types of things
constitute a media failure.

Another thing that would be
considered a media failure

would be the loss
of a data file.

So someone goes
out to the database

and actually deletes a
data file accidentally.

Any of those kind
of things would

require the
intervention of the DBA

in the form of a
recovery operation.

So when we talk about
backup and recovery,

it's important to remember
that what saves us

in situations like a media
failure isn't just our backup,

but it's really the entire
Oracle recoverability

architecture.

The idea that Oracle is
built from the ground up

to be recoverable up to the
last committed transaction.

So it rolls into
things like redo

logs that record every change
in the database, things

like archive logs that
can store our reading

logs as they switch.

All of those things go into the
concept of backup and recovery.

When we perform backup and
recovery operations in Oracle,

we use a tool called
Recovery Manager

and RMAN is going to be a
command line tool, for the most

part.

It interfaces with other GUI
tools, like Enterprise Manager.

But for our purposes, we use
it in the command line setting.

It has a number
of benefits to it

and probably most
importantly, RMAN

performs what's called
true block level backups.

So when we think of the
idea of doing a backup,

it might be as simple as
shutting down the database,

copying all the data
files somewhere else.

But if those data files
are all half full,

let's say, then
we've taken longer

to copy those files than
we really needed to.

RMAN is capable, since it's
built into the Oracle engine,

of looking at and reading those
database blocks in the data

files themselves.

Those are what gets read and
written out to backup files.

RMAN is also capable of
ignoring empty data file blocks.

So in tablespaces that maybe are
only a half full or a quarter

full, it's not required of RMAN
to backup those empty blocks.

So that makes our backups
faster and higher performing.

RMAN also supports
compressed backup.

So the ability to compress
our backup on the fly,

further reducing our space
requirements for backups.

And also supports
encrypted backups,

backups that are built with an
encryption key or a password,

something of that
nature in order

to make database
backups more secure.

Another concept in Oracle's
backup and recovery

is something called
the fast recovery area

and that's going to be a
specialized directory structure

for backup related files.

It's defined by two parameters,
db_recovery_file_dest,

the dest being for destination,
and db_recovery_file_dest_size.

So the recovery
file dest is going

to be a directory
that's specified

that will contain all
of the backup files,

archive logs,
flashback logs, any

of the types of files that are
related to backup and recovery.

And Oracle put this in
place because there was too

many instances in the real world
of DBAs who would do backups

but then would kind of lose
track of where everything was.

Because when you do a
recovery, a lot of times

you need everything.

You need to make sure you have
all of the pieces that comprise

the backup, and there were too
many situations where databases

became unrecoverable
because there

wasn't any continuity to how
DBAs stored their backup files.

So this is a really
useful thing to use.

The fast recovery
area was formerly

known as the flash recovery
area in previous versions.

And so to take a look at what a
fast recovery area looks like,

notice that we're in the Oracle
based directory on my machine

and there's a directory
called fast recovery area.

If we click that, we have
the name of the database.

If we have more
than one database,

there'll be a list of them here.

Click that and notice the kind
of files that are stored here.

So we have archive log files
and we have a directory here

that is given the date so we
know exactly where our archive

logs are.

We have a control file
directory that'll store usually

a copy of the control file.

In this case, we
have online logs,

but these are going to be
redo logs here in this case.

So all of the recovery
related files.

Notice that we don't
see here backup related

files because we haven't done
any backups on this machine

yet.

Another concept involved
in backup and recovery,

at least as it pertains to
RMAN, is the repository.

So the repository
is a collection

of information about backups.

So you can do all the
backups that you want

but what unit remembers
all of that information?

What remembers
what was backed up

and where it was written
to and so on and so forth

for the purposes of recovery?

What was the repository
that does that?

And the repository can be
two different entities.

First of all, the control file
keeps this info by default.

So backup and
recovery information

is stored in the control file.

But we could also have it--

for higher stability
and security,

we could have it in a recovery
catalog, which is actually

a separate database that we
would create where we could

connect to that database and
then connect to the database

that we're backing up, and
RMAN would talk to both areas

and the recovery catalog
would keep that information.

So in the event of a complete
loss including the control

file, we would still be able
to recover the database.

And finally, archive log
versus no archive log mode.

So when we're talking
about no archive log mode,

we're talking about that when
changes in the database switch,

they're not written
out to a static file.

So in no archive log mode,
we have the capability

of writing over changes
that have occurred

and that makes us
non-recoverable.

So when we're running
with no archive log mode,

our recovery options
are very, very limited

and that must be stressed.

Really, in no archive log mode,
about the only thing you can do

is restore your backup and
that's as far as you can go.

So if you backup on a Sunday
night and you lose media,

data file, or
whatever on Thursday,

then you lose all the changes
between Sunday and Thursday.

So that's really
important to stress.

However, with
archive log mode, we

don't have that problem
because every change

is stored in static files.

So changes are written
to the redo logs,

and then the redo logs are
written to archive logs.

So the use of archive
log mode allows us

to do things like hot backups.

So backups while
the database is up.

We can do a recovery up until
the very point of failure.

The very last
committed transaction

can be recovered when
we're in archive log mode.

And we can also do things
like time-based recoveries.

So we can recover a database
to the point in the past.

So how do we decide if we're an
archive log mode or no archive

log mode?

Let's go into our
database, Assist DBA,

and we'll execute a command
called archive log list.

So archive log list tells
us that our database log

mode is no archive mode.

Automatic archival is disabled,
and our archive destination,

should we enable archive log, is
a keyword use DB recovery file

desk, which means it is writing
to the fast recovery area.

So our database
is open right now.

How can we put our database
in archive log mode

so we can have the most
recoverability options?

Well, in order to enable archive
log mode, it's very simple

but we need to be
in the mount state.

So we're going to shut
down our database.

We're going to start
up in mount mode.

So now we're in the mount
state, and we simply

type alter database archive log.

Now we're an archive
log mode so we

need to start up the database,
at least to the open state,

alter database open.

So with our database open, we
can do archive log list again

to check.

Now we are in archive mode with
automatic archival enabled.

We want to make sure of this and
kind of see it for ourselves,

we could do an alter
system switch log file.

So this will switch from
the one redo log to the next

and write out our archive log.

We go back to our
fast recovery area.

We notice there is
a new folder written

for the date and an
archive log written out.

So now we're in archive
log mode and fully

prepared to do backups
and recoveries.