Shutdowns

231 views

Published on

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

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
231
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Shutdowns

  1. 1. Shutdown Options Administration TipsShutdown OptionsDatabases can be shutdown with one of the following commands: • shutdown normal • shutdown transactional (Oracle 7.3 and above only) • shutdown immediate • shutdown abortIn 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 beperformed in Server Manager. In 8i, SQL Plus acquired the ability to perform PrivilegedActions, so you can use that tool instead.Of course, to perform a Privileged Action, you have to be a Privileged User. That meansyou 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 willhave 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 ofthe habit quickly! It works for Oracle 7, 8 and 8i. But it stops working in Oracle 9i. Ifyouve any sense, youll start using the as sysdba technique early, so that scripts etc. dontbreak when you finally make that move to 9i.Shutdown Normal is terribly polite: it ring-fences the database (so no new connections areallowed). But anybody already connected is left alone to do whatever they like. They canstay in there for days, or weeks -all the while preventing the thing from actually shuttingdown. When everyone *does* finally remember to log themselves out, then Oracle flushesthe entire Buffer Cache, issues a checkpoint, and shuts down the database gracefully. Nodata whatsoever is lost.Shutdown Transactional is a bit more forceful. Again, the database is ring-fenced. But anyexisting Users are only allowed to finish their *current* transaction (that is, issue a rollbackor commit command). Once they do that, they are forcibly disconected, and (because ofthe ring-fence) they cannot re-connect. When all Users have been disconnected in thisway, Oracle flushes the entire Buffer Cache, issues a checkpoint, and shuts down thedatabase gracefully. No data whatsoever is lost. You still have trouble, though, if youhave Users who forget to issue a rollback or commit command.Copyright © Howard Rogers 2001 31/10/2001 Page 1 of 2
  2. 2. Shutdown Options Administration TipsShutdown Immediate starts getting a bit rude. As ever, the database is ring-fenced fromnew connections. But existing Users are simply booted off the system, whatever they aredoing. If they are in the middle of a transaction, tough. Their session is neverthelessterminated, 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 uncommittedtransactions are lost, however. When all uncommitted transactions are rolled back, Oracleflushes the entire Buffer Cache, issues a checkpoint, and shuts down the databasegracefully. No committed data is lost. Note that the need to rollback pendingtransactions means that a shutdown immediate isnt always terribly immediate! Ive seenone take 6 hours to complete because there were that many outstanding transactionspending at the time.Shutdown Abort is simply the nuclear option. Oracle simply dismantles the Instance.Theres no nice flush of the Buffer Cache, no nice checkpoint, no time to finish whatevertransaction you were in the middle of. The Instance just disappears, and your connectionwith it. Its the equivalent of pulling the plug on the box. Shutdown Aborts therefore takepractically 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 -becauseall those transactions that were pending when the Instance disappeared now have to berecovered (and rolled back). In other words, a Shutdown Abort requires a subsequentInstance Recovery -and that can take time (again, Ive seen one take 3 hours to complete).Instance Recoveries mean that all committed data is recovered, but all uncommitted stuffis lost -so at the end of the day, its functionally equivalent to a Shutdown Immediate. Itjust depends on whether you want the Instance Recovery performed before the shutdown,or before the subsequent startup.Theres 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 apretty 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 isanyway 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 fordire emergencies. And thats probably a reasonable decision to make.Copyright © Howard Rogers 2001 31/10/2001 Page 2 of 2

×