All language subtitles for [SubtitleTools.com] The Instance - Background Memory Processes - Learning Oracle 12c [Video]

In this lesson, we
want to take a look

at the background processes
that run from the Oracle kernel.

So the background
processes are going

to be a part of the Oracle
instance, the instance being

comprised of background
processes and memory caches.

So this is the background
process portion

of the instance.

These align really
with the CPU resource.

So if the three basic
resources of a computer

are CPU, memory, and disk,
the background processes

are utilized by the CPU.

That's where the rubber
meets the road when it comes

to the CPU making Oracle work.

It does it by using these
background processes.

These all run as a part
of the Oracle kernel.

So if you've ever heard of
an operating system kernel,

Oracle has a kernel as well.

It's kind of a core set of
operations that it can do.

When we talk about
background processes,

it's important to
make a distinction

between certain kinds
of operating systems.

There are two basic
types of operating system

for our purposes in
this discussion--

multi-threaded
and multi-process.

And example of a
multi-process operating system

would be something
like Linux or Unix,

where every one of these
background processes

is going to be given a dedicated
operating system process.

So each one of these
processes that we're

going to discuss basically
has its own set of resources

in order to do its job.

And that's a very
efficient way to handle

a server-based operating system.

A multi-threaded operating
system is slightly different.

That's something more
like Windows would be.

Windows runs as a
multi-threaded operating system.

So what that means is when we
start Oracle, it actually runs

through one single executable.

And you can actually
see this on Windows.

It's an oracle.exe.

That's the only
process that's started.

All of these
background processes

run as threads or
portions of the process.

And that is honestly
a less efficient way

to run a server
operating system and can

cause some of the
higher end performance

problems that you can have
on Oracle running on Windows.

So the first process that
we're going to look at

is the main process.

And that's PMON, or
the Process Monitor.

PMON regulates all of
the other processes.

So PMON cleans up processes
like zombie processes

that have been
disconnected irregularly.

So the PMON process is the
single most important process

that must be alive and
running in an Oracle database.

Often DBAs will check to see
if the PMON process is running

when they're trying to
determine whether a database is

up or not.

It's not the only way to do it.

But you do know if at the
operating system level,

you look for PMON, say
in a Linux machine,

and PMON is not
running, you definitely

do not have a database running,
because PMON must be alive.

And so an example of how you
would look at that and Linux

is with a command
like ps, for process.

So its "ps -ef | grep pmon."

And that would allow you
to see the PMON process.

The next process
we look at is SMON,

and that's the System Monitor.

SMON has two primary
responsibilities.

It's responsible for
cleaning up instance recovery

and cleaning up temporary files.

So let's talk about what
instance recovery means.

Let's say for a second that
we have a server that's

running in Oracle Database.

We haven't shut it
down or anything.

It's running along.

Users are connecting
and doing work.

And someone pulls the plug
out of the back of the server.

Well, of course, a
crash is going to occur.

Both the operating system
and Oracle will crash.

So we plug it back in,
restart the server.

The operating system starts.

And then we restart Oracle.

Well, what's happened
in that crash

is that everything in Oracle--

the processes, memory
that's being used--

all of that has come down
in an inconsistent state.

So it can't be used as
it is at that point.

However, the SMON process
comes in during the startup

and initiates what's
called instance recovery.

And SMON will synchronize all
of the different components

in Oracle to get them
back into a stable state.

So instance recovery
is very important.

The most important
thing to remember

about instance
recovery, however,

is that Oracle does
it automatically.

It's not something that
you have to get involved.

It's not like a
database recovery.

That's why it's called
instance recovery, because it's

a different type of recovery.

The second primary
responsibility of SMON

is to clean up temporary files.

Oracle will create
temporary files

at times when it has to write
extra data from memory down

to disk.

So there's not enough
memory to do the operation

that Oracle needs.

And it writes it out to disk.

SMON is responsible for
cleaning that up and keeping

those temporary files as open
with as much free space as

possible.

Next is the Database
Writer process, or DBWn.

And the small n is intentional.

In Oracle, no operations
are done on disk.

It's done in memory instead.

The reason is processing
in memory is faster.

than processing on disk.

So when we look at how
Oracle actually works,

a process will go out to the
disk and read data from disk

and bring it into memory.

And there in memory
is where it'll

be available to other
users who might need it

and the user that initiated
the query to begin with.

So it's the Database Writer
process that does this.

It reads data from
disk into memory

and then eventually
writes it back to disk.

The reason that we call
the Database Writer process

DBWn, or little n, is that
we can have multiple database

writer processes.

There's a lot of work in
reading data from disk

up into memory and back.

And so, consequently,
sometimes it

helps from a
performance perspective

to have multiple Database
Writer processes.

And so if we had
more than one, they

would be named DBW0, DBW1,
and so on and so forth.

Next process is the
Checkpoint Process.

The functionality of
the Checkpoint process

used to be done by the
Database Writer process

in earlier versions of Oracle.

It was later separated out.

So we just mentioned how
Oracle will read data from disk

and put it into memory.

The data that's on the
disk is known as a block.

And the data in memory
is known as a buffer.

So it's almost like Oracle,
the Database Writer process,

actually, that reads
data blocks from disk

and puts them into
buffers that's

the same size as the
block into those buffers.

When a block is written into
a buffer and then changed,

it becomes what's
called a dirty buffer.

So that buffer in memory
needs to be written down

to disk for consistency.

So buffers that have not
been changed are clean.

Those that have been
changed are dirty.

It's the CKPT
process that signals

the writing of the dirty
buffers back down to disk.

When it decides
that needs to occur,

the amount of dirty
buffers in memory

has reached a
certain threshold, it

signals Database Writer, write
all of those dirty buffers

back to disk for
read consistency.

We can have full checkpoints
and incremental checkpoints.

A full checkpoint will
actually write out

all of the dirty buffers.

And that used to be
the way that Oracle

operated all of the time.

Now in newer versions
of Oracle, we

have what's called
incremental checkpoints.

It's a little more
intelligent process

that can decide the
dirty buffers that

need to be written
down to disk the most

importantly, the ones that are
the most important to write.

The reason is a checkpoint
can cause a sort of pause

in the database
while that's being

done for read consistency.

And so it can be more efficient
to do incremental checkpoints.

Another important process is
the Log Writer Process, or LGWR.

The Log Writer process
is crucial in Oracle's

recoverability architecture.

So Oracle is designed
from the ground up

to be able to recover
from disasters,

from the loss of data,
the loss of disk.

But an architecture
has to be in place

that allows that to happen.

So the Log Writer
process is really

key to that, because every
change that occurs in an Oracle

Database, is written out
eventually to files called redo

logs for recovery purposes.

So those changes are
written and recorded

by the Log Writer process.

They're written first to
memory and then later to disk,

as what we call redo logs.

Then those redo logs can
be used during recovery

in order to recover a database.

Next is the Archiver
Process, or the ARCn.

So we just discussed the
recoverability architecture.

The way this actually works
is that as the LGWR process is

writing changes that
eventually go to redo logs,

those redo logs
will be written to

and will eventually become full.

It switches to the next redo
log, and so on and so forth.

But there's a finite
number of redo logs.

So it's possible
that eventually you

can go through all
of the redo logs

and go back to
the first redo log

and begin overwriting
the changes.

Now that would completely
short circuit our ability

to do recovery, because those
changes are being overwritten.

That's a process called
NOARCHIVELOG mode.

So when we are running
a NOARCHIVELOG mode,

we're saying that
recoverability of the database

is not important to us.

We don't want to do the
extra setup involved

in the ARCHIVELOG mode.

In ARCHIVELOG mode, a separate
process, the Archiver Process,

is going to copy the redo
log out to a static file.

So while the redo
logs are dynamic,

and they'll be
written to, switched,

and can be overwritten.

Before that can ever
happen, Archiver Process

will make a copy
of that redo log.

And so now we have a history
of all of the changes

that have occurred.

Even the ones that were
overwritten in the redo logs

were already written
out to ARCHIVELOGs.

And the reason that we
use the ARCn designation

is because the
Archiver Process can

have multiple processes as
well, such as ARC0, ARC1,

and so forth.

This is to allow the
Archiver to write

to multiple destinations,
such as a D drive,

and then also to an E drive,
and then maybe to a tape system

as well, or to off-site storage.

There are a few other
background processes that we

should look at before we close.

These are less important
than the core processes

that we've discussed.

But they become important as
well as new features are added.

The first MMON, which writes
out performance metrics.

So Oracle is capable of
monitoring its own performance

metrics inside the database.

And it has a dedicated process.

MMON, to record
that information.

And that makes that available
to DBAs as well for diagnostics.

The next process is
MMAN, the Memory Manager.

And that will
automatically manage memory

in an Oracle Database.

So we can set up our
memory management

in a lot of different ways
for an Oracle database.

It's very flexible.

We can also choose to just let
Oracle take care of it, decide

what the memory
sizing should be.

And that's what the
MMAN process does.

The last is the LREG process,
for Listener Registration.

This is a new process in 12c
that will register a database

with what's called a listener.

And a listener is
just a process that

is listening for incoming
connections to the database.