Understanding database transaction sequence and latency

Maintain low latency in your replication environment by optimizing the number of subscriptions that you deploy. In some cases, good subscription design involves a trade-off between low latency and applying transactions in strict order.

Several factors can affect transaction sequence and latency:
  • Transactional consistency—Ordinary database processing maintains transactional integrity by applying transactions in the exact order in which they occur. For example, a withdrawal from your bank account might succeed only if the bank first completes your transfer to that account.
  • Latency—Replication processing differs from ordinary database processing in that low latency is also a high priority. In change data capture, you lower latency and maintain relative transactional consistency by deploying more subscriptions. For example, you can redistribute the replication mappings in an existing subscription into multiple subscriptions.

    The trade-off is that, as you increase the amount of parallel processing in your replication environment, you decrease the likelihood of applying transactions to the target database in perfect order.

  • Parallel processing—When you deploy more subscriptions, the target engine increases the resources that it devotes to apply processing. Information management professionals sometimes refer to concurrent apply processing as parallelism, because the target engine applies changes to the target database concurrently.
  • Subscription design—Design your subscriptions to address your business needs for low latency and precise order. For example, precise ordering is unlikely if replication stops for a subscription and a transaction cannot finish processing until you restart the subscription. Because subscriptions maintain independent restart positions, the target engine might apply later transactions before the original transaction can finish.

    Transactions that change databases in more than one subscription can result in splitting a UR into two or more apply transactions that arrive at the target database in unpredictable order. To keep the number of such transactions to a minimum, include all databases that are related to a single business application within one subscription wherever possible. For example, include your Customer data sources in one subscription and your Inventory data sources in another.