Browse Prior Art Database

Initial full refresh for a PUSH apply

IP.com Disclosure Number: IPCOM000013782D
Original Publication Date: 2002-Jan-01
Included in the Prior Art Database: 2003-Jun-18
Document File: 3 page(s) / 43K

Publishing Venue

IBM

Abstract

The present invention relates to Replication process for DB2 (AIX).

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 3

Initial full refresh for a PUSH apply

The present invention relates to Replication process for DB2 (AIX).

When using apply with PUSH technique, performance problems in the initial full refresh of the target database are frequently experienced. Depending on transmission time, the table sizes and number of tables in the subscription, this initial refresh could be very long and time consuming. This long refreshing time limits the availability of the data in the target. This problem becomes worse when the initial load in the source database is large and there is a need to do it more than one time.

    This is only the initial problem, other problems use to go with this, such as when the format for unload file didn't matched with the target table, the order or name of the column was not the same in the source and in the target, or when any modification in the tables or in the definition of subscription implies a modification in the statements. An additional problem was the amount of log used by the application, making the massive population of the tables in the source.

    All those problems suggested the need for a new method able to generate in a dynamic way all the statements necessary in the process, avoiding any manual modification and thus, making automatic all those tasks.

Advantages of the Invention

    Since the data are inserted (it's not a load utility, it's an application) without data capture, most parts of the process are prepared automatically, and the load in the target is local with load utility, the data are available in the target in a shorter time

    All necessary steps prior to the massive load and for the full refresh with load utility are generated by the tool, so they use the last modifications in the databases and subscriptions. The process is reusable for others subscriptions. The modifications have no impact in the process. This process is integrated in the operating system.

Solution:

      It's based in catalog and replication DB2 tables. Parts of the tool runs some SQL statements reading the information from those tables and building the appropriate commands to make the following tasks:

    Before massive load with the application, to avoid the additional writes in the log, it disables the capture data for the tables in one subscription and prepare the full refresh:

Stop the apply or put disable the subscription; Unload the configuration for Replication...