|
Very well said Edgar, I completely agree, (along with my earlier post), but wanted to also say that a 'shutdown abort' is not 'SAFE' as I see it. In a Unix/Linux environment, when you issue a 'shutdown abort' it immediately releases the shared memory segment and semaphores attached to the SGA at the OS level. This is why a shutdown abort is so fast. This always scares me and I avoid it completely in scripts and scheduled processes. I only issue a 'shutdown abort' if I absolutely had to shut down 'NOW!!', if I could wait, then wait Mike Edgar Chupit wrote: -- //www.freelists.org/webpage/oracle-lDear Jeremiah, First of all, I would like to mention that I don't like to shutdown database without any practical reason (like hardware/OS maintenance/upgrades/etc). And still I would like to argue that under normal circumstances startup force restrict + shutdown immediate (or shutdown abort, startup force, shutdown immediate) will run almost as fast and is as dangerous as a single shutdown immediate. After shutting down abort in order to perform cold backup you still need to startup database and close it in consistent mode. Database startup is not very fast process in it self, because Oracle not only needs to recover database into consistent state (rollback uncommitted transactions), but also allocate memory structures and prepare itself for a normal work. And to shutdown database in consistent state you still need to issue shutdown immediate. One of the popular reasons why shutdown immediate can take a longer time to proceed is because Oracle waits for SNP process to wakeup (Note: 1018421.102), but this can also happened when the shutdown immediate is called second time (after startup force), so even checkpointing and using startup force restrict can cause database to hang in shutdown immediate mode. Also, there is a Note: 46001.1 that suggest to minimize usage of shutdown abort on Windows systems, because it can cause "allocation problems when Oracle is next started.". Note: 161234.1 that describes situation when shutdown abort can hang. Note: 222553.1 that states that startup force can be safer than shutdown abort. And plenty of other notes that describes different problems that can occur during database shutdown. And surely there are many bugs that can occur after shutdown abort (but under normal circumstances shutdown abort is very safe). Saying all this, I would like to return to thread subject and suggest to the original poster to try to convince the management to switch to hot backups, and forget about shutting down the databases because of backup at all. On 2/27/06, Jeremiah Wilton <jeremiah@xxxxxxxxxxx> wrote: |
