From oracle-l-bounce@freelists.org Fri Apr 1 02:42:37 2005 Return-Path: Received: from air891.startdedicated.com (root@localhost) by orafaq.com (8.12.10/8.12.10) with ESMTP id j318gbfE016530 for ; Fri, 1 Apr 2005 02:42:37 -0600 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 j318gbem016526 for ; Fri, 1 Apr 2005 02:42:37 -0600 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 791A68AF4A; Fri, 1 Apr 2005 02:40:39 -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 00861-08; Fri, 1 Apr 2005 02:40:39 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id E45CF8A683; Fri, 1 Apr 2005 02:40:38 -0500 (EST) Subject: Re: Copying Oracle software between Unix servers From: Carel-Jan Engel To: chris@thedunscombes.f2s.com Cc: davidsharples@gmail.com, "oracle-l@freelists.org" In-Reply-To: <1112339980.424cf60c7fe0b@webmail.christallize.com> References: <4b36877205033105192dc14fe@mail.gmail.com> <1112339980.424cf60c7fe0b@webmail.christallize.com> Content-type: text/plain Organization: DBA!ert Message-Id: <1112341123.3278.13.camel@dbalert199.dbalert.nl> Mime-Version: 1.0 Date: Fri, 01 Apr 2005 09:38:46 +0200 Content-Transfer-Encoding: 8bit X-archive-position: 17959 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: cjpengel.dbalert@xs4all.nl Precedence: normal Reply-To: cjpengel.dbalert@xs4all.nl X-list: oracle-l X-Virus-Scanned: by amavisd-new-20030616-p9 (Debian) at avenirtech.net X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on air891.startdedicated.com X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RISK_FREE autolearn=no version=2.60 X-Spam-Level: At a site I'm working for, (using NIM), we will use response files. We're in the middle of developing scripts and parameter-structures, which will enable us to roll out any install with just one script-call. Important part is that ORACLE_HOME naming is extended: e.g. 9.2.0.6.0.a represents the 9.2.0.6.0 version, first install. Any 'one-off' patch will cause the last position to increase. The install-script knows (by parameters) of pre-requisites. The 9.2.0.6. patchset will only be installed after 9.2.0.1 (or ..4, depending on parameter settings) is installed in the 9.2.0.6.0.a directory. The inventory is isolated, by maintaining an oraInst.loc file per installed version. The response-files have placeholders, substituted for the 'real' values before the script executes the installer. Advantages: - one ORACLE_HOME per version, to the lowest version level. This enables us to host numerous databases on one host, whithout the need to patch them all at once, and even being able to leave some of them unpatched (if it ain't broke, don't fix it) - automated installations of software on new boxes, enabling the SA's to do the full software install. Needless to say that automated installations help to standardize the modus operandi. - Pre-requisite-tests in the script: A software-copy doesn't check whether the right OS-patches have been applied. Our script will do that. - No risk of overwriting already existing software. The script prevents this. - for GC, agent and iAS-installs: all hard-coded servernames, IP-adresses and whatever will be taken care of by the installer There will be some disadvantages as well: - X-server needed for pre-10g installs - find out about the response-files, put the placeholders in there - create and maintain the mother-of-all-install-scripts Best regards, Carel-Jan Engel === If you think education is expensive, try ignorance. (Derek Bok) === On Fri, 2005-04-01 at 09:19, Chris Dunscombe wrote: > Dave, > > I agree. A couple of years back we managed to mess up an 8i installation on dev > server by copying the software (Oracle worked fine but not patching etc. was > possible). The issue related to the inventory and various "pointers" about file > locations etc, can't remember the details (too long ago). > > Anyway I believe that if you're very careful and edit appropriate files (on > Unix) then you can do it safely but it's definately safer to do proper > installs. > > Chris > > > Quoting David Sharples : > > > yes you can really mess up the inventory and then you are unable to patch it > > > > > > On Thu, 31 Mar 2005 08:19:06 -0500, Luc Demanche > > wrote: > > > Hi, > > > > > Do you have some bad stories about that? > > -- > > http://www.freelists.org/webpage/oracle-l > > > > > Chris Dunscombe > > www.christallize.com > -- > http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-l