All language subtitles for 12_02-Instance Shutdown-en

In this lesson, we'll be
talking about instance shutdown,

or in a single
instance database,

it would really be an instance
and a database shutdown.

So when we shutdown the
database, what we're attempting

to do is release all the
resources associated with it,

and making it
unavailable to users.

And that way we can do
certain kinds of maintenance,

such as patching, cold
backups, those types of things.

The differences in the way
we shut down our database

are really based
on how it occurs,

the steps that are
taken leading up

to the final shutdown
of the database.

And we, as the DBA,
have control over that.

So we'll look at each
of the individual ways

to do a shutdown, and the
recommended ones as well.

So the first one is
a shutdown command.

It's also shutdown normal.

So we can type in shutdown
or shutdown normal.

Either one will
accomplish the same task.

When a shutdown normal
occurs, the database

waits for all the sessions that
are connected to gracefully

disconnect, exit programs
that connect to the database,

and then it proceeds with
a shutdown of the database.

Even though this is the default,
if we just type in shutdown,

that doesn't mean it's
the preferred way.

So even though this is
considered the nicest way

to do a shutdown, it's really
impractical in a true sense.

Because in a normal
maintenance situation

where you need to take
down the database,

you can't necessarily
wait for everyone

to get back to their desks
or log-in or whatever,

type in their password,
and then disconnect

from their application that's
connected to the database.

It's also affected by
things like agents,

so enterprise
manager agents that

connect to the database,
any of those kind of things

will prevent you from being
able to shutdown the database.

So even though it is the
most graceful if you will,

in terms of how it deals
with connected sessions,

it's generally not practical
to do a shutdown normal.

The next is shutdown
transactional.

And in a shutdown
transactional, the database

waits for any
uncommitted transactions

to complete and
commit, and then it

will disconnect those users and
those jobs from the database,

and then proceed
with the shutdown.

Shutdown transactional
is probably

a little more practical
than shutdown normal,

but still has some
problems with it,

in that if anyone has a session
that just hasn't done a commit,

that would prevent you from
taking down the database.

So a long running job or a hung
job, something of that nature,

that would completely
prevent you

from being able to take
down the database, at least

as a shutdown transactional.

So from that perspective, it's
not completely practical either

to do a shutdown transactional.

The most common way to
shutdown a database is to type

shut shutdown immediate.

And during a shutdown immediate,
all the connected sessions

are disconnected immediately.

Any transactions that are in
the process are rolled back.

And then those sessions
are disconnected,

and the database
completes its shutdown.

So this is a graceful
shutdown, point

of perspective of the database.

So everything goes down.

It's closed normally.

The instance is
released properly.

The data files are
all checked pointed

and synchronized together.

So typically, the
way we do a shutdown

is a shutdown immediate.

The last type of shutdown we
can do is to shutdown abort.

Now this is not
advisable to do, but it

is something that
happens very frequently

in the life of a DBA.

In a shutdown abort,
what Oracle does

is immediately
disconnect the instance.

So what it actually does
is crash the database

in a pretty similar way as
if we just pulled the power

on the server itself.

Maybe a little more graceful
than that, but not much.

So it disconnects the instance,
and when it shuts down,

it's considered in
an unstable state.

So anytime you do
a shutdown abort,

you want to make sure that
you do a clean startup,

and then a shutdown
immediate to get

both the clean startup
and the clean shutdown

after a shutdown abort.

And I've heard many
stories as a DBA

about people who are DBAs who
did a shutdown abort prior

to doing a database backup.

And the problem with that is
that that backup, the database

that gets backed up, is backed
up in an inconsistent state,

and very likely, you
wouldn't be able to recover

from that backup.

So it's very important that if
you do a shutdown abort, which

does happen on many occasions.

For whatever
reason, the database

may not go down with
a shutdown immediate.

There could be bugs or
problems or hung sessions

or something that prevents
it from doing a shutdown.

Then a shutdown
abort is necessary.

But it's not advisable.

It's a last resort
type of action.

When we deal with
Windows, we must also

remember to shut down
the services that

run in order to truly
release the resources that

are used by Oracle.

So in Windows, every
enterprise type of application,

anything that needs
access to shared

memory and those
kinds of resources,

has to run as a service.

And Oracle is number exception.

So Oracle runs as a
service in Windows.

And so, when we go
into the services,

we'll also need to
shut down the services.

Windows DBAs that work
on Oracle sometimes

will just use the service
to shut down the database.

And depending on how you
have the service shutdown,

it either does a shutdown
immediate or a shutdown abort,

so that's something we
definitely have to be aware of.

So let's take a look
at this process.

I have my command
line interface here.

I'm going to do a SQL plus.

I'm going to connect to sysdba.

That's going to be the role that
has the ability to do start ups

and shut downs.

And then we'll do a
shutdown immediate.

And so, we complete the
shut shutdown immediate.

The database is closed.

Its dismounted, and
then it indicates

that the instance is shutdown.

This means all the
instance resources,

such as the background
processes and memory caches,

are released.

Now this isn't completely
true in Windows,

because Windows will
allocate those resources

from the service perspective.

So I'm going to start
the database back up,

and then we'll look
at a shutdown abort.

All right.

Our database is in open state.

So when we did the shutdown
immediate, it took some time.

It was going through the process
of disconnecting sessions,

checking the data
files for closure,

releasing the instance, all
of those types of things.

So going to do in this
case a shutdown abort.

Even though it
took a little time,

notice that it didn't do the
process of closing the database

and dismounting it.

It simply says
instance shutdown.

So we've released the instance,
basically, in a hard fashion.

So this is not an advisable
way to shut down the database,

unless we absolutely need to.