DB2 Replication, Version 8: Technical Update Briefing for GSE. Neale Armstrong IBM UK Software Group

Transcription

1 DB2 Replication, Version 8: Technical Update Briefing for GSE Neale Armstrong IBM UK Software Group

2 Agenda A Brief History of DB2 Replication Two previous architectural levels Capabilities, Architecture & Limitations Enhancements to DB2 Replication V7 Things that snuck in via the fixpak process Replication V8.1 - Big Picture Transactional, Multi Threaded, Operations Support, Change Management Architectural positioning for V8.2 Pub/Sub Replication Replication V8.1 - Technical Details Capture Apply Replication Centre Administration Migration from previous versions Replication with Information Integrator Data Replication ; Information Integration Future Directions for DB2 Replication Advantages of Pub/Sub Replication

3 A Brief History of DB2 Replication Two previous architectural levels Capabilities, Architecture & Limitations

4 Architectural Version History Architectural Level DPropR Version 1 V1.1 V1.2 V2.1 Capabilities Basic Change Capture from Log Apply Changes... table by table ========================= But: "Convergent Consistency" (ie: No Referential Integrity) Runtime Dialog Overheads Weak Admin Tools DPropR Version 5 V5.1 V6.1 V7.1 Subscription Sets (RI) Runtime Dialog optimisations Better Admin (via DB2 Control Centre) Update Anywhere Replication

5 Architectural Overview Capture runs locally to the source table and reads changes from the log Transaction consistency is maintained Apply fetches data via client/server communications and applies the data to target tables Source Target source source source uow changes changes Apply control target target target changes Log Capture control Administration

6 Top Issues & Considerations with DB2 Replication V7 No "Operations" support ( Start / Stop / Monitor / Alerts etc...) Not Good at handling DDL & mapping changes FAQ: Using Replication for Disaster Recovery Performant bi-directional replication Supporting RI on Target (ie Transactional Apply) Capture to Local Change Data Tables: great as a shared queue for multiple distributed targets great because it exposes changes for SQL transformations extra Write I/O & Logging Nature of the Beast "batched" SQL, not transactional Limited Scope: Relational Data to Relational Data

7 Enhancements to DB2 Replication V7 Things that snuck in via the fixpak process Transactional Apply Peer to Peer Replication

8 Apply Set Processing - Table Mode CD TABLE A CD TABLE B CD TABLE C SOURCE 3 members have been created in one set. The set is not a replica set, and the commit_count(x) set option was not specified 1 1 Apply first collects changes for the 3 source tables into 3 separate spill files Spill File A 2A 2A Spill File B 2B APPLY 2B 2C 2C Spill File C COPYTABLE A COPYTABLE B COPYTABLE C TARGET 2 In table mode processing, Apply will process all changes from spill file A into copy table A, then all changes from spill file B to copy table B, all changes from spill file C to copy table C, and then will issue a DB2 commit to commit all of the changes for the whole set

9 Apply Set Processing - Transaction Mode CD TABLE A CD TABLE B CD TABLE C SOURCE 3 members have been created in one set. The set was created with commit_count(x), which is the default for update-anywhere and peer-to-peer sets. Spill File A Spill File B 2A APPLY Spill File C COPYTABLE A COPYTABLE B COPYTABLE C 1 2 TARGET 1 2 Apply first collects changes for the 3 source tables into 3 separate spill files In transaction mode processing, Apply will open and process all changes from all spill files at the same time. The apply order is the source transaction order. If commit_count(x) was specified, then commits are issued after each x transactions have been applied.

10 Peer to Peer Replication Tokyo Capture Apply London Apply Capture Variation of update-anywhere replication Source and target tables are defined as replicas Supports RI at both "source" and "target" No Conflict Detection (> requires operational controls)

11 DB2 Replication V8.1 - Big Picture Transactional, Multi Threaded, Operations Support, Change Management Architectural positioning for V8.2 Pub/Sub Replication

12 DB2 Replication V8.1 is Part 1 of a 2 Part Journey SQL DRDA Links Relational Apply Table Table Table CD_Table log Architectural Motivation behind V8 Apply was already Transactional Capture is now also Transactional Table Positioning for Part 2 Deliver transactional data without staging tables

13 Improvements Areas Delivered in V8.1 Usability New Replication Center Operation & Monitoring Interfaces Less rules, product is more adaptive Reliability Emphasis on continuous operation Improved restart and failure algorithms Performance Multi-threaded transaction-based Capture Multiple Capture schemas Reduced need for joins Serviceability Dynamic trace facility Security Improved password management

14 DB2 Replication V8.1 - Technical Details Capture Apply Replication Centre Administration Migration

15 New Capture Features Transactional Capture Multi-threaded Capture Multiple Capture schemas allowed Focus on usability, continuous operation Option to turn off recapture CHGONLY at the registration level

16 Transactional Capture to Staging Tables Changes: 1. In-flight data 2. CD table columns LOG Tx1: insert T1 Tx2: update T2 Tx3: delete T1 Tx2: update T2 Tx1: commit Tx3: undo T1 Tx3: rollback... Capture program In-memory transactions: T1 T2 Tx3: delete T1 Tx3: undo T1 Tx3: rollback REGISTER Capture log reader Tx2: update T2 Tx2: update T2 T1CD T2CD Tx1: insert T1 Tx1: commit T1CD UOW uowid commitseq 'bourbon' OP xc1 c1 I - 5 U 5 8 T2CD authid commitseq intentseq OP xc1 c I - 5 nothing processed yet as transaction is still in-flight never makes it to staging tables - zapped at abort

17 Benefits of Transactional Capture Extensible architecture Removes the need for some joins During Apply to usercopy targets During pruning of CD tables No insert or delete cost for rows of aborted transactions Exact warmstart point is always known Capture always tracks the lowest in-flight lsn as well as the highest committed lsn and commits this info with CD/UOW inserts. Removes previous nasty hiccups that could occur during restart or after timeout scenarios Removes the need for the GETLSEQ command - this data is always available in the new Capture RESTART table No more orphans

18 Multi-Threaded Capture Main process thread Handles command input Starts other threads LOG Tx1: insert T1 Tx2: update T2 Tx3: delete T1 Tx2: update T2 Tx1: commit Tx3: undo T1 Tx3: rollback... Capture program cmds thread locking thread Tx3: delete T1 Tx3: undo T1 Tx3: rollback monitor thread log reader thread Tx2: update T2 Tx2: update T2 pruning thread tran stats memory stats latency stats Tx1: insert T1 Tx1: commit Capture tables SIGNAL MONITOR TRACE UOW uowid commitseq authid 1 OP 1018 xc1 c1 'bourbon' I - 5 U 5 8 T1CD T2CD commitseq intentseq OP xc1 c I - 5

19 Multi-Threaded Capture - Benefits Performance Pruning can run as often as desired - keeps CD and UOW tables small Decreases storage use Improves performance of Apply Pruning will not affect Capture latency Capture worker thread is concurrent Usability Monitor statistics can be externalized as desired monitor_interval controls frequency monitor_limit controls how long data remains in the table

20 Pruning Behavior Pruning is performed in its own thread - autoprune is highly recommended The following tables are pruned automatically, at each prune_interval or on demand: TRACE based on trace_limit MONITOR based on monitor_limit SIGNAL based on status or retention_limit UOW, and all CD tables based on status or retention_limit CD and UOW tables Pruning status is determined from information Apply stored in the new table IBMSNAP_PRUNE_SET SIGNAL table Pruning status is determined by the SIGNAL_STATUS column Pruning logic is cursor based with interim commits

21 Multiple Capture Schemas SOURCE SRC2 SRC1 Capture schema CAP2 CD2 CAP2.UOW CAP2.CNTL ASNLOAD CAPTURE CD1 CAP1.UOW DB2 Log CAP1.CNTL CAPTURE Capture schema CAP1

22 Benefits of Multiple Capture Schemas Provide isolation of key low latency tables These tables can be replicated with their own Capture and Apply programs. Low latency tables can have different run-time priority and Capture characteristics such as pruning interval and monitor interval. As with subscription sets, any tables that require transactional consistency must be handled by the same Capture. Might provide higher throughput This benefit must be traded off for the additional cpu overhead associated with multiple log readers. Might be especially significant in a source environment with multiple cpus available. Provide easier configuration in a replication scenario that involves multiple federated sources One DB2 database can be used to manage multiple federated sources, each with their own Capture schema.

23 New Capture Behaviors The Register table is read at startup or at REINIT: Only active registrations are loaded into memory. New registrations will be loaded dynamically on first use. Invalid registrations (active registrations read at startup, reinit, or on first use) can be flagged with an error msg and ignored OR optionally can stop Capture - user option. For source and/or CD table changes (ALTER ADD columns): If a log record is read that indicates that the source has been changed -> reload registration column definition. If an insert to a CD fails due to an invalid SQLDA -> reload registration column definition. When a registration attribute changes: Example: change the CHGONLY flag from 'N' to 'Y' User must recycle Capture program or use the REINIT command On a media failure: If on the worker thread, Capture stops If on the monitor or prune thread, issue error message only

24 Capture Operational Parameters Shipped program defaults Used when no other input is provided. IBMSNAP_CAPPARMS table When table data is present, it overrides the shipped defaults. Table is read only at startup; contains one row. Startup options When present, this option overrides the CAPPARMS table entries. Will stay in effect until the Capture process is stopped, or until a CHGPARMS command is used. CHGPARMS command When used, this command overrides whatever was previously in use. Will stay in effect until the Capture process is stopped, or until a CHGPARMS command is used.

25 Choice: Recapture or Not? Update-Anywhere Model Peer-to-Peer Model Master Peer 1 Capture Capture Peer 2 Apply Peer 3 Replica 1 Capture Replica 2 Capture Capture Apply Capture Apply Apply Apply Data that changes at Replica 1 gets to Replica 2 through recapture at the master table - Data applied to replicas does not need to be recaptured Data is always transmitted directly from one peer to all other peers - No recapture is needed in this configuration - If replicas are mutually exclusive partitions of the master, then no recapture is required at the master

26 Peer to Peer Considerations ADVANTAGES Capture and Apply automatically prevent circular replication when the target is a replica table. The same Apply qualifier must be used for both directions to make this happen. When Apply processes a replica set, it sends the Apply qualifier to Capture and Capture identifies the units of work for Apply in the IBMSNAP_UOW table. Can use new RECAPTURE setting in IBMSNAP_REGISTER to prevent capturing the same change twice. The Apply qualifier (see above) is used to identify units of work that were done by Apply rather than by users and applications. Apply automatically uses transactional replication (by UOW rather than by table). This is the default when a replica is processed. DISADVANTAGES No conflict detection. Each Apply processes independently, so neither can detect conflicts. Full refreshes must always be done manually. (easy with Crossloader) Cannot administer with the Replication Center. (yet) Use PEERGEN tool - available on request from IBM

27 CHGONLY In V6 and V7, CHGONLY was a startup option for Capture CHGONLY means that only changes to registered columns (that is, columns selected in CD tables) will be captured. In V8 this startup option is removed and the setting is allowed at the individual registration level This change allows for some tables to be registered for CHGONLY while others are not. Some customers choose to register only primary keys for a table and capture the key values for rows changed. Later these keys are used as input for a selective extract and manipulation of the source data.

28 New Apply Features Commit_count(x) at subscription-set level ( Transactional Apply ) New primary-key change option ASNLOAD support of DB2 Crossloader Optimize for one subscription set - OPT4ONE Improved handling of RI failures Peer to Peer Replication

29 Commit_count(x) Subscription Set Option COMMIT_COUNT(x) This subscription-set option is used to influence the processing order that is used by Apply. For valid subscription sets, Apply will process the data in transactional source commit order (replica set order). Sets can contain only the following types of target tables: replica, user copy, and point-in-time. If the source of any member within a set is a CCD table, the option is not valid for that set and the option is ignored. Sets cannot contain target tables with LOBs or Datalinks. Allows users to create RI definitions on their target tables. After every x transactions have been processed, Apply will issue a commit. Might reduce active log-space requirements on the target system as well as contention on target tables.

30 New - Choice of "Key Change" Options Current Capture option Registration option - capture updates as delete/insert pairs Allows for keeping multiple partitioned targets in synch Use when subscription predicate values are subject to change customer acct balance is updated from to CUSTOMERS insert new row Premium Customers where acct_balance > delete old row Regular Customers where acct_balance <= 50000

31 New "Key Change" Option New Apply option Subscription option - updates are captured as updates Requires registration of before images of all target key columns Apply issues "update target table set all cols = new col values where all key cols = old key values" Use wherever the target "IS_KEY" columns are subject to update This option is especially useful in situations where a delete/insert is not appropriate due to other constraints such as RI rules Key column value A changes to B Set key column = 'B' where key column = 'A' Master table A Z update row RI Parent replica A Z delete restrict RI Child replica A B C D

32 DB2 Crossloader Option - Full Refresh New DB2 Utility option Available on DB2 for z/os Utilities, Version 7. Available on DB2 for UNIX and Windows, Version 8. Crossloader function must be available at the target. Load from defined cursor Create cursor for any valid select. Remote OK. Can take advantage of federated, relational connect. Load from that cursor Data is retrieved via select. Blocks of data are piped directly to loader.

33 Apply invokes DB2 Crossloader through ASNLOAD SOURCE TARGET APPLY SRC ASNLOAD create cursor for (select * from SRC) load from cursor Selected data blocks feed directly into load utility zos: 3 part name LUW: federated nickname zos Target: Load invoked thru a WLM Stored Procedure PQ54884 UQ63468 UQ63470 min: DB2 V7 ; DB2 Utils V7 ; DPropR V7 LOAD UTILITY select * from SRC load data TGT

34 New Apply Behavior Two threads Apply worker thread Apply commands thread Initial support of Apply commands STATUS STOP New table ASN.IBMSNAP_APPLYTRACE Contains Error, Warning, and Info messages Apply will wait for Capture to complete initial cold start Less rules to memorize More information is posted to the APPLYTRAIL table to enable monitoring of throughput and latency

35 New Miscellaneous Features Long-name support Column names 30 bytes, table names 128 bytes, schema names 30 bytes Dynamic trace invocation Separate process; trace can be turned on, turned off, dumped to file, and formatted Improved password management Password encryption is supported for Apply, Monitor, and Analyzer Improved NT services Improved ease of use Capture, apply, and monitor processes can be started and stopped through services

36 New Administrative Features Replication Center Definitions Manage control definitions for replication Customize names and sizes of objects Operations Start Capture, Apply, Monitor, Analyzer, and Trace Issue commands such as STOP or STATUS Monitoring Perform static and dynamic monitoring

37 Replication Center

38 Replication Centre Component Overview asnclp Repl> SET SERVER CAPTURE TO DB sample... Repl> SET PROFILE myprof FOR OBJECT CD TABLESPACE OPTIONS... Repl> CREATE CONTROL TABLES FOR CAPTURE SERVER IN... Repl> CREATE REGISTRATION psee.t1 DIFFERENTIAL REFRESH... Repl>... RC CLP Replication Center GUI Replication Center APIs JDBC (Admin) Client machine Java Toolbox/400 (Ops) DASe Client (Ops) DASe Server (Ops) Capture Control server Capture program Apply Control server Apply program Target server

39 Replication Center - Customization Choose default naming conventions for replication objects Choose default table spaces, options, and sizes Choose default attributes for replication objects

40 Replication Center - Operations Support

41 Replication Monitoring Dynamic monitoring program Runs continuously Polls capture and apply processes at user-specified interval Notifies user of alert conditions via pager or Operates based on user-defined alerts and thresholds Historical statistics View latency and throughput information in the RC Static monitor display System health at-a-glance from the RC

42 Replication Monitor Z series DB2 V6 Capture DB2 V7 Apply Z series DPropR Alert DPropR Alert Monitor Server Unix, Windows or zos Collect information about Capture and Apply Notify on failure or exceeded threshold via pager or

43 Replication Center - Monitoring Display

44 Monitor - Show Throughput Detail Choose the range of data to be analyzed Choose how to format the display rate for Apply throughput Choose the time intervals within this range

45 Performance - Latency Measurements Run Capture and Apply concurrently, using the IRWW workload with a varying number of users, to generate varying throughput loads. The table shows different scenarios used to generate particular levels of throughput. Latency measured by timestamped inserts: (time of insert at target - time of insert at source) Throughput (rows/sec) Min (seconds) Max (seconds) Avg (seconds) Capture commit_interval = 1; Apply sleep_minutes = 0, delay = 0

46 Change Management - Through Replication Centre Add Registration Add a New Column to a Registered Source Table Drop Registration Activate/Deactivate Subscription Set Change Attributes of Subscription Set Add Subscription Set Add Subscription Set Member Add a New Column to a Replicated Table Delete Subscription Set Copy Replication Configuration to Another System Many changes are 100% GUI-driven Some changes require some manual SQL intervention Clear procedures are documented in DB2 Replication Guide and Reference V8 (SC )

47 Migration to Replication V8 Pre-Requisites to Migration from V7 Precondition Capture Update federated triggers/procedures with DJRA Coexistence using "bilingual" Apply Mixed level environment Check DB2 Client/Server Compatibility

48 Migration Utility: ASNMIG8 ASNMIG8 is the V8 replication migration program Use ASNMIG8 program on LUW or zseries platforms Use QZSNMIG8 on iseries before running, the migration control tables must be created asnmig8 and asnmig4c must be bound on LUW and z/os Backup Step all current replication server data is copied to the backup tables Migration Step pre-v8 control tables are dropped V8 control tables are built, and the new tables are then populated using the backup tables some data may be manipulated or removed to fit V8 usage check default values for new V8 functions and correct as desired (chgonly,recapture,commit_count,etc.) Fallback Step (Optional) if capture or apply has been run after the migration phase, the fallback/restore returns the control information to an earlier state - not recommended in some environments a fallback is not possible, does not make sense, e.g. in a source server migration from DB2 LUW V7 -> V8 (Capture is not bilingual like apply and cannot read the logs)

49 DB2 Replication V8.1 with Information Integrator Data Replication ; Information Integration

50 Information Integration Overview Integrating diverse business information across and beyond the enterprise Applications DB Client Web Service Message Workflow WebSphere Information Integration Data federation Read/write access across diverse data and content sources Database flavor (SQL) Content flavor (CM API) XML flavor (XML API) Data placement Caching and Replication over heterogeneous information Data transformation SQL, XML Advanced search and mining Metadata management Part of a complete business integration solution Best data store for XML data - DB2 WebSphere business integration Open platform based on industry standards

51 Heterogeneous Replication with Information Integrator Staging tables DB2/zOS DB2/iSeries Changed Data (CD) tables DB2/UDB DB2/UDB LOG based IMS - VSAM LOG based Sybase SQL Server Consistent Changed Data (CCD) tables II Federation engine DB2/iSeries DB2/zOS Sybase SQL Server IBM Informix IBM Informix Trigger based Oracle Oracle ANY source Teradata External application

52 Future Directions for DB2 Replication Messaging Pub/Sub Option

53 Replication Directions Summary Capture ESE Multi-Partitioned Databases Peer to Peer Replication Center Support for IBM DB2 Data Propagator Remote log read (DB2 for Windows/Unix) Replication using MQSeries message queues Low-latency - High throughput Parallel Apply - parallelize non-dependent transactions Advanced conflict resolution Publishing transactions as XML messages over message queues

54 Partitioned DB2 UDB Database (DPF) as Source Clients Partition 1 Partition 2 Partition N CPU CPU CPU CPU Log Buffers CPU DB2 Server Coordinator Agent Buffer Pools Parallel Subagents CPU CPU CPU CPU CPU Log Buffers DB2 Server Buffer Pools Coordinator Agent Agent Parallel Subagents... CPU CPU CPU CPU Log Buffers CPU DB2 Server Buffer Pools Coordinator Agent Agent Parallel Subagents CPU CPU CPU CPU CPU CPU CPU Logger Prefetchers Page Cleaners CPU Logger Prefetchers Page Cleaners CPU Logger Prefetchers Page Cleaners Log Log Log SubTX SubTX SubTX Capture Log Reader Local Transactions Log Merge Capture Global Transactions CD UOW CD Memory

55 DB2 Replication V8 Architecture Part 2 SQL DRDA Links Relational Apply Table Table Table CD_Table log MQ Put MQ Apply Table WMQI MQ Series Links MQ Get Application

56 Transaction Publishing Source System DB2 Log Target applications Any user application Q Capture Transactions in Memory WebSphere MQ Integrator MQ Send Queue XML Relational data changes are inserted as full transaction messages or individual row change messages on an MQ queue in open XML format Provides enhanced application messaging Allows changed data "streaming" to a web application

57 BASE Queue Replication DB2 Replication Solution that is: R/W Application Log Q Capture BASE BASE Q Apply Peer node 1 Peer node 2 WebSphere MQ R/W Application Log Q Capture BASE BASE BASE Q Apply Very fast parallel processing that meets the highest of requirements for throughput and latency Multi-directional peer to peer replication support with flexible options for conflict management Manageable integrated administrative tools, new and enhanced utilities for monitoring and reconciliation processing Flexible multi-purpose High availability scenarios Workload balancing Data distribution / consolidation Business Intelligence High speed transaction transport

58 . Natwest Bank Designed back it in 1996! DB2 Log Groper WALLACE HIGH-LEVEL SYSTEM ARCHITECTURE Whacker DB2 Magic Ingredient Packager Queue Squirter Queue Copyright M. Turner 16/01/96

59 Expected Benefits of Replication Pub/Sub Performance Eliminate Change Data Table Load MQ Series throughput Flexibility Structured Message Format for Change-UOW Option to Exploit WMQI ( Workflow Control etc... )

60 Further Information DB2 Data Propagator homepage: Contains: White papers Documentation Frequently asked questions Free downloads New V8 Redbook A Practical Guide to DB2 UDB Data Replication V8 (Dec. 27, 2002), SG

61 DB2 Replication, Version 8: Technical Update Briefing for GSE Neale Armstrong IBM UK Software Group