Re: Informix Remote Mirror Disk

Jim Gordon <jgordon@ssf-sys.DHL.COM> writes: > Bill Williams in X-Informix-List-Id: <list.267> appears to consider > that remote mirroring of data should not be implemented as it will > affect performance of the database. True, but that is not the essence of my argument. I had to sit down and really think this out a bit more thoroughly, given all the responses I had to a quick "shotgun" response to the first message on this subject. My argument against remote mirroring across a LAN as a regular way of doing daily business is from a systems analysis standpoint, not just a performance standpoint. One of the first things I learned in systems analysis and design is that you don't automate things that don't need automating. This rule applies, in a manner of speaking. From a performance standpoint, when you mirror across a LAN, you're doubling (or more) the number of I/Os necessary to get the job done: at least one I/O for each communications activity (probably more like two or three), and one I/O at the remote site for hard disk storage. Why add this layer of I/O activity when you can add local hard drive storage so easily and inexpensively? It makes more sense to mirror to a local - perhaps even removable - hard drive device and/or perform regular backups to tape. This way, you keep performance at an optimum level. Further, if you mirror to a LAN device, you are likely (I'm not sure on this point) to lose the Online engine's capability to use UNIX raw devices as opposed to storage in a cooked file (which is slower). (Granted, you can use RFS for cooked file storage on a remote Unix system, but that is another *entire* bucket of worms.) Additionally, you can't legally keep a copy of the Informix software on two computer systems, unless you bought two copies of the software. If you haven't bought a second copy, you're going to have to have your Informix language system backed up to tape/removable disk, anyway, just in case the system fails. This means you're still going to have to restore from tape or removable disk, just to get the Informix language system available on the new system! So one restore from tape or removable disk is going to be necessary at the outset, and possibly two, if you back up your executables separately from the Informix language system. If you still have to restore your databases and transaction logs from tape, this would be a BFD layer on top of the other restores. Now, if survivability of data - real-time, down to the last transaction occurring a second ago - is the only issue, then certainly you can say "hang the cost - buy me everything I need!" and press on. And that kind of survivability of data I am familiar with, but only from a WAR DEFENSE standpoint, i.e., from a military perspective I can understand the need, but from a *business* perspective, where lives are *not* at stake?? Ahem. (One eyebrow raised at a peculiar angle.) Perhaps some business executives are keen on it (and have megabucks to burn), and perhaps some sales types are begging for it (because they've convinced the executives with the megabucks), but . . . *Sigh.* There are many ways to ensure a _reasonable_ survivability of data, using the Online engine, but they all involve planning and coordination. You can have all the advantages of mirroring across a LAN without the disadvantages of high cost by: having a contingency plan, possibly having a second system set up and ready to take the Informix database files, local mirroring (if possible), regular tape backups (or mirroring to a removable hard drive), and regular log backups (or automatic continuous backup of transaction logs to tape). If you store your tapes (or hard drive packs) "off-site", as most standard theoreticians recommend, you are going to survive even a major disaster with a minimum of difficulty. I believe that this addresses the issues of safety and availability of data. In most instances, you should not have more than a 3 hour delay, if you _haven't_ done your planning and homework. If you have planned out your contingency actions, and you have prepared another system - in advance - to receive the Informix databases and programs, you can cut your recovery time, in most cases, to 30 minutes or less, with a bare minimum of data loss (we're talking 1-30 transactions or so if you're doing continuous transaction backup to tape) in the event of a total system failure. In the event of a *catastrophic* system failure (fire, flood, whatever), you simply restore from your most current off-site tapes and will lose, at most, from the start of that day's business transactions up to the point where you had the meltdown or whatever. I submit that, in the event of such a catastrophic failure, the business executives are going to have *much* bigger concerns than losing a day's work (worst case). As to why I'm against Informix putting time into _developing_ this feature, at the present time -?? My reasons are purely selfish. I want to see Informix get other things taken care of first, without going off on this particular tangent right now. Maybe as a version 5.0 or 5.1 feature, fine, but they've got their hands full with current development and bug repair work. I don't mean _never_ develop this feature, just give it an appropriate priority, given that it will only *really* be needed at less than 5% of existing sites (by my best generous guesstimate). Note that I said "needed", as opposed to "desired". Bill Williams ------------------------------------------------------------------------------ STANDARD DISCLAIMER: Any opinions offered by me are mine alone and in no way reflect the judgment or opinions of the US Air Force, Department of Defense, or United States Government. BUT THEY SHOULD! ------------------------------------------------------------------------------