Shirley, A few words of warning about using database replication to establish a standby database server. We replicated a 100 gig database on beefy NT servers with 9 pairs of mirrored hard drives...fast machines. We used database replication to support having a hot failover NT database server for a few years. It worked, but my liver barely survived the experience for a number of reasons:
1) Database replication adds a great many I/Os (and a little CPU use) to the production database server. The number of database disk I/O's roughly triple as captured changes are written to "mirror" database tables and then read from "mirror" database tables and then deleted from "mirror" database tables (also triples the number of writes to the log drive). Also, if replication falls behind (many updates to the database will cause this) replication causes your log drive to thrash as the replication process will constantly yank the disk heads (so much for the dedicated log drive) back to old log files, crippling your application performance. We had to cease replicating some heavily updated tables, too many updates. 2) When you have a complete database on one platform and empty database on the other, the built in process to obtain initial synchronization of the two databases did not work. The database was too big. We had to play tricks with restoring the production database and "tricking" replication into thinking that it had been replicating the database all along. Kind of tricky. We were on V6, this may be better now. 3) Someone already mentioned that once you fail over you may have to eventually fail over again to get back on the production machine. Then you have to re-establish replication back to the target machine. 4) You may lose data. Replication is not magical. There is a process that reads changes from the source database and applies them to the target database. We were replicating 900+ tables and we were usually lagging 5-10 minutes behind, meaning if the production database server crashed and we failed over, we lost 5-10 minutes of changes. 5) We hit some bugs in replication. We already hit them, called them in and got them fixed for you, but this is an ornate process and more bugs are definitely possible. You may have to refresh the target database because a particular type of update wasn't being replicated for a period of time. Worse yet, you may failover and then discover that a certain type of change wasn't being replicated. 6) Setting up and monitoring database replication is a very manual, time consuming process. We probably spent 10-20 hours a month monitoring, tweaking and tuning the process AFTER it stabilized. 7) The database statistics on the two databases may not be identical. This may lead to poor access paths after failover. We eventually ported the DB2/NT database to DB2/390. We now have no failover (other than 72 hour mainframe DR failover), but the database is sitting on rock solid hardware and rock solid OS. If I were you, I'd re-evaluate whether you really need failover. Are you supporting a lung machine? Does it REALLY matter if the application is down for 4-6 hours? Perhaps a server that you restore the last backup and archived log files onto AFTER the production box fails is the way to go. Management may not be able to wait 4 hours, but they can usually wait 1 hour, 4 times. :-) Kelly Kilhoffer Senior DBA Country Insurance and Financial Services -----Original Message----- From: Shirley Fan [mailto:[EMAIL PROTECTED]] Sent: Monday, December 30, 2002 6:16 PM To: [EMAIL PROTECTED] Subject: [DB2EUG] Failover database Hi all, I have two Win2k servers, each with UDB V7.2 Enterprise installed. One will be used as a backup server. I like to set up a standby database to be a replica of a primary database and is maintained by applying archived redo logs from the primary database to the standby in order to keep them synchronized. When the system crashes, I need to failover to the standby database. Since I haven't done this before, I would appreciate if someone could give me some guidance on how I could approach this situation. Can I use the standard UDB replication tools to set up this standby database or do I need any other products to achieve this failover feature? Because if the system crashes on the primary server, it is impossible to apply the archived redo log to the target server. What is the different between standby database and database replication ? If I want to replicate the whole database from a source to target server, Is there a way to replicate the whole database rather than table by table. It is quite troublesome to setup the replication by table name if I would like to replicate the whole database Creating a Standby Database sounds like what you're wanting to do. A standby database is basically a replica of a primary database and is maintained by applying archived redo logs from the primary database to the standby database in order to keep them synchronized. If the primary database is lost (system crash, data corruption, etc), you can failover to the standby database. In this case, the standby database now becomes the primary database. The only issue I see is that you said you want to be able to switch back to Server 1 after it has been recovered. The way a standby database works is that once it becomes the primary database, it stays the primary database. Basically, once you get your crashed server back up, you'd then make it the standby database and typically wouldn't attempt to "switch back." - ::: When replying to the list, please use 'Reply-All' and make sure ::: a copy goes to the list ([EMAIL PROTECTED]). *** To unsubscribe, send 'unsubscribe' to [EMAIL PROTECTED] *** For more information, check http://www.db2eug.uni.cc
