Original subtitles

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.