oracle foreign key primary key constraints performance tuning MTS IOT 9i block size backup rman corrupted column drop rename recovery controlfile backup clone architecture database archives export dump dmp duplicate rows extents segments fragmentation hot cold blobs migration tablespace locally managed redo undo new features rollback ora-1555 shrink free space user password link TNS tnsnames.ora listener java shutdown sequence

1. Shutdown Options Administration Tips
Shutdown Options
Databases can be shutdown with one of the following commands:
• shutdown normal
• shutdown transactional (Oracle 7.3 and above only)
• shutdown immediate
• shutdown abort
In Oracle 7 or 8.0, these commands must be issued within the Server Manager utility,
because shutting down a database is a Privileged Action, and Privileged Actions can only be
performed in Server Manager. In 8i, SQL Plus acquired the ability to perform Privileged
Actions, so you can use that tool instead.
Of course, to perform a Privileged Action, you have to be a Privileged User. That means
you must connect as SYS, with the SYSDBA privilege. If you are using O/S authentication,
then "connect / as sysdba" will do the trick. If you are using a password file, then it will
have to be "connect sys/<whatever the password is> as sysdba".
Lots of Oracle 7 Users have got into the habit of doing "connect Internal". Well, get out of
the habit quickly! It works for Oracle 7, 8 and 8i. But it stops working in Oracle 9i. If
you've any sense, you'll start using the 'as sysdba' technique early, so that scripts etc. don't
break when you finally make that move to 9i.
Shutdown Normal is terribly polite: it ring-fences the database (so no new connections are
allowed). But anybody already connected is left alone to do whatever they like. They can
stay in there for days, or weeks -all the while preventing the thing from actually shutting
down. When everyone *does* finally remember to log themselves out, then Oracle flushes
the entire Buffer Cache, issues a checkpoint, and shuts down the database gracefully. No
data whatsoever is lost.
Shutdown Transactional is a bit more forceful. Again, the database is ring-fenced. But any
existing Users are only allowed to finish their *current* transaction (that is, issue a rollback
or commit command). Once they do that, they are forcibly disconected, and (because of
the ring-fence) they cannot re-connect. When all Users have been disconnected in this
way, Oracle flushes the entire Buffer Cache, issues a checkpoint, and shuts down the
database gracefully. No data whatsoever is lost. You still have trouble, though, if you
have Users who forget to issue a rollback or commit command.
Copyright © Howard Rogers 2001 31/10/2001 Page 1 of 2

2. Shutdown Options Administration Tips
Shutdown Immediate starts getting a bit rude. As ever, the database is ring-fenced from
new connections. But existing Users are simply booted off the system, whatever they are
doing. If they are in the middle of a transaction, tough. Their session is nevertheless
terminated, and whatever updates they had managed to perform are rolled back.
Obviously, if they managed to fit in a "commit", that data is safe. All uncommitted
transactions are lost, however. When all uncommitted transactions are rolled back, Oracle
flushes the entire Buffer Cache, issues a checkpoint, and shuts down the database
gracefully. No committed data is lost. Note that the need to rollback pending
transactions means that a shutdown immediate isn't always terribly immediate! I've seen
one take 6 hours to complete because there were that many outstanding transactions
pending at the time.
Shutdown Abort is simply the nuclear option. Oracle simply dismantles the Instance.
There's no nice flush of the Buffer Cache, no nice checkpoint, no time to finish whatever
transaction you were in the middle of. The Instance just disappears, and your connection
with it. It's the equivalent of pulling the plug on the box. Shutdown Aborts therefore take
practically no time to complete (a matter of seconds). However, just as when you *do*
accidentally pull the plug on the box, a subsequent startup can take a long time -because
all those transactions that were pending when the Instance disappeared now have to be
recovered (and rolled back). In other words, a Shutdown Abort requires a subsequent
Instance Recovery -and that can take time (again, I've seen one take 3 hours to complete).
Instance Recoveries mean that all committed data is recovered, but all uncommitted stuff
is lost -so at the end of the day, it's functionally equivalent to a Shutdown Immediate. It
just depends on whether you want the Instance Recovery performed before the shutdown,
or before the subsequent startup.
There's a lot of old nonsense talked about Shutdown Abort being somehow "dangerous";
that, somehow, it renders you liable to data loss. Such talk is complete nonsense.
Provided your online redo logs are OK, Oracle never loses committed data (and would be a
pretty sad product if it did). Nevertheless, there is a glimmer of risk with an Abort
(suppose Junior DBA accidentally deletes your current redo log afterwards?), and it is
anyway considered a bit rude to be pulling the plug on your Users in such a brutal way.
Most DBAs would consider a Shutdown Immediate to be acceptable, and reserve Aborts for
dire emergencies. And that's probably a reasonable decision to make.
Copyright © Howard Rogers 2001 31/10/2001 Page 2 of 2