RE: IDS HDR - Performance Penalties ?

Colin, We use HDR in a production environment, and all on HPUX 10.20. Except for a few HDR-specific bugs that we've run into -- it works GREAT! Each of our HDR pairs is set up so that the primary and secondary are several hundred miles apart -- one is in California and the other is here in Arizona. Dunno what the bandwidth is, but I do know that the network load varies quite a bit -- no noticeable impact on performance of the primary due to HDR. Occasionally, our network has brief bouts of "hiccups", and a primary / secondary loses connection with the other. Usually, these periods of not being connected last from a few seconds to a few minutes. When the connection is re-established, the two servers sync up automatically -- no manual intervention needed! I mentioned above that we've run into a few HDR-specific bugs. The one that has probably caused the biggest headaches is: Defect 102951 is described as: [HDR: ENGINE DOES NOT DESTROY A SESSION WHICH WAS RUNNING DR_PRPING ] [THREADAFTER DR OUTAGE ] Current impact is 16k of memory for each stray thread. Defect fix incorporated into 7.24.UC8 and 7.30.UC8 and scheduled to be fixed in 7.31.UC3 also. Can't really comment on the automatic failover feature -- we don't use it. The reason is the fact I mentioned above that our network from time to time has brief little hiccups. The primary and secondary will lose contact for a brief time (might be a few seconds to several minutes), and then they will suddenly regain contact and automatically re-synchronize. If we used automatic failover, there would be times when we would be flipping back and forth between primary/secondary servers unnecessarily. We *have* manually switched several times now (we have the 24x7x365 requirement). Basically, to switch primary from box A to box B: we disconnect the application from A, I run a few onmode commands to make sure that all of the data has been replicated over to B, I take down the DBMS on A, switch B to standard mode, and then have the application connect to B. This all takes about 5 minutes max. Then, while the application is running on B, I do the level-0 on B, ftp it over to A, do the ontape -p on A, and then do the onmode -d commands on A and B to establish replication from B to A. We use the same procedure when we are ready to switch back. This process works well -- the biggest drawback is the time to do the level-0 archive, ftp it over to the other box, and then do the physical restore over on that other box. The only other comment I'd make is that we have *looked* at and played with Enterprise Replication (aka, ER or CDR) to possibly replace HDR. MY opinion (not necessarily that of my employer, yadda, yadda, yadda...) is that ER is extremely complex to administer, and is still not a "mature" product on which to rely for disaster recovery. However, I have *heard* that a lot of problems with ER have been fixed in 7.31, which I have not yet had a chance to play with. (Here's another one for ya, Ed Y. :-) HTH ================================ Paul A. Mosser, Open Systems DBA Informix Certified DBSA Wells Fargo & Co. Tempe, Arizona paul.mosser@wellsfargo.com ================================ -----Original Message----- From: Colin Taberman [mailto:ctaberma@lhr-sys.DHL.COM] Sent: Tuesday, July 06, 1999 2:21 AM To: Informix User Group Cc: Colin Taberman Subject: IDS HDR - Performance Penalties ? I would be interested to hear of any experiences using Informix DS High Availability Data Replication in a production environment. Particularly on HPUX 10.20, but not specifically. The main areas I am investigating is the impact upon the Primary server should the line between the two instances be of low bandwidth i.e. 64K over long distance. What are the noticeable impacts upon the primary server in general, is the management of synchronisation during breaks between the servers an overhead, can this be automated to any degree. Any experiences, with potential pitfalls would be interesting to me. Thanks in Advance, Rgds, Colin --