Browse Prior Art Database

Dynamic policy based latency management in relational database replication system for differentiated quality of service (QoS) Disclosure Number: IPCOM000169390D
Original Publication Date: 2008-Apr-14
Included in the Prior Art Database: 2008-Apr-14

Publishing Venue



This article proposes a method and apparatus for database transaction replication solutions to offer differentiated quality of service in terms of replication performance i.e. transaction latency & throughput. Herein, replication is used as a stateful IT infrastructure service by various business applications, aligning itself with todays 'differentiated service' oriented business model. It provides a more flexible way of grouping the replication transactions into multiple service classes using rule or policy based classification mechanism e.g. you can write a policy condition which can identify a set of transactions to monitor for replication performance. Scheme allows run-time classification of transactions as opposed to static service class definitions so that applications can dynamically change the service class organization (through policies) without any reconfiguration of underlying replication service infrastructure.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 12% of the total text.

Page 1 of 10

Dynamic policy based latency management in relational database replication system for differentiated quality of service (QoS)

Today, most of the commercial applications store their data in relational database management systems and use the process of database replication to improve upon the application performance, scalability and availability. For example, some typical use cases for database replication are:
replicate the data from operational data store to data warehouse to off-load the data analytics and reporting process.
replicate the data for balancing the query workload among set of database replicas to improve the scalability.
replicate the data to update the front-end database cache from a set of back-end databases to improve the application performance.
replicate the data to improve the application availability where data from master database is replicated to standby server to be used during fail-over etc.

Depending on application requirements on the target database (replica) such as transactional integrity, resource impact, accessibility of the target data etc., different technologies are used in replicating database data. For example:

Synchronous or Zero latency replication where source changes are replicated and applied to target database in the commit scope of source transaction versus asynchronous replication where changes are captured and propagated asynchronous to source database updates.

Snapshot replication where whole or subset of data in a database table is periodically copied to replica table as a point in time copy versus incremental replication where only changes to data source are propagated to the replica either periodically or when they happen.

Push vs. Pull mechanism where data changes to be delivered are either pushed by the source to target replicas or staged in between for target replicas to pull on demand.

Although these various techniques are available in practice, most of the commercial replication products support transaction replication where incremental updates to source database in terms of database transactions (associated with table(s) being replicated) are captured and propagated to target database. Transactions are typically applied in the same order/sequence as they appear on the source unless there is no dependency between them.

This article illustrates the idea of dynamic, policy based management of replication latency for differentiated quality of service (QoS), especially in the context of IBM WS II Q-Replication product which is an incremental, asynchronous transaction replication solution providing high throughput & low latency solution for various commercial databases. Latency is a key performance attribute of a database replication process which indicates an average time that target replica is behind the source database in terms of database updates. It is calculat...