Re: Upgrade Procedures

Dale asked a very sensible question, and David gave a good answer, but I was surprised that no-one else joined in (unless I missed it, somehow). David Williams (djw@smooth1.demon.co.uk) writes: >X-Informix-List-Id: <news.35140> > >Dale Forrey (forrey@wsu.edu) writes: >> When a new version of Informix Online is received by your shop what >>is your standard installation procedure? For example, let's assume that you >>currently have Online 7.20 installed on a UNIX box and you receive version >>7.22. Let's also assume that you have ESQL/C and perhaps CLI also installed >>on this machine. Do you install 7.22 as a completely separate instance of >>Online and test it out and then install it again over the top of the >>production 7.20 version? If you run a separate test instance of Online then >>have you also installed separate copies of ESQL/C and so on? Are there any >>dangers in running multiple instances of Online on the same machine? >> I have looked at the Informix Migration Guide and chapter 5 deals >>with some of my questions. I suppose I am looking for practicle suggestions >>from those of you who have spent some time working with these products. >>Thanks for your advice. > > My normal procedure for upgrading Informix is > > Test against demo > ----------------- > 0. Backup everything (UNIX full backup + level 0 archives). Sound advice. Always do this before you do any major changes to the system. > 1 Install new version of Informix in another directory. This is very important too. Ensure that you install all the products that are going to be running in the new INFORMIXDIR. Don't forget the rule of TEN (Tools, Engines, Network) for the install order. In practical terms, that means install ISQL & I4GL before ESQL/C & Informix-CLI, and all of those before OnLine. You do still have the original tapes and licence number information for the ISQL & I4GL products, don't you? (If not, then you'll need to do some selective copying -- I supplied some tools to help with that process earlier this year (Feb 97)). For my work, I create a new sub-directory with the version number identifying the key component (eg: /usr/informix/9.03.UC2 for IUS, /usr/informix/6.04.UC1 for I4GL & ISQL + 6.00.UE1 OnLine & ESQL/C). If I do not have enough space on the /usr file system, then I use a symlink to somewhere where there is enough space. > 2. Check release notes for any kernel parameter changes/known bugs/ > functionality changes. Always important; usually neglected. Note that the system configuration recorded in the release notes may not be sensible for you. For example, the Solaris OnLine ports list the system configuration as: set semsys:seminfo_semmap=64 set semsys:seminfo_semmni=4096 set semsys:seminfo_semmns=4096 set semsys:seminfo_semmnu=4096 set semsys:seminfo_semmsl=100 set semsys:seminfo_semume=64 set shmsys:shminfo_shmmax=268435456 set shmsys:shminfo_shmmin=100 set shmsys:shminfo_shmmni=100 set shmsys:shminfo_shmseg=100 If you don't have 4000-odd users configured, you will probably want to reduce the numbers of semaphores (I use 1024 very happily, and could probably use 256 without problems). Similarly, if you don't want to commit 256 MB of shared memory on you machine, you should reduce shminfo_shmmax (I run with 16 MB on a machine with 48 MB physical memory). > 3 Configure demo instance on Online to use new engine (Change . demo > script to point to new $INFORMIXDIR etc. It is a good idea to make sure things seem to work for you with some sort of demo system. This doesn't need to be as carefully configured as a production system -- it might well use a cooked file, for example. However, sooner or later, you are going to need to change the production databases, and that's the point at which you really need to have your backups made. > 4. Start demo Online engine and allow it to upgrade sysmaster etc. It depends on whether you already have a demo system in existence, or whether you have created a new one. If you have a test or development database in a separate OnLine instance, upgrade it first and get the developers to check that it seems to work... > 4. Run update statistics on demo to update to new index structures > etc + redo optimzer stats (Good time to do update stats whilst > no-one is on it). Also good advice. Bear in mind that you should use more complex strategies than simply 'update statistics' for the ODS (OnLine Dynamic Server, aka Version 6.00 upwards) systems. > 5. Compile + Test applications against new version of Informix. Correct. > Then install again (0-5 above) for live instance. Here I part ways with David. I wouldn't reinstall unless there'd been problems in steps 1-5 above, and I wouldn't be considering moving onto this step (6 or 7, presumably, depending on whether the duplicated step number 4 is fixed) until all was OK in the new INFORMIXDIR. I would, however, carefully copy the sqlhosts and onconfig files from the current live database into the new $INFORMIXDIR. Then I'd examine the onconfig.std file to see whether there are new parameters to worry about. Assuming that I have a big enough window of opportunity for getting the upgrade done (eg a substantial portion of a weekend), I'd then take the old system offline and archive it. I'd then run the new OnMonitor up to check over the parameters (and make sure I've got the environment set correctly, etc). One of the things I'd check is that the configuration won't use more shared memory than I want it to. I always limit the dynamic shared memory on my 7.2x systems, simply because I don't want all the memory to be eaten by OnLine. Your milage will vary on this point. Then I'd bring the system OnLine, making sure I did not reinitialize the disks. And I'd check that everything went OK. If the upgrade was intended to add disks to enable fragmentation, for example, then I'd go about ensuring that the database was physically reorganized as required at this stage. Then I'd run the chosen UPDATE STATISTICS strategy to ensure that things are OK. Then I'd make sure that the system is brought up and down correctly at boot time (or however it is handled -- you may need to adjust your start up scripts), and that any automated processes that are supposed to work with the database system are correct. Then I'd do a backup of the new configuration! All of it. Including the material not in $INFORMIXDIR. Then, with luck, you just have to ensure that your users are all working with the new INFORMIXDIR and the correct database server. Normally, I'd do this by having a standardized symlink (eg /opt/informix) which points to the current INFORMIXDIR for end-users, and I'd retain the same server name across the upgrade. That way, once the symlink is replaced, when the users start their applications again, they are using the new system. If your window of opportunity for the upgrade is smaller, you may have to do the reorganizations, etc, later. You need to allow enough time for recovery if something does go wrong. Using a second machine (instead of a second INFORMIXDIR on one machine) can be on