Re: Upgrade Procedures

In article <5gno3g$laf@cssun.mathcs.emory.edu>, Jonathan Leffler <johnl@informix.com> writes >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... > Forgot to mention - we ALWAYS have a demo system for testing application upgrades. Also it is always on the same machine (as clients rarely have a spare machine) also allows us to be sure that live will run on the same release of the O/S as demo. >> 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. > True. >> 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. > Agreed - I assume that any problems found in step 5 would be resolved as part of step 5. >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 ol >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. > I had assumed overnight backups would cover it. >Then, with luck, you just h