All language subtitles for [SubtitleTools.com] The Redo Architecture - Learning Oracle 12c [Video]

In this lesson, we want to
examine the redo architecture

of the Oracle database system.

Any true RDBMS must be
designed with recovery in mind.

So there are many
types of failures

that can occur in an
Oracle database that

require some kind of recovery.

For instance, if we have a
database server and the disk

in that server fails--

let's say one of the disks--

10 disks, one of
them fails, that disk

was holding database data--

then a recovery is
required in some way.

And an RDBMS must be able to
perform incomplete recovery as

well as complete recovery.

So if we were to define
complete recovery,

that means the recovery
of all the changes

and data in the database up
until the point of failure--

so right before the
failure occurred,

that's our level of
recovery-- complete recovery.

So you might ask,
well, why do we need

to do an incomplete recovery?

Well, the truth is that
an incomplete recovery

is almost as common as
a complete recovery is.

An incomplete
recovery occurs when

we need to recover the
database to a point

that it was in the past.

So you might wonder, why
would we need to do this?

Let's say that a
developer accidentally

drops a production table--

an essential production table
that we cannot be without--

but doesn't tell us until about
six hours after the act occurs.

Changes occur in the database
after the table was dropped,

but the table itself
has to be recovered.

So if we do a complete
recovery, that

means we'll restore the backup
and do a complete recovery

of all the changes
in the database

all the way up to
the present time,

but that would actually
restore the statement

that dropped the table.

So it would not gain us anything
to do with complete recovery

in that scenario.

What we would need to do
is an incomplete recovery.

So we would need to
recover the database up

to the point in time
right before the drop

of the production
table occurred,

and then open the database.

We would lose the changes
that occurred after,

and that's something
that has to be decided

on-- whether the table itself
is more important than the data

that occurred after.

But that's the concept of
an incomplete recovery.

So both must be done
at times in an RDBMS.

So in Oracle's architecture,
the Log Writer, process or LGWR,

writes changes to the
log buffer in memory

and then to redo logs.

Oracle can operate in two
different modes in terms

of the redo architecture.

The first is NOARCHIVELOG mode.

So let's take a look
at how this works.

Let's say that we have a
database with three redo logs.

And the redo logs,
again, will be

the storage for the changes
that occur in the database.

So the log writer process
writes to the first redo log.

Once that redo log
is full, Oracle

performs what's
called a log switch.

That switches to a log writer
process writing to the next,

or second redo log.

Once that data is written and
the second redo log is full,

another log switch occurs.

Now we're writing to the third.

But what happens when
the third is full?

Oracle performs
another log switch,

and the log writer
process begins

writing to the first
redo log again, actually

overwriting the changes
that were there before.

Now, we may say this is
counterintuitive to the idea

that this is a
recoverable architecture,

and we would be correct.

NOARCHIVELOG mode is not a
recoverability architecture.

We would not be able to
do complete recoveries

with NOARCHIVELOG mode.

However, it is a valid mode.

You can operate a database
at NOARCHIVELOG mode,

and there are situations where
company business requirements

may state that the
database does not

need to be recoverable;
that that's not

an important part
of the requirements.

Things like storage
may be more important.

So NOARCHIVELOG is valid,
although Oracle does not

recommend that you run
databases in NOARCHIVELOG mode.

And it's worth
understanding that that's

the default for a database
when it's created.

So let's examine
ARCHIVELOG mode,

which is a full
recoverability architecture.

Just as before, the
log writer process

begins writing to
the first redo log.

When a log switch
occurs, log writer

begins writing to
the second redo log.

But at that moment,
the archiver process

writes a copy of
the redo log out

to what's called an
archived log file--

or an offline log,
sometimes referred to.

That'll be a complete and
full copy of the changes that

are in redo log 1.

So now we've switched to here.

Log writer's writing
to the second redo log.

It gets full.

Log switch occurs.

An archiver writes
out arch02.log--

so the second archive log,
which is a copy of redo log 2.

Log writer writes to
the third redo log.

Switch occurs again.

Archiver writes out
the third archive log.

Now, at this point,
we're overwriting

changes in the redo
log, but we're not

concerned about this,
because the changes are all

written in this static file.

And when the log
switch occurs again,

the data that's in
the first redo log

will be written out to the next
archive log in the sequence.

What this gives us,
consequently, is with a backup,

we can apply all of the changes
that are stored in the archive

logs, then all the changes
that are in the redo logs,

and get a full recoverability
architecture of all the changes

that occurred up to
the point of failure.