Remote replication between the DB2 database and the Oracle database

I. BACKGROUND

DB2 Federated database is a special form of distributed database management. In federated database Systems, a command request to multiple data sources can be issued through an SQL command. Before replicating between DB2 and DB2 databases, it is first necessary to ensure that a non-DB2 data source can be accessed by DB2 ESE Version 8 federated database. The federated database functionality required for DB2 Replication version 8 can be provided in the existing published DB2 ESE version 8 and DB2 Connect Enterprise Version 8.

SQL replication, also known as "DB2 replication," is one of two types of data replication developed for DB2, which is replicated through SQL. To make a simple mention here, another "Q copy" in DB2 replication is done through Websphere MQ Message Queuing. In the case of SQL replication, the Capture program reads the DB2 recovery log to obtain changes to the specified source table. This program saves changes to the transport table, also known as the Change datasheet (changed data table), and the Apply program reads the changes in parallel and applies to the target transaction, as shown in Figure 1.

Figure 1:sql The structure of replication

WebSphere II Global Information Integration replication, through replication between different databases, effectively utilizes the data resources and provides a good platform for improving efficiency.

Replication between DB2 and non-DB2 databases requires WebSphere II. This paper tries to make the readers have a whole concept of replication between different databases by copying the examples.

Second, the motive

Commercial use of replication for a number of reasons can be summed up as:

• Scatter: Scatter data to various locations;
• Integration: Combining data from other locations;
• Exchange: Bidirectional data exchange with other locations;
• Flexible application: Make some changes or combinations of the methods mentioned above.

The birth of Federated (Federated) database system, using the existing data resources to integrate the data of different commercial database software, has greatly improved the data utilization. A federated database can use an SQL statement to make requests to multiple data sources that are distributed across different locations. Federated database systems can connect local tables to remote data sources, just as data is local, and can improve data source processing by distributing requests to the data source, and you can supplement the SQL limit of the data source by processing partial distribution requests at the Federated server.

Federated databases have two different features from other application servers:

• A federated server can be configured to receive all or part of a request for a data source. The federated server disperses these requests to the data source.
• Like other application servers, a federated server communicates with the DB2 family instance using DRDA communication protocols (such as SNA and TCP/IP). However, unlike other application servers, other protocols are used when communicating with a DB2 family instance.

Figure 2: Setup process for federated database systems

WebSphere II includes two kinds of wrappers (wrapper), a relational wrapper that is responsible for replicating data such as DB2 UDB, Informix, Oracle, Microsoft SQL Server, Sybase, ODBC, OLE DB, and so on. The other is a non relational wrapper, responsible for Flatfile, Excel, XML and other non relational data replication.

The wrapper defines a library that is responsible for communicating the local database to the remote database. The wrapper performs many tasks, such as: it can connect to the data source, and the wrapper applies the standard connection API for the data source. It can also submit requests to the data source. A federated database system can operate a table for a remote federated system. Remote tables are virtual in the local federated database, and client applications can manipulate these virtual tables, but they really exist in the remote database. For each remote virtual database, the federated database is treated as a database client and they respond only to requests from the database client. Therefore, federated databases need to download clients for various remote databases.

The construction of a federated system requires a DB2 instance as a federated server, a database of federated databases, one or more data sources, and customers (users and applications) that can access databases and data sources. If you want to complete replication between remote databases, you also need to apply the DB2 data replication functionality.

IBM DB2 replication (called data propagation on some platforms) is a powerful, flexible tool for replicating DB2 and/or other database vendor data from one location to another. IBM's replication supports data conversion, data connectivity, and filtering data. Data can be moved between different platforms, or data can be dispersed to different locations or aggregated into one place from scattered places. You can exchange data between different systems.