Oracle Distributed Systems

Controlling Propagation

We can measure the success of a replicated environment by determining how quickly and efficiently DML changes and RPCs are delivered to their destinations. In order to deliver changes to remote sites as quickly as possible, most people succumb to the temptation to propagate changes as frequently as Oracle will allow, which is once per second. In some cases, such an aggressive schedule is warranted, but in most it is not.

Consider the analogy of grocery shopping. Perhaps you maintain a list (or queue) of items that you need to pick up during your next shopping expedition. Do you run to the grocery store every time an item is added to the list, or do you wait until the list is sufficiently long to merit a shopping expedition? Most likely, you wait until the trip is worthwhile.

So it is with propagating DML among master sites. The problem with the one-second propagation strategy is that it generally takes longer than one second to perform a push! Therefore, you may actually end up falling behind if you opt for such a frequent schedule. On the other hand, if you opt for infrequent propagation, the likelihood of conflicts increases. The optimal situation is to schedule pushes in such a way that they deliver a fairly constant number of transactions with each push and the average latency of transactions does not exceed the push interval.

Warning

Scheduled jobs cause updates to data dictionary tables such as SYS.JOB$ every time they run. Therefore, the more frequent ...