From oracle-l-bounce@freelists.org Wed Apr 20 12:22:50 2005 Return-Path: Received: from air891.startdedicated.com (root@localhost) by orafaq.com (8.12.10/8.12.10) with ESMTP id j3KHMokh006811 for ; Wed, 20 Apr 2005 12:22:50 -0500 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air891.startdedicated.com (8.12.10/8.12.10) with ESMTP id j3KHMo4Z006806 for ; Wed, 20 Apr 2005 12:22:50 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 41565185BA2; Wed, 20 Apr 2005 11:20:31 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03669-07; Wed, 20 Apr 2005 11:20:31 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 942B4185B72; Wed, 20 Apr 2005 11:20:30 -0500 (EST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ltnLomd9qlNqP4znv5A0PL+OZsmSW+SJDnNMXzyxQ/8vQwgENObEoHLqImF/ig+5Vj//0bw9oF2UfTuP+QzKNnWhJ25UrztA+lj8CY255T+a+eb+pM59DavE5FDD2BHZE5HGgz//6atrgNzCAivU2545xNy0yN7CsP7pFClXGFE= Message-ID: <68b1285505042009186709a8b7@mail.gmail.com> Date: Wed, 20 Apr 2005 18:18:40 +0200 From: Vitalis To: jungwolf Subject: Re: sqlplus shutdown "time-out" Cc: mosicr@rogers.com, JHostetter@decommunications.com, Oracle-L , "Goulet, Dick" In-Reply-To: <10644b9e0504200821559ae601@mail.gmail.com> Mime-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Disposition: inline References: <005c01c5454b$341e9390$54369c18@vv4xpaygpndtkd> <68b1285505042006227529dde8@mail.gmail.com> <10644b9e0504200821559ae601@mail.gmail.com> X-archive-position: 18681 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: vitalisman@gmail.com Precedence: normal Reply-To: vitalisman@gmail.com X-list: oracle-l X-Virus-Scanned: by amavisd-new-20030616-p9 (Debian) at avenirtech.net X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on air891.startdedicated.com X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=ham version=2.63 Hi Steven! Comments in-lined: On 4/20/05, jungwolf wrote: > On 4/20/05, Vitalis wrote: > > Regarding my original script (used with 9i instances on Unix): > > shutdown immediate > > startup > > shutdown immediate > > startup mount > ... > > instance has crashed. I wrote this first shutdown so that it would > > completely close a "half-crashed" instance. Then hopefully the startup > > would proceed without any problem. > > Of course this approach is not suitable for production databases > > (offline backups should be avoided on production databases in the > > first place!) > > > > Question: Is this "half-crashed" instance scenario plausible (with > > regard of PMON, SMON...)? >=20 > Sure, I've seen database processes hanging around after a crash. You > might even be able to "connect", but as soon as you try anything it > shuts the connection. Unfortunately, I've also noticed that a > "shutdown immediate" usually hangs when the database is in this state. Thanks for this piece of information. >=20 > Since this is not production, how about the venerable "shutdown abort; > startup; shutdown immediate" process? Maybe that's a sequence that would work in all situations (crash/no crash). But like Jay I don't feel comfortable doing this (why use "abort" and force a recovery everytime while we could use "immediate" in most cases?) The best (but longer) solution might be to code a script capable of testing the instance status and launch the proper command accordingly... >=20 > Steven >=20 > p.s. > As a side note, why do you say offline backups should be avoided on > PROD DBs? If the downtime window is available, I don't see the > problem (although just because one can doesn't mean one should). > Certain business requirements might even mandate a cold backup > (archival reasons, copies of DB to satellite offices for research, > etc). I agree. My sentence should have read: *regular automated scheduled* offline backups should be avoided on production databases (the day-to-day backup policy should not be made of cold backups.) The main reason (apart from the obvious instance unavailability) is that the backup might fail due to something going awry during the shutdown (for example, a shutdown time-out =3D) Of course I don't have anything against exceptional manual offline backups of production databases. Regards, Jerome -- http://www.freelists.org/webpage/oracle-l