Hi, if you update your database software to a newer build or minor release number, you will not modify the database content. But the database restart with the new software will do an inplace migration. So if you once started with the newer version, you cannot go back (without restore).
Note that on a server, where an update is to be installed, x_server must be stopped. Stopping x_server will cut all existing database connections. It is therefore a good idea to do a database shutdown and an x_server stop... Installing the new software version in the same directory will have the advantage, that your database registration still points to the right path. Installation in different pathes is possible, but to get your database instance to run on the new version, you have to use dbmcli command 'db_reg -R new_inst_root' either using old version dbmcli if the version supports (use dbmcli help db_reg to find out), or new version dbmcli (dmmcli called with '-s' option. If '-s' tells dbmcli to execute the command without using a dbmsrv select by the database instance...) If you can manage to switch over to a 'single' server mode (turning off failover software and splitting common directory access on /usr/spool/sql and ../indep_data) you can reduce your downtime by beginning software update on the NON active server without restart (x_server stopped). Then you could shutdown your database manually, switch the servers and restart with the new software version. After that you can install the software update on the other server (x_server stopped) and recombine both servers to a cluster again. CU jrg > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] > Sent: Dienstag, 16. April 2002 11:21 > To: [EMAIL PROTECTED] > Subject: Update of the SAP DB software in a cluster configuration > > > Hi, > > we going to use SAP DB (v7.3.0.18) on a cluster system (HP > L1000). The cluster consists of 2 nodes and a common RAID1 > array (hardware) which can be accessed from both nodes and > which is switched to the active node during operation. Each > node has its own > local harddrives (for OS etc., also RAID1). Our SAP DB setup > is as follows (short discription): > > We installed the SAP DB software on the local disks on both > nodes. The database instance which should run on this > cluster is created on the common RAID array by using the > installtion of the DBMS on the active node. In order to > switch the instance from > one node to the other in case of a failover, one has to > provide this other node with the informations about the > database instance which are holded in the directory branches > of ../indep_data and /var/spool/sql. So we moved these to one > disk of the common > RAID array and set soft links at former locations of these > directory branches. This we did on both nodes. > > Now my question: > How do I have to carry out an update of SAP DB software when > using the configuration discribed above? Do I only have to > process the update on the active node, then switch over to > other node (to be able to access the common RAID array from > the other node) > and process the update a second time? > > Any hints would be helpful. > > Thanks in advance! > Frank Schimmelpfennig > > PHILIPS Semiconductors Hamburg > ATO-Hamburg IT&DataSupport > Tel.: +49 40 5613 -1835, Fax: -3020 > > > _______________________________________________ > sapdb.general mailing list > [EMAIL PROTECTED] > http://listserv.sap.com/mailman/listinfo/sapdb.general > _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
