Re: Use of log files to update other On-Line Servers?

Adam Broun writes:- > - Is it possible to run the logical log from one Informix server against > the data from another server, and expect all the same updates to occur? Yes, but only to replicate the other server. You cannot use multiple tapes from different servers and combine them into a single server. Even if the system would let you try, which it won't, it would run into major integrity problems. > - Is it possible to take a log file, and separate it into smaller files, > each one of which could be run against a different server? Not an Informix Log file. > - or do I have to write a whole set of custom transaction logging > routines to do this? Probably. You could use tblog to work out what the transaction log says and then recreate the transactions using a single program that would handle the integrity issues. Probably be easier to generate your own logs as you know the transactions you need to handle. > - or is there another way? We don't want to use anything that involves a > 2-phase commit over the network, since there are very stringent > performance requirements for the local on-line systems, and since each > system must be able to operate during the day even if the network or > central server is down. I'm not sure this would be easier, it certainly would require a large admin effort and disk space. It would be possible, using the logs, to replicate each remote server as seperate Informix Online servers on the central box. Reporting could then be done, using I-star and a central synoynmed database, across all these Informix servers on the central machine. Alternatively programs could be written to extract the new data from the replicated servers to update a seperate central database. It would avoid the need to impact your remote systems with transaction logging requirements or 2 phase commit protocols. This solution might also be used to provide hot standby to each remote site. This could be very useful, but to do it brings up a number of other issues and problems which must be dealt with. Another possibility is to use a client/server architecture at the remote sites with business transaction messages being used across the client to server interface. If these messages are logged they could be played back against a version of the application server running against the Central Database. > | Adam Broun | Pointy birds. Oh, pointy pointy | Cheers - Jim My opinions are my own. They may vary with time but they remain MINE! ---------------------------------------------------------------------- Name: Jim Gordon Internet: jgordon@ssf-sys.DHL.COM Company: DHL Systems Inc Phone: (415) 375-5222 (Work) Address: 700 Airport Blvd. #300 (415) 775-7762 (Home) Burlingame, CA 94010-1937 Fax: (415) 375-5019 ----------------------------------------------------------------------