Re: Replication and Locks
In article <3rjfi3$e5u@ixnews3.ix.netcom.com> fcasas@ix.netcom.com (Francisco Casas) writes: >From: fcasas@ix.netcom.com (Francisco Casas) >Subject: Re: Replication and Locks >Date: 13 Jun 1995 07:42:59 GMT >With Sybase Replication Server there are no locks aquired. The Sybase >Replication Server reads the transaction log with a process called the >Log Transaction Manager (LTM). The LTM then sends the "atomic" >transaction to the Replication Server process which then sends it to >the receiving data source (Sybase SQL Server for example). This >approach places very little overhead on the production Sybase SQL >Server, if any, since it is not competing with users for locks by only >referencing commited data. The flaw in the log approach is that if the process fails, machine failure etc, then the state of the replicated transaction is unknown. Oracle's approach, while incurring more processing overhead, uses a true two-phase commit to replicate the transaction and to record that the transaction was successfully replicated. If a failure occurs the transaction is rolled back and the data remains consistent, ie the destination data has not been replicated and the source of the data knows this. There is no additional locking overhead in this approach. >There are a number of uses for replication, here one use (I'd like to >give you more but it's about 12:45AM): >In a distributed environment a customer may have, let's say, 20 nodes. >The customer may decide to have the local data stored on each of the >nodes then rolling it up to a central node in near real-time (a few >seconds of letancy may happen depending on your network). The central >node may then decide whether the other 19 nodes may be updated with the >replicated data. >By the way, Sybase Replication Server was written specifically for Wall >Street customes, where Sybase is the standard in over 90% of the >companies. If it is robust enough for Wall Street it's gotta be robust >enough for you. >If you need more information I encourage you to contact your local >Sybase office and ask for the various Sybase Replication Server white >papers. >Francisco >In <3qlnll$pfa@lantana.singnet.com.sg> sookee@merlion.singnet.com.sg >(Tan Kah Hong) writes: >> >>Can anybody post information on replication servers? What is >>the exact purpose of these servers: Is it for performance, or >>for recovery incase of a crash? >>In our current project we plan to use replication servers for >>performance ie. Data will be accessed simultaneously from these >>servers when a request comes. My question is whether there will >>be a window of inconsistency in the data between the primary >>database and replicate database. I heard about something called >>a lock propogation from primary to replicate servers. Is this >>possible in any of the current databases? >> >>Please reply to these questions to this e-mail id or >>jijo%istc206a04%st@singtel.com >> >>Regards, >>Joe >> >>(Work) (Singapore - 65) 462-3575 >>(Home) (Singapore - 65) 365-8094 >>(Fax ) (Singapore - 65) 467-9106