Original subtitles

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.