Data redundancy in your distributed relational database network

Data redundancy in a distributed relational database also provides different ways for users on the distributed relational database network to access a database on the network.

The considerations a distributed relational database administrator examines to create a data redundancy strategy are more complex than ensuring communications paths are available to the data.

Tables can be replicated across systems in the network, or a snapshot of data can be used to provide data availability. DB2® DataPropagator can provide this capability.

The following figure shows that a copy of the MP000 system distributed relational database can be stored on the KC000 system, and a copy of the KC000 system distributed relational database can be stored on the MP000 system. The client from one region can link to the other server to query or to update a replicated copy of their relational database.

Data Redundancy Example — Figure 1. Data redundancy example

The administrator must decide what is the most efficient, effective strategy to allow distributed relational database processing. Alternative strategies might include these scenarios.

One alternative might be that when MP000 is unavailable, its clients connect to the KC000 system to query a read-only snapshot of the MP000 distributed relational database so service work can be scheduled.

DB2 DataPropagator can provide a read-only copy of the tables to a remote system on a regular basis. For the Spiffy Corporation, this might be at the end or the beginning of each business day. In this example, the MP000 database snapshot provides a 24-hour-old, last-point-in-time picture for dealerships to use for scheduling only. When the MP000 system is back on line, its clients query the MP000 distributed relational database to completely process inventory requests or other work queried on the read-only copy.

Another alternative might be that Spiffy Corporation wants dealership users to be able to update a replicated table at another server when their regional server is unavailable.

For example, a client that normally connects to the MP000 database can connect to a replicated MP000 database on the KC000 system to process work. When the MP000 system is available again, the MP000 relational database can be updated by applying journal entries from activity that originated in its replicated tables at the KC000 location. When these journal entries have been applied to the original MP000 tables, distributed relational database users can access the MP000 as a server again.

Journal management processes on each regional system update all relational databases. The amount of journal management copy activity in this situation should be examined because of potential adverse performance effects on these systems.