IBM Informix-Ent Repl Guide

DB2 IBM Informix
Version 10.0
IBM Informix Dynamic Server Enterprise Replication Guide
G251-2279-00
DB2 IBM Informix
Version 10.0
G251-2279-00
Note: Before using this information and the product it supports, read the information in Notices on page J-1.
First Edition (December 2004) This document contains proprietary information of IBM. It is provided under a license agreement and is protected by copyright law. The information contained in this publication does not include any product warranties, and any statements provided in this manual should not be interpreted as such. When you send information to IBM, you grant IBM a nonexclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you. Copyright International Business Machines Corporation 1996, 2004. All rights reserved. US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix About This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Types of Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x Software Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . x Assumptions About Your Locale . . . . . . . . . . . . . . . . . . . . . . . x Demonstration Databases . . . . . . . . . . . . . . . . . . . . . . . . . xi New Features in Dynamic Server, Version 10.0 . . . . . . . . . . . . . . . . . . . xi Functionality Enhancements . . . . . . . . . . . . . . . . . . . . . . . . xi Command-Line Changes . . . . . . . . . . . . . . . . . . . . . . . . . xii Configuration Parameter Changes . . . . . . . . . . . . . . . . . . . . . . xiii Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . xiii Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . xiv Feature, Product, and Platform . . . . . . . . . . . . . . . . . . . . . . . xiv Syntax Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Example Code Conventions . . . . . . . . . . . . . . . . . . . . . . . . xix Additional Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . xx Installation Guides . . . . . . . . . . . . . . . . . . . . . . . . . . . xx Online Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx Informix Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . xxii Manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii Accessibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii IBM Informix Dynamic Server Version 10.0 and CSDK Version 2.90 Documentation Set . . . . . xxiii Compliance with Industry Standards . . . . . . . . . . . . . . . . . . . . . . xxvi IBM Welcomes Your Comments . . . . . . . . . . . . . . . . . . . . . . . xxvii
Part 1. Introducing Enterprise Replication

Chapter 1. About IBM Informix Enterprise Replication . . . . . . . . . . . . . . . 1-1 IBM Informix Enterprise Replication . . . . . . . . . . . . . . . . . . . . . . 1-1 Asynchronous Data Replication . . . . . . . . . . . . . . . . . . . . . . . 1-2 Log-Based Data Capture . . . . . . . . . . . . . . . . . . . . . . . . . 1-3 High Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3 High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4 Consistent Information Delivery . . . . . . . . . . . . . . . . . . . . . . . 1-4 Repair and Initial Data Synchronization . . . . . . . . . . . . . . . . . . . . 1-4 Flexible Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5 Centralized Administration . . . . . . . . . . . . . . . . . . . . . . . . 1-6 Ease of Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6 Network Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7 How Enterprise Replication Replicates Data . . . . . . . . . . . . . . . . . . . . 1-7 Capturing Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8 Evaluating Data for Replication . . . . . . . . . . . . . . . . . . . . . . . 1-8 Distributing Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
Copyright IBM Corp. 1996, 2004
iii
Applying Replicated Data
. 1-14
Chapter 2. Overview of Enterprise Replication Administration Overview of Enterprise Replication Administration . . . . . Enterprise Replication Server Administrator . . . . . . . . Enterprise Replication Terminology . . . . . . . . . . . Enterprise Replication Server . . . . . . . . . . . . Replicate . . . . . . . . . . . . . . . . . . . Master Replicate . . . . . . . . . . . . . . . . Shadow Replicate . . . . . . . . . . . . . . . . Participant . . . . . . . . . . . . . . . . . . Replicate Set . . . . . . . . . . . . . . . . . Template . . . . . . . . . . . . . . . . . . . Global Catalog . . . . . . . . . . . . . . . . . Enterprise Replication Considerations . . . . . . . . . . Operational Considerations . . . . . . . . . . . . Backup and Restore Considerations . . . . . . . . . . Database and Table Design Considerations . . . . . . . Transaction Processing Considerations . . . . . . . . Replication Environment Considerations . . . . . . . . Enterprise Replication Data Types . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . 2-1 . . 2-2 . . 2-3 . . 2-3 . . 2-3 . . 2-4 . . 2-4 . . 2-4 . . 2-4 . . 2-4 . . 2-4 . . 2-5 . . 2-6 . . 2-6 . . 2-7 . . 2-7 . . 2-11 . . 2-13 . . 2-14
Part 2. Setting Up and Managing Enterprise Replication

Chapter 3. Selecting the Enterprise Replication System and Selecting the Enterprise Replication System . . . . . . . Primary-Target Replication System . . . . . . . . . Update-Anywhere Replication System . . . . . . . . Conflict Resolution . . . . . . . . . . . . . . Choosing a Replication Network Topology . . . . . . . Fully Connected Topology . . . . . . . . . . . Hierarchical Replication Topologies . . . . . . . . Chapter 4. Preparing the Replication Environment . Preparing the Network Environment . . . . . . Setting Up the Hosts File . . . . . . . . . Setting Up the Services File . . . . . . . . Setting Up the Trusted Environment . . . . . Verifying SQLHOSTS . . . . . . . . . . Testing the Network Environment . . . . . . Preparing the Disk . . . . . . . . . . . . Planning for Disk Space Requirements . . . . . Setting Up Send and Receive Queue Spool Areas . Setting Up the Grouper Paging File . . . . . Creating ATS and RIS Directories . . . . . . Preparing the Database Server Environment . . . Setting Environment Variables . . . . . . . Setting Configuration Parameters . . . . . . Preparing Data for Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1 . . 3-1 . . 3-1 . . 3-6 . . 3-7 . . 3-14 . . 3-14 . . 3-15 . . 4-1 . . 4-2 . . 4-2 . . 4-3 . . 4-3 . . 4-3 . . 4-7 . . 4-7 . . 4-8 . . 4-10 . . 4-14 . . 4-15 . . 4-16 . . 4-16 . . 4-16 . . 4-17
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv
Preparing Consistent Data . . . . . . . . . . Blocking Replication . . . . . . . . . . . . Preparing to Replicate User-Defined Types . . . . . Preparing to Replicate User-Defined Routines . . . . Preparing Tables for Conflict Resolution . . . . . . Preparing Logging Databases . . . . . . . . . Loading and Unloading Data . . . . . . . . . . High-Performance Loader . . . . . . . . . . onunload and onload Utilities . . . . . . . . . dbexport and dbimport Utilities . . . . . . . . UNLOAD and LOAD Statements . . . . . . . . Data Preparation Example . . . . . . . . . . . Using the cdr start replicate Command . . . . . . Using LOAD, UNLOAD, and BEGIN WORK WITHOUT
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . REPLICATION .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
4-18 4-18 4-20 4-20 4-20 4-21 4-21 4-22 4-22 4-22 4-23 4-23 4-23 4-24
Chapter 5. Using High-Availability Data Replication with Enterprise Replication . . . . . . 5-1 High-Availability Replication System . . . . . . . . . . . . . . . . . . . . . . 5-1 Using HDR in a Hierarchical Tree Topology . . . . . . . . . . . . . . . . . . . 5-3 Using HDR in a Forest of Trees Topology . . . . . . . . . . . . . . . . . . . . 5-4 Preparing HDR Database Servers . . . . . . . . . . . . . . . . . . . . . . . 5-5 HDR Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6 Setting Up Database Server Groups . . . . . . . . . . . . . . . . . . . . . . 5-6 Preparing to Replicate UDTs, UDRs, and DataBlade Modules . . . . . . . . . . . . . 5-7 Loading and Unloading Data . . . . . . . . . . . . . . . . . . . . . . . . 5-8 Managing Enterprise Replication with High-Availability Data Replication . . . . . . . . . . 5-8 Row Data Sbspace Logging . . . . . . . . . . . . . . . . . . . . . . . . 5-8 HDR Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8 Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . 5-10 Chapter 6. Defining Replication Servers, Replicates, Participants, Initializing Database Servers . . . . . . . . . . . . . . Defining Replication Servers . . . . . . . . . . . . . . Customizing the Replication Server Definition . . . . . . . Defining Replicates . . . . . . . . . . . . . . . . . Defining Participants . . . . . . . . . . . . . . . Defining Master Replicates. . . . . . . . . . . . . . Defining Shadow Replicates . . . . . . . . . . . . . Specifying Conflict Resolution Rules and Scope . . . . . . . Specifying Replication Frequency . . . . . . . . . . . Setting Up Error Logging . . . . . . . . . . . . . . Replicating Only Changed Columns . . . . . . . . . . Using the IEEE Floating Point or Canonical Format . . . . . Enabling Triggers . . . . . . . . . . . . . . . . Defining Replicate Sets . . . . . . . . . . . . . . . Exclusive Replicate Sets . . . . . . . . . . . . . . Non-Exclusive Replicate Sets . . . . . . . . . . . . Customizing the Replicate Set Definition . . . . . . . . Initially Synchronizing Data Among Database Servers . . . . . Using Templates to Set Up Replication . . . . . . . . . . Defining Templates . . . . . . . . . . . . . . . . and Replicate Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1 . . 6-2 . . 6-3 . . 6-3 . . 6-4 . . 6-5 . . 6-6 . . 6-8 . . 6-9 . . 6-10 . . 6-10 . . 6-11 . . 6-12 . . 6-12 . . 6-13 . . 6-13 . . 6-13 . . 6-14 . . 6-14 . . 6-16 . . 6-16
Contents
Realizing Templates
. 6-17
Chapter 7. Managing Replication Servers and Replicates Managing Replication Servers. . . . . . . . . . . Modifying Replication Servers . . . . . . . . . Viewing Replication Server Attributes . . . . . . . Connecting to Another Replication Server. . . . . . Stopping Replication on a Server . . . . . . . . Restarting Replication on a Stopped Server . . . . . Suspending Replication for a Server . . . . . . . Resuming a Suspended Replication Server . . . . . Deleting a Replication Server . . . . . . . . . . Managing Replicates . . . . . . . . . . . . . . Modifying Replicates . . . . . . . . . . . . Viewing Replicate Properties . . . . . . . . . . Starting a Replicate . . . . . . . . . . . . . Stopping a Replicate . . . . . . . . . . . . . Suspending a Replicate . . . . . . . . . . . . Resuming a Suspended Replicate . . . . . . . . Deleting a Replicate . . . . . . . . . . . . . Managing Replicate Sets . . . . . . . . . . . . Modifying Replicate Sets . . . . . . . . . . . Viewing Replicate Sets . . . . . . . . . . . . Starting a Replicate Set . . . . . . . . . . . Stopping a Replicate Set . . . . . . . . . . . Suspending a Replicate Set . . . . . . . . . . Resuming a Replicate Set . . . . . . . . . . . Deleting a Replicate Set . . . . . . . . . . . Managing Templates . . . . . . . . . . . . . Viewing Template Definitions . . . . . . . . . Deleting Templates . . . . . . . . . . . . . Managing Replication Server Network Connections . . . Viewing Network Connection Status . . . . . . . Dropping the Network Connection . . . . . . . Reestablishing the Network Connection . . . . . . Resynchronizing Data Among Replication Servers . . . Performing a Repair Job Using Source Tables . . . . Solving Synchronization Errors . . . . . . . . . Resynchronizing Data Manually . . . . . . . . Performing Alter Operations on Replicated Tables . . . Adding a Column . . . . . . . . . . . . . Attaching a New Fragment to a Replicated Table . . . Remastering a Replicate . . . . . . . . . . . Dropping a Replicated Column . . . . . . . . . Altering a Replicated Column . . . . . . . . . Restrictions . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . 7-1 . . 7-2 . . 7-2 . . 7-3 . . 7-3 . . 7-3 . . 7-4 . . 7-4 . . 7-4 . . 7-5 . . 7-5 . . 7-6 . . 7-7 . . 7-7 . . 7-8 . . 7-8 . . 7-9 . . 7-9 . . 7-10 . . 7-10 . . 7-11 . . 7-11 . . 7-11 . . 7-12 . . 7-12 . . 7-12 . . 7-13 . . 7-13 . . 7-13 . . 7-13 . . 7-13 . . 7-13 . . 7-14 . . 7-14 . . 7-14 . . 7-16 . . 7-16 . . 7-17 . . 7-18 . . 7-18 . . 7-18 . . 7-19 . . 7-20 . . 7-20
Chapter 8. Monitoring and Troubleshooting Enterprise Replication . . . . . . . . . . . 8-1 Aborted Transaction Spooling Files . . . . . . . . . . . . . . . . . . . . . . . 8-2 Preparing to Use ATS . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
vi
About ATS Filenames . . . . . . . . . . . . . About ATS File Information . . . . . . . . . . . BYTE and TEXT Information in ATS Files . . . . . . . Changed Column Information in ATS Files . . . . . . BLOB and CLOB Information in ATS Files . . . . . . UDT Information in ATS Files . . . . . . . . . . Suppressing Datasync Errors and Warnings in ATS Files . . Row Information Spooling Files . . . . . . . . . . . Preparing to Use RIS. . . . . . . . . . . . . . About RIS Filenames . . . . . . . . . . . . . BYTE and TEXT Information in RIS Files . . . . . . . Changed Column Information in RIS Files . . . . . . BLOB and CLOB Information in RIS Files. . . . . . . UDT Information in RIS Files . . . . . . . . . . . Suppressing Datasync Errors and Warnings in RIS Files . . Preventing Memory Queues from Overflowing . . . . . . Preventing DDRBLOCK Mode . . . . . . . . . . Monitoring Disk Usage for Send and Receive Queue Spool Increasing the Sizes of Storage Spaces. . . . . . . . Recovering when Storage Spaces Fill . . . . . . . . Solving Common Configuration Problems . . . . . . . Enterprise Replication Event Alarms . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
8-3 8-3 8-4 8-5 8-5 8-5 8-5 8-6 8-6 8-6 8-7 8-8 8-8 8-8 8-8 8-8 8-9 8-11 8-11 8-11 8-12 8-13
Part 3. Appendixes
Appendix A. Command-Line Utility Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1 . B-1 . C-1 . D-1 . E-1 . F-1 . G-1 . H-1 . I-1 . J-1 . X-1
Appendix B. Configuration Parameter and Environment Variable Reference Appendix C. onstat Command Reference . Appendix D. SMI Table Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Appendix E. Replication Examples .
Appendix F. SQLHOSTS Registry Key (Windows) .
Appendix G. Datasync Warning and Error Messages . Appendix H. Synchronization Failures Table . Appendix I. Accessibility . Notices . Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents
vii
viii
Introduction
About This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Types of Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x Software Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . x Assumptions About Your Locale . . . . . . . . . . . . . . . . . . . . . . . x Demonstration Databases . . . . . . . . . . . . . . . . . . . . . . . . . xi New Features in Dynamic Server, Version 10.0 . . . . . . . . . . . . . . . . . . . xi Functionality Enhancements . . . . . . . . . . . . . . . . . . . . . . . . xi Command-Line Changes . . . . . . . . . . . . . . . . . . . . . . . . . xii Configuration Parameter Changes . . . . . . . . . . . . . . . . . . . . . . xiii Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . xiii Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . xiv Feature, Product, and Platform . . . . . . . . . . . . . . . . . . . . . . . xiv Syntax Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv How to Read a Command-Line Syntax Diagram . . . . . . . . . . . . . . . . xvii Keywords and Punctuation . . . . . . . . . . . . . . . . . . . . . . . xviii Identifiers and Names . . . . . . . . . . . . . . . . . . . . . . . . . xviii Example Code Conventions . . . . . . . . . . . . . . . . . . . . . . . . xix Additional Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . xx Installation Guides . . . . . . . . . . . . . . . . . . . . . . . . . . . xx Online Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx Locating Online Notes . . . . . . . . . . . . . . . . . . . . . . . . . xxi Online Notes Filenames . . . . . . . . . . . . . . . . . . . . . . . . xxii Informix Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . xxii Manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii Online Manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii Printed Manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii Accessibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii IBM Informix Dynamic Server Version 10.0 and CSDK Version 2.90 Documentation Set . . . . . xxiii Compliance with Industry Standards . . . . . . . . . . . . . . . . . . . . . . xxvi IBM Welcomes Your Comments . . . . . . . . . . . . . . . . . . . . . . . xxvii
In This Introduction
This introduction provides an overview of the information in this manual and describes the conventions it uses.
About This Manual

This manual describes IBM Informix Enterprise Replication and the concepts of data replication. This manual explains how to design your replication system, as well as administer and manage data replication throughout your enterprise.
ix
This section discusses the intended audience and the associated software products that you must have to use Enterprise Replication.
Types of Users
This manual is for database server administrators and assumes that you have the following background: v A working knowledge of your computer, your operating system, and the utilities that your operating system provides v Some experience working with relational databases or exposure to database concepts v Some experience with database server administration, operating- system administration, and network administration If you have limited experience with relational databases, SQL, or your operating system, refer to your IBM Informix: Getting Started Guide for a list of supplementary titles.
Software Dependencies
To use Enterprise Replication, you must use IBM Informix Dynamic Server as your database server. Check the release notes for specific version compatibility. This manual assumes that you are using Dynamic Server, Version 10.0, as your database server.
Assumptions About Your Locale

IBM Informix products can support many languages, cultures, and code sets. All the information related to character set, collation and representation of numeric data, currency, date, and time is brought together in a single environment, called a GLS (Global Language Support) locale. The examples in this manual are written with the assumption that you are using the default locale, en_us.8859-1. This locale supports U.S. English format conventions for date, time, and currency. In addition, this locale supports the ISO 8859-1 code set, which includes the ASCII code set plus many 8-bit characters such as , , and . If you plan to use nondefault characters in your data or your SQL identifiers, or if you want to conform to the nondefault collation rules of character data, you need to specify the appropriate nondefault locale. For instructions on how to specify a nondefault locale, additional syntax, and other considerations related to GLS locales, see the IBM Informix: GLS User's Guide.
Demonstration Databases
The DBAccess utility, which is provided with your IBM Informix database server products, includes one or more of the following demonstration databases: v The stores_demo database illustrates a relational schema with information about a fictitious wholesale sporting-goods distributor. Many examples in IBM Informix manuals are based on the stores_demo database. v The superstores_demo database illustrates an object-relational schema. The superstores_demo database contains examples of extended data types, type and table inheritance, and user-defined routines. For information about how to create and populate the demonstration databases, see the IBM Informix: DBAccess User's Guide. For descriptions of the databases and their contents, see the IBM Informix: Guide to SQL Reference. The scripts that you use to install the demonstration databases reside in the $INFORMIXDIR/bin directory on UNIX platforms and in the %INFORMIXDIR%\bin directory in Windows environments.
New Features in Dynamic Server, Version 10.0

This section describes new Enterprise Replication features. These features fall into the following areas: v Functionality Enhancements v Command-Line Changes v Configuration Parameter Changes For a description of all new features, see the IBM Informix: Getting Started Guide.
Functionality Enhancements
Enterprise Replication for Dynamic Server, Version 10.0, includes the following functionality enhancements: v Event Alarms You can use event alarms that are specific to Enterprise Replication to automate many administrative tasks. See Enterprise Replication Event Alarms on page 8-13 for more information. v Master Replicates To guarantee consistency between the nodes in your Enterprise Replication environment, you can create master replicates. See Defining Master Replicates on page 6-6 for more information. v Templates
Introduction
xi
Enterprise Replication provides templates to allow easy set up and deployment of replication for clients with large numbers of tables to replicate. See Using Templates to Set Up Replication on page 6-16 for more information. v Alter Support You can alter a replicated tables schema or its fragmentation strategy without stopping replication. See Performing Alter Operations on Replicated Tables on page 7-17 for more information. v Repair and Initial Data Synchronization If replication has failed for some reason and data is out of synchronization, you can define and run a repair job to resynchronize your tables while replication is still active. Enterprise Replication also provides an initial synchronization feature that allows you to easily bring a new table up-to-date with replication when you start a new replicate, or when you add a new participant to an existing replicate. See Resynchronizing Data Among Replication Servers on page 7-14 and Initially Synchronizing Data Among Database Servers on page 6-14 for more information. v Repair using ATS and RIS files You can also repair data after replication has failed by using ATS and RIS files. Enterprise Replication examines the specified ATS or RIS file and attempts to reconcile the rows that failed to be applied. This method is fast, but does not allow you as much flexibility in defining how the repair should be done. See Repairing with ATS and RIS Files on page 7-15 for more information. v Shadow Replicates Enterprise Replication uses shadow replicates to manage alter and repair operations on replicated tables. If you perform manual remastering of a replicate that was defined with the -n option, you must create a shadow replicate. See Defining Shadow Replicates on page 6-8 for more information.
Command-Line Changes
This release includes the following new commands for the command-line interface: v The cdr define template and cdr realize template commands to define and implement replication using a template. The cdr list template and cdr delete template commands to view and clean up templates. v The cdr define repair and cdr start repair commands to create and run a repair job to resynchronize your replicated data. The cdr stop repair command to halt a running repair job. The cdr list repair and cdr delete repair commands to view and clean up repair jobs. v The cdr repair command to make repairs using ATS or RIS files.
xii
v The cdr remaster command to redefine a master replicate, and the cdr swap shadow command to switch a replicate with its shadow replicate during manual remastering. v The cdr alter command to place tables in alter mode. v The cdr cleanstart command to start an Enterprise Replication server with empty queues. This release includes the following new options for commands in the command-line interface: v The options --syncdatasource and --extratargetrows for the cdr start replicate command. These options allow you to perform an initial synchronization of data when you start a new replicate, or when you add a new participant to an existing replicate. v The master replicate options --master, --empty, --name, --verify, and --autocreate for the cdr define replicate command. v The shadow replicate option --mirrors for the cdr define replicate command. v A brief option for the cdr list replicate command to display a summary of participants for all replicates. For more information on these commands and their options, see Appendix A, Command-Line Utility Reference, on page A-1.
Configuration Parameter Changes

This release includes the following new configuration parameters: v ENCRYPT_SWITCH to define the frequency at which ciphers and secret keys are renegotiated (The cipher is the encryption methodology. The secret key is the key used to build the encrypted data using the cipher.) v CDR_SUPPRESS_ATSRISWARN to prevent certain Datasync errors and warnings from appearing in ATS files. For more information, see Appendix B, Configuration Parameter and Environment Variable Reference, on page B-1.
Documentation Conventions
This section describes the conventions that this manual uses. These conventions make it easier to gather information from this and other volumes in the documentation set. The following conventions are discussed: v Typographical conventions v Other conventions
Introduction
xiii
v Syntax diagrams v Command-line conventions v Example code conventions
Typographical Conventions
This manual uses the following conventions to introduce new terms, illustrate screen displays, describe command syntax, and so forth.
Convention KEYWORD italics italics italics boldface boldface monospace monospace KEYSTROKE > Meaning All primary elements in a programming language statement (keywords) appear in uppercase letters in a serif font. Within text, new terms and emphasized words appear in italics. Within syntax and code examples, variable values that you are to specify appear in italics. Names of program entities (such as classes, events, and tables), environment variables, file and pathnames, and interface elements (such as icons, menu items, and buttons) appear in boldface. Information that the product displays and information that you enter appear in a monospace typeface. Keys that you are to press appear in uppercase letters in a sans serif font. This symbol indicates a menu item. For example, Choose Tools > Options means choose the Options item from the Tools menu.
Tip: When you are instructed to enter characters or to execute a command, immediately press RETURN after the entry. When you are instructed to type the text or to press other keys, no RETURN is required.
Feature, Product, and Platform

Feature, product, and platform markup identifies paragraphs that contain feature-specific, product-specific, or platform-specific information. Some
xiv
examples of this markup follow: Dynamic Server Identifies information that is specific to IBM Informix Dynamic Server End of Dynamic Server Extended Parallel Server Identifies information that is specific to IBM Informix Extended Parallel Server End of Extended Parallel Server UNIX Only Identifies information that is specific to UNIX platforms End of UNIX Only Windows Only Identifies information that is specific to the Windows environment End of Windows Only This markup can apply to one or more paragraphs within a section. When an entire section applies to a particular product or platform, this is noted as part of the heading text, for example: Table Sorting (Linux Only)
Syntax Diagrams
This guide uses syntax diagrams built with the following components to describe the syntax for statements and all commands other than system-level commands. Note: Starting in 2004, syntax diagrams have been reformatted to conform to the IBM standard. Syntax diagrams depicting SQL and command-line statements have changed in the following ways: v The symbols at the beginning and end of statements are now double arrows instead of a vertical line at the end. v The symbols at the beginning and end of syntax segment diagrams are now vertical lines instead of arrows.
Introduction
xv
v How many times a loop can be repeated is now explained in a diagram footnote instead of a number in a gate symbol. v Syntax statements that are longer than one line now continue on the next line instead of looping down with a continuous line. v Product or condition-specific paths are now explained in diagram footnotes instead of icons. The following table describes syntax diagram components.
Component represented in PDF Component represented in HTML >>---------------------Meaning Statement begins.
----------------------->
Statement continues on next line. Statement continues from previous line. Statement ends. Required item. Optional item.
>--------------------------------------------->< --------SELECT-----------+-----------------+--------LOCAL------ ---+-----ALL-------+--+--DISTINCT-----+ ---UNIQUE------
Required item with choice. One and only one item must be present.
---+------------------+--+--FOR UPDATE-----+ --FOR READ ONLY-- .---NEXT---------. ----+----------------+--+---PRIOR--------+ ---PREVIOUS-----
Optional items with choice are shown below the main line, one of which you might specify. The values below the main line are optional, one of which you might specify. If you do not specify an item, the value above the line will be used as the default.
xvi
Component represented in PDF
Component represented in HTML .-------,-----------. V | ---+-----------------+--+---index_name---+ ---table_name---
Meaning Optional items. Several items are allowed; a comma must precede each repetition.
>>-| Table Reference |->< Table Reference |--+-----view--------+--| +------table------+ ----synonym------
Reference to a syntax segment. Syntax segment.
How to Read a Command-Line Syntax Diagram The following command-line syntax diagram uses some of the elements listed in the table in the previous section.
Creating a No-Conversion Job
onpladm create job job -p project -n -d device -D database
-t table (1) Setting the Run Mode -S server -T target
Notes: 1 See page 17-4
The second line in this diagram has a segment named Setting the Run Mode, which according to the diagram footnote, is on page 17-4. This segment is shown in the following segment diagram (the diagram uses segment start and end components).
Setting the Run Mode:
Introduction
xvii
l c -f d p a u n N
To construct a command correctly, start at the top left with the command. Follow the diagram to the right, including the elements that you want. The elements in the diagram are case sensitive. The Creating a No-Conversion Job diagram illustrates the following steps: 1. Type onpladm create job and then the name of the job. 2. Optionally, type -p and then the name of the project. 3. Type the following required elements: v -n v -d and the name of the device v -D and the name of the database v -t and the name of the table 4. Optionally, you can choose one or more of the following elements and repeat them an arbitrary number of times: v -S and the server name v -T and the target server name v The run mode. To set the run mode, follow the Setting the Run Mode segment diagram to type -f, optionally type d, p, or a, and then optionally type l or u. 5. Follow the diagram to the terminator. Your diagram is complete. Keywords and Punctuation Keywords are words reserved for statements and all commands except system-level commands. When a keyword appears in a syntax diagram, it is shown in uppercase letters. When you use a keyword in a command, you can write it in uppercase or lowercase letters, but you must spell the keyword exactly as it appears in the syntax diagram. You must also use any punctuation in your statements and commands exactly as shown in the syntax diagrams. Identifiers and Names Variables serve as placeholders for identifiers and names in the syntax diagrams and examples. You can replace a variable with an arbitrary name,
xviii
identifier, or literal, depending on the context. Variables are also used to represent complex syntax elements that are expanded in additional syntax diagrams. When a variable appears in a syntax diagram, an example, or text, it is shown in lowercase italic. The following syntax diagram uses variables to illustrate the general form of a simple SELECT statement.
SELECT column_name FROM table_name
When you write a SELECT statement of this form, you replace the variables column_name and table_name with the name of a specific column and table.
Example Code Conventions

Examples of SQL code occur throughout this manual. Except as noted, the code is not specific to any single IBM Informix application development tool. If only SQL statements are listed in the example, they are not delimited by semicolons. For instance, you might see the code in the following example:
CONNECT TO stores_demo ... DELETE FROM customer WHERE customer_num = 121 ... COMMIT WORK DISCONNECT CURRENT
To use this SQL code for a specific product, you must apply the syntax rules for that product. For example, if you are using DBAccess, you must delimit multiple statements with semicolons. If you are using an SQL API, you must use EXEC SQL at the start of each statement and a semicolon (or other appropriate delimiter) at the end of the statement. Tip: Ellipsis points in a code example indicate that more code would be added in a full application, but it is not necessary to show it to describe the concept being discussed. For detailed directions on using SQL statements for a particular application development tool or SQL API, see the manual for your product.
Introduction
xix
Additional Documentation
For additional information, refer to the following types of documentation: v Installation guides v Online notes v Informix error messages v Manuals v Online help
Installation Guides
Installation guides are located in the /doc directory of the product CD or in the /doc directory of the products compressed file if you downloaded it from the IBM Web site. Alternatively, you can obtain installation guides from the IBM Informix Online Documentation site at http://www.ibm.com/software/data/informix/pubs/library/.
Online Notes
The following sections describe the online files that supplement the information in this manual. Please examine these files before you begin using your IBM Informix product. They contain vital information about application and performance issues.
xx
Online File TOC Notes
Description
Format
The TOC (Table of Contents) notes file HTML provides a comprehensive directory of hyperlinks to the release notes, the fixed and known defects file, and all the documentation notes files for individual manual titles. The documentation notes file for each manual HTML, text contains important information and corrections that supplement the information in the manual or information that was modified since publication. The release notes file describes feature differences from earlier versions of IBM Informix products and how these differences might affect current products. For some products, this file also contains information about any known problems and their workarounds. (Non-Windows platforms only) The machine notes file describes any platform-specific actions that you must take to configure and use IBM Informix products on your computer. HTML, text
Documentation Notes
Release Notes
Machine Notes
text
Fixed and Known Defects File
This text file lists issues that have been text identified with the current version. It also lists customer-reported defects that have been fixed in both the current version and in previous versions.
Locating Online Notes Online notes are available from the IBM Informix Online Documentation site at http://www.ibm.com/software/data/informix/pubs/library/. Additionally you can locate these files before or after installation as described below. Before Installation All online notes are located in the /doc directory of the product CD. The easiest way to access the documentation notes, the release notes, and the fixed and known defects file is through the hyperlinks from the TOC notes file. The machine notes file and the fixed and known defects file are only provided in text format. After Installation
Introduction
xxi
On UNIX platforms in the default locale, the documentation notes, release notes, and machine notes files appear under the $INFORMIXDIR/release/en_us/0333 directory. Dynamic Server On Windows the documentation and release notes files appear in the Informix folder. To display this folder, choose Start > Programs > IBM Informix Dynamic Server version > Documentation Notes or Release Notes from the taskbar. Machine notes do not apply to Windows platforms. End of Dynamic Server Online Notes Filenames Online notes have the following file formats:
Online File TOC Notes Documentation Notes Release Notes Machine Notes Fixed and Known Defects File File Format prod_os_tocnotes_version.html prod_bookname_docnotes_version.html/txt prod_os_relnotes_version.html/txt prod_machine_notes_version.txt prod_defects_version.txt Examples ids_win_tocnotes_10.0.html ids_hpl_docnotes_10.0.html ids_unix_relnotes_10.0.txt ids_machine_notes_10.0.txt ids_defects_10.0.txt client_defects_2.90.txt ids_win_fixed_and_known _defects_10.0.txt
ids_win_fixed_and_known _defects_version.txt
Informix Error Messages

This file is a comprehensive index of error messages and their corrective actions for the Informix products and version numbers. On UNIX platforms, use the finderr command to read the error messages and their corrective actions. Dynamic Server On Windows, use the Informix Error Messages utility to read error messages and their corrective actions. To display this utility, choose Start > Programs > IBM Informix Dynamic Server version > Informix Error Messages from the taskbar. End of Dynamic Server
xxii
You can also access these files from the IBM Informix Online Documentation site at http://www.ibm.com/software/data/informix/pubs/library/.
Manuals
Online Manuals A CD that contains your manuals in electronic format is provided with your IBM Informix products. You can install the documentation or access it directly from the CD. For information about how to install, read, and print online manuals, see the installation insert that accompanies your CD. You can also obtain the same online manuals from the IBM Informix Online Documentation site at http://www.ibm.com/software/data/informix/pubs/library/. Printed Manuals To order hardcopy manuals, contact your sales representative or visit the IBM Publications Center Web site at http://www.ibm.com/software/howtobuy/data.html.
Online Help
IBM Informix online help, provided with each graphical user interface (GUI), displays information about those interfaces and the functions that they perform. Use the help facilities that each GUI provides to display the online help.
Accessibility
IBM is committed to making our documentation accessible to persons with disabilities. Our books are available in HTML format so that they can be accessed with assistive technology such as screen reader software. The syntax diagrams in our manuals are available in dotted decimal format, which is an accessible format that is available only if you are using a screen reader. For more information about the dotted decimal format, see the Accessibility appendix.
IBM Informix Dynamic Server Version 10.0 and CSDK Version 2.90 Documentation Set
The following tables list the manuals that are part of the IBM Informix Dynamic Server, Version 10.0 and the CSDK Version 2.90, documentation set. PDF and HTML versions of these manuals are available at http://www.ibm.com/software/data/informix/pubs/library/. You can order hardcopy versions of these manuals from the IBM Publications Center at http://www.ibm.com/software/howtobuy/data.html.
Introduction
xxiii
Table 1. Database Server Manuals Manual Administrators Guide Administrators Reference Subject Understanding, configuring, and administering your database server. Reference material for Informix Dynamic Server, such as the syntax of database server utilities onmode and onstat, and descriptions of configuration parameters, the sysmasters tables, and logical-log records. The concepts and methods you need to understand when you use the ON-Bar and ontape utilities to back up and restore data. Using the DB-Access utility to access, modify, and retrieve data from Informix databases. The DataBlade API functions and the subset of ESQL/C functions that the DataBlade API supports. You can use the DataBlade API to develop client LIBMI applications and C user-defined routines that access data in Informix databases. The DataBlade API, which is the C-language application-programming interface provided with Dynamic Server. You use the DataBlade API to develop client and server applications that access data stored in Informix databases. Designing, implementing, and managing your Informix databases. How to design, implement, and manage an Enterprise Replication system to replicate data between multiple database servers. Causes and solutions for numbered error messages you might receive when you work with IBM Informix products. Describes the products bundled with IBM Informix Dynamic Server and interoperability with other IBM products. Summarizes important features of Dynamic Server and the new features for each version. Information about Informix databases, data types, system catalog tables, environment variables, and the stores_demo demonstration database. Detailed descriptions of the syntax for all Informix SQL and SPL statements. A tutorial on SQL, as implemented by Informix products, that describes the basic ideas and terms that are used when you work with a relational database. Accessing and using the High-Performance Loader (HPL), to load and unload large quantities of data to and from Informix databases. Instructions for installing IBM Informix Dynamic Server on Windows. Instructions for installing IBM Informix Dynamic Server on UNIX and Linux.
Backup and Restore Guide DB-Access Users Guide DataBlade API Function Reference
DataBlade API Programmers Guide
Database Design and Implementation Guide Enterprise Replication Guide Error Messages file Getting Started Guide
Guide to SQL: Reference Guide to SQL: Syntax Guide to SQL: Tutorial
High-Performance Loader Users Guide Installation Guide for Microsoft Windows Installation Guide for UNIX and Linux
xxiv
Table 1. Database Server Manuals (continued) Manual J/Foundation Developers Guide Large Object Locator DataBlade Module Users Guide Subject Writing user-defined routines (UDRs) in the Java programming language for Informix Dynamic Server with J/Foundation. Using the Large Object Locator, a foundation DataBlade module that can be used by other modules that create or store large-object data. The Large Object Locator enables you to create a single consistent interface to large objects and extends the concept of large objects to include data stored outside the database. Conversion to and reversion from the latest versions of Informix database servers. Migration between different Informix database servers. The Optical Subsystem, a utility that supports the storage of BYTE and TEXT data on optical disk. Configuring and operating IBM Informix Dynamic Server to achieve optimum performance. Creating R-tree indexes on appropriate data types, creating new operator classes that use the R-tree access method, and managing databases that use the R-tree secondary access method. The IBM Informix subagent that allows a Simple Network Management Protocol (SNMP) network manager to monitor the status of Informix servers. Informix Storage Manager (ISM), which manages storage devices and media for your Informix database server. The secure-auditing capabilities of Dynamic Server, including the creation and maintenance of audit logs. How to define new data types and enable user-defined routines (UDRs) to extend IBM Informix Dynamic Server. Creating a secondary access method (index) with the Virtual-Index Interface (VII) to extend the built-in indexing schemes of IBM Informix Dynamic Server. Typically used with a DataBlade module. Creating a primary access method with the Virtual-Table Interface (VTI) so that users have a single SQL interface to Informix tables and to data that does not conform to the storage scheme of Informix Dynamic Server.
Migration Guide Optical Subsystem Guide Performance Guide R-Tree Index Users Guide
SNMP Subagent Guide
Storage Manager Administrators Guide Trusted Facility Guide User-Defined Routines and Data Types Developers Guide Virtual-Index Interface Programmers Guide Virtual-Table Interface Programmers Guide
Table 2. Client/Connectivity Manuals Manual Client Products Installation Guide Embedded SQLJ Users Guide Subject Installing IBM Informix Client Software Developers Kit (Client SDK) and IBM Informix Connect on computers that use UNIX, Linux, and Windows. Using IBM Informix Embedded SQLJ to embed SQL statements in Java programs.
Introduction
xxv
Table 2. Client/Connectivity Manuals (continued) Manual ESQL/C Programmers Manual GLS Users Guide Subject The IBM Informix implementation of embedded SQL for C. The Global Language Support (GLS) feature, which allows IBM Informix APIs and database servers to handle different languages, cultural conventions, and code sets. Installing and using Informix JDBC Driver to connect to an Informix database from within a Java application or applet. Using Informix .NET Provider to enable .NET client applications to access and manipulate data in Informix databases.
JDBC Driver Programmers Guide .NET Provider Reference Guide
ODBC Driver Programmers Using the Informix ODBC Driver API to access an Informix database and Manual interact with the Informix database server. OLE DB Provider Programmers Guide Object Interface for C++ Programmers Guide Installing and configuring Informix OLE DB Provider to enable client applications, such as ActiveX Data Object (ADO) applications and Web pages, to access data on an Informix server. The architecture of the C++ object interface and a complete class reference.
Table 3. DataBlade Developers Kit Manuals Manual DataBlade Developers Kit Users Guide DataBlade Module Development Overview Subject Developing and packaging DataBlade modules using BladeSmith and BladePack. Basic orientation for developing DataBlade modules. Includes an example illustrating the development of a DataBlade module.
DataBlade Module Installing DataBlade modules and using BladeManager to manage Installation and Registration DataBlade modules in Informix databases. Guide
Compliance with Industry Standards

The American National Standards Institute (ANSI) and the International Organization of Standardization (ISO) have jointly established a set of industry standards for the Structured Query Language (SQL). IBM Informix SQL-based products are fully compliant with SQL-92 Entry Level (published as ANSI X3.135-1992), which is identical to ISO 9075:1992. In addition, many features of IBM Informix database servers comply with the SQL-92 Intermediate and Full Level and X/Open SQL Common Applications Environment (CAE) standards.
xxvi
IBM Welcomes Your Comments

We want to know about any corrections or clarifications that you would find useful in our manuals, which will help us improve future versions. Include the following information: v The name and version of the manual that you are using v Section and page number v Your suggestions about the manual Send your comments to us at the following email address: docinf@us.ibm.com This email address is reserved for reporting errors and omissions in our documentation. For immediate help with a technical problem, contact IBM Technical Support. We appreciate your suggestions.
Introduction
xxvii
xxviii
Part 1. Introducing Enterprise Replication
Chapter 1. About IBM Informix Enterprise Replication

IBM Informix Enterprise Replication . . . . . Asynchronous Data Replication . . . . . . Log-Based Data Capture . . . . . . . . High Performance . . . . . . . . . . High Availability . . . . . . . . . . . Consistent Information Delivery . . . . . . Repair and Initial Data Synchronization . . . Flexible Architecture . . . . . . . . . . Centralized Administration . . . . . . . Ease of Implementation . . . . . . . . . Network Encryption . . . . . . . . . . How Enterprise Replication Replicates Data . . . Capturing Transactions . . . . . . . . . Evaluating Data for Replication . . . . . . Row Images . . . . . . . . . . . Evaluating Rows for Updates . . . . . Send Data Queues and Receive Data Queues Data Evaluation Examples . . . . . . Distributing Data . . . . . . . . . . Applying Replicated Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1 . 1-2 . 1-3 . 1-3 . 1-4 . 1-4 . 1-4 . 1-5 . 1-6 . 1-6 . 1-7 . 1-7 . 1-8 . 1-8 . 1-8 . 1-10 . 1-11 . 1-12 . 1-14 . 1-14
In This Chapter
Data replication generates and manages multiple copies of data at one or more sites, which allows an enterprise to share corporate data throughout its organization. This chapter introduces IBM Informix Enterprise Replication and explains how this product replicates data.
IBM Informix Enterprise Replication

IBM Informix Enterprise Replication is an asynchronous, log-based tool for replicating data between IBM Informix Dynamic Server database servers. Enterprise Replication on the source server captures transactions to be replicated by reading the logical log, storing the transactions, and reliably transmitting each transaction as replication data to the target servers. At each target server, Enterprise Replication receives and applies each transaction contained in the replication data to the appropriate databases and tables as a normal, logged transaction.
1-1
IBM Informix Enterprise Replication provides the following features: v Asynchronous Data Replication v Log-Based Data Capture v High Performance v High Availability v Consistent Information Delivery v Repair and Initial Data Synchronization v Flexible Architecture v Centralized Administration v Ease of Implementation v Network Encryption
Asynchronous Data Replication

Enterprise Replication uses asynchronous data replication to update the databases that reside at a replicated site after the primary database has committed a change. With asynchronous replication, the delay to update the replicated-site databases can vary depending on the business application and user requirements. However, the data eventually synchronizes to the same value at all sites. The major benefit of this type of data replication is that if a particular database server fails, the replication process can continue and all transactions in the replication system will be committed. In contrast to this, synchronous data replication replicates data immediately when the source data is updated. Synchronous data replication uses the two-phase commit technology to protect data integrity. In a two-phase commit, a transaction is applied only if all interconnected distributed sites agree to accept the transaction. Synchronous data replication is appropriate for applications that require immediate data synchronization. However, synchronous data replication requires that all hardware components and networks in the replication system be available at all times. For more information about synchronous replication, refer to the discussion of two-phase commit in your IBM Informix: Dynamic Server Administrator's Guide. Asynchronous replication is often preferred because it allows for system and network failures. Asynchronous replication allows the following replication models: v Primary-target (Primary-Target Replication System on page 3-1) All database changes originate at the primary database and are replicated to the target databases. Changes at the target databases are not replicated to the primary.
1-2
v Update-anywhere (Update-Anywhere Replication System on page 3-6) All databases have read and write capabilities. Updates are applied at all databases. The update-anywhere model provides the greater challenge in asynchronous replication. For example, if a replication system contains three replication sites that all have read and write capabilities, conflicts occur when the sites try to update the same data at the same time. Conflicts must be detected and resolved so that the data elements eventually have the same value at every site. For more information, see Conflict Resolution on page 3-7.
Log-Based Data Capture

Enterprise Replication uses log-based data capture to gather data for replication. Enterprise Replication reads the logical log to obtain the row images for tables that participate in replication and then evaluates the row images. Log-based data capture takes changes from the logical log and does not compete with transactions for access to production tables. Log-based data-capture systems operate as part of the normal database-logging process and thus add minimal overhead to the system. Two other methods of data capture, which Enterprise Replication does not support, include: v Trigger-based data capture A trigger is code in the database that is associated with a piece of data. When the data changes, the trigger activates the replication process. v Trigger-based transaction capture A trigger is associated with a table. Data changes are grouped into transactions and a single transaction might trigger several replications if it modifies several tables. The trigger receives the whole transaction, but the procedure that captures the data runs as a part of the original transaction, thus slowing down the original transaction.
High Performance
Enterprise Replication provides high performance by not overly burdening the data source and by using networks and all other resources efficiently. Because Enterprise Replication captures changes from the logical log instead of competing with transactions that access production tables, Enterprise Replication minimizes the effect on transaction performance. Because the capture mechanism is internal to the database, the database server implements this capture mechanism efficiently. For more information, see Log-Based Data Capture on page 1-3.
1-3
All Enterprise Replication operations are performed in parallel, which further extends the performance of Enterprise Replication.
High Availability
Because Enterprise Replication implements asynchronous data replication, network and target database server outages are tolerated. In the event of a database server or network failure, the local database server continues to service local users. The local database server stores replicated transactions in persistent storage until the remote server becomes available. If high availability is critical, you can use High-Availability Data Replication (HDR) in conjunction with Enterprise Replication. HDR supports synchronous data replication between two database servers: a primary server, which can participate in Enterprise Replication, and a secondary server, which is read-only and does not participate in Enterprise Replication. If a primary server in an HDR pair fails, you switch the secondary server to the standard server, allowing it to participate in Enterprise Replication. Client connections to the original primary server can be automatically switched to the new standard server. For more information on using HDR with Enterprise Replication, see Chapter 5, Using High-Availability Data Replication with Enterprise Replication.
Consistent Information Delivery

Enterprise Replication protects data integrity. All Enterprise Replication transactions are stored in a reliable queue to maintain the consistency of transactions. Enterprise Replication uses a data-synchronization process to ensure that transactions are applied at the target database servers in any order equivalent to the order that they were committed on the source database server. If Enterprise Replication can preserve the consistency of the database, Enterprise Replication might commit transactions in a slightly different order on the target database. If update conflicts occur, Enterprise Replication provides built-in automatic conflict detection and resolution. You can configure the way conflict resolution behaves to meet the needs of your enterprise. For more information, see Conflict Resolution on page 3-7.
Repair and Initial Data Synchronization

Enterprise Replication provides an initial synchronization feature that allows you to easily bring a new table up-to-date with replication when you start a new replicate, or when you add a new participant to an existing replicate. Initial synchronization can be run online while replication is active. For more
1-4
information about initial synchronization, see Initially Synchronizing Data Among Database Servers on page 6-14. If replication has failed for some reason, Enterprise Replication allows you to run a repair job to resynchronize data and correct data mismatches between replicated tables. Repair jobs can be run online while replication is active. For more information, see Resynchronizing Data Among Replication Servers on page 7-14. You can also repair data after replication has failed by using ATS and RIS files. Enterprise Replication examines the specified ATS or RIS file and attempts to reconcile the rows that failed to be applied. This method is fast, but does not allow as much flexibility as a repair job allows in defining how the repair should be done. See Repairing with ATS and RIS Files on page 7-15 for more information.
Flexible Architecture
Enterprise Replication allows replications based on specific business and application requirements and does not impose model or methodology restrictions on the enterprise. Enterprise Replication supports both primary-target and update-anywhere replication models. For more information, see Selecting the Enterprise Replication System on page 3-1. Enterprise Replication supports the following network topologies: v Fully connected Continuous connectivity between all participating database servers. v Hierarchical tree A parent-child configuration that supports continuous and intermittent connectivity. v Forest of trees Multiple hierarchical trees that connect at the root database servers. You can add High-Availability Data Replication to any of these topologies. For more information on topologies, see Choosing a Replication Network Topology on page 3-14. Enterprise Replication supports all built-in Informix data types, as well as extended and user-defined data types. For more information, see Enterprise Replication Data Types on page 2-14. Enterprise Replication operates in LAN, WAN, and combined LAN/WAN configurations across a range of network transport protocols.
1-5
Enterprise Replication supports the Global Language Support (GLS) feature, which allows IBM Informix products to handle different languages, regional conventions, and code sets. For more information, see Using GLS with Enterprise Replication on page 2-14.
Centralized Administration
Enterprise Replication allows administrators to easily manage all the distributed components of the replication system from a single point of control. You can use the command-line utility (CLU) to administer the replication system from your system command prompt and connect to other servers involved in replication, as necessary. For information, see Appendix A, Command-Line Utility Reference, on page A-1. In addition, you can use IBM Informix Server Administrator (ISA) to administer your replication system from a web browser.
Ease of Implementation
Enterprise Replication provides templates to allow easy set up and deployment of replication for clients with large numbers of tables to replicate. Administrators of Enterprise Replication can use templates to develop scripts and with only a few commands can set up replication over a large number of server nodes. Without using templates, many individual commands must be run. Using templates, you can also easily add a new server into your replication environment and optionally create and populate new database tables. First, you create a template using the cdr define template command. This defines the database, tables, and columns and the characteristics of the replicates that will be created. You can view information about a template by using the cdr list template command from a non-leaf node. Second, you instantiate the template on the servers where you want to replicate this data by running the cdr realize template command. If the table already exists on a node, Enterprise Replication verifies it matches the template definition. If the table does not exist on a node, Enterprise Replication can optionally create the table. Enterprise Replication can also optionally perform an initial data synchronization on all servers where you realize the template. You can delete templates that you no longer need using the cdr delete template command.
1-6
See Using Templates to Set Up Replication on page 6-16 for more information. All replication commands mentioned in this section are described in detail in Appendix A, Command-Line Utility Reference, on page A-1.
Network Encryption
Enterprise Replication supports the same network encryption that you can use with client/server communications to provide complete data encryption with the OpenSSL library. A message authentication code (MAC) is transmitted as part of the encrypted data transmission to ensure data integrity. A MAC is an encrypted message digest. The encryption algorithms use OpenSSL 0.9.6 as the code base. However, encryption is implemented differently for Enterprise Replication than for client/server communications: v Client/server network encryption uses the ENCCSM communications support module (CSM) that is specified in the SQLHOSTS file. v Enterprise Replication encryption requires setting encryption configuration parameters. Enterprise Replication cannot accept a connection that is configured with a CSM. To combine client/server network encryption with Enterprise Replication encryption, configure two network connections for each database server, one with CSM and one without. For more information, see Network Encryption and SQLHOSTS on page 4-6. Important: HDR does not support encryption. If you combine Enterprise Replication with HDR, communication between Enterprise Replication servers and the HDR primary server can be encrypted, but the communication between the HDR primary server and the HDR secondary server cannot be encrypted. Enterprise Replication encryption configuration parameters are documented in Appendix B, Configuration Parameter and Environment Variable Reference, on page B-1.
How Enterprise Replication Replicates Data

Before you can replicate data, you must declare a database server for replication and define the replicates (the data to replicate and the database servers that participate in replication). To declare a database server for replication, see Defining Replication Servers on page 6-3. To define replicates, see Defining Replicates on page 6-4. Appendix E, Replication Examples, on page E-1, has simple examples of declaring replication servers and defining replicates.
1-7
After the servers and replicates are defined, Enterprise Replication uses the following steps to replicate data: 1. Capturing Transactions 2. Evaluating Data for Replication 3. Distributing Data 4. Applying Replicated Data
Capturing Transactions
As the database server writes rows to the logical log, it marks rows that should be replicated. Later, Enterprise Replication reads the logical log to obtain the row images for tables that participate in replication. Informix database servers manage the logical log in a circular fashion; the most recent logical-log entries write over the oldest entries. Enterprise Replication must read the logical log quickly enough to prevent new logical-log entries from overwriting the logs Enterprise Replication has not yet processed. If the database server comes close to overwriting a logical log that Enterprise Replication has not yet processed, user transactions are blocked until Enterprise Replication can advance. (This situation is called DDRBLOCK mode and occurs only if the system is severely misconfigured.) The row images that participate in replication are passed to Enterprise Replication for further evaluation.
Evaluating Data for Replication

Enterprise Replication evaluates transactions based on a change to a final image of a row. Row Images Enterprise Replication evaluates the initial and final images of a row and any changes that occur between the two row images to determine which rows to replicate. Each row image contains the data in the row as well as the action performed on that row. A row might change more than once in a particular transaction. For example, a transaction might insert and then update a row prior to committing. Enterprise Replication evaluates the net effect (final state) of a transaction based on the row buffers in the log. Enterprise Replication then determines what should replicate, based on the net effect, the initial state of the row, and whether the replicate definition (in particular, the WHERE clause) applies to the initial and final state. Table 1-1 shows the logic that determines which rows are candidates for replication.
1-8
Table 1-1. Enterprise Replication Evaluation Logic PrimaryKey Changed? Yes or no Send to Destination Database Server Nothing
Initial Image INSERT
Replicate Evaluates T or F
Final Image DELETE
Replicate Evaluates T or F
Comments Net change of transaction results in no replication Inserts final data of transaction Final evaluation determines no replication Net result of transaction is delete Net change of transaction results in no replication Ensures old primary key does not replicate
INSERT INSERT
T or F T or F
UPDATE UPDATE
T F
Yes or no Yes or no
INSERT with final row image Nothing
UPDATE
DELETE
T or F
Yes or no
DELETE with initial row image Nothing
UPDATE
DELETE
T or F
Yes or no
UPDATE
UPDATE
Yes
DELETE with initial row image and INSERT with final row image UPDATE with final row image DELETE with initial row image INSERT with final row image Nothing
UPDATE UPDATE
T T
UPDATE UPDATE
T F
No Yes or no
Simple update Row no longer matches replicate definition Row now matches replicate definition No match exists, and therefore, no replication
UPDATE UPDATE
F F
UPDATE UPDATE
T F
Yes or no Yes or no
Where: v Initial image is the before image of the transaction in the logical log. v The replicate evaluates to T (true) or F (false). v Final image is the image of the transaction that is replicated. Table 1-1 on page 1-9 illustrates how Enterprise Replication evaluates the row-image type (INSERT, UPDATE, DELETE), the results of evaluating the
1-9
replicate WHERE clause for both the initial and final image, and whether the primary key changes as a result of the transaction. Tip: The evaluation logic in Table 1-1 on page 1-9 assumes that the source and the destination tables are initially synchronized (identical before replication begins). If the tables were not synchronized, anomalous behavior could result. After Enterprise Replication identifies transactions that qualify for replication, Enterprise Replication transfers the transaction data to a queue. Evaluating Rows for Updates Enterprise Replication evaluates rows for primary-key updates, for WHERE-clause column updates, and for multiple updates to the same row. The following list describes an occurrence in a transaction and the Enterprise Replication action: v Primary-key updates Enterprise Replication translates an update of a primary key into a delete of the original row and an insert of the row image with the new primary key. If triggers are enabled on the target system, insert triggers are executed. v WHERE-clause column updates If a replicate includes a WHERE clause in its data selection, the WHERE clause imposes selection criteria for rows in the replicated table. If an update changes a row so that it no longer passes the selection criteria on the source, it is deleted from the target table. Enterprise Replication translates the update into a delete and sends it to the target. If an update changes a row so that it passes the selection criteria on the source, it is inserted into the target table. Enterprise Replication translates the update into an insert and sends it to the target. v Multiple-row images in a transaction Enterprise Replication compresses multiple-row images and only sends the net change to the target. Because of this, triggers might not execute on the target database. For more information, see Triggers on page 2-9. Enterprise Replication supports the replication of BYTE and TEXT data types (simple large objects) and BLOB and CLOB data types (smart large objects), and opaque user-defined data types, as well as all built-in Informix data types. However, Enterprise Replication implements the replication of these types of data somewhat differently from the replication of other data types. For more information, see Replicating Simple and Smart Large Objects on page 2-15, and Replicating Opaque User-Defined Data Types on page 2-19.
1-10
Send Data Queues and Receive Data Queues Enterprise Replication uses send and receive queues to receive and deliver replication data to and from database servers that participate in a replicate: v Send queue Enterprise Replication stores replication data in memory to be delivered to target database servers that participate in a replicate. If the send queue fills, Enterprise Replication spools the send-queue transaction records to a dbspace and the send-queue row data to an sbspace. v Receive queue Enterprise Replication stores replication data in memory at the target database server until the target database server acknowledges receipt of the data. If the receive queue fills as a result of a large transaction, Enterprise Replication spools the receive queue transaction header and replicate records to a dbspace and the receive queue row data to an sbspace. For more information, see Large Transactions on page 2-11. For more information, see Setting Up Send and Receive Queue Spool Areas on page 4-10 and Preventing Memory Queues from Overflowing on page 8-8. The data contains the filtered log records for a single transaction. Enterprise Replication stores the replication data in a stable (recoverable) send queue on the source database server. Target sites acknowledge receipt of data when it is applied to or rejected from the target database. If a target database server is unreachable, the replication data remains in a stable queue at the source database server. Temporary failures are common, and no immediate action is taken by the source database server; it continues to queue transactions. When the target database server becomes available again, queued transactions are transmitted and applied (see Applying Replicated Data on page 1-14). If the target database server is unavailable for an extended period, the send queue on the source database server might consume excessive resources. In this situation, you might not want to save all transactions for the target database server. To prevent unlimited transaction accumulation, you can remove the unavailable target database server from the replicate (see Managing Replication Servers on page 7-2). Before the database server that is removed rejoins any replicate, however, you must synchronize (bring tables to consistency) with the other database servers (see Resynchronizing Data Among Replication Servers on page 7-14.).
1-11
Data Evaluation Examples Figure 1-1, Figure 1-2 on page 1-13, and Figure 1-3 on page 1-14 show three examples of how Enterprise Replication uses logic to evaluate transactions for potential replication.
Replicate SQL=SELECT emp_id, salary FROM employee WHERE exempt = N; dallas_office BEGIN WORK; INSERT INTO employee VALUES (927, Smith... phoenix_office
DELETE FROM employee WHERE emp_id=927 COMMIT WORK;
Figure 1-1. Insert Followed by a Delete
Figure 1-1 shows a transaction that takes place at the Dallas office. Enterprise Replication uses the logic in Table 1-2 to evaluate whether any information is sent to the destination database server at the Phoenix office.
Table 1-2. Insert Followed by a Delete Evaluation Logic Replicate Initial Image Evaluates INSERT T or F Final Image DELETE Replicate Evaluates T or F Primary-Key Changed? Yes or no Send to Destination Database Server Nothing
Enterprise Replication determines that the insert followed by a delete results in no replication operation; therefore, no replication data is sent. In Figure 1-2, Enterprise Replication uses the logic in Table 1-3 to evaluate whether any information is sent to the destination database server.
1-12
Replicate SQL=SELECT emp_id, salary FROM employee WHERE exempt = N; dallas_office BEGIN WORK; INSERT INTO employee VALUES (927, Smith, N INSERT INTO employee VALUES (927, "Jones" phoenix_office BEGIN WORK;
UPDATE employee SET lname = Jones WHERE emp_id = 927 COMMIT WORK;
COMMIT WORK;
Figure 1-2. Insert Followed by an Update
Table 1-3. Insert Followed by An Update Evaluation Logic Initial Image INSERT Replicate Evaluates T or F Final Image UPDATE Replicate Evaluates T Primary-Key Changed? Yes or no Send to Destination Database Server INSERT with final row image
The replicate WHERE clause imposes the restriction that only rows are replicated where the exempt column contains a value of N. Enterprise Replication evaluates the transaction (an insert followed by an update) and converts it to an insert to propagate the updated (final) image. In Figure 1-3, Enterprise Replication uses the logic in Table 1-4 to evaluate whether any information is sent to the destination database server.
1-13
Replicate SQL=SELECT emp_id, salary FROM employee WHERE exempt = N; dallas_office BEGIN WORK; phoenix_office BEGIN WORK; INSERT INTO employee VALUES (927, Jones, ...
UPDATE employee SET EXEMPT = N WHERE emp_id = 927 COMMIT WORK;
COMMIT WORK;
Figure 1-3. Update; Not Selected to Selected
Table 1-4. Update; Not Selected to Selected Evaluation Logic Initial Image UPDATE Replicate Evaluates F Replicate Final Image Evaluates UPDATE T Primary-Key Changed? Yes or no Send to Destination Database Server INSERT with final row image
The example shows a replicate WHERE clause column update. A row that does not meet the WHERE clause selection criteria is updated to meet the criteria. Enterprise Replication replicates the updated row image and converts the update to an insert.
Distributing Data
Enterprise Replication ensures that all data reaches the appropriate server, regardless of a network or system failure. In the event of a failure, Enterprise Replication stores data until the network or system is operational. Enterprise Replication replicates data efficiently with a minimum of data copying and sending.
Applying Replicated Data

Enterprise Replication uses a data-synchronization process to apply the replicated data to target database servers. The target database servers acknowledge receipt of data when the data is applied to the target database. The data-synchronization process ensures that transactions are applied at the target database servers in an order equivalent to the order that they were committed on the source database server. If consistency can be preserved, Enterprise Replication might commit transactions out of order on the target database.
1-14
When Enterprise Replication applies replication data, it checks to make sure that no collisions exist. A collision occurs when two database servers update the same data simultaneously. Enterprise Replication reviews the data one row at a time to detect a collision. If Enterprise Replication finds a collision, it must resolve the conflict before applying the replication data to the target database server.
Pakistan Time= 12:29:25 Products (in inventory) India Pakistan Bangkok

Column Column field value field value field value field value
Bangkok Time= 12:29:27
Figure 1-4. Collision Example
Figure 1-4 shows a situation that yields a conflict. Pakistan updates the row two seconds before Bangkok updates the same row. The Bangkok update arrives at the India site first, and the Pakistan update follows. The Pakistan time is earlier than the Bangkok time. Because both updates involve the same data and a time discrepancy exists, Enterprise Replication detects a collision. For more information, see Conflict Resolution on page 3-7. Enterprise Replication scans to see if the same primary key already exists in the target table or in the associated delete table, or if a replication order error is detected. A delete table stores the row images of deleted rows. A replication order error is the result of replication data that arrives from different database servers with one of the following illogical results: v A replicated DELETE that finds no row to DELETE on the target v An UPDATE that finds no row to UPDATE on the target v An INSERT that finds a row that already exists on the target
1-15
1-16
Chapter 2. Overview of Enterprise Replication Administration

Overview of Enterprise Replication Administration Enterprise Replication Server Administrator . . . Enterprise Replication Terminology . . . . . . Enterprise Replication Server . . . . . . . Replicate . . . . . . . . . . . . . . Master Replicate . . . . . . . . . . . Shadow Replicate . . . . . . . . . . . Participant . . . . . . . . . . . . . Replicate Set . . . . . . . . . . . . Template . . . . . . . . . . . . . . Global Catalog . . . . . . . . . . . . Enterprise Replication Considerations . . . . . Operational Considerations . . . . . . . Backup and Restore Considerations . . . . . Database and Table Design Considerations . . Unbuffered Logging . . . . . . . . . Table Types . . . . . . . . . . . . Out-of-Row Data . . . . . . . . . . Shadow Columns . . . . . . . . . . Primary Key Constraint . . . . . . . . SERIAL Data Types and Primary Keys . . . Cascading Deletes . . . . . . . . . Triggers . . . . . . . . . . . . . Using Constraints . . . . . . . . . Sequence Objects . . . . . . . . . Transaction Processing Considerations . . . Replication Volume . . . . . . . . . Distributed Transactions . . . . . . . Large Transactions . . . . . . . . . Supported SQL Statements . . . . . . Replication Environment Considerations . . . Time Synchronization . . . . . . . . Using GLS with Enterprise Replication . . Enterprise Replication Data Types . . . . . Replicating on Heterogeneous Hardware . Replicating Simple and Smart Large Objects Replicating Opaque User-Defined Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2 . 2-3 . 2-3 . 2-3 . 2-4 . 2-4 . 2-4 . 2-4 . 2-4 . 2-4 . 2-5 . 2-6 . 2-6 . 2-7 . 2-7 . 2-7 . 2-8 . 2-8 . 2-8 . 2-8 . 2-9 . 2-9 . 2-9 . 2-10 . 2-10 . 2-11 . 2-11 . 2-11 . 2-11 . 2-12 . 2-13 . 2-13 . 2-14 . 2-14 . 2-15 . 2-15 . 2-19
2-1
Verifying the Data Type of Replicated Columns .
. 2-20
In This Chapter
This chapter introduces you to Enterprise Replication administration and describes the Enterprise Replication server administrator, Enterprise Replication terminology, and considerations for using Enterprise Replication.
Overview of Enterprise Replication Administration

To set up Enterprise Replication: 1. Select the Enterprise Replication system and network topology to use for your replication environment. For information, see Chapter 3, Selecting the Enterprise Replication System and Network Topology, on page 3-1. 2. Prepare the replication environment. For information, see Chapter 4, Preparing the Replication Environment, on page 4-1. 3. Initialize the database server. For information, see Chapter 6, Defining Replication Servers, Replicates, Participants, and Replicate Sets, on page 6-1. 4. Define database servers for replication. For information, see Chapter 6. 5. Define replicates and participants. For information, see Chapter 7, Managing Replication Servers and Replicates, on page 7-1. 6. Create replicate sets (optional). For information, see Defining Replicate Sets on page 6-13. 7. Start the replicate. For information, see Chapter 7. Once you configure Enterprise Replication, use this information to manage your replication environment: v Managing Replication Servers on page 7-2 v Managing Replicates on page 7-5 v Managing Replicate Sets on page 7-10 v Chapter 8, Monitoring and Troubleshooting Enterprise Replication, on page 8-1
2-2
Enterprise Replication Server Administrator

The Enterprise Replication server administrator must have Informix administrator privileges to configure and manage Enterprise Replication.
Operating System UNIX Windows Privileges user informix Member of the Informix-Admin group
Enterprise Replication Terminology

The following terms define the data in an Enterprise Replication system and how it is treated: v Enterprise Replication server v Replicate v Master Replicate v Shadow Replicate v Participant v Replicate Set v Template v Global Catalog
Enterprise Replication Server

An Enterprise Replication server, or replication server, is an Informix database server that participates in data replication. The replication server maintains information about the replication environment, which columns should be replicated, and the conditions under which the data should be replicated. This information is stored in a database, syscdr, that the database server creates when it is initialized. Multiple database servers can be on the same physical computer, and each database server can participate in Enterprise Replication. Important: For each server participating in replication, you must set up a database server group in the SQLHOSTS file (UNIX) or registry (Windows). For more information, see Setting up Database Server Groups on page 4-4 and Appendix F, SQLHOSTS Registry Key (Windows), on page F-1. Tip: This manual uses the convention that the name of a database server group is g_ followed by the name of a database server that is in the group; for example, g_italy. For more information, see Defining Replication Servers on page 6-3 and cdr define server on page A-25.
2-3
Replicate
A replicate defines the replication participants and various attributes of how to replicate the data, such as frequency and how to handle any conflicts during replication. For more information, see Defining Replicates on page 6-4 and cdr define replicate on page A-15.
Master Replicate
A master replicate is a replicate that guarantees data integrity by verifying that replicated tables on different servers have consistent column attributes. Master replicates also allow you to perform alter operations on replicated tables. For more information, Defining Master Replicates on page 6-6 and cdr define replicate on page A-15.
Shadow Replicate
A shadow replicate is a copy of an existing (primary) replicate. Shadow replicates allow Enterprise Replication to manage alter and repair operations on replicated tables. For more information, see Defining Shadow Replicates on page 6-8 and cdr define replicate on page A-15.
Participant
A participant specifies the data (database, table, and columns) to replicate and the database servers to which the data replicates. Important: You cannot start and stop replicates that have no participants. For more information, see Defining Participants on page 6-5 and Participant on page A-110.
Replicate Set
A replicate set combines several replicates to form a set that can be administered together as a unit. If your replication system contains many replicates that you define as part of a replicate set, you can use a single command to start, stop, suspend, or resume all the replicates in the set. For more information, see Managing Replicate Sets on page 7-10 and cdr change replicateset on page A-7.
Template
A template provides a mechanism to set up and deploy replication for a group of tables on one or more servers. This is especially useful if you have a large
2-4
number of tables to replicate between many servers. Internally, a template defines a group of master replicates and a replicate set for a specified group of tables using attributes such as database, tables, columns and primary keys from the master node. You create a template using the cdr define template command and then instantiate, or realize, it on servers with the cdr realize template command. See Using Templates to Set Up Replication on page 6-16 for more information.
Global Catalog
Each database server that participates in Enterprise Replication maintains tables in the syscdr database to keep track of Enterprise Replication configuration information and state. For all root and nonroot replication servers, this catalog is a global catalog that maintains a global inventory of Enterprise Replication configuration information. The global catalog is created when you define the server for replication. For more information, see Table 3-5 on page 3-16. The global catalog includes the following: v Enterprise Replication server definitions and state v Routing and connectivity information v Replicate definitions and state v Participant definitions and state v Replicate set definitions and state v Conflict detection and resolution rules and any associated SPL routines The tables in one global catalog instance are automatically replicated to the global catalogs of all other replication servers (except leaf servers). Thus you can manage the entire replication environment from one non-leaf replication server. For information about managing replication servers (and their global catalogs), refer to Managing Replication Servers on page 7-2. Leaf replication servers (Table 3-5 on page 3-16) have limited catalogs. Because the parent database server always manages operations that involve a leaf database server, the catalog of the leaf database server contains only enough data to allow it to interact with its parent server. Limiting the catalog of leaf database servers makes the replication system more efficient because the global catalogs do not need to be replicated to the leaf servers. For information on defining root, nonroot, and leaf servers, see Customizing the Replication Server Definition on page 6-3.
2-5
Enterprise Replication Considerations

This section discusses items to consider when planning to use Enterprise Replication: v Operational Considerations v Backup and Restore Considerations v Database and Table Design Considerations v Transaction Processing Considerations v Replication Environment Considerations v Enterprise Replication Data Types
Operational Considerations
Enterprise Replication imposes the following operational limitations: v Enterprise Replication supports replication on IBM Informix Dynamic Server only. v Replication is restricted to base tables. That is, you cannot define a replicate on a view or synonym. A view is a synthetic table, a synthesis of data that exists in real tables and other views. A synonym is an alternative name for a table or a view. For more information on views and synonyms, see the IBM Informix: Database Design and Implementation Guide. v Replication is not inherited by any child tables in a typed hierarchy. Enterprise Replication asynchronously propagates many control operations through the Enterprise Replication network. When you perform administrative functions using Enterprise Replication, the status that returns from those operations is indicative only of the success or failure of the operation at the database server to which you are directly connected. The operation might still be propagating through the other Enterprise Replication database servers in the network at that time. Due to this asynchronous propagation, avoid performing control operations in quick succession that might directly conflict with one another without verifying that the first operation has successfully propagated through the entire enterprise network. Specifically, avoid deleting Enterprise Replication objects such as replicates, replicate sets, and Enterprise Replication servers, and immediately re-creating those objects with the same name. Doing so can cause failures in the Enterprise Replication system at the time of the operation or later. These failures might manifest themselves in ways that do not directly indicate the source of the problem. If you must delete and re-create a definition, use a different name for the new object (for example, delete replicate a.001 and recreate it as a.002) or wait until the delete action has successfully propagated through the entire Enterprise Replication system before you re-create the object. The former strategy is
2-6
especially appropriate if you have database servers that are not connected to the Enterprise Replication network at all times. It might take a significant amount of time before the operation is propagated to those disconnected servers.
Backup and Restore Considerations

When backing up and restoring database servers that participate in replication, do not stop Enterprise Replication before performing a backup on an Enterprise Replication system.
Database and Table Design Considerations

Consider the following when designing databases and tables for replication: v Unbuffered Logging v Table Types v Shadow Columns v SERIAL Data Types and Primary Keys v Cascading Deletes v Triggers v Sequence Objects Unbuffered Logging Databases on all server instances involved in replication must be created with logging. It is recommended that you replicate tables only from databases created with unbuffered logging. Enterprise Replication evaluates the logical log for transactions that modify tables defined for replication. If a table defined for replication resides in a database that uses buffered logging, the transactions are not immediately written to the logical log, but are instead buffered and then written to the logical log in a block of logical records. When this occurs, Enterprise Replication evaluates the buffer of logical-log records all at once, which consumes excess CPU time and memory. When you define a table for replication in a database created with unbuffered logging, Enterprise Replication can evaluate the transactions as they are produced. To create a database with unbuffered logging, use:
CREATE DATABASE db_name WITH LOG
To minimize impact on the system, Enterprise Replication uses buffered logging whenever possible, even if the database is defined as unbuffered. For more information, see the section on CREATE DATABASE in the IBM Informix: Database Design and Implementation Guide.
2-7
Table Types The following table types are not supported by Enterprise Replication: v RAW tables Because RAW tables are not logged, they cannot be replicated using Enterprise Replication. v Temporary tables Because the database server deletes temporary tables when an application terminates or closes the database, you should not include these tables in your replication environment. For more information on table types, see IBM Informix: Database Design and Implementation Guide. Out-of-Row Data Enterprise Replication collects out-of-row data for transmission after the user transaction has committed. Due to activity on the replicated row, the data might not exist at the time Enterprise Replication collects it for replication. In such cases, Enterprise Replication normally applies a NULL on the target system. Therefore, you should avoid placing a NOT NULL constraint on any replicated column that includes out-of-row data. Shadow Columns In an update-anywhere replication environment, you must provide for conflict resolution using a conflict-resolution rule (see Conflict Resolution on page 3-7). When you create a table that uses the time stamp or time stamp plus SPL conflict-resolution rule, you must define the shadow columns, cdrserver and cdrtime on both the source and target replication servers. Tip: If you plan to use only the ignore conflict-resolution rule, you do not need to define the cdrserver and cdrtime shadow columns. For more information, see Preparing Tables for Conflict Resolution on page 4-20. Primary Key Constraint All tables involved in replication must have a PRIMARY KEY constraint defined on at least one column, which forces the column to be unique. (For more information about primary keys, see the IBM Informix: Database Design and Implementation Guide and the IBM Informix: Guide to SQL Syntax.) Important: Because primary key updates are sent as DELETE/INSERT statement pairs, avoid changing the primary key and updating data in the same transaction.
2-8
SERIAL Data Types and Primary Keys If you plan to use SERIAL data types (SERIAL and SERIAL8) as the primary key for a table, the same serial value might be generated on two servers at the same time. To avoid this problem, use the CDR_SERIAL configuration parameter to generate non-overlapping (unique) values for SERIAL columns across all database servers in your replication environment. Set CDR_SERIAL in the ONCONFIG file for each primary (source) database server. For more information and examples, see CDR_SERIAL Configuration Parameter on page B-8. If you do not set CDR_SERIAL, you must specify that the serial column is part of a composite primary key, to avoid generating non-unique SERIAL primary keys. The non-serial column part of the primary key identifies the server on which the row was initially created. Cascading Deletes If a table includes a cascading delete, when a parent row is deleted, the children are also deleted. If both the parent and child tables participate in replication, the deletes for both the parent and child are replicated to the target servers. If the same table definition exists on the target database, Enterprise Replication attempts to delete the child rows twice. Enterprise Replication usually processes deletes on the parent tables first and then the children tables. When Enterprise Replication processes deletes on the children, an error might result, because the rows were already deleted when the parent was deleted. The table in Table 2-1 indicates how Enterprise Replication resolves cascading deletes with conflict-resolution scopes and rules. For more information on cascading deletes, see the ON DELETE CASCADE section in the IBM Informix: Guide to SQL Syntax.
Table 2-1. Resolving Cascade Deletes Conflict-Resolution Rule Time stamp Ignore Ignore Conflict-Resolution Scope Row-by-row or transaction Transaction Row-by-row Actions on Delete Errors Continue processing rest of the transaction Abort entire transaction Continue processing rest of the transaction
Triggers A trigger is a database object that automatically sets off a specified set of SQL statements when a specified event occurs.
2-9
If the --firetrigger option is enabled on a replicate, any triggers defined on a table that participates in replication are invoked when transactions are processed on the target server. However, because Enterprise Replication only replicates the final result of a transaction, triggers execute only once on the target regardless of how many triggers execute on the source. In cases where the final evaluation of the transaction results in no replication (for example, an INSERT where the final row image is a DELETE, as shown in Table 1-2 on page 1-12), no triggers execute on the target database. If the same triggers are defined on both the source and target tables, any insert, update, or delete operation that the triggers generate are also sent to the target database server. For example, the target table might receive replicate data caused by a trigger that also executes locally. Depending on the conflict-resolution rule and scope, these operations can result in errors. To avoid this problem, define the replicate to not fire triggers on the target table. For more information on triggers, see Enabling Triggers on page 6-12 and the CREATE TRIGGER section in IBM Informix: Guide to SQL Syntax. Using Constraints When using constraints, ensure that the constraints you add at the target server are not more restrictive than those at the source server. Discrepancies between constraints at the source and target servers can cause some rows to fail to be replicated. For tables that have referential integrity constraints set up between them, if you need to run a repair job to resynchronize the data in the tables, you can define the repair job for the replicate set. For replicate sets, Enterprise Replication synchronizes tables in an order that preserves referential integrity constraints (for example, child tables are synchronized after parent tables). When you run a repair job, or an initial synchronization (when you add a new table to your replication environment), rows that fail to be repaired due to discrepancies between constraints are recorded in the synchronization failures table. See Appendix H, Synchronization Failures Table for information about using this table to solve these errors. Sequence Objects In bi-directional Enterprise Replication, if you replicate tables using sequence objects for update, insert, or delete operations, the same sequences might be generated on different servers at the same time, leading to collisions. To avoid this problem, define sequence objects on each server so that the generated sequences are disjointed. For more information, see the IBM Informix: Guide to SQL Syntax.
2-10
Transaction Processing Considerations

Many variables affect what impact replicating data has on your transaction processing. This section discusses some of these variables: v Replication Volume v Distributed Transactions v Large Transactions v Supported SQL Statements Replication Volume To determine replication volume, you must estimate how many data rows change per day. For example, an application issues a simple INSERT statement that inserts 100 rows. If this table is replicated, Enterprise Replication must propagate and analyze these 100 rows before applying them to the targets. Distributed Transactions A distributed transaction is a transaction that commits data in a single transaction over two or more database servers. Outside of the replication environment, Dynamic Server uses a two-phase commit protocol to ensure that the transaction is either committed completely across all servers involved or is not committed on any server. For more information about the two-phase commit protocol, see the IBM Informix: Dynamic Server Administrator's Guide. In a replication environment, when a distributed transaction is committed across the source servers, each part of the transaction that applies to the local server is written to the local logical logs. When Enterprise Replication retrieves the transaction from the logical logs and forms its transaction data, it is unable to identify the separate transaction data as the original single transaction. This situation could result in Enterprise Replication applying one transaction successfully while aborting another. Another result might be a time lapse between the application of one transaction and another (depending on how much transaction data is in each servers send queue and the state of the server). Large Transactions While Enterprise Replication is able to handle large transactions, it is optimized for small transactions. For best performance, avoid replicating large transactions. Large transactions are handled with a grouper paging file located in temporary smart large objects. Enterprise Replication can process transactions
2-11
up to 4 TB in size. For more information, see Setting Up the Grouper Paging File on page 4-14. You can view Enterprise Replication grouper paging statistics with the onstat -g grp pager command (see onstat -g grp on page C-7). Instead of using Enterprise Replication to perform a batch job, use BEGIN WORK WITHOUT REPLICATION to run the batch job locally on each database server. For more information, see Blocking Replication on page 4-18. Supported SQL Statements After you define Enterprise Replication on a table by including that table as a participant in a replicate you cannot exclusively lock a database that is involved in replication (or perform operations that require an exclusive lock). However, you can exclusively lock a table in a database. To use the forbidden and limited SQL statements described in this section against a table defined for replication, you must first stop (not suspend) the replicate that contains the table, before running the SQL statement. After modifying the table at all required nodes, restart the replicate. For more information, see Managing Replicates on page 7-5. Forbidden SQL Statements: You cannot use the following SQL statements against a table that is included in a replicate: v DROP TABLE v RENAME TABLE v TRUNCATE (or TRUNCATE TABLE) Limited SQL Statements: The following additional limitations also apply to tables defined for replication: v Do not add or drop rowids. v Do not add or drop CRCOLS (shadow columns): ALTER TABLE ... ADD CRCOLS ALTER TABLE ... DROP CRCOLS For more information about CRCOLS, see Preparing Tables for Conflict Resolution on page 4-20. v Do not remove or disable the primary key constraint. v Do not modify the primary key columns. For example, do not alter the column to add default values or other integrity constraints. v Do not change the primary key from one column to another. For example, if a primary key is defined on col1, do not change the primary key to col2.
2-12
Permitted SQL Statements: Enterprise Replication permits the following SQL statements with no limitations: v SET object mode (no disabling of primary key constraint) v START VIOLATIONS TABLE v v v v v v v v v v v STOP VIOLATIONS TABLE CREATE TRIGGER DROP TRIGGER CREATE VIEW DROP VIEW CREATE SYNONYM DROP SYNONYM ADD INDEX DROP INDEX ALTER INDEX ALTER TABLE (except for the primary key)
Tip: You can rename both dbspaces and sbspaces while Enterprise Replication is active.
Replication Environment Considerations

Each replication system that you create affects your environment. Consider the following when setting up your replication environment: v Time Synchronization v Using GLS with Enterprise Replication Time Synchronization Whenever you use replication that requires time stamp conflict resolution (see Conflict Resolution on page 3-7), the operating system times of the database servers that participate in the replicate must be synchronized. All time stamps and internal computations are performed in Greenwich Mean Time (GMT) and have an accuracy of plus or minus one second. Important: Enterprise Replication does not manage clock synchronization between database servers that participate in a replicate. To synchronize the time on one database server with the time on another database server, use one of the following commands.
2-13
Operating System UNIX Windows
Command rdate hostname net time \\servername /set net time /domain:servername /set
Important: These commands do not guarantee the times will remain synchronized. You should use a product that supplies a network time protocol to ensure that times remain synchronized. For information on tools for synchronizing the times, refer to your operating system documentation. Using GLS with Enterprise Replication An Enterprise Replication system can include databases in different locales, with the following restrictions: v When you define a database server for Enterprise Replication, that server must be running in the English locale. In other words, the syscdr database on every Enterprise Replication server must be in the English locale. v You can replicate only between databases that are in the same locale. v Replicate names can be in the locale of the database. Code-set conversion with the GLS library requires only those code-set conversion files found in the $INFORMIXDIR/gls/cv9 directory. v For U.S. English, locales are handled automatically by the Client SDK/Informix Connnect installation and setup. v For non-U.S. English locales, you might need to explicitly provide the locale and conversion files. For information about how to specify a nondefault locale and other considerations related to GLS locales, see the IBM Informix: GLS User's Guide.
Enterprise Replication Data Types

Enterprise Replication supports built-in data types and user-defined data types, including row types and collection types. This section describes how Enterprise Replication handles special data types: v Replicating on Heterogeneous Hardware v Replicating Simple and Smart Large Objects v Replicating Opaque User-Defined Data Types For general information on data types, refer to the IBM Informix: Guide to SQL Reference.
2-14
Important: Enterprise Replication does not support replication of simple large objects stored on optical devices. Important: Enterprise Replication does not verify the data types of columns in tables that participate in replication. The replicated column in a table on the source database server must have the same data type as the corresponding column on the target server. The exception to this rule is cross-replication between simple large objects and smart large objects. If you use SERIAL or SERIAL8 data types, you must be careful when defining serial columns. For more information, see SERIAL Data Types and Primary Keys on page 2-9. Replicating on Heterogeneous Hardware Enterprise Replication supports all primitive data types across heterogeneous hardware. If you define a replicate that includes non-primitive data types (for example, BYTE and TEXT data), the application must resolve data-representation issues that are architecture dependent. If you use floating-point data types with heterogeneous hardware, you might need to use IEEE floating point or canonical format for the data transfers. For more information, see Using the IEEE Floating Point or Canonical Format on page 6-12. Replicating Simple and Smart Large Objects Enterprise Replication replicates: v Simple large object data types (TEXT and BYTE) You can store simple large objects either in the tblspace with the rest of the table columns (in a dbspace) or in a blobspace. v Smart large object data types (BLOB and CLOB) You must store smart large objects in sbspaces. For more information about database storage, see the IBM Informix: Dynamic Server Administrator's Guide. Replicating Simple Large Objects from Tblspaces: Simple large object data that is stored in tblspaces (rather than in blobspaces) is placed in the logical log. Enterprise Replication reads the logical log to capture and evaluate the data for potential replication. Replicating Large Objects from Blobspaces or Sbspaces: Enterprise Replication does not retrieve simple large object data that is stored in blobspaces and smart large object data that is stored in sbspaces from the
2-15
logical log. Instead, Enterprise Replication retrieves the large object data directly from the blobspace or sbspace before sending the data to the target database server. It is possible that a transaction subsequent to the transaction being replicated can modify or delete a simple or smart large object that Enterprise Replication is trying to retrieve. If Enterprise Replication encounters a row whose large object (simple or smart) has been modified or deleted by a subsequent transaction, Enterprise Replication does not send the data in the large object. In most cases, the subsequent transaction that modified or deleted the large object will also be replicated, so the data again becomes consistent once that transaction is replicated. The data in the large object is inconsistent for only a short time. Keep in mind that if you specify sending only the columns that changed, the data might not get updated during the next update of the row. For more information, see Replicating Only Changed Columns on page 6-11. Tip: Enterprise Replication allows cross-replication between simple large objects and smart large objects. For example, you can replicate a simple large object on the source database server to a smart large object on the target server or vice versa. Conflict Resolution for Simple and Smart Large Objects: By default, Enterprise Replication performs all conflict detection and resolution at the row level. However, in some cases, simple large object data that is stored in a tblspace (rather than in a blobspace) is accepted by the target server even if the row is rejected. This does not apply to simple large object data that is stored in blobspaces or smart large object data that is stored in sbspaces. Time-Stamp Conflict Resolution for Simple Large Objects: When a replicated BYTE or TEXT column is modified on the source database server, Enterprise Replication records the value of cdrserver and cdrtime for that column. (For more information on cdrserver and cdrtime, see Preparing Tables for Conflict Resolution on page 4-20.) If the column on the target database server is also stored in a tablespace (rather than in a blobspace), Enterprise Replication evaluates the cdrserver and cdrtime values in the source and target columns and uses the following logic to determine if the data is to be applied: v If the column of the replicated data has a time stamp that is greater than the time stamp of the column on the local row, the data for the column is accepted for replication. v If the server ID and time stamp of the replicated column are equal to the server ID and time stamp on the column on the local row, the data for the column is accepted for replication.
2-16
v If there is no SPL conflict-resolution rule and the time stamps are equal, then Enterprise Replication applies the data to the row with the lowest CDR server ID. SPL Conflict Resolution for Simple Large Objects: If the replicate is defined with an SPL conflict-resolution rule, the SPL routine must return the desired action for each BYTE or TEXT column. When the routine is invoked, information about each BYTE or TEXT column is passed to the routine as five separate fields. The following table describes the fields.
Argument Column size (INTEGER) BLOB flag [CHAR(1)] Description The size of the column (if data exists for this column). NULL if the column is NULL. For the local row, the field is always NULL. For the replicated row: v D indicates BYTE or TEXT data is sent from the source database server. v U indicates BYTE or TEXT data is unchanged on the source database server. Column type [CHAR(1)] v P indicates tablespace data. v B indicates blobspace data. ID of last update server [CHAR(18)] The ID of the database server that last updated this column for tablespace data. For blobspace data: NULL Last update time (DATETIME YEAR TO SECOND) For tablespace data: The date and time when the data was last updated. For blobspace data: NULL
For information on creating stored procedures, see the IBM Informix: Guide to SQL Tutorial. If the routine returns an action code of A, D, I, or U, the routine parses the return values of the replicated columns. Each BYTE or TEXT column can return a two-character field. For information about the action codes, refer to SPL Conflict-Resolution Rule on page 3-10. The first character defines the desired option for the BYTE or TEXT column, as the following table shows.
2-17
Value C N R L
Function Performs a time-stamp check for this column as used by the time-stamp rule Sets the replicate column to NULL Accepts the replicated data as it is received Retains the local data
The second character defines the desired option for blobspace data if the data is found to be undeliverable, as the following table shows.
Value N L O X Function Sets the replicated column to NULL Retains the local data (default) Aborts the row Aborts the transaction
SPL Conflict Resolution for Smart Large Objects: Enterprise Replication handles conflict resolution for smart large objects using the SPL conflict-resolution rule in the same way as for simple large objects. See Conflict Resolution for Simple and Smart Large Objects on page 2-16. Distributing BYTE and TEXT Data: If Enterprise Replication processes a row and discovers undeliverable BYTE or TEXT columns, the following actions can occur: v Any undeliverable columns are set to NULL if the replication operation is an INSERT and the row does not already exist at the target. v The old value of the local row is retained if the replication operation is an UPDATE or if the row already exists on the target. Considerations for Replicating Smart Large Objects: The following conditions apply to replicating smart large objects: v Enterprise Replication does not support replication of smart large object updates performed outside of a row update. v After you update a smart large object that is referenced explicitly in the table schema, you must update the referencing row before Enterprise Replication can replicate the updated smart large object. For example:
UPDATE table_name SET smart_large_object_column = x
For more information, see the IBM Informix: Guide to SQL Syntax.
2-18
v Enterprise Replication replicates updates to in-place smart large objects by sending a new copy of the entire smart large object. Enterprise Replication does not send only the logged changes to update smart large objects. v Enterprise Replication does not support sharing out-of-row data (multiple references to a smart large object) during replication. If you try to replicate multiple references to the same smart large object on the source database server, Enterprise Replication does not re-create those references on the target database server. Instead, Enterprise Replication creates multiple smart large objects on the target database server. Replicating Opaque User-Defined Data Types Enterprise Replication supports built-in data types and extended data types, including opaque data types and user-defined types (UDTs). Installing and Registering UDTs: You must install and register UDTs and their associated support routines on all database servers participating in Enterprise Replication prior to starting replication. If you combine Enterprise Replication with High-Availability Data Replication (HDR), you must install UDTs on both HDR database servers, but only register them on the primary HDR database server (see IBM Informix: Dynamic Server Administrator's Guide). UDT Support Functions: If you plan to replicate opaque user-defined types (UDTs), the UDT designer must provide two support functions, streamwrite() and streamread(). This also applies to UDTs embedded in complex types. The purpose of these functions is similar to the existing send() and receive() functions provided for client/server transmissions. For information on writing these support functions, see the section on Enterprise Replication stream support functions in the IBM Informix: DataBlade API Programmer's Guide. When preparing a row that includes any UDT columns to queue to the target system, Enterprise Replication calls the streamwrite() function on each UDT column. The function converts the UDT column data from the in-server representation to a representation that can be shipped over the network. This allows Enterprise Replication to replicate the column without understanding the internal representation of the UDT. On the target server, Enterprise Replication calls the streamread() function for each UDT column that it transmitted using the streamwrite() function. Considerations for Replicating Opaque Data Types: The following conditions apply to replicating opaque data types:
2-19
v The WHERE clause of the SELECT statement of the participant modifier can reference an opaque UDT as long as the UDT is always stored in row. v Any UDRs in a WHERE clause can use only parameters whose values can be extracted fully from the logged row images, plus any optional constants. v All of the columns in the SELECT statement of each participant definition must be actual columns in that table. Enterprise Replication does not support virtual columns (results of UDRs on table columns). See Participant Modifier on page A-112 for information on the WHERE clause in participant definitions. v You cannot use SPL routines for conflict resolution if the replicate includes any UDTs in the SELECT statement or if the replicate is defined to replicate only changed columns. See Conflict Resolution on page 3-7 and Replicating Only Changed Columns on page 6-11. v Enterprise Replication allows you to define replicates on tables that contain one or more UDT columns as the primary key. For more information, see the section on primary key constraints in the IBM Informix: Guide to SQL Syntax. Replicating Table Hierarchies: To replicate tables that form a hierarchy, you must define a separate replicate for each table. If you define a replicate on a super table, Enterprise Replication does not automatically create implicit replicate definitions on the subordinate tables. Tip: Enterprise Replication does not require that the table hierarchies be identical on the source and target servers. You must use conflict resolution uniformly for all tables in the hierarchy. In other words, either no conflict resolution for all tables or conflict resolution for all tables. Verifying the Data Type of Replicated Columns By using master replicates you can verify that all participants in a replicate have columns with matching data types. Master replicates also allow verification that each participant contains all replicated columns, and optionally that column names are the same on each participant. See Defining Master Replicates on page 6-6 for more information.
2-20
Part 2. Setting Up and Managing Enterprise Replication
Chapter 3. Selecting the Enterprise Replication System and Network Topology

Selecting the Enterprise Replication System . Primary-Target Replication System . . . Primary-Target Business Models . . . Primary-Target Considerations . . . Update-Anywhere Replication System . . Conflict Resolution . . . . . . . . Conflict-Resolution Rule . . . . . Scope . . . . . . . . . . . Choosing a Replication Network Topology . Fully Connected Topology . . . . . Hierarchical Replication Topologies . . HR Topology Terminology . . . . Hierarchical Tree. . . . . . . . Forest of Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1 . 3-1 . 3-2 . 3-5 . 3-6 . 3-7 . 3-7 . 3-13 . 3-14 . 3-14 . 3-15 . 3-15 . 3-16 . 3-17
In This Chapter
This chapter describes types of replication systems provided by Enterprise Replication and discusses the trade-offs associated with performance and data availability.
Selecting the Enterprise Replication System

Enterprise Replication supports the following types of replication systems: v Primary-Target Replication System v Update-Anywhere Replication System
Primary-Target Replication System

In the primary-target replication system, the flow of information is in one direction. In primary-target replication, all database changes originate at the primary database and are replicated to the target databases. Changes at the target databases are not replicated to the primary. A primary-target replication system can provide one-to-many or many-to-one replication: v One-to-many replication
3-1
In one-to-many (distribution) replication, all changes to a primary database server are replicated to many target database servers. Use this replication model when information gathered at a central site must be disseminated to many scattered sites. v Many-to-one replication In many-to-one (consolidation) replication, many primary servers send information to a single target server. Use this replication model when many sites are gathering information (for example, local field studies for an environmental study) that needs to be centralized for final processing. Primary-Target Business Models Primary-target Enterprise Replication systems support the following business models: v Data Dissemination v Data Consolidation v Workload Partitioning v Workflow Replication Data Dissemination: Data dissemination supports business needs where data is updated in a central location and then replicated to read-only sites. This method of distribution can be particularly useful for online transaction processing (OLTP) systems where data is required at several sites, but because of the large amounts of data, read-write capabilities at all sites would cripple the performance of the application. Figure 3-1 on page 3-2 illustrates data dissemination.
Target Database server (Read-only) Primary Database server Target Database server (Read-only) (Read-write)
Target Database server (Read-only)
Target Database server (Read-only)
Figure 3-1. Data Dissemination in a Primary-Target Replication System
Data Consolidation: As businesses reorganize to become more competitive, many choose to consolidate data into one central database server. Data
3-2
consolidation allows the migration of data from several database servers to one central database server. In Figure 3-2, the remote locations have read-write capabilities while the central database server is read-only.
Primary Database server (Read-write) Target Database server Primary Database server (Read-write) (Read-only)
Primary Database server (Read-write)
Primary Database server (Read-write)
Figure 3-2. Data Consolidation in a Primary-Target Replication System
Businesses can also use data consolidation to off-load OLTP data for decision support (DSS) analysis. For example, data from several OLTP systems can be replicated to a DSS system for read-only analysis. Pay close attention to the configuration of the tables from which data is replicated to ensure that each primary key is unique among the multiple primary database servers. Workload Partitioning: Workload partitioning gives businesses the flexibility of assigning data ownership at the table-partition level, rather than within an application. Figure 3-3 illustrates workload partitioning.
3-3
Asia-Pacific Database server
U.S.A. Database server
Europe Database server
A-P Partition
emp# 2994 4402 empname N. Night R. River
A-P Partition
emp# 5783 1235 empname A. Alder M. Markar
A-P Partition
emp# 5761 6642 empname B. Barry Z. Zachary
U.S.A. Partition
emp# 6398 9456 empname D. Davis E. Eldridge
U.S.A. Partition
emp# 9631 4951 empname J. Jones H. Height
U.S.A. Partition
emp# 3622 7333 empname C. Cowpar K. Kristen
Europe Partition
emp# 6520 3798 empname P. Peters G. Gladys
Europe Partition
emp# 8002 9966 empname F. Fire S. Smith
Europe Partition
emp# 3711 5540 empname L. Lane T. Thomas
Owner of partition (Read-write)
Read-only privileges
Figure 3-3. Workload Partitioning in a Primary-Target Replication System
In Figure 3-3, the replication model matches the partition model for the employee tables. The Asia-Pacific database server owns the partition and can therefore update, insert, and delete employee records for personnel in its region. The changes are then propagated to the U.S. and European regions. The Asia-Pacific database server can query or read the other partitions locally, but cannot update those partitions locally. This strategy applies to other regions as well. Workflow Replication: Unlike the data dissemination model, in a workflow-replication system, the data moves from site to site. Each site processes or approves the data before sending it on to the next site.
3-4
Order entry
custno custname 1234 XYZLTD 1235 XSPORTS
Accounting
Inventory management
Ship
Order processing
Order processing
Order processing
Order processing
Figure 3-4. A Workflow-Replication System Where Update Authority Moves From Site to Site
Figure 3-4 illustrates an order-processing system. Order processing typically follows a well-ordered series of steps: orders are entered, approved by accounting, inventory is reconciled, and the order is finally shipped. In a workflow-replication system, application modules can be distributed across multiple sites and databases. Data can also be replicated to sites that need read-only access to the data (for example, if order-entry sites want to monitor the progress of an order). A workflow-replication system, like the primary-target replication system, allows only unidirectional updates. Many facts that you need to consider for a primary-target replication system should also be considered for the workflow-replication system. However, unlike the primary-target replication system, availability can become an issue if a database server goes down. The database servers in the workflow-replication system rely on the data updated at a previous site. Consider this fact when you select a workflow-replication system. Primary-Target Considerations The following sections describe some of the factors to consider when you select a primary-target replication system: v Administration Primary-target replication systems are the easiest to administer because all updates are unidirectional and therefore, no data update conflicts occur. Primary-target replication systems use the ignore conflict-resolution rule. See Conflict-Resolution Rule on page 3-7. v Capacity planning All replication systems require you to plan for capacity changes. For more information, see Preparing Data for Replication on page 4-17. v High-availability planning In the primary-target replication system, if a target database server or network connection goes down, Enterprise Replication continues to log information for the database server until it becomes available again. If a
3-5
database server is unavailable for some time, you might want to remove the database server from the replication system. If the unavailable database server is the read-write database server, you must plan a course of action to change read-write capabilities on another database server. If you require a fail-safe replication system, you should select a high-availability replication system. For more information, see High-Availability Replication System on page 5-1.
Update-Anywhere Replication System

In update-anywhere replication, changes made on any participating database server are replicated to all other participating database servers. This capability allows users to function autonomously even when other systems or networks in the replication system are not available. Figure 3-5 illustrates an update-anywhere replication system.
Washington service center Database server Update Update Database server Los Angeles service center Update
New York service center Database server
Figure 3-5. Update-Anywhere Replication System
Because each service center can update a copy of the data, conflicts can occur when the data is replicated to the other sites. To resolve update conflicts, Enterprise Replication uses conflict resolution. For more information, see Conflict Resolution on page 3-7. Review the following information before you select your update-anywhere replication system: v Administration Update-anywhere replication systems allow peer-to-peer updates, and therefore require conflict-resolution (see Conflict Resolution on page 3-7). Update-anywhere replication systems require more administration than primary-target replication systems. v Information consistency
3-6
Some risk is associated with delivering consistent information in an update-anywhere replication system. You determine the amount of risk based on the type of conflict-resolution rules and routines you choose for resolving conflicts. You can configure an update-anywhere replication system where no data is ever lost; however, you might find that other factors (for example, performance) outweigh your need for a fail-safe mechanism to deliver consistent information. v Capacity Planning All replication systems require you to plan for capacity changes. For more information, see Preparing Data for Replication on page 4-17. In particular, if you choose the time stamp or time stamp plus SPL routine conflict-resolution rule, see Delete Table Disk Space on page 4-9 and Shadow Column Disk Space on page 4-9. v High Availability If any of your database servers are critical, consider using HDR to provide backup servers. For more information, see High-Availability Replication System on page 5-1.
Conflict Resolution
When multiple database servers try to update the same row simultaneously (the time stamp for both updates is the same GMT time), a collision occurs. For more information, see Applying Replicated Data on page 1-14. Enterprise Replication must determine which new data to replicate. To solve conflict resolution, you must specify the following for each replicate: v A conflict-resolution rule v The scope of the rule Conflict-Resolution Rule Enterprise Replication supports the following conflict-resolution rules.
Conflict Resolution Rule Ignore Time stamp SPL routine Effect Enterprise Replication does not attempt to resolve conflicts. The row or transaction with the most recent time stamp is applied. Enterprise Replication uses a routine written in SPL (Stored Procedure Language) that you provide to determine which data should be applied. If the time stamps are identical, Enterprise Replication invokes an SPL routine that you provide to resolve the conflict. Reference page 3-8 page 3-9 page 3-10
Time stamp with SPL routine
page 3-9, page 3-10
3-7
Conflict Resolution Rule Always-apply
Effect Enterprise Replication does not attempt to resolve conflicts.
Reference page 3-13
For all conflict-resolution rules except ignore and always-apply, you must create shadow columns in the tables on both the source and target servers involved in replication. For more information, see Shadow Columns on page 2-8. Enterprise Replication supports up to two conflict-resolution rules for each replicate: a primary rule and a secondary rule (if desired). Table 3-1 shows the valid combinations of Enterprise Replication conflict-resolution rules.
Table 3-1. Valid Conflict-Resolution Rule Combinations Primary Rule Ignore Time stamp Time stamp SPL routine Always-apply Secondary Rule None None SPL routine None None
Ignore Conflict-Resolution Rule: The ignore conflict-resolution rule does not attempt to detect or resolve conflicts. A row or transaction either applies successfully or it fails. A row might fail to replicate because of standard database reasons, such as a deadlock situation, when an application locks rows. The ignore conflict-resolution rule can only be used as a primary conflictresolution rule and can have either a transaction or a row scope (as described in Scope on page 3-13). Table 3-2 describes the ignore conflict-resolution rule.
Table 3-2. Ignore Conflict-Resolution Rule Database Operation Row Exists in Target? No Yes Insert Apply row Discard row Update Discard row Apply row Delete Discard row Apply row
When a replication message fails to apply to a target, you can spool the information to one or both of the following directories: v Aborted-transaction spooling (ATS) If selected, all buffers in a failed replication message that compose a transaction are written to this directory.
3-8
v Row-information spooling (RIS) If selected, the replication message for a row that could not be applied to a target is written to this directory. For more information, see Chapter 8, Monitoring and Troubleshooting Enterprise Replication, on page 8-1. Time-Stamp Conflict-Resolution Rule: The time-stamp rule evaluates the latest time stamp of the replication against the target and determines how to resolve any conflict. Tip: All time stamps and internal computations are performed in Greenwich Mean Time (GMT). The time-stamp resolution rule behaves differently depending on which scope is in effect: v Row scope Enterprise Replication evaluates one row at a time. The row with the most recent time stamp wins the conflict and is applied to the target database servers. If an SPL routine is defined as a secondary conflict-resolution rule, the routine resolves the conflict when the row times are equal. v Transaction scope Enterprise Replication evaluates the most recent row-update time among all the rows in the replicated transaction. This time is compared to the time stamp of the appropriate target row. If the time stamp of the replicated row is more recent than the target, the entire replicated transaction is applied. If a routine is defined as a secondary conflict-resolution rule, it is used to resolve the conflict when the time stamps are equal. For more information, see Scope on page 3-13. A secondary routine is invoked only if Enterprise Replication evaluates rows and discovers equal time stamps. If no secondary conflict-resolution rule is defined and the time stamps are equal, the transaction from the database server with the lower value in the cdrserver shadow column wins the conflict. Table 3-3 on page 3-10 shows how a conflict is resolved based on the latest time stamp with row scope. The time stamp Tlast_update (the time of the last update) represents the row on the target database server with the last (most recent) update. The time stamp Trepl (the time when replication occurs) represents the time stamp on the incoming row.
3-9
Enterprise Replication first checks to see if a row with the same primary key exists in either the target table or its corresponding delete table. Important: Do not remove the delete tables created by Enterprise Replication. The delete table is automatically removed when the last replicate defined with conflict resolution is deleted. If the row exists, Enterprise Replication uses the latest time stamp to resolve the conflict.
Table 3-3. Conflict Resolution Based on the Time Stamp Row Exists on Target? No Database Operation Time Stamp n/a Insert Apply row Update Apply row (Convert UPDATE to INSERT) Apply row Delete Apply row (INSERT into Enterprise Replication delete table) Apply row
Yes
Tlast_update < Trepl
Apply row (Convert INSERT to UPDATE) Discard row
Tlast_update > Trepl Tlast_update = Trepl
Apply row if no routine is defined as a secondary conflict-resolution rule. Otherwise, invoke the routine.
The time-stamp conflict-resolution rule assumes time synchronization between cooperating Enterprise Replication servers. For more information, see Time Synchronization on page 2-13. SPL Conflict-Resolution Rule: Tip: The SPL rule allows you complete flexibility to determine which row prevails in the database. However, for most users, the time-stamp conflict-resolution rule provides sufficient conflict resolution. You can assign an SPL routine as the primary conflict-resolution rule. If you use an SPL routine as a secondary conflict-resolution rule, the time-stamp conflict-resolution rule must be the primary rule. Important: The owner of an SPL routine used for conflict resolution must be the same as the owner of the table. Routines for conflict-resolution must be in SPL. Enterprise Replication does not allow user-defined routines in C or in Java.
3-10
Important: You cannot use an SPL routine or a time stamp with an SPL routine if the replicate is defined to replicate only changed columns or the replicated table contains any extensible data types. See Replicating Only Changed Columns on page 6-11. Enterprise Replication passes the following information to an SPL routine as arguments.
Argument Server name [CHAR(18)] Time stamp (DATETIME YEAR TO SECOND) Description From the local target row NULL if local target row does not exist From the local target row NULL if local target row does not exist
Local delete-table indicator [CHAR(1)] Y indicates the origin of the row is the delete or Local key delete-row indicator table. [CHAR(1)] K indicates the origin of the row is the replicate-key delete row. If a conflict occurs while deleting a primary key row, because the local row with the old key no longer exists, the received key delete row is passed as the local row (using the seventh argument, local row data, described below). The received key insert row is passed to the stored procedure as the replicated row using the eighth argument, described below. Server name [CHAR(18)] Time stamp (DATETIME YEAR TO SECOND) Replicate action type [CHAR(1)] Of the replicate source From the replicated row I - insert D - delete U - update Where the regular SQL format is taken from the SELECT clause of the participant list Where the regular SQL format is taken from the SELECT clause of the participant list
Local row data returned in regular SQL format Replicate row data after-image returned in regular SQL format
The routine must set the following arguments before the routine can be applied to the replication message.
3-11
Argument An indicator of the desired database operation to be performed [CHAR(1)]
Description Same as the replicate action codes with the following additional codes v A - Accept the replicated row and apply the column values returned by the SPL routine. For example, if Enterprise Replication receives an insert and the row already exists locally, the insert is converted to an update v S - Accept the replicated row and apply the column values as received from the other site. For example, if Enterprise Replication receives an insert and the row already exists locally, the insert fails at the time Enterprise Replication tries to apply the transaction to the database, and the transaction aborts with an SQL error. v O - Discard the replicated row. v X - Abort the transaction.
A non-zero integer value to request logging of the conflict resolution and the integer value in the spooling files (INTEGER)
Logging value takes effect only if logging is configured for this replicate.
The columns of the row to be applied This list of column values is not parsed if the to the target table replicate action type replicate action type that the routine returns is in regular SQL format S, O, or X.
You can use the arguments to develop application-specific routines. For example, you can create a routine in which a database server always wins a conflict regardless of the time stamp. The following list includes some items to consider when you use an SPL routine for conflict resolution: v Any action that a routine takes as a result of replication does not replicate. v You cannot use an SPL routine to start another transaction. v Frequent use of routines might affect performance. In addition, you must determine when the SPL routine executes: v An optimized SPL routine is called only when a collision is detected and the row to be replicated fails to meet one of the following two conditions: It is from the same database server that last updated the local row on the target table. It has a time stamp greater than or equal to that of the local row.
3-12
v A nonoptimized SPL routine executes every time Enterprise Replication detects a collision. By default, SPL routines are nonoptimized. For information on specifying that the SPL routine is optimized, see Conflict Options on page A-17. Tip: Do not assign a routine that is not optimized as a primary conflict-resolution rule for applications that usually insert rows successfully. Always-Apply Conflict-Resolution Rule: The always-apply conflict-resolution rule does not attempt to detect or resolve conflicts. Unlike with the ignore conflict-resolution rule, replicated changes are applied even if the operations are not the same on the source and target servers. In the case of a conflict, the current row on the target is deleted and replaced with the replicated row from the source. Table 3-4 describes the always-apply conflict-resolution rule.
Table 3-4. Always-Apply Conflict-Resolution Rule Database Operation Row Exists in Target? No Insert Apply row Update Delete
Apply row Apply row (convert UPDATE (INSERT into to INSERT) Enterprise Replication delete table, no error returned) Apply row Deletes the row
Yes
Apply as an UPDATE (overwrite the existing row)
Scope Each conflict-resolution rule behaves differently depending on the scope. Enterprise Replication uses the following scopes: v Row scope When you choose a row scope, Enterprise Replication evaluates one row at a time. It only applies replicated rows that win the conflict resolution with the target row. If an entire replicated transaction receives row-by-row evaluation, some replicated rows are applied while other replicated rows might not be applied. v Transaction scope
3-13
When you choose a transaction scope, Enterprise Replication applies the entire transaction if the replicated transaction wins the conflict resolution. If the target wins the conflict (or other database errors are present), the entire replicated transaction is not applied. A transaction scope for conflict resolution guarantees transactional integrity. Important: Enterprise Replication defers some constraint checking on the target tables until the transaction commits. If a unique constraint or foreign-key constraint violation is found on any row of the transaction at commit time, the entire transaction is rejected (regardless of the scope) and, if you have ATS set up, written to the ATS directory. For more information, see Aborted Transaction Spooling Files on page 8-2.
Choosing a Replication Network Topology

Enterprise Replication topology describes connections that replication servers make to interact with each other. You must define the replication topology within the topology of the physical network, but the replication topology is not synonymous with the physical network topology. The order in which you define the database servers for replication and the options that you use when you define the database server determine the replication topology. Enterprise Replication supports two types of network topology: v Fully Connected Topology v Hierarchical Replication Topologies The topology that you choose influences the types of replication that you can use. The next sections describe the topologies that Enterprise Replication supports.
Fully Connected Topology

Fully connected replication topology indicates that all database servers connect to each other and that Enterprise Replication establishes and manages the connections. Replication messages are sent directly from one database server to another. No additional routing is necessary to deliver replication messages. Figure 3-6 shows a fully connected replication topology. Each database server connects directly to every other database server in the replication environment.
3-14
Europe Italy
Germany
France
Figure 3-6. Fully Connected Topology
If necessary, you can also add HDR and a backup server to any server to provide high availability. For more information, see High-Availability Replication System on page 5-1.
Hierarchical Replication Topologies

Enterprise Replication provides two types of Hierarchical Routing topology: v Hierarchical Tree v Forest of Trees HR Topology Terminology Enterprise Replication uses the terms in the Table 3-5 to describe Hierarchical Routing topology.
3-15
Table 3-5. Replication Topology Terms Term Root server Definition An Enterprise Replication server that is the uppermost level in a hierarchically organized set of information The root is the point from which database servers branch into a logical sequence. All root database servers within Enterprise Replication must be fully interconnected. Nonroot server An Enterprise Replication server that is not a root database server but has a complete global catalog and is connected to its parent and to its children A data structure that contains database servers that are linked in a hierarchical manner The topmost node is called the root. The root can have zero or more child database servers; the root is the parent database server to its children. Parent-child A relationship between database servers in a tree data structure in which the parent is one step closer to the root than the child. A database server that has a limited catalog and no children.
Tree
Leaf server
A root server is fully connected to all other root servers. It has information about all other replication servers in its replication environment. Figure 3-6 on page 3-15 shows an environment with four root servers. A nonroot server is similar to a root server except that it forwards all replicated messages for other root servers (and their children) through its parent. All nonroot servers are known to all root and other nonroot servers. A nonroot server might or might not have children. All root and nonroot servers are aware of all other servers in the replication environment. Important: In Hierarchical Routing topologies, Enterprise Replication specifies the synchronization server as the new servers parent in the current topology. For more information, see Customizing the Replication Server Definition on page 6-3 and cdr define server on page A-25. Hierarchical Tree A hierarchical tree consists of a root database server and one or more database servers organized into a tree topology. The tree contains only one root, which has no parent. Each database server within the tree references its parent. A
3-16
database server that is not a parent is a leaf. Figure 3-7 illustrates a replication tree.
Asia
Japan
China
Beijing
Guangzhou
Hong Kong
Shanghai
Figure 3-7. Hierarchical Tree Topology
In Figure 3-7, the parent-child relationship within the tree is as follows: v Asia is the parent of China and Japan. v China is the child of Asia and the parent of Beijing, Shanghai, and Guangzhou. v Guangzhou is the child of China and the parent of Hong Kong. Asia is the root database server. Japan, China, and Guangzhou are nonroot database servers. You can define Beijing, Shanghai, and Hong Kong as either nonroot database servers or leaf database servers, depending on how you plan to use them. The dashed connection from China to Shanghai indicates that Shanghai is a leaf server. Parent servers are good candidates for using HDR to provide backup servers. For more information, see Hierarchical Replication Topologies on page 3-15. Forest of Trees A forest of trees consists of several hierarchical trees whose root database servers are fully connected. Each hierarchical tree starts with a root database server. The root database servers transfer replication messages to the other root servers for delivery to its child database servers. Figure 3-8 shows a forest of trees.
3-17
North America Europe
France
Germany Asia
Japan
China
Beijing
Guangzhou
Hong Kong
Shanghai
Figure 3-8. Forest-of-Trees Topology
In Figure 3-8, North America, Asia, and Europe are root database servers. That is, they are fully connected with each other. France and Germany are in a tree whose root is Europe. Asia is the root for the six database servers in its tree. In a forest of trees, all replication messages from one tree to another must pass through their roots. For example, a replication message from Beijing to France must pass through China, Asia, and Europe. Organizing the database servers in a hierarchical tree or a forest of trees greatly reduces the number of physical connections that are required to make a replication system. If all the database servers in Figure 3-8 were fully connected, instead of being organized in trees, 55 connections would be required. To ensure that all servers retain access to the replication system, use HDR on parent servers. For more information, see Using HDR in a Forest of Trees Topology on page 5-4.
3-18
Chapter 4. Preparing the Replication Environment

Preparing the Network Environment . . . . . . . . Setting Up the Hosts File . . . . . . . . . . . Setting Up the Services File . . . . . . . . . . Setting Up the Trusted Environment . . . . . . . Verifying SQLHOSTS . . . . . . . . . . . . Setting up Database Server Groups . . . . . . . Hierarchical Routing Topologies and SQLHOSTS . . Network Encryption and SQLHOSTS . . . . . . Using the Connection Security Option (s=6) . . . . Testing the Network Environment . . . . . . . . Preparing the Disk . . . . . . . . . . . . . . Planning for Disk Space Requirements . . . . . . . Logical Log Configuration Disk Space . . . . . . Logical Log Configuration Guidelines . . . . . . Delete Table Disk Space . . . . . . . . . . . Shadow Column Disk Space . . . . . . . . . Setting Up Send and Receive Queue Spool Areas . . . Transaction Record dbspace . . . . . . . . . Row Data sbspaces . . . . . . . . . . . . Setting Up the Grouper Paging File . . . . . . . Creating ATS and RIS Directories . . . . . . . . Preparing the Database Server Environment . . . . . Setting Environment Variables . . . . . . . . . Setting Configuration Parameters . . . . . . . . Preparing Data for Replication . . . . . . . . . . Preparing Consistent Data . . . . . . . . . . Blocking Replication . . . . . . . . . . . . Using DB-Access to Begin Work Without Replication Using ESQL/C to Begin Work Without Replication . Preparing to Replicate User-Defined Types . . . . . Preparing to Replicate User-Defined Routines . . . . Preparing Tables for Conflict Resolution . . . . . . Preparing Logging Databases . . . . . . . . . Loading and Unloading Data . . . . . . . . . . High-Performance Loader . . . . . . . . . . onunload and onload Utilities . . . . . . . . . dbexport and dbimport Utilities . . . . . . . . UNLOAD and LOAD Statements . . . . . . . . Data Preparation Example . . . . . . . . . . . Using the cdr start replicate Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2 . 4-2 . 4-3 . 4-3 . 4-3 . 4-4 . 4-6 . 4-6 . 4-7 . 4-7 . 4-7 . 4-8 . 4-8 . 4-8 . 4-9 . 4-9 . 4-10 . 4-10 . 4-11 . 4-14 . 4-15 . 4-16 . 4-16 . 4-16 . 4-17 . 4-18 . 4-18 . 4-19 . 4-19 . 4-20 . 4-20 . 4-20 . 4-21 . 4-21 . 4-22 . 4-22 . 4-22 . 4-23 . 4-23 . 4-23
4-1
Using LOAD, UNLOAD, and BEGIN WORK WITHOUT REPLICATION .
. 4-24
In This Chapter
This chapter covers the steps to take to prepare your environment for replicating data with Enterprise Replication: preparing the network environment, the disk, the server environment, and the data.
Preparing the Network Environment

For more information on preparing the network environment, see the chapter on client/server connectivity in the IBM Informix: Dynamic Server Administrator's Guide. See Appendix E, Replication Examples, on page E-1, for a sample setup. To prepare your network environment: 1. Set up the hosts file. For information, see Setting Up the Hosts File on page 4-2. 2. Set up the services file. For information, see Setting Up the Services File on page 4-3. 3. Set up the trusted environment. For information, see Setting Up the Trusted Environment on page 4-3. 4. Verify the SQLHOSTS information. For information, see Verifying SQLHOSTS on page 4-3. 5. Test the network environment. For information, see Testing the Network Environment on page 4-7.
Setting Up the Hosts File

First, make sure the hosts file includes the IP addresses and system names for all database servers involved in Enterprise Replication. Important: If you are using Domain Name Service (DNS) to identify IP addresses and system names, you do not need to configure the hosts file. The hosts file is in the following location.
Operating System UNIX Windows File /etc/hosts %WINDIR%\system32\drivers\etc\hosts
Important: Leave a blank line at the end of the hosts file on Windows.
4-2
For example, your hosts file might look like the following:
123.456.789.1 sydney 123.456.789.2 melbourne
Setting Up the Services File

Next, make sure that the services file includes the port numbers and service names for all the database servers involved in Enterprise Replication. The services file is in the following location.
Operating System UNIX Windows File /etc/services %WINDIR%\system32\drivers\etc\services
Important: Leave a blank line at the end of the services file on Windows. For example, your services file might look like the following:
sydney 5327/tcp melbourne 5327/tcp
If the database servers reside on the same system, you must provide unique port numbers for each.
Setting Up the Trusted Environment

To establish the trust relationship for all users, set up the hosts.equiv file. The hosts.equiv file is in the following location.
Operating System UNIX Windows File /etc/hosts.equiv %WINDIR%\system32\drivers\etc\hosts.equiv
For example, your hosts.equiv file might look like the following:
sydney melbourne
Tip: Instead of allowing access to all users, you can set up .rhosts files in the home directory of specific users. See your operating system documentation for more information.
Verifying SQLHOSTS
Make sure that the SQLHOSTS file is set up properly on each server participating in replication.
4-3
Setting up Database Server Groups Enterprise Replication requires that all database servers participating in replication be members of database server groups. Each server in the enterprise must have a unique identifier; the database server group uniquely identifies a server. If you are combining Enterprise Replication with HDR, both the primary and secondary HDR servers must be members of the same database server group. For more information, see Managing Enterprise Replication with High-Availability Data Replication on page 5-8. Typically, a server group includes only one database server. However, if the computer has multiple network protocols or network interface cards, the server group includes all aliases for the database server. Enterprise Replication treats the server group as one object, whether it includes one or several database server names. All Enterprise Replication commands and options use the name of the database server group of the more familiar database server name (that is, the name specified by the INFORMIXSERVER environment variable) for all references to database servers. The exception is the --connect option, which can use both server name or group name. This manual also refers to a database server group as a server group. This manual uses the convention that the name of a database server group is g_ followed by the name of a database server that is in the group. This use of g_ is only a convention; g_ is not required syntax. Database Server Groups on UNIX: On UNIX, a database server group is defined in the sqlhosts file. The following example shows a very simple sqlhosts file for four Enterprise Replication servers, john, paul, george, and ringo and their database server groups. The first line describes the database server group g_john, which includes the database server john, and so on.
dbservername g_john john g_paul paul g_george george g_ringo ringo nettype group ontlitcp group ontlitcp group ontlitcp group ontlitcp hostname sydney.australia.com melbourne.australia.com perth.australia.com brisbane.australia.com servicename 10110 2939 5329 10101 options i=143 g=g_john i=144 g=g_paul i=145 g=g_george i=146 g=g_ringo
4-4
The following table describes the fields in the sqlhosts example above.
dbservername nettype hostname servicename options Database server group name or database server name Type of connection (composed of the database server product, interface type, and network protocol) The name of the computer where the database server resides The service name or port number entry in the services file v The g option specifies the name of the group to which the database server belongs. v The i option specifies a unique identifier for the database server. Make sure that this identifier is consistent for the database server across all nodes in the enterprise.
Important: The network connection entry should appear immediately after the database server group definition. Important: It is not necessary for the DBSERVERNAME to be set to a network connection; however, at least one of server names listed by the DBSERVERNAME or the DBSERVERALIASES configuration parameters should be set to a network protocol. For information about database server aliases, refer to the IBM Informix: Dynamic Server Administrator's Guide. Important: Enterprise Replication cannot use shared memory connections even if the replicating servers are on same machine. For an example of an SQLHOSTS file when combining Enterprise Replication and High-Availability Data Replication, see Managing Enterprise Replication with High-Availability Data Replication on page 5-8. For more information about database server groups and setting up SQLHOSTS, see the chapter on client/server communications in the IBM Informix: Dynamic Server Administrator's Guide. Database Server Groups on Windows: For information about preparing the SQLHOSTS connectivity information on Windows, see Appendix F, SQLHOSTS Registry Key (Windows), on page F-1. Important: It is strongly recommended that you use IBM Informix Server Administrator (ISA), rather than regedt32, to set up the SQLHOSTS registry key and database server group registry key on your Windows system. In addition, ISA allows you to administer your replication system from a web browser.
4-5
Hierarchical Routing Topologies and SQLHOSTS For hierarchical routing (HR) topologies: v Root and nonroot servers must each have complete SQLHOSTS server group information for the entire enterprise. v Each leaf server must have SQLHOSTS connectivity information only for itself and its parent (hub). Root and nonroot servers contain the complete global catalog; leaf servers do not. For more information, see HR Topology Terminology on page 3-15 and Global Catalog on page 2-5. Network Encryption and SQLHOSTS Client/server network communication is encrypted by specifying the ENCCSM module with the communications support module (CSM) option in the SQLHOSTS file. However, Enterprise Replication can only be encrypted by setting encryption configuration parameters. The ENCRYPT_CDR configuration parameter must be set to 1 or 2 to allow encryption. Important: Enterprise Replication cannot use a connection configured with a CSM. To combine client/server network encryption with Enterprise Replication encryption, configure two network connections for each database server. The configuration in the SQLHOSTS file would look like the following example.
dbservername g_group1 cdr1 serv1 nettype group ontlitcp ontlitcp hostname texpdx texpdx servicename mp.cdr1 mp.serv1 options i=1 g=g_group1 csm=(ENCCSM)
In this example, cdr1 and serv1 are two connection ports on the same database server. Encrypted client/server communications uses the serv1 port, while encrypted Enterprise Replication uses the cdr1 port. For more information on encrypting client/server network communications, see the IBM Informix: Dynamic Server Administrator's Guide. For more information on encrypting Enterprise Replication, see Setting Configuration Parameters on page 4-16 and Appendix B, Configuration Parameter and Environment Variable Reference, on page B-1.
4-6
Using the Connection Security Option (s=6) If you are using the connection security option, s=6, your SQLHOSTS file must contain a regular connection (without s=6) within the same group. To do this, you can add an alias server definition that includes the server group name. For example:
g_serv1 group - - i=10 serv1 ontlitcp lxsun02 ertest1 g=g_serv1, s=6 a_serv1 ontlitcp lxsun02 ertest10 g=g_serv1
For more information about the connection security option, see the IBM Informix: Administrator's Guide.
Testing the Network Environment

Once you have verified the network setup information, test the network environment. To test the network environment: 1. Verify the network connection. Use the ping command to test the connection between two systems. For example, from sydney, test the connection to melbourne:
ping melbourne
2. Test the trusted environment. a. Run dbaccess. b. Select the Connection menu option. c. Select the Connect menu option. d. Connect to the server group name and the server name of the other hosts. For example, if you are running dbaccess on sydney, and you are testing the connection to a database server on melbourne, select paul and g_paul. e. When prompted for the USER NAME, press Enter. If you can connect to the host database server, the host server is trusted for user informix. For more information, see the IBM Informix: DBAccess User's Guide.
Preparing the Disk

Preparing your disk for Enterprise Replication includes the following: v Planning for Disk Space Requirements v Setting Up Send and Receive Queue Spool Areas v Creating ATS and RIS Directories
4-7
Planning for Disk Space Requirements

Enterprise Replication requires additional disk space for storing the logical logs and, depending on your conflict-resolution configuration, delete tables and shadow columns. Logical Log Configuration Disk Space The database server uses the logical log to store a record of changes to the data since the last archive. Enterprise Replication requires the logical log to contain entire row images for updated rows, including deleted rows. The database server normally logs only columns that have changed. This behavior is called the logical-log record reduction option. Enterprise Replication deactivates this option for tables that participate in replication. (The logical-log record reduction option remains enabled for tables that do not participate in Enterprise Replication.) Enterprise Replication logs all columns, not only the columns that have changed, which increases the size of your logical log. To determine the size of your logical log, examine your data activity for normal operations and for the replication system you defined. Keep in mind that defining replication on a table causes Enterprise Replication to deactivate log reduction for that table, and that your transactions might log more data. Important: Enterprise Replication performs internal cleanup tasks based on how often the log files switch. If the log files switch too frequently, Enterprise Replication might perform excessive cleanup work. Logical Log Configuration Guidelines Use the following guidelines when configuring your logical log files: v Make sure that all logical log files are approximately the same size. v Make the size of the logical log files large enough so that the database server switches log files no more than once every 15 minutes during normal processing. v Plan to have sufficient logical-log space to hold at least four times the maximum transaction size. v Set LTXEHWM (long-transaction, exclusive-access, high-watermark) 30 percent larger than LTXHWM (long-transaction high-watermark). Important: If you specify that the database server allocate logical log files dynamically (DYNAMIC_LOGS), it is recommended that you set LTXEHWM to no higher than 70 when using Enterprise Replication.
4-8
For more information about logical logs and these configuration parameters, see IBM Informix: Administrator's Reference and IBM Informix: Dynamic Server Administrator's Guide. The database server can add logs dynamically when Enterprise Replication enters blockout mode if the CDR_MAX_DYNAMIC_LOGS configuration parameter is set to a non-zero integer. For more information, see Preventing DDRBLOCK Mode on page 8-9. Delete Table Disk Space If you use the time stamp or time stamp and SPL routine conflict-resolution rules, Enterprise Replication creates delete tables to keep track of modified rows for conflict resolution. (Enterprise Replication creates delete tables only for tables that have replicates defined with a conflict-resolution rule other than ignore.) Delete tables handle conflicts such as when a DELETE or UPDATE finds no corresponding row on the target. The DTCleaner thread removes a row from the delete tables after all the servers have progressed beyond that row. For more information, see Conflict-Resolution Rule on page 3-7. Delete tables are created on the database server where the data originates and on all the database servers to which data gets replicated. Delete tables are stored in the same dbspaces, using the same fragmentation strategy, as their base tables. To determine the disk space requirements to accommodate delete tables, estimate how many rows will be deleted or modified. For example, if the base table has 100 megabytes of data, but only half the rows might be deleted or modified, then 50 megabytes is a reasonable estimate for the size of the delete table. Important: Do not remove the delete tables created by Enterprise Replication. The delete table is automatically removed when the last replicate defined with conflict resolution is deleted. Shadow Column Disk Space When you define a replicate that uses any conflict-resolution rule except ignore, you must define shadow columns (CRCOLS) with the WITH CRCOLS clause. The shadow columns, cdrserver and cdrtime, store server and time-stamp information that Enterprise Replication uses for conflict resolution. The two shadow columns are integers, which adds a total of 8 bytes to each row in the table involved in a replicate that uses conflict resolution. Tip: If you plan to use only the ignore conflict-resolution rule, you do not need to define the cdrserver and cdrtime shadow columns.
4-9
For more information, see Conflict-Resolution Rule on page 3-7 and Preparing Tables for Conflict Resolution on page 4-20.
Setting Up Send and Receive Queue Spool Areas

The term data queue refers to both the send queue and the receive queue. Enterprise Replication collects information from the logical logs and places the data to be transferred in the send queue. Then Enterprise Replication transfers the contents of the send queue to the receive queue on the target server. Enterprise Replication on the target reads the data from the receive queue and applies the changes to the tables on the target server. The send and receive queues reside in memory and are managed by the Reliable Queue Manager (RQM). The CDR_QUEUEMEM configuration parameter (CDR_QUEUEMEM Configuration Parameter on page B-7) specifies the amount of memory space that is available for the data queues. When a queue in memory fills (for the receive queue, this only occurs with large transactions), the transaction buffers are written (spooled) to disk. Spooled transactions consist of transaction records (headers that contain internal information for Enterprise Replication), replicate information (summaries of the replication information for each transaction), and row data (the actual replicated data). Spooled transaction records and replication records are stored in transaction tables and replication tables in a single dbspace. Spooled row data is stored in one or more sbspaces. Important: To prevent the send and receive queues from spooling to disk, see Preventing Memory Queues from Overflowing on page 8-8. Transaction Record dbspace By default, the transaction records and replication records are stored in the root dbspace. Because Enterprise Replication and other database servers become unavailable if the root dbspace fills, you should define a single, separate dbspace for the send and receive queue transaction records and replication records before you define the replication server. To determine the size of your transaction record dbspace, you must determine the estimated number of transactions in a given period. You should allocate 110 bytes per transaction to the dbspace and allocate enough disk space to store 24 hours of transaction records. For example, if your network is down for 24 hours, and you estimate that you will log 1000 transactions each day, the size of the transaction record dbspace should be at least 108 kilobytes (110 bytes * 1000 transactions / 1024). To create the transaction record dbspace, use onspaces -c. For example, to create a 110 kilobyte dbspace called er_dbspace using raw disk space on UNIX with an offset of 0, enter:
4-10
onspaces -c -d er_dbspace -p /dev/raw_dev1 -o 0 -s 110
The pathname for the dbspace cannot be longer than 256 bytes. Set the CDR_QHDR_DBSPACE configuration parameter (CDR_QHDR_DBSPACE Configuration Parameter on page B-7) in the ONCONFIG file to the location of the transaction record dbspace (er_dbspace, in this example). Warning: Do not change the value of CDR_QHDR_DBSPACE after you initialize Enterprise Replication on a server. For information on creating dbspaces, see the chapter on managing disk space in the IBM Informix: Dynamic Server Administrator's Guide and the utilities chapter in the IBM Informix: Administrator's Reference. Row Data sbspaces Replicated data might include UDT and CLOB or BLOB data types. Therefore, the spooled row data is stored as smart large objects in one or more sbspaces. Important: Before starting Enterprise Replication, you must create at least one sbspace for spooled row data and set the CDR_QDATA_SBSPACE configuration parameter to its location. The CDR_QDATA_SBSPACE configuration parameter accepts multiple sbspaces, up to a maximum of 32 sbspaces. Enterprise Replication can support a combination of logging and non-logging sbspaces for storing spooled row data. If CDR_QDATA_SBSPACE is configured for multiple sbspaces, then Enterprise Replication uses all appropriate sbspaces in round-robin order. For more information, see CDR_QDATA_SBSPACE Configuration Parameter on page B-6. Creating sbspaces for Spooled Row Data: Follow these guidelines when creating sbspaces for spooled row data: v Create all the sbspaces of same default log mode type with the same size. v Do not use Enterprise Replication row data sbspaces for non-Enterprise Replication activity. v Ensure that the sbspaces are sufficiently large. To determine the size of your spooled row data sbspaces, determine your log usage and then consider how much data you can collect if your network goes down. For example, assume that you usually log 40 megabytes of data each day, but only 10 percent of that is replicated data. If your network is down for 24 hours and you estimate that you will log 4 megabytes of replicated data each day, the size of the sbspaces you identify
4-11
for the spooled row data must be a total of at least 4 megabytes. Windows Only On Windows, increase the resulting size of the sbspace by approximately a factor of two. (The default page size, the way that data maps onto a page, and the number of pages written to disk differs on Windows.) End of Windows Only Warning: When the row data sbspaces fill, Enterprise Replication hangs until you either resolve the problem that is causing Enterprise Replication to spool or allocate additional disk space to the sbspaces. For more information, see Preventing Memory Queues from Overflowing on page 8-8. To create row data sbspaces, use the onspaces -c utility. For example, to create a 4-megabyte sbspace, called er_sbspace, using raw disk space on UNIX with an offset of 0, enter:
onspaces -c -S er_sbspace -p /dev/rdsk/c0t1d0s4 -o 0 -s 4000\ -m /dev/rdsk2/c0t1d0s4 0 \ -Df "AVG_LO_SIZE=2,LOGGING=OFF"
The pathname for an sbspace cannot be longer than 256 bytes. The -m option specifies the location and offset of the sbspace mirror. The -Df option specifies default behavior of the smart large objects stored in the sbspace: v AVG_LO_SIZE (average large object size) Set this parameter to the expected average transaction size (in kilobytes). The database server uses this value to calculate the metadata size. The minimum value for AVG_LO_SIZE is 2 kilobytes, which is appropriate for Enterprise Replication in most cases. (The default value of AVG_LO_SIZE is 32 kilobytes.) If you set AVG_LO_SIZE to larger than the expected transaction size, you might run out of metadata space. If you set AVG_LO_SIZE too small, you might waste space on metadata. v LOGGING Set this parameter to OFF to create an sbspace without logging. Set this parameter to ON to create an sbspace with logging. It is recommended that you use a combination of logging and non-logging sbspaces for Enterprise Replication. For more information, see Logging Mode for sbspaces on page 4-13.
4-12
Set the CDR_QDATA_SBSPACE configuration parameter in the ONCONFIG file to the location of the row data sbspace (er_sbspace, in this example). For more information, see CDR_QDATA_SBSPACE Configuration Parameter on page B-6. Warning: Do not change the value of CDR_QDATA_SBSPACE after you initialize Enterprise Replication. Logging Mode for sbspaces: Enterprise Replication uses the default log mode that the sbspace was created with for spooling row data. Create sbspaces with a default logging mode of ON or OFF according to the types of transactions Enterprise Replication replicates: v LOGGING=ON Create sbspaces with LOGGING set to ON to support these situations: Replicated systems with HDR Enterprise Replication must use logging sbspaces for transactions involved in HDR. Small transactions Enterprise Replication uses logging sbspaces for transactions that are less than a page size (2K or 4K) of replicated data. For logging sbspaces, performance might be enhanced because logging mode enables asynchronous IO. However, a logging sbspace consumes additional logical-log space. v LOGGING=OFF Create sbspaces with LOGGING set to OFF to support replication of large transactions (greater than a page size of replicated data). It is recommended that you mirror non-logging sbspaces. For more information, see the chapter on managing disk space in the IBM Informix: Dynamic Server Administrator's Guide and the utilities chapter in the IBM Informix: Administrator's Reference. For non-logging sbspaces, performance is enhanced on the database server when Enterprise Replication spools to disk because Enterprise Replication writes less data to disk. Warning: Do not change the Enterprise Replication sbspace default log mode while Enterprise Replication is running. To change the default log mode, follow the procedure below. You can change the default logging mode of the row data sbspace if you have more than one sbspace specified by the CDR_QDATA_SBSPACE configuration parameter.
4-13
To change the default logging mode of a row data sbspace: 1. Shut down the database server. 2. Remove the sbspace from the CDR_QDATA_SBSPACE configuration parameter value list. 3. Start the database server in recovery mode. 4. Wait for all the smart large objects to get deleted from the sbspace. Use the onstat -g smb lod command to check for smart large objects stored in an sbspace. 5. Change the default logging mode for the sbspace. 6. Add the sbspace name to the CDR_QDATA_SBSPACE configuration parameter value list. 7. Shut down and restart the database server using the onmode -ky and oninit commands. Dropping a Spooled Row Data sbspace: You can drop a row data sbspace if you have more than one sbspace specified by the CDR_QDATA_SBSPACE configuration parameter. Dropping a row data sbspace: 1. Shutdown the database server. 2. Remove the sbspace from the CDR_QDATA_SBSPACE configuration parameter value list. 3. Start the database server in recovery mode. 4. Wait for all the smart large objects to get deleted from the sbspace. Use the onstat -g smb lod command to check for smart large objects stored in a sbspace. 5. Drop the sbspace. Warning: Do not drop an Enterprise Replication row data sbspace using the onspaces -d -f (force) command.
Setting Up the Grouper Paging File

Enterprise Replication uses a grouper paging mechanism for evaluating large transactions. A transaction is large if the portion to be replicated meets at least one of the following conditions: v It has greater than 5,000 log records. v It exceeds one fifth the size of the value of the CDR_QUEUEMEM onconfig variable. v It exceeds one tenth the size of the value of the SHMVIRTSIZE configuration variable. The location of the sbspace used for the paging file is determined by the first of the following ONCONFIG configuration parameters that is set:
4-14
v SBSPACETEMP v SBSPACENAME v CDR_QDATA_SBSPACE The best solution is to set up an unlogged sbspace, as specified by the SBSPACETEMP configuration parameter. All updates to the paging files are unlogged. The size of the paging sbspace should be at least three time the size of the largest transaction to be processed. This sbspace is also used by the database server for other tasks; consider its overall usage when determining size requirements. Warning: If the paging sbspace fills, Enterprise Replication hangs until you allocate additional disk space to the sbspace. If additional space is unavailable, use the cdr stop command to stop replication.
Creating ATS and RIS Directories

The Aborted Transactions Spooling (ATS) and Row Information Spooling (RIS) files contain information about failed transactions and aborted rows. You can repair data after replication has failed by using ATS and RIS files. Enterprise Replication examines the specified ATS or RIS file and attempts to reconcile the rows that failed to be applied. This method is fast, but does not allow as much flexibility as a repair job allows in defining how the repair should be done. See Repairing with ATS and RIS Files on page 7-15 for more information. For information about repair jobs, see Resynchronizing Data Among Replication Servers on page 7-14. If you set up ATS and RIS, Enterprise Replication writes ATS and RIS files to directories on the system: v ATS files If you are using primary-target replication, create the ATS directory on the target system. If you are using update-anywhere replication (Update-Anywhere Replication System on page 3-6) and have conflict resolution (Conflict Resolution on page 3-7) enabled, create the ATS directory on all participating replication systems. v RIS files If you have conflict resolution enabled, create the RIS directory on all participating replication systems. The default location for these directories is /tmp (UNIX) or \tmp (Windows). Specify a location other than /tmp or \tmp for the spooling directories.
4-15
Create the new location for these directories before you define the server for replication. The pathnames for the ATS and RIS directories cannot be longer than 256 characters. For information about ATS and RIS, refer to Chapter 8, Monitoring and Troubleshooting Enterprise Replication, on page 8-1.
Preparing the Database Server Environment

To prepare the database server environment, complete the following tasks: v Setting Environment Variables v Setting Configuration Parameters If you are using High-Availability Data (HDR) replication with Enterprise Replication, set up your HDR servers according to the instructions in the section HDR Requirements on page 5-6.
Setting Environment Variables

To configure the database server environment, verify that the following environment variables are set correctly: v INFORMIXDIR is set to the full path of the Informix directory. v INFORMIXSERVER is set to the name of the default database server. For more information, see also Connect Option on page A-109. v INFORMIXSQLHOSTS is set to the full path to the SQLHOSTS file (UNIX) or the SQLHOSTS registry host machine (Windows). For more information, see the IBM Informix: Administrator's Reference.
Setting Configuration Parameters

In the ONCONFIG file for each database server, make sure that the following configuration parameters are set: v DBSERVERNAME is set to the correct database server. If you use both DBSERVERNAME and DBSERVERALIASES, DBSERVERNAME should refer to the TCP connection and not to a shared-memory connection. For information about database server aliases, refer to the IBM Informix: Dynamic Server Administrator's Guide. v CDR_DBSPACE is set to the dbspace for the syscdr database. If not set, the root dbspace is used. v CDR_QUEUEMEM is set to the maximum amount of memory to be used for the send and receive queues. v CDR_QHDR_DBSPACE is set to the location of the transaction record dbspace. For more information, see Transaction Record dbspace on page 4-10.
4-16
v CDR_QDATA_SBSPACE is set to the location of the row data sbspace. If the CDR_QDATA_SBSPACE configuration parameter is not set in ONCONFIG or the sbspace name specified by CDR_QDATA_SBSPACE is invalid, Enterprise Replication fails to define the server. For more information, see Row Data sbspaces on page 4-11. v CDR_SERIAL is set to generate non-overlapping (unique) values for SERIAL columns across all database servers in the replication environment. For more information, see SERIAL Data Types and Primary Keys on page 2-9. If you want to suppress certain Datasync error and warning codes from appearing in ATS and RIS files, you can set the CDR_SUPPRESS_ATSRISWARN configuration parameter. See CDR_SUPPRESS_ATSRISWARN Configuration Parameter on page B-8 for more information. If you want to encrypt network communications, make sure that the following configuration parameters are set in the ONCONFIG file for each database server: v ENCRYPT_CDR is set to 1 or 2 to enable encryption. The default value is 0, which prevents encryption. v ENCRYPT_CIPHER specifies which ciphers and cipher modes are used for encryption. v ENCRYPT_MAC controls the level of Message Authentication Code (MAC) used to ensure message integrity. v ENCRYPT_MACFILE is set to the full path and filenames of the MAC files. v ENCRYPT_SWITCH is set to the number of minutes between automatic renegotiations of ciphers and keys. (The cipher is the encryption methodology. The secret key is the key used to build the encrypted data using the cipher.) These configuration parameters are documented in Appendix B, Configuration Parameter and Environment Variable Reference, on page B-1.
Preparing Data for Replication

The goal of data replication is to provide identical, or at least consistent, data on multiple database servers. This section describes how to prepare the information in your databases for replication. When you define a new replicate on tables with existing data on different database servers, the data might not be consistent. Similarly, if you add a participant to an existing replicate, you must ensure that all the databases in the replicate have consistent values.
4-17
For more information, see Data Preparation Example on page 4-23.
Preparing Consistent Data

In most cases, preparing consistent data simply requires that you decide which of your databases has the most accurate data and then that you copy that data onto the target database. If the target database already has data, for data consistency, you must remove that data before adding the copied data. For information on loading the data, see Loading and Unloading Data on page 4-21.
Blocking Replication
You might need to put data into a database that you do not want replicated, perhaps for a new server or because you had to drop and re-create a table. To block replication while you prepare a table, use the BEGIN WORK WITHOUT REPLICATION statement. This starts a transaction that does not replicate to other database servers. The following code fragment shows how you might use this statement:
BEGIN WORK WITHOUT REPLICATION LOCK TABLE office DELETE FROM office WHERE description = portlandR_D COMMIT WORK
The following list indicates actions that occur when a transaction starts with BEGIN WORK WITHOUT REPLICATION: v SQL does not generate any values for the shadow columns (cdrserver and cdrtime) for the rows that are inserted or updated within the transaction. You must supply values for these columns with the explicit column list. You must supply these values even if you want the column values to be NULL. v To modify a table with shadow columns that is already defined in Enterprise Replication, you must explicitly list the columns to be modified. The following two examples show an SQL statement and the correct changes to the statement to modify columns: If table_name1 is a table defined for replication, you must change the following statement:
LOAD FROM filename INSERT INTO table_name1;
to:
LOAD FROM filename INSERT INTO table_name1 \ (list of columns);
The list of columns must match the order and the number of fields in the load file. v If table_name3 and table_name4 are tables defined for replication with the same schema, you must change the following statement:
4-18
INSERT INTO table_name3 SELECT * FROM table_name4;
to an explicit statement, where col1, col2,..., colN are the columns of the table:
INSERT INTO table_name3 VALUES (cdrserver, cdrtime, col1, ..., colN) cdrserver, cdrtime * FROM table_name4;
The shadow columns (cdrserver and cdrtime) are not included in an * list. For more information about these statements, refer to the IBM Informix: Guide to SQL Syntax. Using DB-Access to Begin Work Without Replication The following example shows how to use DBAccess to begin work without replication as well as update the Enterprise Replication shadow columns cdrserver and cdrtime:
DATABASE adatabase; BEGIN WORK WITHOUT REPLICATION INSERT into mytable (cdrserver, cdrtime, col1, col2, ....) VALUES (10, 845484154, value1, value2, ....); UPDATE mytable SET cdrserver = 10, cdrtime = 945484154 WHERE col1 > col2; COMMIT WORK
Using ESQL/C to Begin Work Without Replication The following example shows how to use ESQL/C to begin work without replication as well as update the Enterprise Replication shadow columns cdrserver and cdrtime:
MAIN (argc, INT CHAR { EXEC SQL EXEC SQL argv) argc; *argv[]; CHAR stmt[256]; database mydatabase;
sprintf(stmt, BEGIN WORK WITHOUT REPLICATION); EXEC SQL execute immediate :stmt; EXEC SQL insert into mytable (cdrserver, cdrtime, col1, col2, ...) values (10, 845494154, value1, value2, ...); EXEC SQL update mytable set cdrserver = 10, cdrtime = 845494154 where col1 > col2; EXEC SQL commit work; }
4-19
Important: You must use the following syntax when you issue the BEGIN WORK WITHOUT REPLICATION statement from ESQL/C programs. Do not use the $ syntax.
sprintf(stmt, BEGIN WORK WITHOUT REPLICATION); EXEC SQL execute immediate :stmt;
Preparing to Replicate User-Defined Types

You must install and register user-defined types on all database servers prior to starting replication. If you are using HDR with Enterprise Replication, follow the instructions in the section Preparing to Replicate UDTs, UDRs, and DataBlade Modules on page 5-7. For Enterprise Replication to be able to replicate opaque user-defined types (UDTs), the UDT designer must provide two support functions, streamwrite() and streamread(). For more information, see Replicating Opaque User-Defined Data Types on page 2-19.
Preparing to Replicate User-Defined Routines

You must install and register user-defined routines on all database servers prior to starting replication. If you are using HDR with Enterprise Replication, follow the instructions in the section Preparing to Replicate UDTs, UDRs, and DataBlade Modules on page 5-7.
Preparing Tables for Conflict Resolution

To use any conflict-resolution rule other than ignore, you must define the shadow columns, cdrserver and cdrtime. Tip: If you plan to use only the ignore conflict-resolution rule, you do not need to define the cdrserver and cdrtime shadow columns. For more information about update-anywhere and conflict resolution, see Update-Anywhere Replication System on page 3-6. To define the shadow columns in your table, use the following statements: v For new tables, use:
CREATE TABLE table_name WITH CRCOLS;
v For existing tables, use:

ALTER TABLE table_name ADD CRCOLS;
Important: If a table already participates in Enterprise Replication, you must stop replication before altering it with the ADD CRCOLS clause. For more information, see Stopping a Replicate on page 7-8.
4-20
To drop the cdrserver and cdrtime shadow columns, use:

ALTER TABLE table_name DROP CRCOLS;
Tip: The ADD CRCOLS and DROP CRCOLS clauses to the ALTER TABLE statement are now processed as in-place alters in most cases. For more information, see the section on in-place alters in the IBM Informix: Performance Guide. For more information on CREATE TABLE and ALTER TABLE, see the sections in the IBM Informix: Guide to SQL Syntax.
Preparing Logging Databases

Databases on all server instances involved in replication must be created with logging. For best results, use unbuffered logging. For more information, see Unbuffered Logging on page 2-7.
Loading and Unloading Data

If you are adding a table to your already existing replication environment, Enterprise Replication provides an initial synchronization feature that allows you to easily bring a new table up-to-date with replication. You can synchronize the new table with data on the source server you specify when you start the new replicate, or when you add a new participant to an existing replicate. You do not need to suspend any servers that are replicating data while you add the new replicate and synchronize it. See Initially Synchronizing Data Among Database Servers on page 6-14 for more information. Otherwise, if you have not yet set up your replication environment, for loading data, you can use the following tools: v High-Performance Loader v onunload and onload Utilities v dbexport and dbimport Utilities v UNLOAD and LOAD Statements When you unload and load data, you must use the same type of utility for both the unload and load operations. For example, you cannot unload data with the onunload utility and then load the data with a LOAD statement. If you are using HDR with Enterprise Replication, follow the instructions in the section Loading and Unloading Data on page 5-8. If the table that you are preparing for replication is in a database that already uses replication, you might need to block replication while you prepare the table. For information on how to do this, see Blocking Replication on page 4-18.
4-21
If a table that you plan to replicate includes the shadow columns, cdrserver and cdrtime, the statements that you use for unloading the data must explicitly name the shadow columns. If you use the SELECT statement with * FROM table_name to the data to unload, the data from the shadow columns will not be unloaded. To include the shadow columns in the unloaded data, use a statement like the following:
SELECT cdrserver, cdrtime, * FROM table_name
For more information, see Shadow Columns on page 2-8.
High-Performance Loader
The High-Performance Loader (HPL) provides a high-speed tool for moving data between databases. How you use the HPL depends on how you defined the tables to replicate. If the table definition included the WITH CRCOLS clause, you must take special steps when you unload the data. If the table contains shadow columns, you must: v Include the cdrserver and cdrtime columns in your map when you load the data. v Use express mode to load data that contains the cdrserver and cdrtime columns. You must perform a level-0 archive after completion. You can also use deluxe mode without replication to load data. After a deluxe mode load, you do not need to perform a level-0 archive. Deluxe mode also allows you to load TEXT and BYTE data and opaque user-defined types. For information about HPL, refer to the IBM Informix: High-Performance Loader User's Guide.
onunload and onload Utilities

You can use the onunload and onload utilities only to unload and load an entire table. If you want to unload selected columns of a table, you must use either the UNLOAD statement or the HPL. Important: You can only use onunload and onload in identical (homogeneous) environments. For more information about onunload and onload, see the IBM Informix: Migration Guide.
dbexport and dbimport Utilities

If you need to copy an entire database for replication, you can use the dbexport and dbimport utilities. These utilities unload an entire database,
4-22
including its schema, and then re-create the database. If you want to move selected tables or selected columns of a table, you must use some other utility. For more information about dbexport and dbimport, see the IBM Informix: Migration Guide.
UNLOAD and LOAD Statements

The UNLOAD and LOAD statements allow you to move data within the context of an SQL program. If the table contains shadow columns, you must: v Include the cdrserver and cdrtime columns explicitly in your statement when you unload your data. v List the columns that you want to load in the INSERT statement and explicitly include the cdrserver and cdrtime columns in the list when you load your data. For more information about the UNLOAD and LOAD statements, see the IBM Informix: Guide to SQL Syntax.
Data Preparation Example

The following examples show how to add a new participant (delta) to an existing replicate by two different methods: v Using the cdr start replicate command This method is simple and can be done while replication is online. v Using the LOAD, UNLOAD, and BEGIN WORK WITHOUT REPLICATION statements. If you use HPL, this method can be faster for a large table. Replicate zebra replicates data from table table1 for the following database servers: alpha, beta, and gamma. The servers alpha, beta, and gamma belong to the server groups g_alpha, g_beta, and g_gamma, respectively. Assume that alpha is the database server from which you want to get the initial copy of the data.
Using the cdr start replicate Command

To add a new participant to an existing replicate: 1. Declare server delta to Enterprise Replication. For example:
cdr def ser -c delta -I -S g_alpha g_delta
4-23
At the end of this step, all servers in the replication environment include information in the syscdr database about delta, and delta has information about all other servers. 2. Add delta as a participant to replicate zebra. For example:
cdr cha rep -a zebra "dbname@g_delta:owner.table1"
This step updates the replication catalog. The servers alpha, beta, and gamma do not queue any qualifying replication data for delta because the replicate on delta, although defined, has not been started. 3. Start replication for replicate zebra on delta.
cdr sta rep zebra g_delta -S g_alpha -e delete
The -S g_alpha option specifies that the server alpha be used as the source for data synchronization. The -e delete option indicates that if there are rows on the target server, delta, that are not present on the synchronization data server (alpha) then those rows are deleted Do not run any transactions on delta that affect table table1 until you finish the synchronization process.
Using LOAD, UNLOAD, and BEGIN WORK WITHOUT REPLICATION

To add a new participant to an existing replicate: 1. Declare server delta to Enterprise Replication. For example:
cdr def ser -c delta -I -S g_alpha g_delta
At the end of this step, all servers in the replication environment include information in the syscdr database about delta, and delta has information about all other servers. 2. Add delta as a participant to replicate zebra. For example:
cdr cha rep -a zebra "dbname@g_delta:owner.table1"
This step updates the replication catalog. The servers alpha, beta, and gamma do not queue any qualifying replication data for delta because the replicate on delta, although defined, has not been started. 3. Suspend server to delta on alpha, beta, and gamma.
cdr sus ser g_alpha g_beta g_gamma
As a result of this step, replication data is queued for delta, but no data is delivered. 4. Start replication for replicate zebra on delta.
cdr sta rep zebra g_delta
This step causes servers alpha, beta, and gamma to start queueing data for delta. No data is delivered to delta because delta is suspended. Then, delta queues and delivers qualifying data (if any) to the other servers. Do not run any transactions on delta that affect table table1 until you finish the synchronization process.
4-24
5. Unload data from table table1 using the UNLOAD statement or the unload utility on HPL. 6. Copy the unloaded data to delta. 7. Start transactions with BEGIN WORK WITHOUT REPLICATION, load the data using the LOAD statement, and commit the transactions. If you used the HPL to unload the data in step 5, then use the HPL Deluxe load without replication to load the data into table1 on delta. 8. Resume server delta on alpha, beta, and gamma. This step starts the flow of data from alpha, beta, and gamma to delta. At this point, you might see some transactions aborted because of conflict. Transactions can abort because alpha, beta, and gamma started queueing data from delta in step 4. However, those same transactions might have been moved in steps 5 and 7. You must declare replication on server delta and then immediately suspend replication because, while you are preparing the replicates and unloading and loading files, the other servers in the replicate (alpha, beta, and gamma) might be collecting information that needs to be replicated. After you finish loading the initial data to delta and resume replication, the information that was generated during the loading process can be replicated.
4-25
4-26
Chapter 5. Using High-Availability Data Replication with Enterprise Replication

High-Availability Replication System . . . . . . . . . . . . . . . . . . . . . . 5-1 Using HDR in a Hierarchical Tree Topology . . . . . . . . . . . . . . . . . . . 5-3 Using HDR in a Forest of Trees Topology . . . . . . . . . . . . . . . . . . . . 5-4 Preparing HDR Database Servers . . . . . . . . . . . . . . . . . . . . . . . 5-5 HDR Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6 Setting Up Database Server Groups . . . . . . . . . . . . . . . . . . . . . . 5-6 Preparing to Replicate UDTs, UDRs, and DataBlade Modules . . . . . . . . . . . . . 5-7 Loading and Unloading Data . . . . . . . . . . . . . . . . . . . . . . . . 5-8 Managing Enterprise Replication with High-Availability Data Replication . . . . . . . . . . 5-8 Row Data Sbspace Logging . . . . . . . . . . . . . . . . . . . . . . . . 5-8 HDR Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8 Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . 5-10
In This Chapter
This chapter covers how to include High-Availability Data Replication (HDR) in your Enterprise Replication system. The following topics are covered: v The design of a high-availability replication system using HDR v Preparing HDR database server v Managing Enterprise Replication with HDR For a complete description of HDR, see the IBM Informix: Dynamic Server Administrator's Guide.
High-Availability Replication System

You can combine Enterprise Replication and HDR to create a high-availability replication system in which a critical read-write database server in an Enterprise Replication system maintains a backup server with HDR. An HDR system consists of two database servers: the primary database server, which receives updates, and the secondary, read-only copy of the primary database server. The secondary server is a mirror image of the primary system and is in perpetual recovery mode, applying logical-log records from the primary server to its dbspaces and sbspaces. The HDR secondary server does not participate in Enterprise Replication; it receives updates through HDR. When the HDR primary server receives an update through Enterprise Replication, the transaction is not committed until the log records containing that transaction are sent to the secondary server. If
5-1
the primary server becomes unavailable, you replace it with the secondary server by switching the secondary server into standard mode and redirecting connections to it. High-availability replication systems are most useful for replication systems in which the failure of a critical server prevents other servers from participating in replication. Figure 5-1 illustrates the combination of a primary-target replication system with a high-availability replication system.
High-Availability Data Replication HDR Secondary (Read-only) Enterprise Replication Target (Read-only) Target (Read-only)
HDR Primary (Read-write) Target (Read-only) Target (Read-only)
Figure 5-1. Using High-Availability with a Primary-Target Replication System
If the primary server fails, the secondary server is set to standard mode, the target database connections are redirected to it, and Enterprise Replication continues, as illustrated in Figure 5-2.
5-2
HDR Secondary (switched to standard mode) (Read-write) Target (Read-only) HDR Primary (offline) (Read-write) Target (Read-only) Target (Read-only) Target (Read-only)
Figure 5-2. Redirection to the Secondary Database Server
In an update-anywhere replication system, you can use HDR with any server for which you need high availability, as illustrated in Figure 5-3.
Critical server (HDR Primary)
Backup server (HDR Secondary)
Figure 5-3. Using High Availability with an Update-Anywhere Replication System
Using HDR with Enterprise Replication is particularly effective when you use a hierarchical or a forest of trees topology.
Using HDR in a Hierarchical Tree Topology

With a hierarchical tree topology, parent servers are good candidates for using HDR to provide backup servers. The following example is based on the example in Figure 3-7 on page 3-17. If China fails, then Beijing and Shanghai can no longer replicate with other servers in the replication system; Guangzhou and Hong Kong can only
5-3
replicate with each other. However, if China participated in HDR, when it failed, the secondary server would replace it and replication could continue, as illustrated in Figure 5-4.
Asia China Japan China (offline) primary Beijing Guangzhou secondary
Hong Kong
Shanghai
Figure 5-4. Hierarchical Tree Topology with HDR
In this example, Asia and Guangzhou, which are also parent servers, could also benefit from using HDR to ensure high availability.
Using HDR in a Forest of Trees Topology

Use HDR to ensure that all servers retain access to the replication system in a forest of trees topology. For example, in Figure 3-8 on page 3-18, Asia, Europe, China, and Guangzhou should use HDR to provide backup servers, as illustrated in Figure 5-5.
5-4
Europe secondary North America HDR Europe primary Germany Asia secondary HDR Asia primary China primary Japan Beijing Guangzhou primary HDR Guangzhou secondary China HDR secondary France
Hong Kong
Shanghai
Figure 5-5. HDR in a Forest-of-Trees Topology
Preparing HDR Database Servers

To prepare HDR database server for Enterprise Replication, perform the following tasks: v Configure HDR database servers according to HDR requirements. v Set up the SQLHOSTS file with both the primary and secondary HDR servers as members of the same database server group. v Install and register user-defined data types, user-defined routines, and DataBlade modules. v Load data using backup and restore procedures. Important: HDR does not support encryption. If you combine Enterprise Replication with HDR, communication between Enterprise Replication servers and the HDR primary server can be encrypted, but the communication between the HDR primary server and the
5-5
HDR secondary server cannot be encrypted. For more information, see ENCRYPT_CDR Configuration Parameter on page B-9.
HDR Requirements
Make sure the HDR database servers meet HDR requirements in the following categories: v Hardware and operating-system requirements For example, the hardware and operating system of the computers running the primary and secondary database servers must be identical. v Database and data requirement For example, all databases must have logging turned on and all data must reside in logged dbspaces or sbspaces. v Database server configuration requirements For example, the database server version, storage space and chunk configuration, and many other configurations must be identical. v Connectivity For example, the connectivity information on each of the computers must identify the database server running on it and the other database server in the HDR pair. For a complete list of configuration requirements, see the IBM Informix: Dynamic Server Administrator's Guide.
Setting Up Database Server Groups

When defining an HDR server pair within Enterprise Replication, the HDR server pair must appear to be a single logical entity within the replication domain. To accomplish this, define the two HDR servers within the same database server group in the SQLHOSTS file. For example, Figure 5-6 illustrates two Enterprise Replication nodes, one of which is an HDR pair.
5-6
serv1 ER
serv2
HDR
serv1_sec
g_serv1
g_serv2
Figure 5-6. Database Server Groups for Enterprise Replication with HDR
In this example, the HDR pair consists of the primary server, serv1, and the secondary server, serv1_sec. These two servers belong to the same database server group, g_serv1. The non-HDR server, serv2, belongs to the database server group g_serv2. The following example displays the SQLHOSTS file for this configuration.
dbservername g_serv1 serv1 serv1_sec g_serv2 serv2 nettype group ontlitcp ontlitcp group ontlitcp hostname machine1pri machine1sec machine2 servicename port1 port1 port1 options i=1 g=g_serv1 g=g_serv1 i=2 g=g_serv2
For more information on setting up the SQLHOSTS file, see Verifying SQLHOSTS on page 4-3. Either HDR or Enterprise Replication can be set up first on the HDR pair serv1 and serv1_sec, but Enterprise Replication cdr commands must be executed only on the primary server. If any cdr commands are attempted on the secondary server, a 117 error is returned: Attempting to process a cdr command on an HDR secondary server.
Preparing to Replicate UDTs, UDRs, and DataBlade Modules

If you are using HDR with Enterprise Replication with user-defined types, user-defined routines, or DataBlade modules, perform the tasks shown in
5-7
Table 5-1 on the primary and secondary database servers.

Table 5-1. Preparing to Replicate UDTs, UDRs, and DataBlade Modules Step 1. On the Primary Install the user-defined types, user-defined routines, or DataBlade modules. Register the user-defined types, user-defined routines, or DataBlade modules. On the Secondary Install the user-defined types, user-defined routines, or DataBlade modules.
2.
When you start HDR, the user-defined types, user-defined routines, or DataBlade modules are registered on the secondary database server. For instructions on starting HDR, see the IBM Informix: Dynamic Server Administrator's Guide.
Loading and Unloading Data

After you load data onto the HDR primary database server, use backup and restore procedures to load the data onto the HDR secondary database server. For instructions, see the IBM Informix: Dynamic Server Administrator's Guide.
Managing Enterprise Replication with High-Availability Data Replication

This section describes how to manage Enterprise Replication with HDR in the following areas: v Row data sbspace logging v HDR failure v Performance
Row Data Sbspace Logging

All sbspaces used by Enterprise Replication with HDR for spooled transaction row data must be created with logging enabled. For more information, see Row Data sbspaces on page 4-11.
HDR Failure
If the primary server within an HDR pair fails, the secondary server can be switched to standard mode by executing the onmode d standard command. However, you must manually start Enterprise Replication by executing the cdr start command on that server. This is necessary to prevent Enterprise Replication from starting on both servers in an HDR pair. Table 5-2 shows how to switch the secondary server to standard mode.
5-8
Table 5-2. Switching the Secondary Server to Standard Mode Step 1. 2. 3. On the Primary The server becomes unavailable. onmode command onmode -d standard cdr command cdr start On the Secondary
If you need to start the primary server while Enterprise Replication is running on the secondary server, use the oninit D command to prevent Enterprise Replication and HDR from starting on the primary server. If the problem has been resolved on the primary server and you wish to reestablish it as the primary server, then first stop Enterprise Replication on the secondary server. Otherwise, Enterprise Replication attempts to restart on the primary server while it is still active on the secondary server. Table 5-3 shows how to reestablish the primary server.
Table 5-3. Reestablishing the Primary Server Step 1. 2. 3. 4. 5. oninit cdr command cdr start On the Primary On the Secondary cdr command cdr stop onmode command onmode -s onmode command onmode -d secondary
If you want to split an active HDR pair into two stand-alone servers, then you must be careful to avoid Enterprise Replication starting on either server after they are split. To prevent Enterprise Replication and HDR from running, start the database servers with the oninit D command. If you remove a server from an HDR pair, use the cdr remove command to eliminate Enterprise Replication from that server. For example, the two HDR servers are being split and the secondary server is to be used for reporting purposes. After the report processing is complete, HDR can be reestablished. Table 5-4 shows how to remove a secondary server from HDR and Enterprise Replication.
5-9
Table 5-4. Removing the Secondary Server from HDR and ER Step 1. 2. On the Primary onmode command onmode -d standard On the Secondary onmode command onmode -d standard cdr command cdr remove
If the HDR primary server has problems communicating to its secondary server, Enterprise Replication is in a suspended state until one of the following actions is taken: v Resolve the connection problem between HDR pairs. v Convert the primary server to standard mode. For more information on managing HDR servers, see the IBM Informix: Dynamic Server Administrator's Guide.
Performance Considerations
When Enterprise Replication is running on an HDR pair, some operations cannot be performed until the logs are shipped to the secondary server. This delay prevents possible inconsistency within the Enterprise Replication domain during an HDR switch-over to a secondary server. Consequently, there is a slight increase in replication latency when Enterprise Replication is used with HDR. You can control this latency increase by setting the DRINTERVAL configuration parameter to a low value.
5-10
Chapter 6. Defining Replication Servers, Replicates, Participants, and Replicate Sets

Initializing Database Servers . . . . . . . . . . . Defining Replication Servers . . . . . . . . . . . Customizing the Replication Server Definition . . . . Defining Replicates . . . . . . . . . . . . . . Defining Participants . . . . . . . . . . . . Defining Replicates on Table Hierarchies . . . . . Defining Master Replicates. . . . . . . . . . . Master Replicate Verification . . . . . . . . . Creating Strict Master Replicates . . . . . . . . Creating Empty Master Replicates . . . . . . . Defining Shadow Replicates . . . . . . . . . . Specifying Conflict Resolution Rules and Scope . . . . Specifying Replication Frequency . . . . . . . . Setting Up Error Logging . . . . . . . . . . . Replicating Only Changed Columns . . . . . . . Using the IEEE Floating Point or Canonical Format . . Enabling Triggers . . . . . . . . . . . . . Defining Replicate Sets . . . . . . . . . . . . Exclusive Replicate Sets . . . . . . . . . . . Non-Exclusive Replicate Sets . . . . . . . . . Customizing the Replicate Set Definition . . . . . Initially Synchronizing Data Among Database Servers . . Using Templates to Set Up Replication . . . . . . . Defining Templates . . . . . . . . . . . . . Realizing Templates . . . . . . . . . . . . Verifying Participants without Applying the Template Synchronizing Data Among Database Servers . . . Creating Tables Automatically . . . . . . . . Other Options . . . . . . . . . . . . . Changing Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2 . 6-3 . 6-3 . 6-4 . 6-5 . 6-6 . 6-6 . 6-7 . 6-8 . 6-8 . 6-8 . 6-9 . 6-10 . 6-10 . 6-11 . 6-12 . 6-12 . 6-13 . 6-13 . 6-13 . 6-14 . 6-14 . 6-16 . 6-16 . 6-17 . 6-17 . 6-17 . 6-17 . 6-17 . 6-18
In This Chapter
This chapter describes the steps for declaring a database server for Enterprise Replication. To define a replication server: 1. Initialize the database server. For information, see Initializing Database Servers on page 6-2. 2. Declare the database server to Enterprise Replication. For information, see Defining Replication Servers on page 6-3.
6-1
Once you define the server for replication, the server is known as a replication server. 3. Define replicates. The replicate definition includes information about the participants, replication options, frequency, and conflict-resolution rules and scope. For information, see Defining Replicates on page 6-4. 4. Define participants. A participant definition specifies the data (database, table, and columns) that should be replicated. Although you can define a replicate with fewer, a replicate should contain two or more participants to be useful. For information, see Defining Participants on page 6-5. Important: You must be the Enterprise Replication server administrator to define the replication server. For more information about the server administrator, see Enterprise Replication Server Administrator on page 2-3. This chapter also covers the following topics: v Defining replicate sets v Initial data synchronization For information on managing your replication servers and replicates, see Chapter 7, Managing Replication Servers and Replicates, on page 7-1.
Initializing Database Servers

The database server must be online before you can declare it for replication. To bring the server from offline to online, issue the following command for your operating system.
Operating System UNIX Windows Command oninit start dbservername
To bring the server from quiescent mode to online on either UNIX or Windows, enter onmode -m. For more information on initializing the database server, see the chapter on database operating modes in the IBM Informix: Administrator's Guide.
6-2
Defining Replication Servers

Once you bring the database server online, the next step is to declare the server to Enterprise Replication. To define the replication server, use the cdr define server command. For example:
cdr define server [--connect=server_name] \ options --init server_group_name
The --init option initializes the server. If INFORMIXSERVER is not set to the server that you are defining, specify the --connect=server_name option. For more information, see Connecting to Another Replication Server on page 7-3. Tip: All Enterprise Replication commands and options use the name of the database server group, also known as a server group, instead of the more familiar database server name for all references to database servers (except the --connect option, which can use both). This manual uses the convention that the name of a server group is g_ followed by the server group name. Important: If the CDR_SBSPACE configuration parameter is not set in ONCONFIG or specifies an invalid sbspace, Enterprise Replication fails to define the server. For more information, see Row Data sbspaces on page 4-11.
Customizing the Replication Server Definition

When you define a replication server, you can change the following aspects of the server in the replication environment: v Synchronize the new servers global catalog with another Enterprise Replication server. For more information, see Global Catalog on page 2-5. For all servers except the first server you define in your Enterprise Replication system, you must use --sync=sync_server in your server definition to synchronize the global catalog with an existing server. For Hierarchical Routing (HR) topologies, Enterprise Replication also uses the synchronization server as the parent of the new server in the current topology. For example, if you add a new server kauai and synchronize its global catalog with hawaii, kauai is connected to hawaii in the Enterprise Replication topology. For more information, see Choosing a Replication Network Topology on page 3-14. v Set the idle timeout. To specify the time (in minutes) that you want to allow the connection between two Enterprise Replication servers to remain idle before disconnecting, use --idle=timeout.
6-3
Depending on the type of Enterprise Replication system (primary-target or update-anywhere) and network topology (fully connected or hierarchical) that you chose, set the following options: v Specify the location of the ATS directory. To use ATS, specify the directory for the Aborted Transaction Spooling (ATS) files for the server using --ats=dir. For more information, see Creating ATS and RIS Directories on page 4-15 and Chapter 8, Monitoring and Troubleshooting Enterprise Replication, on page 8-1. v Specify the location of the RIS directory. To use RIS, specify the directory for the Row Information Spooling (RIS) files for the server using --ris=dir. For more information, see Creating ATS and RIS Directories on page 4-15 and Chapter 8, Monitoring and Troubleshooting Enterprise Replication, on page 8-1. v Specify the type of server (hierarchical replication). To specify the server as a nonroot server, use --nonroot. To specify the server as a leaf server, use --leaf. If neither --leaf nor --nonroot is specified, the server is defined as a root server. For more information, see Hierarchical Replication Topologies on page 3-15. For more information on network topology, see Chapter 3, Selecting the Enterprise Replication System and Network Topology, on page 3-1. For more information, see cdr define server on page A-25.
Defining Replicates
To define a replicate, use the cdr define replicate command. You can provide the following information in the replicate definition: v Participants For more information, see Defining Participants on page 6-5. v Create as a master replicate For more information, see Defining Master Replicates on page 6-6. v Conflict resolution rules and scope For more information, see Specifying Conflict Resolution Rules and Scope on page 6-9. v Replication frequency
6-4
For more information, see Specifying Replication Frequency on page 6-10. v Error logging For more information, see Setting Up Error Logging on page 6-10. v Replicate full rows or only changed columns For more information, see Replicating Only Changed Columns on page 6-11. v IEEE or canonical message formats For more information, see Using the IEEE Floating Point or Canonical Format on page 6-12. v Database triggers For more information, see Enabling Triggers on page 6-12. After you define the replicate and participants, you must manually start the replicate using the cdr start replicate command. See Starting a Replicate on page 7-7.
Defining Participants
You must define participants for each server involved in the replicate in the replicate definition using the cdr define replicate command. Important: You cannot start and stop replicates that have no participants. Each participant definition includes the following information: v Database server group name v Database in which the table to be replicated resides v Table name v Table owner See Table Owner on page A-111. v SELECT statement and optional WHERE clause See Participant Modifier on page A-112. If you use a SELECT * FROM table_name statement, the tables must be identical on all database servers defined for the replicate. Important: Do not create more than one participant definition for each row and column to replicate. If the participant is the same, Enterprise Replication attempts to insert or update duplicate values during replication. For example, if one participant modifier includes WHERE x < 50 and another includes WHERE x < 100, Enterprise Replication sends the data twice. In addition, for a primary-target replication system, you can specify the participant type as either primary or target (receive-only). If you do not specify
6-5
the participant type, Enterprise Replication defines the participant as update-anywhere, by default. For more information, see Primary-Target Replication System on page 3-1 and Participant Type on page A-112. For example, in the following participant definition, the P indicates that in this replicate, hawaii is a primary server.
P db1@g_hawaii:informix.mfct select * from mfct \
If any data in the selected columns changes, that changed data is to be sent to the secondary servers. In the following example, the R indicates that in this replicate, maui is a secondary server:
R db2@g_maui:informix.mfct select * from mfct
The specified table and columns receive information sent from the primary server. Changes to those columns on maui are not replicated. Important: The R in the participant definition indicates that the table is receive-only mode, not that the table is in read-only mode. If you do not specify the participant type, Enterprise Replication defines the participant as update-anywhere by default. For example:
db1@g_hawaii:informix.mfct select * from mfct \ db2@g_maui:informix.mfct select * from mfct
For more information, see Participant on page A-110. Defining Replicates on Table Hierarchies When you define replicates on inherited table hierarchies, use the following guidelines to replicate operations: v For both the parent and child tables, define a replicate on each table. v For only the parent table (not the child table), define a replicate on the parent table only. v For only the child table (not the parent table), define a replicate on the child table only.
Defining Master Replicates

To guarantee consistency between the nodes in your Enterprise Replication environment, you can define master replicates using the cdr define replicate command with the -- master option. Dictionary information is then stored about replicated column attributes for the participant you specify. This enables Enterprise Replication to check for consistency between this master definition and local participant definitions. Checks are performed when the replicate is
6-6
defined and each time a new participant is added to the replicate, thus avoiding runtime errors. Verification also occurs each time the master replicate is started on a server. Defining a replicate as a master replicate provides several advantages: v Ensures data integrity by verifying that all participants in the replicate have table and replicated column attributes that match the master replicate definition. v Provides automatic table generation on participants that do not already contain the table specified in the master replicate. However, Enterprise Replication cannot create tables with user-defined data types. v Allows alter operations on the replicated tables. For more information, see Performing Alter Operations on Replicated Tables on page 7-17. When you define a master replicate, you must specify a participant that is on the server for which you are running the command. This participant is used to create the dictionary information for the master replicate. If you specify additional participants in the cdr define replicate command, they are verified against the master definition and added to the replicate if they pass validation. If they fail validation, the cdr define replicate command fails and that local participant is disabled. The master replicate options are: v --empty Use this option to create an empty master replicate and add participants later. For more information, see Creating Empty Master Replicates on page 6-8. v --name Use this option to create a strict master replicate that supports alter operations. For more information, see Creating Strict Master Replicates on page 6-8. Master Replicate Verification Enterprise Replication verifies the following information about a participant when the participant is added to the master replicate: v The participant contains all replicated columns. v The replicated columns in the participant have the correct data types. For columns that are user-defined data types, only the names of the data types are verified. v Optionally, the replicated columns in the participant have the same column names as the master replicate.
6-7
Creating Strict Master Replicates You can create a strict master replicate in which all participants have the same replicated column names by using the --name=y option. This option specifies that when the master replicate verification is done for a new participant, that the column names on the participant must be identical to the column names of the master replicate. Strict master replicates allow you to perform the following tasks: v Alter operations on replicated tables. For more information, see Performing Alter Operations on Replicated Tables on page 7-17. v Remastering by using the cdr remaster command. For more information, see Remastering a Replicate on page 7-18. You can modify an existing master replicate to remove name verification by using the --name=n option of the cdr modify replicate command. Creating Empty Master Replicates You can create an empty master replicate by using the --empty option. This option allows you to specify a participant as the basis of the master replicate but not include that participant in the replicate. Creating an empty replicate can be convenient in large environments in which you later add all participants using scripts. When you define an empty master replicate, you must specify only one participant in the cdr define replicate command. This participant is used to create the master dictionary information but is not added to the replicate. The --empty option is only supported for master replicates, you cannot use it without the --master option.
Defining Shadow Replicates

A shadow replicate is a copy of an existing, or primary, replicate. Enterprise Replication uses shadow replicates to manage alter and repair operations on replicated tables. You must create a shadow replicate to perform a manual remastering of a replicate that was defined with the -n option. See Resynchronizing Data Manually on page 7-16 for information about how you can repair, or remaster, your replicated data. After creating the shadow replicate, the next step in manual remastering is to switch the primary replicate and the shadow replicate using the cdr swap shadow command. You create a shadow replicate using the cdr define replicate command with the --mirrors option, as described in cdr define replicate on page A-15. When you define a shadow replicate, its state is always set to the same state as the primary replicate. If you change the state of the primary replicate, all its shadow replicates states are also changed to the same state.
6-8
You cannot delete a primary replicate if it has any shadow replicates defined. You must first delete the shadow replicates, and then the primary replicate. You cannot modify a primary replicate (using the cdr modify replicate command) if it has any shadow replicates defined. Also, you cannot modify shadow replicates directly. You cannot suspend or resume a primary replicate (using the cdr suspend replicate or cdr resume replicate command) if it has any shadow replicates defined. Also, you cannot suspend or resume shadow replicates directly. If the primary replicate and its shadow replicates are part of an exclusive replicate set, you can suspend or resume the entire replicate set using the cdr suspend replicate or cdr resume replicate command. You cannot add a participant to a shadow replicate: v If the participant is not part of the primary replicates definition v After remastering the replicate If the primary replicate is part of an exclusive replicate set, any shadow replicates you define are automatically added to that replicate set. If you add a primary replicate to an exclusive replicate set, all its shadow replicates are also automatically added. If you delete a primary replicate from an exclusive replicate set, all its shadow replicates are also automatically deleted.
Specifying Conflict Resolution Rules and Scope

For update-anywhere replication systems, you must specify the conflict-resolution rules in the replicate definition using the --conflict=rule option. The conflict resolution rules are: v ignore v timestamp v routine_name If you use an SPL routine for your conflict-resolution rule, you can also use the --optimize option to specify that the routine is optimized. For more information, see the following: v Update-Anywhere Replication System on page 3-6 v Conflict-Resolution Rule on page 3-7 v Conflict Options on page A-17 You can also specify the scope using the --scope=scope option: v transaction (default)
6-9
v row For more information, see Scope on page 3-13, and Scope Options on page A-18.
Specifying Replication Frequency

The replication frequency options allow you to specify the interval between replications, or the time of day when an action should occur. If you do not specify the frequency, the default action is that replication always occurs immediately when data arrives. The frequency options are: v --immed v --every=interval v --at=time For more information, see Frequency Options on page A-114. Important: If you use time-based replication and two tables have referential constraints, the replicates must belong to the same exclusive replicate set. For more information, see Exclusive Replicate Sets on page 6-13.
Setting Up Error Logging

The Aborted Transaction Spooling (ATS) files and Row Information Spooling (RIS) files contain information about failed transactions and aborted rows. You can use this information to help you diagnose problems that arise during replication. It is recommended that, until you become thoroughly familiar with the behavior of the replication system, you select both options. For more information about these files, refer to Chapter 8, Monitoring and Troubleshooting Enterprise Replication, on page 8-1. To configure your replicate to use ATS and RIS: 1. Set up the ATS and RIS directories. For instructions, see Creating ATS and RIS Directories on page 4-15. 2. Specify the location of the ATS and RIS directories when you define your server. For instructions, see Defining Replication Servers on page 6-3. 3. Specify that the replicate use ATS and RIS when you define the replicate by including the --ats and --ris options in the replicate definition. For more information, see Special Options on page A-19.
6-10
Replicating Only Changed Columns

By default, Enterprise Replication replicates the entire row, even if only one column changed. (For more information on how Enterprise Replication evaluates data for replication, see Evaluating Data for Replication on page 1-8.) You can change the default behavior to replicate only the columns that changed. To replicate only changed columns, include the --fullrow n option in the replicate definition. Tip: Enterprise Replication always sends the primary key column, even if you specify to replicate only changed columns. Replicating only the columns that changed has the following advantages: v Sends less data This is particularly useful when replicating large objects, such as data stored as smart large objects and opaque user-defined types (UDTs). For example, when you replicate a row with a large column that changes infrequently and a small column that changes frequently, Enterprise Replication sends significantly less data each time it updates the row if it only replicates the changed columns. v Uses fewer Enterprise Replication resources, such as memory If Enterprise Replication replicates an entire row from the source, and the corresponding row does not exist on the target, Enterprise Replication applies the update as an INSERT, also known as an UPSERT, on the target. By replicating the entire row, Enterprise Replication self-corrects any errors during replication. If any errors occur in an update of the target database server (for example, a large object is deleted before Enterprise Replication can send the data), the next update from the source database server (a complete row image) corrects the data on the target server. Replicating only the columns that changed has the following disadvantages: v Enterprise Replication does not apply upserts. If the row to replicate does not exist on the target, Enterprise Replication does not apply it. If you set up error logging (Setting Up Error Logging on page 6-10), Enterprise Replication logs this information as a failed operation. v You cannot use the SPL routine or time stamp with SPL routine conflict-resolution rules. For more information, see Conflict Resolution on page 3-7. v You cannot use update-anywhere replication; doing so can result in inconsistent conflict resolution. v All database servers in the enterprise must be Version 9.3 or later.
6-11
Enterprise Replication does not enforce this restriction. If you attempt to replicate only changed columns to a pre-Version 9.3 database server, you will corrupt the data on that database server. Enterprise Replication logs bitmap information about the updated columns in the logical-log file. For more information, see the CDR record type in the logical-logs chapter in the IBM Informix: Administrator's Reference. For more information on the --fullrow option, see Special Options on page A-19.
Using the IEEE Floating Point or Canonical Format

The FLOAT and SMALLFLOAT data types are handled inconsistently across different platforms. You can specify sending this data in either IEEE floating point format or machine-independent decimal representation: v Enable IEEE floating point format to send all floating point values in either 32-bit (for SMALLFLOAT) or 64-bit (for FLOAT) IEEE floating point format. To use IEE floating point format, include the --floatieee option in your replicate definition. It is recommended that you define all new replicates with the --floatieee option. v Enable canonical format to send floating-point values in a machine-independent decimal representation when you replicate data between dissimilar hardware platforms. To use canonical format, include the --floatcanon option in your replicate definition. The --floatcanon option is provided for backward compatibility only; it is recommended that you use the --floatieee option when defining new replicates. v If you specify neither IEEE or canonical formats, Enterprise Replication sends FLOAT and SMALLFLOAT data types as a straight copy of machine representation. If you are replicating across different platforms, replicated floating-point numbers will be incorrect. For more information, see Special Options on page A-19. Important: Once set, you cannot modify the replicate to change the --floatieee or --floatcanon options.
Enabling Triggers
By default, when a replicate causes an insert, update, or delete on a target table, triggers associated with the table are not executed. However, you can specify that triggers are executed when the replicate data is applied by enabling triggers in the replicate definition. To enable triggers, include the --firetrigger option in your replicate definition.
6-12
For information, refer to Triggers on page 2-9 and Special Options on page A-19.
Defining Replicate Sets

To create a replicate set, use the cdr define replicateset command. Enterprise Replication supports two types of replicate sets: exclusive and non-exclusive.
Exclusive Replicate Sets

To maintain referential integrity between replicates that include tables that have referential constraints placed on columns, you must create an exclusive replicate set and add the replicate to it. An exclusive replicate set has the following characteristics: v All replicates in an exclusive replicate set have the same state and frequency settings. For more information, see Displaying Information About Replicates on page A-49. v When you create the replicate set, Enterprise Replication sets the initial state of the replicate set to active. v You can manage the replicates in an exclusive replicate set only as part of the set. Enterprise Replication does not support the following actions for the individual replicates in an exclusive replicate set: Starting a Replicate Stopping a Replicate Suspending a Replicate Resuming a Suspended Replicate v Replicates that belong to an exclusive replicate set cannot belong to any other replicate sets. To create an exclusive replicate set, use the --exclusive (-X) option with cdr define replicateset. Important: Once you create an exclusive replicate set, you cannot change it to non-exclusive and vice versa.
Non-Exclusive Replicate Sets

By default, cdr define replicateset creates non-exclusive replicate sets. A non-exclusive replicate set has the following characteristics: v You can manage replicates that belong to a non-exclusive replicate set both individually and as part of the set.
6-13
v Because individual replicates in a non-exclusive replicate set can have different states, the non-exclusive replicate set itself has no state. v You should not use non-exclusive replicate sets for replicates that include tables that have referential constraints placed on columns. v A replicate can belong to more than one non-exclusive replicate set. Important: Once you create a non-exclusive replicate set, you cannot change it to exclusive. Use non-exclusive replicate sets if you want to add a replicate to more than one replicate set. For example, you might want to create replicate sets to manage replicates on the target server, table, or entire database. To do this, create three non-exclusive replicate sets: v A set that contains the replicates that replicate to the target server v A set that contains the replicates on a particular table v A set that contains all the replicates In this scenario, each replicate belongs to three non-exclusive replicate sets.
Customizing the Replicate Set Definition

You can specify the replication frequency (Specifying Replication Frequency on page 6-10) for all the replicates when you define the replicate set. For example, to define the non-exclusive replicate set sales_set with the replicates sales_fiji and sales_tahiti and specify that the members of sales_set replicate at 4:00 A.M. every day, enter:
cdr define replicateset --at 4:00 sales_set sales_fiji \ sales_tahiti
To define the exclusive replicate set dev_set with the replicates dev_pdx and dev_lenexa and specify that the members of dev_set replicate at 5:00 P.M. every day, enter:
cdr define replicateset -X --at 17:00 dev_set dev_pdx\ dev_lenexa
Important: For replicates that belong to an exclusive replicate set, you cannot specify the frequency for the individual replicates in the set. For more information, see cdr define replicateset on page A-23.
Initially Synchronizing Data Among Database Servers

Enterprise Replication provides an initial synchronization feature that allows you to easily bring a new table up-to-date with replication when you start a new replicate, or when you add a new participant to an existing replicate.
6-14
You do not need to suspend any servers that are replicating data while you add the new replicate and synchronize it. The cdr start replicate and cdr start replicateset commands provide options to perform an initial synchronization for the replicates you are starting. All of the rows that match the replication criteria will be transferred from the source server to the target servers. If you are starting a replicate set, Enterprise Replication synchronizes tables in an order that preserves referential integrity constraints (for example, child tables are synchronized after parent tables). Use the --syncdatasource (-S) option of the cdr start replicate or cdr start replicateset command to specify the source server for synchronization. Any existing rows in the specified replicates are deleted from the remote tables and replaced by the data from the node you specify using -S. The --extratargetrows (-e) option of the cdr start replicate and cdr start replicateset commands specifies how to handle rows found on the target servers that are not present on the source server. For information about the cdr start replicate and cdr start replicateset commands, see Appendix A, Command-Line Utility Reference, on page A-1. If you use the cdr start replicate or cdr start replicateset command to specify a subset of servers on which to start the replicate (or replicate set), that replicate (or replicate set) must already be active on the source server. The source server is the server you specify with the -S option. For example, for the following command, repl1 must already be active on serv1:
cdr start repl repl1 ... -S serv1 serv2 serv3
When you start a replicate (or replicate set) for participants on all servers, the replicate does not need to be active on the source server. So, for the following command, repl1 does not need to be active:
cdr start repl1 ... -S serv1
When Enterprise Replication performs initial data synchronization, it keeps track of discrepancies between the constraints set up on source and target server tables. Rows that fail to be repaired due to these discrepancies are recorded in the synchronization failures table. See Appendix H, Synchronization Failures Table for information about using this table to solve these errors. If replication fails for some reason and data becomes out of synchronization, there are different ways to correct data mismatches between replicated tables while replication is active. The best (most thorough) way is to define and run a repair job. You can also repair data based on an ATS or RIS file. Both of these methods are described in Resynchronizing Data Among Replication Servers on page 7-14.
6-15
Using Templates to Set Up Replication

Enterprise Replication provides templates to allow easy set up and deployment of replication for clients with large numbers of tables to replicate. A template uses schema information about a database, a group of tables, columns, and primary keys to define a group of master replicates and a replicate set. First, you create a template using the cdr define template command; then, you instantiate it on the servers where you want to replicate data by running the cdr realize template command. Important: If you want to use time-based replication, you must set up replication manually. Important: Templates set up replication for full rows of tables (all the columns in the table), because they are designed to facilitate setting up large scale replication environments. If you want a participant to contain a partial row (just some columns in the table), you can either set up replication manually, or, after you realize a template you can use the cdr modify replicate command to restrict the query. All options of the cdr define template, cdr list template, cdr realize template, and cdr delete template commands are described in detail in Appendix A, Command-Line Utility Reference, on page A-1.
Defining Templates
You define a template using the cdr define template command, with which you can specify which tables to use, the database and server they are located in, and whether to create an exclusive or non-exclusive replicate set. Table names can be listed on the command line or accessed from a file using the --file option, or all tables in a database can be selected. Specify that the replicate set is exclusive if you have referential constraints on the replicated columns. Also, if you create an exclusive replicate set using a template, you do not need to stop the replicate set to add replicates. For more information about exclusive replicate sets, see Defining Replicate Sets on page 6-13. A template defines a group of master replicates and a replicate set. If a master replicate already exists that matches the template definition, that master replicate will be used.
6-16
You can use the cdr list template command from a non-leaf node to view details about the template, including the internally generated names of the master replicates. These are unique names based on the template, the server, and table names. Important: A template cannot define tables from more than one database.
Realizing Templates
After you define a template using the cdr define template command, use the cdr realize template command to instantiate the template on your Enterprise Replication database servers. The cdr realize template command first verifies that the tables on each node match the master definition used to create the template. Then, on each node, it adds the tables defined in the template as participants to master replicates created by the template. If a table on a server has additional columns to those defined in the template, those columns are not considered part of the replicate. If a table does not already exist on a server where you realize the template, you can choose to create it, and it is also added to the replicate. Also, at realization time, you can also choose to synchronize data among all servers. Verifying Participants without Applying the Template The cdr realize template command --verify option allows you to check that a templates schema information is correct on all servers before actually instantiating the template. Synchronizing Data Among Database Servers Use the --syncdatasource option to specify a server to act as the source for data synchronization on all servers where you are realizing the template. Creating Tables Automatically The --autocreate option allows you to choose to automatically create tables in the template definition if they do not already exist on a server. (This cannot be done for tables that contain user-defined data types.) Use the --dbspace option to specify a dbspace for table creation. Other Options You can use the --applyasowner option to realize a table by its owner rather than the user informix.
6-17
The --extratargetrows option specifies whether to delete, keep or merge rows found on target servers that are not present on the source server during the synchronization operation. The --target option defines whether target servers are receive-only (when target servers are defined as receive-only, updates made on the server are not propagated). Changing Templates You cannot update a template. To adjust a template, you must delete it with the cdr delete template command and then re-create it with the cdr define template command.
6-18
Chapter 7. Managing Replication Servers and Replicates

Managing Replication Servers. . . . . . . . . . . Modifying Replication Servers . . . . . . . . . Viewing Replication Server Attributes . . . . . . . Connecting to Another Replication Server. . . . . . Stopping Replication on a Server . . . . . . . . Restarting Replication on a Stopped Server . . . . . Suspending Replication for a Server . . . . . . . Resuming a Suspended Replication Server . . . . . Deleting a Replication Server . . . . . . . . . . Managing Replicates . . . . . . . . . . . . . . Modifying Replicates . . . . . . . . . . . . Adding or Deleting Participants . . . . . . . . Changing Replicate Attributes . . . . . . . . Viewing Replicate Properties . . . . . . . . . . Starting a Replicate . . . . . . . . . . . . . Stopping a Replicate . . . . . . . . . . . . . Suspending a Replicate . . . . . . . . . . . . Resuming a Suspended Replicate . . . . . . . . Deleting a Replicate . . . . . . . . . . . . . Managing Replicate Sets . . . . . . . . . . . . Modifying Replicate Sets . . . . . . . . . . . Adding or Deleting Replicates From a Replicate Set . Changing Replication Frequency For the Replicate Set Viewing Replicate Sets . . . . . . . . . . . . Starting a Replicate Set . . . . . . . . . . . Stopping a Replicate Set . . . . . . . . . . . Suspending a Replicate Set . . . . . . . . . . Resuming a Replicate Set . . . . . . . . . . . Deleting a Replicate Set . . . . . . . . . . . Managing Templates . . . . . . . . . . . . . Viewing Template Definitions . . . . . . . . . Deleting Templates . . . . . . . . . . . . . Managing Replication Server Network Connections . . . Viewing Network Connection Status . . . . . . . Dropping the Network Connection . . . . . . . Reestablishing the Network Connection . . . . . . Resynchronizing Data Among Replication Servers . . . Performing a Repair Job Using Source Tables . . . . Using a Repair Job . . . . . . . . . . . . Repairing with ATS and RIS Files . . . . . . . Solving Synchronization Errors . . . . . . . . . Resynchronizing Data Manually . . . . . . . . Performing Alter Operations on Replicated Tables . . . Adding a Column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2 . 7-2 . 7-3 . 7-3 . 7-3 . 7-4 . 7-4 . 7-4 . 7-5 . 7-5 . 7-6 . 7-6 . 7-6 . 7-7 . 7-7 . 7-8 . 7-8 . 7-9 . 7-9 . 7-10 . 7-10 . 7-10 . 7-11 . 7-11 . 7-11 . 7-11 . 7-12 . 7-12 . 7-12 . 7-13 . 7-13 . 7-13 . 7-13 . 7-13 . 7-13 . 7-14 . 7-14 . 7-14 . 7-14 . 7-15 . 7-16 . 7-16 . 7-17 . 7-18
7-1
Attaching a New Fragment to a Replicated Table . Remastering a Replicate . . . . . . . . . Automatic Remastering . . . . . . . . Manual Remastering . . . . . . . . . Dropping a Replicated Column . . . . . . . Altering a Replicated Column . . . . . . . Restrictions . . . . . . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
7-18 7-18 7-19 7-19 7-19 7-20 7-20
In This Chapter
This chapter covers how to manage your Enterprise Replication system, including managing replication servers, replicates and participants, replicate sets, templates, replication server network connections, and resynchronizing data, and performing alter operations on replicated tables.
Managing Replication Servers

The state of the server refers to the relationship between the source server and the target server. To determine the current state of the server, use cdr list server server_name. For more information about the possible server states, see The STATE Column on page A-54. This section contains information on performing the following tasks: v Modifying Replication Servers v Viewing Replication Server Attributes v Connecting to Another Replication Server v Stopping Replication on a Server v Restarting Replication on a Stopped Server v Suspending Replication for a Server v Resuming a Suspended Replication Server v Deleting a Replication Server
Modifying Replication Servers

To modify a replication server, use the cdr modify server command. With this command, you can change the following attributes of the server: v Idle timeout v Location of the directory for the Aborted Transaction Spooling (ATS) files v Location of the directory for the Row Information Spooling (RIS) files For information about each of these attributes, see Defining Replication Servers on page 6-3. For more information, see cdr modify server on page A-66.
7-2
Viewing Replication Server Attributes

Once you define a server for replication (Defining Replication Servers on page 6-3), you can view information about the server using the cdr list server command. If you do not specify the name of a defined server on the command line, Enterprise Replication lists all the servers that are visible to the current server. If you specify a server name, Enterprise Replication displays information about the current server, including server ID, server state, and attributes. For more information, see cdr list server on page A-54.
Connecting to Another Replication Server

By default, when you view information about a server, Enterprise Replication connects to the global catalog of the database server specified by $INFORMIXSERVER. You can connect to the global catalog of another database server using the --connect option. For example, to connect to the global catalog of the database server idaho, enter:
cdr list server --connect=idaho
For more information, see Global Catalog on page 2-5 and Connect Option on page A-109.
Stopping Replication on a Server

Enterprise Replication starts automatically when you use cdr define server to declare the server for replication. The replication threads continue running until you shut the database server down or you remove the server with cdr delete server. If you shut down the database server while Enterprise Replication is running, replication begins again when you restart the database server. For more information about managing the database server, see the chapter on database operating modes in the IBM Informix: Dynamic Server Administrator's Guide. Generally, to stop Enterprise Replication on a server, you should bring down the server. However, you might want to temporarily stop the Enterprise Replication threads without stopping the server. To stop replication, use the cdr stop command. When you use cdr stop, Enterprise Replication stops capturing data to be replicated. To ensure consistency, verify that no database update activity occurs while Enterprise Replication is stopped. Replication threads remain stopped (even if the database server is stopped and restarted) until you issue a cdr start command.
7-3
Warning: When you stop replication on a server, you must ensure that the send queues on the other Enterprise Replication servers participating in replication do not fill. For more information, see cdr stop on page A-92.
Restarting Replication on a Stopped Server

To restart replication on a stopped server, use the cdr start command. When you restart the server, the Enterprise Replication threads start and continue. Enterprise Replication resumes evaluating the logical logs at the replay position (where Enterprise Replication stopped evaluating the logical log when the server was stopped). Warning: If the logical log corresponding to the replay position no longer exists, then the restart partially fails and no database updates performed on the local database server are replicated. For more information, see cdr start on page A-83.
Suspending Replication for a Server

If you do not want to completely shut down the Enterprise Replication threads, you can suspend replication of data to the server using the cdr suspend server command. When replication is suspended to the server, the source server queues replicated data but suspends delivery of replicated data to the target server. Note that this command does not affect the network connection to the suspended server. The source server continues to send other messages, such as acknowledgement and control messages. For example, to suspend replication of data to the server group g_papeete from the server group g_raratonga, enter:
cdr suspend server g_papeete g_raratonga
To suspend replication to g_papeete from all servers in the enterprise, enter:

cdr suspend server g_papeete
Warning: When you suspend replication on a server, you must ensure that the send queues on the other Enterprise Replication servers participating in replication do not fill. For more information, see cdr suspend server on page A-102.
Resuming a Suspended Replication Server

To resume replication to a suspended server, use the cdr resume server command. When you resume the server, the queued data is delivered.
7-4
For example, to resume replication to the g_papeete server group, enter:

cdr resume server g_papeete
If you do not specify the server group (g_papeete in the example), cdr resume server resumes replication from all servers participating in replication. For more information, see cdr resume server on page A-81.
Deleting a Replication Server

To delete a replication server, use the cdr delete server command. You must run the cdr delete server command twice. For example, to remove the server group g_papeete from Enterprise Replication, set $INFORMIXSERVER to papeete and run the following commands:
cdr delete server g_papeete cdr delete server --connect=raratonga g_papeete
The first command deletes the local server group (g_papeete) from Enterprise Replication, and the second connects to another server in the replication environment (raratonga) and deletes g_papeete from that server. The change then replicates to the other servers in the replication environment. Warning: Avoid deleting an Enterprise Replication server and immediately re-creating it with the same name. If you re-create the objects immediately (before the operation finishes propagating to the other Enterprise Replication database servers in the network), failures might occur in the Enterprise Replication system at the time of the operation or later. For more information, see Operational Considerations on page 2-6. For more information, see cdr delete server on page A-38.
Managing Replicates
For more information about the possible replicate states, see Displaying Information About Replicates on page A-49. Important: If a replicate belongs to an exclusive replicate set, you cannot manage the replicates individually. For more information, see Exclusive Replicate Sets on page 6-13. With the exception of deleting the replicate, you must manage the replicate as part of the exclusive replicate set. For more information, see Managing Replicate Sets on page 7-10. If the replicate belongs to a non-exclusive replicate set, you can manage the replicates both
7-5
individually and as part of the set. For more information, see Non-Exclusive Replicate Sets on page 6-13.
Modifying Replicates
You can modify replicates in two ways: v Adding or Deleting Participants v Changing Replicate Attributes Adding or Deleting Participants To be useful, a replicate must include at least two participants. You can define a replicate (Defining Replicates on page 6-4) that has fewer than two participants, but before you can use that replicate, you must add more participants. To add a participant to an existing replicate, use cdr change replicate --add. For example, to add two participants to the sales_data replicate, enter:
cdr change replicate --add sales_data \ "db1@hawaii:jane.table1" "select * from table1" \ "db2@maui:john.table2" "select * from table2"
To delete a participant from the replicate, use cdr change replicate --delete. For example, to delete these two participants from the replicate, enter:
cdr change replicate --delete sales_data \ "db1@hawaii:jane.table1" "db2@maui:john.table2"
For more information, see cdr change replicate on page A-5. Changing Replicate Attributes You can change the following attributes of a replicate using the cdr modify replicate command: v Conflict-resolution rules and scope v Replication frequency v Error logging v Replicate full rows or only changed columns v Database triggers v Participant type Important: You cannot change the conflict resolution from ignore to a non-ignore option (time stamp, SPL routine, or time stamp and SPL routine). You cannot change a non-ignore conflict resolution option to ignore.
7-6
For information on each of these attributes, see Defining Replicates on page 6-4. For example, to change the replication frequency for the sales_data replicate to every Sunday at noon, enter:
cdr modify replicate sales_data Sunday.12:00
For more information, see cdr modify replicate on page A-60.
Viewing Replicate Properties

Once you define a replicate, you can view the properties of the replicate using the cdr list replicate command. For more information, see Defining Replicates on page 6-4. If you do not specify the name of a defined replicate on the command line, Enterprise Replication lists detailed information on all the replicates defined on the current server. If you use the brief option, Enterprise Replication lists participant information about all the replicates. If you specify a replicate name, Enterprise Replication displays participant information about the replicate. For information about this command, see cdr list replicate on page A-48.
Starting a Replicate
When you define a replicate, the replicate does not begin until you explicitly change its state to active. When a replicate is active, Enterprise Replication captures data from the logical log and transmits it to the participants. Important: You cannot start replicates that have no participants. To change the replicate state to active, use the cdr start replicate command. For example, to start the replicate sales_data on the servers server1 and server23, enter:
cdr start replicate sales_data server1 server23
This command causes server1 and server23 to start sending data for the sales_data replicate. If you omit the server names, this command starts the replicate on all servers that are included in that replicate. When you start a replicate, you can choose to perform an initial data synchronization, as described in Initially Synchronizing Data Among Database Servers on page 6-14.
7-7
Warning: Run the cdr start replicate command on an idle system (no transactions are occurring) or use the BEGIN WORK WITHOUT REPLICATION statement until after you successfully start the replicate. Important: If a replicate belongs to an exclusive replicate set, you must start the replicate set to which the replicate belongs. For more information, see Exclusive Replicate Sets on page 6-13 and Starting a Replicate Set on page 7-11. For more information, see cdr start replicate on page A-86.
Stopping a Replicate
To stop the replicate, use the cdr stop replicate command. This command changes the replicate state to inactive and deletes any data in the send queue for that replicate. When a replicate is inactive, Enterprise Replication does not capture, transmit, or process any database changes. Important: You cannot stop replicates that have no participants. For example, to stop the sales_data replicate on the servers server1 and server23, enter:
cdr stop replicate sales_data server1 server23
This command causes server1 and server23 to purge any data in the send queue for the sales_data replicate and stops sending data for that replicate. Any servers not listed on the command line continue to capture and send data for the sales_data replicate (even to server1 and server23). If you omit the server names, this command stops the replicate on all servers that are included in that replicate. Important: If a replicate belongs to an exclusive replicate set, you must stop the replicate set to which the replicate belongs. For more information, see Exclusive Replicate Sets on page 6-13 and Stopping a Replicate Set on page 7-11. For more information, see cdr stop replicate on page A-94.
Suspending a Replicate
If you do not want to completely halt all processing for a replicate, you can suspend a replicate using the cdr suspend replicate command. When a replicate is suspended, the replicate captures and accumulates changes to the source database, but does not transmit the captured data to the target database.
7-8
Warning: Enterprise Replication does not support referential integrity if a replicate is suspended. Instead, you should suspend a server. For more information, see Suspending Replication for a Server on page 7-4. For example, to suspend the sales_data replicate, enter:
cdr suspend replicate sales_data
Important: If a replicate belongs to an exclusive replicate set, you must suspend the replicate set to which the replicate belongs. For more information, see Exclusive Replicate Sets on page 6-13 and Suspending a Replicate Set on page 7-12. For more information, see cdr suspend replicate on page A-98.
Resuming a Suspended Replicate

To return the state of a suspended replicate to active, use the cdr resume replicate command. For example:
cdr resume replicate sales_data
Important: If a replicate belongs to an exclusive replicate set, you must resume the replicate set to which the replicate belongs. For more information, see Exclusive Replicate Sets on page 6-13 and Resuming a Replicate Set on page 7-12. For more information, see cdr resume replicate on page A-77.
Deleting a Replicate
To delete the replicate from the global catalog, use the cdr delete replicate command. When you delete a replicate, Enterprise Replication purges all replication data for the replicate from the send queue at all participating database servers. For example, to delete sales_data from the global catalog, enter:
cdr delete replicate sales_data
Warning: Avoid deleting a replicate and immediately re-creating it with the same name. If you re-create the objects immediately (before the operation finishes propagating to the other Enterprise Replication database servers in the network), failures might occur in the Enterprise Replication system at the time of the operation or later. For more information, see Operational Considerations on page 2-6. For more information, see cdr delete replicate on page A-34.
7-9
Managing Replicate Sets

When you create a replicate set, you can manage the replicates that belong to that set together or individually. If the replicate set is exclusive, you can only manage the individual replicates as part of the set. Important: Performing an operation on a replicate set (except cdr delete replicateset) is equivalent to performing the operation on each replicate in the replicate set individually. For more information, see Managing Replicates on page 7-5.
Modifying Replicate Sets

You can modify replicate sets in two ways: v Adding or Deleting Replicates From a Replicate Set v Changing Replication Frequency For the Replicate Set Adding or Deleting Replicates From a Replicate Set To add a replicate to an existing replicate set, use the command cdr change replicateset --add. For example, to add two replicates to sales_set, enter:
cdr change replicateset --add sales_set sales_kauai \ sales_moorea
When you add a replicate to: v A non-exclusive replicate set, the state of the new replicate remains as it was when you added it to the set. To bring all the replicates in the non-exclusive set to the same state, use one of the commands described in Managing Replicate Sets on page 7-10. v An exclusive replicate set, Enterprise Replication changes the existing state and replication frequency settings of the replicate to the current properties of the exclusive replicate set. To delete a replicate from the replicate set, use cdr change replicate --delete. For example, to delete the two replicates, sales_kauai and sales_moorea, from the replicate set, enter:
cdr change replicateset --delete sales_set sales_kauai\ sales_moorea
When you add or remove a replicate from an exclusive replicate set that is suspended or that is defined with a frequency interval, Enterprise Replication transmits all the data in the queue for the replicates in the replicate set up to the point when you added or removed the replicate. For more information, see Suspending a Replicate Set on page 7-12 and Frequency Options on page A-114.
7-10
For more information, see cdr change replicateset on page A-7. Changing Replication Frequency For the Replicate Set You can change the replication frequency for the replicates in an exclusive or non-exclusive replicate set using the cdr modify replicateset command. For more information, see Specifying Replication Frequency on page 6-10. For example, to change the replication frequency for each of the replicates in the sales_set to every Monday at midnight, enter:
cdr modify replicateset sales_set Monday.24:00
For more information, see cdr change replicateset on page A-7.
Viewing Replicate Sets

To view the properties of the replicate set, use the cdr list replicateset command. The cdr list replicateset command displays the replicate set name and a list of the replicates that are members of the set. To find out more about each replicate in the replicate set, see Viewing Replicate Properties on page 7-7. For more information, see cdr list replicateset on page A-52.
Starting a Replicate Set

To change the state of all the replicates in the replicate set to active, use the cdr start replicateset command. For example, to start the replicate set sales_set, enter:
cdr start replicateset sales_set
When you start a replicate set, you can choose to perform an initial data synchronization, as described in Initially Synchronizing Data Among Database Servers on page 6-14. Warning: Run the cdr start replicateset command on an idle system (when no transactions are occurring) or use the BEGIN WORK WITHOUT REPLICATION statement after you successfully start the replicate. For more information, see cdr start replicateset on page A-89 and cdr start replicate on page A-86.
Stopping a Replicate Set

To stop the replicates in the replicate set, use the cdr stop replicateset command. This command changes the state of all the replicates in the set to inactive. For example, to stop the sales_set replicate set, enter:
cdr stop replicateset sales_set
7-11
For more information, see cdr stop replicateset on page A-96 and cdr stop replicate on page A-94.
Suspending a Replicate Set

If you do not want to completely halt all processing for the replicates in a replicate set, you can suspend the replicates in the set using the cdr suspend replicateset command. For example, to suspend the sales_set replicate set, enter:
cdr suspend replicateset sales_set
For more information, see cdr suspend replicateset on page A-100 and cdr suspend replicate on page A-98.
Resuming a Replicate Set

To return the suspended replicates in the replicate set to active, use the cdr resume replicateset command. For example:
cdr resume replicateset sales_set
For more information, see cdr resume replicateset on page A-79 and cdr resume replicate on page A-77.
Deleting a Replicate Set

To delete the replicate set, use the cdr delete replicateset command. Tip: When you delete a replicate set, Enterprise Replication does not delete the replicates that are members of the replicate set. The replicates remain in the state they were in when the set was deleted. For example, to delete sales_set, enter:
cdr delete replicateset sales_set
Warning: Avoid deleting a replicate set and immediately re-creating it with the same name. If you re-create the objects immediately (before the operation finishes propagating to the other Enterprise Replication database servers in the network), failures might occur in the Enterprise Replication system at the time of the operation or later. For more information, see Operational Considerations on page 2-6. For more information, see cdr delete replicateset on page A-36.
7-12
Managing Templates
You can use the cdr list template and cdr delete template commands to view information about your templates and to clean up obsolete templates. The commands are described in detail, including examples and sample output, in Appendix A, Command-Line Utility Reference.
Viewing Template Definitions

Use the cdr list template command to view detailed information about the template and the servers, databases and tables for which the template defines replication.
Deleting Templates
Use the cdr delete template command to delete any templates that you no longer want to use to set up replication. The command also deletes any underlying replicate sets associated with the template (these will exist if the template has been realized). Important: Deleting a template does not delete replicates that may have been created by realizing a template. You cannot update a template. To modify a template, you must delete it with the cdr delete template command and then re-create it with the cdr define template command.
Managing Replication Server Network Connections

This section explains how you can view network connections status, drop network connections, and reestablish dropped network connections.
Viewing Network Connection Status

To determine the current status of the network connection to each of the servers participating in replication, use cdr list server. For more information about network connection status, see The STATUS Column on page A-55. For more information, see cdr list server on page A-54.
Dropping the Network Connection

To drop the Enterprise Replication network connection for a server, use the cdr disconnect server command. When you drop the connection, Enterprise Replication continues to function and queue transactions. For example, to disconnect the network connection between the current replication server and the server g_papeete, enter:
cdr disconnect server g_papeete
7-13
Warning: When you disconnect a server from Enterprise Replication, you must ensure that the send queues on all other Enterprise Replication servers participating in replication do not fill. For more information, see cdr disconnect server on page A-42.
Reestablishing the Network Connection

To reestablish a dropped network connection, use the cdr connect server command. For example, to reestablish the network connection between the current replication server and the server g_papeete, enter:
cdr connect server g_papeete
For more information, see cdr connect server on page A-10.
Resynchronizing Data Among Replication Servers

If replication has failed for some reason and data is out of synchronization, there are different ways to correct data mismatches between replicated tables. The following two methods repair a table based on source tables: v Using a repair job. v Processing the ATS or RIS files. You can also repair tables manually, as described in Resynchronizing Data Manually on page 7-16.
Performing a Repair Job Using Source Tables

Using a repair job is the preferred method to resynchronize your tables. You can only use ATS and RIS files if you used the --ats or --ris option when you defined the replicate or the server. Using a Repair Job Repair jobs can be run online while replication is active. First, you create the repair job using the cdr define repair command. Then, run the job using the cdr start repair command. You can define a repair job for a single replicate or for a replicate set. When you repair a replicate set, Enterprise Replication synchronizes tables in an order that preserves referential integrity constraints (for example, child tables are synchronized after parent tables). Important: Running a repair job can consume a large amount of space in your log files. Ensure you have sufficient space before starting the repair job.
7-14
Repairing Part of the Table: If you have a situation where just part of the table needs to be repaired, for example when one fragment in a partitioned table has incorrect data, you can use the --filter (-f) option of the cdr define repair command. With the --filter option you specify a WHERE clause for the source participant and a WHERE clause for the target participant that restrict the columns for which the repair job runs. Important: In the WHERE clauses, only specify columns that are exactly the same on the source and target nodes and only specify columns that are not updated. Stopping Repair Jobs: You can stop a repair job using the cdr stop repair command. You can restart from where it left off by running the cdr start repair command again. If you have defined a new repair job of the same name, the new job will be started from the beginning. The old, partially run job will not be started again. Viewing Information About Repair Jobs: You can view information about repair jobs by using the cdr list repair command. Deleting Repair Jobs: Repair job definitions are not automatically cleaned up in the global catalog, but you can delete them using the cdr delete repair command. Warning: If the repair job is active when you issue the cdr delete repair command, the repair data in the send queue of the source server is purged. Important: The cdr delete repair command does not delete the synchronization failures table associated with the repair job. You can tidy up these tables yourself; see Appendix H, Synchronization Failures Table for more information. Restrictions: The following restrictions apply to running repair jobs: v The replicate must not be in a suspended or stopped state when you start a repair job or while the job is running. v The replicate must not be set up for time based replication. Repairing with ATS and RIS Files Using this method, Enterprise Replication examines the specified ATS or RIS file and attempts to reconcile the rows that failed to be applied. This method is fast, but does not allow you as much flexibility as a repair job allows in defining how the repair should be done. To apply repairs based on an ATS or RIS file, use the cdr repair command, as described in Appendix A, Command-Line Utility Reference. The cdr repair command processes one ATS or RIS file each time you specify the command. The following table
7-15
shows how failed operations are handled.

Failed Operation Delete Insert or Update Action Taken on Target Server Delete If the row is found on the source server, does an update If the row is not found on the source server, does a delete
Solving Synchronization Errors

When Enterprise Replication runs a repair job, it keeps track of discrepancies between the constraints set up on source and target server tables. Rows that fail to be repaired due to these discrepancies are recorded in the synchronization failures table. See Appendix H, Synchronization Failures Table for information about using this table to solve these errors.
Resynchronizing Data Manually

Manual resynchronization is the least preferred method to repair your replicated tables. Only use it if you cannot run a repair job. Warning: Make sure that there are no user transactions performing updates on any replicated tables while you run this procedure. To synchronize the replication g_papeete with the g_raratonga: 1. Suspend replication to the replication server group g_papeete. See Suspending Replication for a Server on page 7-4. 2. Unload the table from the server group g_raratonga. See Loading and Unloading Data on page 4-21. 3. Load the table on g_papeete and specify BEGIN WORK WITHOUT REPLICATION. See Loading and Unloading Data on page 4-21 and Blocking Replication on page 4-18. 4. Resume replication to g_papeete. See Resuming a Suspended Replication Server on page 7-4. Important: If tables that you are synchronizing include shadow columns, you must explicitly unload and load these columns. If these values are not included, Enterprise Replication inserts NULL values. For more information, see Shadow Column Disk Space on page 4-9 and Loading and Unloading Data on page 4-21.
7-16
Performing Alter Operations on Replicated Tables

Starting with Informix Dynamic Server, Version 10.0, you can alter a replicated tables schema or its fragmentation strategy without stopping replication. You can make any of the following changes while replication is in progress: v Add or drop default values v Add or drop SQL checks v Add or drop constraints v Add or drop fragments v Alter locking granularity v Attach or detach fragments v Alter the next extent size v Add or drop columns v Alter SERIAL columns v Recluster indexes v Alter columns (change the type or size of both replicated and non-replicated columns) Enterprise Replication uses shadow replicates to manage alter operations on replicated tables without causing any interruption to replication. By using shadow replicates, the replicate participants SELECT clause can be modified seamlessly while replication is active. For example, a new column can be brought into the replicate definition, an existing replicated column can be removed from the replicate definition and the data type or size of a replicated column can be changed without interrupting replication. The steps required to perform these operations are described later in this section. See Defining Shadow Replicates on page 6-8 for more information about shadow replicates. Before altering a replicated table, ensure that you have sufficient log space allocated for long transactions, a sufficient number of locks available, and sufficient space available for the queue sbspace. When you issue a command to alter a replicated table, Enterprise Replication places the table in alter mode before performing the alter operation. Alter mode is a state in which only DDL (data-definition language) and SELECT operations are allowed but DML (data-manipulation language) operations are not. After the transaction that initiated the alter operation completes, Enterprise Replication unsets alter mode. Important: To attach a new fragment, you must set alter mode manually prior to the alter operation and unset it after the operation, as described in Attaching a New Fragment to a Replicated Table on page 7-18.
7-17
Important: If you want to drop a replicated column, before you perform the alter operation you must first run the cdr remaster command, as described in Dropping a Replicated Column on page 7-19. Important: If you add a column, it will be ignored until you run the cdr remaster command, as described in Adding a Column. Important: ALTER TABLE and ALTER FRAGMENT statements are only allowed on master replicates. See Defining Master Replicates on page 6-6 for information about master replicates.
Adding a Column
To add a new column to a replicated table, follow these steps: 1. Use the ALTER TABLE statement to add the column to the replicated table at all participating nodes. 2. Remaster the replicate to include the newly added column in the replicate definition, as described in Remastering a Replicate.
Attaching a New Fragment to a Replicated Table

To attach a new fragment, you must first manually place the replicated table in alter mode using the cdr alter command (described in Appendix A, Command-Line Utility Reference, on page A-1). Enterprise Replication cannot automatically set alter mode for this operation due to an SQL restriction that requires attaching a fragment to be performed in multiple steps. After setting the table to alter mode, follow these steps: 1. Drop the tables primary key 2. Attach the new fragment 3. Re-create the primary key 4. Unset alter mode, using the cdr alter command.
Remastering a Replicate
The cdr remaster command redefines an existing master replicate, or turns an existing non-master replicate into a master replicate. If in a replicated table, you add a new column, drop a column, or modify the data type or size of a column, you need to run the cdr remaster command, as described in Adding a Column and Dropping a Replicated Column on page 7-19. You can remaster a replicate using two different methods, automatic and manual remastering.
7-18
Automatic Remastering To use automatic remastering simply run the cdr remaster command for the replicate for which you want to update the definition. To use automatic remastering, the master replicate definition must have been created with name verification turned on (--name option of the cdr define replicate command set to y). See Appendix A, Command-Line Utility Reference, on page A-1 for details about the cdr remaster command and the cdr define replicate command. Manual Remastering To manually remaster a replicated table, follow these steps: 1. Use the cdr define replicate command to create a shadow replicate with the same attributes as the primary replicate, but with a SELECT statement that is correct for the table after the alter operation. The SELECT statement can include newly added columns or omit newly dropped columns. 2. Use the cdr swap shadow command to exchange the existing primary replicate and the newly created shadow replicate. While performing the cdr swap shadow operation, Enterprise Replication stores the BEGIN WORK position of the last known transaction sent to the grouper as a swap log position for the current swap operation. Any transaction begun prior to the swap log position will use the original (old) replicate definition. Any transaction begun after the swap log position will use the new replicate definition. The old replicate definition will be cleaned up automatically after the replicate definition is no longer required by Enterprise Replication.
Dropping a Replicated Column

To drop a replicated column, follow these steps: 1. Remaster the replicate and modify the replicates SELECT statement to remove the column being dropped, as described in Remastering a Replicate on page 7-18. 2. If the master replicate has shadow replicates defined, remove the column being dropped from their definitions as well. 3. Wait for the shadow replicate created by the remastering process to be cleaned up automatically. To check when the shadow replicate has been deleted, look in the server log file for a message similar to this:
CDR CDRRTBCleaner: Deleted obsolete replicate Shadow_4_Repl1_GMT1090373046_GID10_PID28836
7-19
The second line shows the name of the shadow replicate. See cdr remaster on page A-73 for information about the format of shadow replicate names. Alternatively, you can use either the cdr list replicate or onstat -g cat repls command to view the status of the shadow replicate. After the shadow replicate has been deleted, these commands will no longer show information about it. 4. Use the ALTER TABLE statement to drop the columns from the replicated table at all participating nodes.
Altering a Replicated Column

You can modify the size or type of a column for all basic data types and for the BOOLEAN and LVARCHAR extended types. Modification of other extended types is not supported. Because bi-directional casting cannot always be guaranteed to be successful, a warning is printed in the log file if Enterprise Replication detects a mismatch in data type or size between the master replicate definition and the local table definition. Enterprise Replication handles the mismatch by having the source server convert data that is in the local dictionary format to the master dictionary format, and the target server convert data from the master dictionary format to the local dictionary format. If the grouper sub-component is not able to convert the replicated row data from the local dictionary format to the master dictionary format, the grouper stops the local participant from the corresponding replicate (or exclusive replicate set) definition and invokes the alarm event handler with Class ID 32. See Enterprise Replication Event Alarms on page 8-13 for more information about event alarms.
Restrictions
The following restrictions apply when you use alter operations on replicated tables. v Enterprise Replication must be in an active state, unless you are only adding or dropping check constraints and default values. v Tables must have a master replicate defined. v The RENAME TABLE and RENAME COLUMN statements are not supported. v The DROP TABLE statement is not supported.
7-20
Chapter 8. Monitoring and Troubleshooting Enterprise Replication

Aborted Transaction Spooling Files . . . . . . . . . . Preparing to Use ATS . . . . . . . . . . . . . About ATS Filenames . . . . . . . . . . . . . About ATS File Information . . . . . . . . . . . BYTE and TEXT Information in ATS Files . . . . . . . Example 1 . . . . . . . . . . . . . . . . Example 2 . . . . . . . . . . . . . . . . Example 3 . . . . . . . . . . . . . . . . Changed Column Information in ATS Files . . . . . . BLOB and CLOB Information in ATS Files . . . . . . UDT Information in ATS Files . . . . . . . . . . Suppressing Datasync Errors and Warnings in ATS Files . . Row Information Spooling Files . . . . . . . . . . . Preparing to Use RIS. . . . . . . . . . . . . . About RIS Filenames . . . . . . . . . . . . . BYTE and TEXT Information in RIS Files . . . . . . . Example 1 . . . . . . . . . . . . . . . . Example 2 . . . . . . . . . . . . . . . . Changed Column Information in RIS Files . . . . . . BLOB and CLOB Information in RIS Files. . . . . . . UDT Information in RIS Files . . . . . . . . . . . Suppressing Datasync Errors and Warnings in RIS Files . . Preventing Memory Queues from Overflowing . . . . . . Preventing DDRBLOCK Mode . . . . . . . . . . Monitoring Disk Usage for Send and Receive Queue Spool Increasing the Sizes of Storage Spaces. . . . . . . . Recovering when Storage Spaces Fill . . . . . . . . Solving Common Configuration Problems . . . . . . . Enterprise Replication Event Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2 8-2 8-3 8-3 8-4 8-4 8-5 8-5 8-5 8-5 8-5 8-5 8-6 8-6 8-6 8-7 8-7 8-8 8-8 8-8 8-8 8-8 8-8 8-9 8-11 8-11 8-11 8-12 8-13
In This Chapter
Enterprise Replication provides tools to help diagnose problems that arise during replications. The Aborted Transaction Spooling (ATS) and Row Information Spooling (RIS) files contain information about failed transactions. In addition, you can use tools provided with the server, such as the onstat command, to display statistics that you can use to diagnose problems. For more information on the onstat commands that are relevant to Enterprise Replication, see Appendix C, onstat Command Reference, on page C-1. This chapter covers the following topics:
8-1
v v v v v
Aborted Transaction Spooling Files Row Information Spooling Files Preventing Memory Queues from Overflowing Solving Common Configuration Problems Enterprise Replication Event Alarms
Aborted Transaction Spooling Files

When ATS is active, all failed replication transactions are recorded in ATS files. Each ATS file contains all the information pertinent to a single failed transaction. If a replicated transaction fails for any reason (constraint violation, duplication, and so forth), all the buffers in the replication message that compose the transaction are written to a local operating-system file. You can use the ATS files to identify problems or as input to custom utilities that extract or reapply the aborted rows. Aborted-transaction spooling only occurs if the entire transaction is aborted. Transactions defined with row scope that have aborted rows but are successfully committed on the target tables are not logged. All rows that fail conflict resolution for a transaction that has row scope defined are also written to the RIS file (Row Information Spooling Files on page 8-6), if defined. In some cases, such as with long transactions, the database server itself aborts transactions. In these cases, Enterprise Replication does not generate an ATS file.
Preparing to Use ATS

Failed transactions are not automatically recorded in ATS files. To collect ATS information: 1. Create a directory for Enterprise Replication to store ATS files. v If you are using primary-target replication, create the directory on the target system. v If you are using update-anywhere replication and have conflict resolution enabled, create the directory on all participating replication systems. For more information, see Creating ATS and RIS Directories on page 4-15. 2. When you define a server for Enterprise Replication, specify the location of the ATS directory you created in step 1. To do this, include the --ats option with the cdr define server command.
8-2
If you do not specify an ATS directory, Enterprise Replication stores the ATS files in the following directory: UNIX Windows /tmp
\tmp directory of the drive that contains %INFORMIXDIR% For more information, see Creating ATS and RIS Directories on page 4-15. 3. When you define a replicate, specify that ATS is active. To do this, include the --ats option with the cdr define replicate command. For more information, see Setting Up Error Logging on page 6-10.
About ATS Filenames

When ATS is active, each aborted transaction is written to a file in the specified directory. The following table provides the naming convention for ATS files:
ats.target.source.threadId.timestamp.sequence Name target source threadId timestamp sequence Description The name of the database server receiving this replicate transaction The name of the database server that originated the transaction The identifier of the thread that processed this transaction The value of the internal time stamp at the time that this ATS instance was started A unique integer, incremented by ATS each time a transaction is spooled
The naming convention ensures that all filenames that ATS generates are unique, and therefore name collision is unlikely. However, when ATS opens a file for writing, any previous file contents will be overwritten. (ATS does not append to a spool file; if a name collision does occur with an existing file, the original contents of the file will be lost.) The following is an example ATS filename for a transaction sent by server g_amsterdam to server g_beijing:
ats.g_beijing.g_amsterdam.D_2.000529_23:27:16.6
About ATS File Information

The first three characters in each line of the ATS spool file describe the type of information for the line, as the following table defines.
8-3
Label TXH
Name Transaction heading
Description This line contains information from the transaction header, including the sending server ID and the commit time, the receiving server ID and the received time, and any Enterprise Replication, SQL, or ISAM error information for the transaction. This line contains header information from the replicated rows, including the row number within the transaction, the group ID, the replicate ID (same as replicate group ID if replicate is not part of any replicate group), the database, owner, table name, and the database operation.
RRH
Replicated row heading
RRS
Replicated row This line contains shadow column information from shadow columns replicated rows, including the source server ID and the time when the row is updated on the source server. This line is printed only if the replicate is defined with a conflict-resolution rule. Replicated row data This line contains the list of replicated columns in the same order as in the SELECT statement in the define replicate command. Each column is separated by a | and displayed in ASCII format. When the spooling program encounters severe errors (for example, cannot retrieve replicate ID for the replicated row, unable to determine the replicated columns type, size, or length), it displays this row data in hexadecimal format. The spooling program also displays the row data in hexadecimal format if a row includes replicated UDT columns.
RRD
BYTE and TEXT Information in ATS Files

When the information recorded in the ATS file includes BYTE or TEXT data, the replicated row data (RRD) information is reported, as the following examples show. Example 1
<1200, TEXT, PB 877(necromsv) 840338515(00/08/17 20:21:55)>
In this example: v 1200 is the size of the data. v TEXT is the data type (it is either BYTE or TEXT). v PB is the storage type (PB when the BYTE or TEXT is stored in the tablespace, BB for blobspace storage). v The next two fields are the server identifier and the time stamp for the column if the conflict-resolution rule is defined for this replicate and the column is stored in a tablespace.
8-4
Example 2
<500 (NoChange), TEXT, PB 877(necromsv) 840338478(00/08/17 20:21:18)>
In this example, (NoChange) after the 500 indicates that the TEXT data has a size of 500, but the data has not been changed on the source server. Therefore the data is not sent from the source server. Example 3
<(Keep local blob),75400, BYTE, PB 877(necromsv) 840338515(00/08/17 20:21:55)>)
In this example, (Keep local blob) indicates that the replicated data for this column was not applied on the target table, but instead the local BYTE data was kept. This usually happens when time-stamp conflict resolution is defined and the local column has a time stamp greater than the replicated column.
Changed Column Information in ATS Files

If you define a replicate to only replicate columns that changed, the RRD entry in the ATS and RIS files show a ? for the value of any columns that are not available. For example:
RRD 427|amsterdam|?|?|?|?|?|?|?|?|?|?|?
For more information, see Replicating Only Changed Columns on page 6-11.
BLOB and CLOB Information in ATS Files

If a replicate includes one or more BLOB or CLOB columns, the RRD entry in the ATS file displays the smart blob metadata (the in-row descriptor of the data), not the smart blob itself, in hexadecimal format in the ATS file. See UDT Information in ATS Files for an example.
UDT Information in ATS Files

If a replicate includes one or more UDT columns, the RRD entry in the ATS file displays the row data in delimited format as usual, except the string <skipped> is put in place of UDT column values. For example, for a table with columns of type INTEGER, UDT, CHAR(10), UDT, the row may look like this:
RRD 334|<skipped>|amsterdam|<skipped>
Suppressing Datasync Errors and Warnings in ATS Files

You prevent certain Datasync errors and warnings from appearing in ATS files by using the CDR_SUPPRESS_ATSRISWARN configuration parameter. For more information on the CDR_SUPPRESS_ATSRISWARN configuration parameter, see CDR_SUPPRESS_ATSRISWARN Configuration Parameter on page B-8.
8-5
For a list of error and warning messages that you can suppress, see Appendix G, Datasync Warning and Error Messages, on page G-1.
Row Information Spooling Files

Row Information Spooling logs the following types of information in RIS files: v Individual aborted row errors v Replication exceptions (such as when a row is converted by Enterprise Replication from insert to update, or from update to insert, and so forth) v Special SPL routine return codes, as defined by the application (if an SPL routine is called to resolve a conflict)
Preparing to Use RIS

Failed transactions are not automatically recorded in RIS files. To collect RIS information: 1. Create a directory for Enterprise Replication to store RIS files. If you have conflict resolution enabled, create the directory on all participating replication systems. For more information, see Creating ATS and RIS Directories on page 4-15. 2. When you define a server for Enterprise Replication, specify the location of the RIS directory you created in step 1. To do this, include the --ris option with the cdr define server command. If you do not specify an RIS directory, Enterprise Replication stores the RIS files in the following directory: UNIX Windows /tmp
\tmp directory of the drive that contains %INFORMIXDIR% If the default directory does not exist, Enterprise Replication returns an error. For more information, see Creating ATS and RIS Directories on page 4-15. 3. When you define a replicate, specify that RIS is active. To do this, include the --ris option with the cdr define replicate command. For more information, see Setting Up Error Logging on page 6-10.
About RIS Filenames

The RIS row information is written at the time that the data-synchronization component finishes processing the replicated row and can therefore also provide the local row information. The RIS filename algorithm is analogous to
8-6
the one that ATS uses, with the ats prefix replaced by ris. The RIS file that corresponds to the ATS file described in the previous section is, for example:
ris.g_beijing.g_amsterdam.D_2.000529_23:27:16.5
For more information, see About ATS Filenames on page 8-3. In addition to the four types of records printed in ATS, the RIS file also includes the following information.
Label LRH LRS Name Local-row header Local-row shadow columns Description Indicates if the local row is found in the delete table and not in the target table Contains the server ID and the time when the row is updated on the target server This line is printed only if the replicate is defined with a conflict-resolution rule. Contains the list of replicated columns extracted from the local row and displayed in the same order as the replicated row data Similar to the replicated row data, each column is separated by a | and written in ASCII format. When the spooling program encounters severe errors (for example, cannot retrieve replicate ID for the replicated row, unable to determine the replicated columns type, size, or length) or the table includes UDT columns (whether defined for replication or not), it displays the replicated row data in hexadecimal format. In this case, the local row data is not spooled.
LRD
Local-row data
BYTE and TEXT Information in RIS Files

When the information recorded in the RIS file includes BYTE or TEXT data, the RRD information is reported as the following examples show. Example 1
<1200, TEXT, PB 877(necromsv) 840338515(00/08/17 20:21:55)>
In this example: v 1200 is the size of the TEXT data. v TEXT is the data type (it is either BYTE or TEXT). v PB is the storage type (PB for storage in the tablespace, BB for blobspace storage). v The next two fields are the server identifier and the time stamp for the column if the conflict-resolution rule is defined for this replicate and the column is stored in a blobspace.
8-7
Example 2
<500 (NoChange), TEXT, PB 877(necromsv) 840338478(0000/08/17 20:21:18)>
In this example, (NoChange) after 500 indicates the TEXT data has size of 500 but the data has not been changed on the source server. Therefore the data is not sent from the source server.
Changed Column Information in RIS Files

See Changed Column Information in ATS Files on page 8-5.
BLOB and CLOB Information in RIS Files

See BLOB and CLOB Information in ATS Files on page 8-5.
UDT Information in RIS Files

See UDT Information in ATS Files on page 8-5.
Suppressing Datasync Errors and Warnings in RIS Files

You prevent certain Datasync errors and warnings from appearing in RIS files by using the CDR_SUPPRESS_ATSRISWARN configuration parameter. For more information on the CDR_SUPPRESS_ATSRISWARN configuration parameter, see CDR_SUPPRESS_ATSRISWARN Configuration Parameter on page B-8. For a list of error and warning messages that you can suppress, see Appendix G, Datasync Warning and Error Messages, on page G-1.
Preventing Memory Queues from Overflowing

In a well-tuned Enterprise Replication system, the send queue and receive queue should not regularly overflow from memory to disk. However, if the queues in memory fill, the transaction buffers are written (spooled) to disk. Spooled transactions consist of transaction records, replicate information, and row data. Spooled transaction records and replicate information are stored in the transaction tables and the replicate information tables in a single dbspace. Spooled row data is stored in one or more sbspaces. For more information, see Setting Up Send and Receive Queue Spool Areas on page 4-10. The following situations can cause Enterprise Replication to spool to disk: v Receiving server is down or suspended. v Network connection is down. If the receiving server or network connection is down or suspended, Enterprise Replication might spool transaction buffers to disk.
8-8
To check for a down server or network connection, run cdr list server on a root server. This command shows all servers and their connection status and state. For more information, see Viewing Replication Server Attributes on page 7-3 and cdr list server on page A-54. Replicate is suspended. If a replicate is suspended, Enterprise Replication might spool transaction buffers to disk. To check for a suspended replicate, run cdr list replicate. This command shows all replicates and their state. For more information, see Viewing Replicate Properties on page 7-7 and cdr list replicate on page A-48. Enterprise Replication is replicating large transactions. Enterprise Replication is optimized to handle small transactions efficiently. Very large transactions or batch jobs force Enterprise Replication into an exceptional processing path that results in spooling. For best results, avoid replicating these types of transactions. For more information, see Large Transactions on page 2-11. Logical log files are too small or too few. If the logical log files are too small or the number of logical log files is too few, Enterprise Replication is more likely to spool transaction buffers to disk. To increase the size of the logical logs, see the chapter on logical logs in the IBM Informix: Dynamic Server Administrator's Guide. For more information on configuring your logical log files for use with Enterprise Replication, see Logical Log Configuration Guidelines on page 4-8. Server is overloaded. If a server is low on resources, Enterprise Replication might not be able to hold all transactions replicating from a source server in memory during processing, and the transactions spool to disk. If this happens, check the system resources; in particular, check disk speed, RAM, and CPU resources.
Preventing DDRBLOCK Mode

If the database server comes close to overwriting a logical log that Enterprise Replication has not yet processed (log wrap), Enterprise Replication enters DDRBLOCK mode. In DDRBLOCK mode, user transactions are blocked and you see the following error in the message log:
DDR Log Snooping - DDRBLOCK phase started, userthreads blocked
Although user transactions are blocked while the server is in DDRBLOCK mode, Enterprise Replication activity is allowed to continue. During this time, Enterprise Replication attempts process transactions to advance the replay
8-9
position and remove the risk of a log overrun. Enterprise Replication can usually resolve the cause of the DDRBLOCK state. However, in more extreme cases, the replay position can be overrun. If the replay position is overrun, the following message appears in the message log file:
WARNING: The replay position was overrun, data may not be replicated.
If this occurs, you must resynchronize the source and target servers. For more information, see Resynchronizing Data Among Replication Servers on page 7-14. DDRBLOCK mode is usually caused by the logical logs being misconfigured for the current transaction activity or by the Enterprise Replication system having to spool more than usual. More-than-usual spooling could be caused by one of the following situations: v A one-time job might be larger than normal and thus require more log space. v If one of the target servers is currently unavailable, more spooling of replicated transactions can be required. v The spool file or paging space could be full and needs to be expanded. For more information, see Preventing Memory Queues from Overflowing on page 8-8. If Enterprise Replication detects that the log files are configured too small for the current database activity, then the following message might appear in the message log file:
Warning - The log space appears to be configured too small for use with Enterprise Replication (ER). ER may require additional logical logs to avoid a DDRBLOCK state and/or replay position log wrap. It is recommended that the logical log configuration be expanded.
Enterprise Replication can be configured to dynamically add a logical log file instead of placing the database server in DDRBLOCK mode. Set the CDR_MAX_DYNAMIC_LOGS configuration parameter to enable Enterprise Replication to dynamically add a logical log file when the system is in danger of a log wrap. This allows the system to better adjust to unusual activity. Set CDR_MAX_DYNAMIC_LOGS to one of the following values:
A positive number -1 0 Enterprise Replication is allowed to dynamically add up to that number of logical log files. Enterprise Replication is allowed to dynamically add an unlimited number of logical log files. Enterprise Replication does not dynamically add logical log files, and the system can enter DDRBLOCK mode.
8-10
Monitoring Disk Usage for Send and Receive Queue Spool

You should periodically monitor disk usage for the dbspace. For more information on disk usage for dbspace and sbspace that Enterprise Replication uses to spool the queues to disk, see CDR_QHDR_DBSPACE Configuration Parameter on page B-7 and the sbspace CDR_QDATA_SBSPACE Configuration Parameter on page B-6. To check disk usage for: v dbspaces Use onstat -d. For more information, see the section on monitoring disk usage in the IBM Informix: Dynamic Server Administrator's Guide and the utilities chapter of the IBM Informix: Administrator's Reference. v sbspaces Use onstat -d or oncheck -cs,-cS, -ce, -pe, -ps, and -pS. For more information, see the section on monitoring sbspaces in the IBM Informix: Dynamic Server Performance Guide and the utilities chapter of the IBM Informix: Administrator's Reference. Tip: When you use onstat -d to monitor disk usage, the S flag in the Flags column indicates an sbspace. For each sbspace chunk, the first row displays information about the whole sbspace and user-data area. The second row displays information about the metadata area.
Increasing the Sizes of Storage Spaces

If you notice that the Enterprise Replication dbspace or sbspace is running out of disk space, you can increase the size of the space by adding chunks to the space. To add a chunk to a dbspace, use onspaces -a. For example, to add a 110 kilobyte chunk with an offset of 0 to the er_dbspace dbspace, enter:
onspaces -a er_dbspace -p /dev/raw_dev2 -o 0 -s 110
To add a chunk to an sbspace, use the same onspaces command above, however you can specify more information about the chunk that you are adding. After you add a chunk to the sbspace, you must perform a level-0 backup of the root dbspace and the sbspace. For more information, see the sections on adding chunks to dbspaces and sbspaces in the IBM Informix: Extended Parallel Server Administrator's Guide and the utilities chapter of the IBM Informix: Administrator's Reference.
Recovering when Storage Spaces Fill

When the Enterprise Replication dbspace runs out of disk space, Enterprise Replication raises an alarm and writes a message to the log. When the sbspace
8-11
runs out of disk space, Enterprise Replication hangs. In either case, you must resolve the problem that is causing Enterprise Replication to spool (Preventing Memory Queues from Overflowing on page 8-8) or you must allocate additional disk space (Increasing the Sizes of Storage Spaces on page 8-11) before you can continue replication.
Solving Common Configuration Problems

If you experience problems setting up Enterprise Replication, check the following: v Make sure that you created an sbspace for the row data and set the CDR_QDATA_SBSPACE in the ONCONFIG file. For more information, see Setting Up Send and Receive Queue Spool Areas on page 4-10 and CDR_QDATA_SBSPACE Configuration Parameter on page B-6. v Verify that the trusted environment is set up correctly. For more information, see Setting Up the Trusted Environment on page 4-3. v Verify that your SQLHOSTS file is set up properly on each server participating in replication. You must set up database server groups in the SQLHOSTS file. For more information, see Verifying SQLHOSTS on page 4-3. v Verify the format of the SQLHOSTS file. The network connection (not the shared memory connection) entry should appear immediately after the database server group definition. If the network connection does not appear immediately after the database server group definition, you might see the following error when you run cdr define server:
command failed -- unable to connect to server specified (5)
You might also see a message like the following in the message log for the target server:
Reason: ASF connect error (-25592)
v Make sure that the unique identifier for each database server (i= in the options field of the SQLHOSTS information) is consistent across all nodes in the enterprise. For more information, see Database Server Groups on UNIX on page 4-4 and Appendix F, SQLHOSTS Registry Key (Windows), on page F-1. v Verify that the operating system times of the database servers that participate in the replicate are synchronized. For more information, see Time Synchronization on page 2-13.
8-12
v Make sure that the database server has adequate logical log disk space. If the database server does not have enough logical log space at initialization, you will see the following error:
command failed -- fatal server error (100)
v Check the $INFORMIXDIR/etc/buildsmi.xxx files to see if a problem occurred when the databases server built the SMI tables. v Make sure that the databases on all database server instances involved in replication are set to logging (unbuffered logging is recommended). For more information, see Unbuffered Logging on page 2-7. v For replicates that use any conflict-resolution rule except ignore, make sure that you define shadow columns (CRCOLS) for each table involved in replication. For more information, see Preparing Tables for Conflict Resolution on page 4-20. v If you defined a participant using SELECT * from table_name, make sure that the tables are identical on all database servers defined for the replicate. For more information, see Defining Participants on page 6-5 and Participant Type on page A-112. v Verify that each replicated column in a table on the source database server has the same data type as the corresponding column on the target server. Enterprise Replication does not support replicating a column with one data type to a column on another database server with a different data type. The exception to this rule is cross-replication between simple large objects and smart large objects. For more information, see Enterprise Replication Data Types on page 2-14. v Verify that all tables defined in a replicate have one PRIMARY KEY. For more information, see Primary Key Constraint on page 2-8, the IBM Informix: Database Design and Implementation Guide, and IBM Informix: Guide to SQL Syntax. v If HDR is enabled in the replication system, then all row data sbspaces must be created with logging by using the -Df LOGGING=ON option of the onspaces command. For more information, see Row Data sbspaces on page 4-11 and the IBM Informix: Dynamic Server Administrator's Guide.
Enterprise Replication Event Alarms

Starting with Version 10.0 of Informix Dynamic Server, you can use event alarms specific to Enterprise Replication to automate many administrative tasks. You can set your ALARMPROGRAM script to capture Enterprise Replication Class IDs and messages and initiate corrective action or
8-13
notification for each event. For example, you can add a new chunk to the queue data sbspace or dbspace if you detect (using Class ID 31) that that storage space is full. For information on setting ALARMPROGRAM scripts to capture events, see the appendix on event alarms in the IBM Informix: Administrator's Reference. If you were already using an ALARMPROGRAM script prior to Version 10.0 to manage Enterprise Replication administrative work, you need to modify the script to detect and take action on the Enterprise Replication events documented in this section. The following table lists the Class IDs and Class Messages for the alarms that are raised by Enterprise Replication.
Class ID 30 31 32 33 34 35 37 38 39 Class Message DDR subsystem [failure | notification] ER stable storage [queue sbspace | queue dbspace | pager sbspace] is full ER: error detected in grouper sub component ER: error detected in data sync sub component ER: error detected in queue management sub component ER: error detected in global catalog sub component ER: error detected while recovering Enterprise Replication ER: resource allocation problem detected Please contact IBM Informix Technical Support
The following tables show for each Class ID the error strings that can be returned, their severity, and the situations that trigger them. In the Situation column, snoopy refers to ddr_snoopy, an internal component of Enterprise Replication that reads the log buffers and passes information to the grouper.
Table 8-1. Events for Class ID 30 Error String Log corruption detected or read error occurred while snooping logs. WARNING: The replay position was overrun, data may not be replicated. Severity ALRM_ EMERGENCY ALRM_ EMERGENCY Situation Snoopy receives a bad buffer during a log read Snoopy detects that the replay position has been overwritten (page 8-9)
8-14
Table 8-1. Events for Class ID 30 (continued) Error String CDR: Unexpected log record type record_type for subsystem subsystem passed to DDR. DDR Log Snooping - Catchup phase started, userthreads blocked DDR Log Snooping - Catchup phase completed, userthreads unblocked Severity ALRM_ EMERGENCY ALRM_ ATTENTION ALRM_ ATTENTION Situation A log record of unexpected type was passed to snoopy Snoopy sets DDRBLOCK (Preventing DDRBLOCK Mode on page 8-9) Snoopy unsets DDRBLOCK (Preventing DDRBLOCK Mode on page 8-9)
Table 8-2. Events for Class ID 31 Error String CDR QUEUER: Send Queue space is FULL - waiting for space in sbspace_name. Severity ALRM_ EMERGENCY Situation An RQM queue runs out of room to spool (Recovering when Storage Spaces Fill on page 8-11) Grouper paging sbspace has run out of space (Increasing the Sizes of Storage Spaces on page 8-11)
CDR Pager: Paging File full: Waiting for additional space in sbspace_name
ALRM_ EMERGENCY
Table 8-3. Events for Class ID 32 Error String Severity Situation Grouper fanout or evaluator is aborting Grouper is unable to copy the transaction into send queue. Grouper detected paging error.
CDR Grouper Fanout/Evaluator thread is aborting. ALRM_ EMERGENCY CDR: Could not copy transaction at log id log_unique_id position log_position. Skipped. CDR: Paging error detected. ALRM_ EMERGENCY ALRM_ EMERGENCY
8-15
Table 8-3. Events for Class ID 32 (continued) Error String CDR Grouper: Local participant (%s) stopped for the replicate %s (or exclusive replicate set), table (%s:%s.%s). Data may be out of sync. If replicated column definition was modified then please perform the alter operation at all the replicate participants, remaster the replicate definition then restart the replicate (or exclusive replicate set) definition for the local participant with the data sync option (-S). Severity ALRM_ EMERGENCY Situation If the grouper sub-component is not able to convert the replicated row data from the local dictionary format to the master dictionary format, the grouper stops the local participant from the corresponding replicate (or exclusive replicate set) definition and invokes the alarm event handler. Grouper was unable to apply an undo (rollback to savepoint) to a transaction
CDR CDR_subcomponent_name: Could not apply undo ALRM_ properly. SKIPPING TRANSACTION. TX Begin Time: ATTENTION datetime TX Restart Log Id: log_id TX Restart Log Position: log_position TX Commit Time: datetime TX End Log Id: log_id TX End Log Position: log_position Table 8-4. Events for Class ID 33 Error String CDR DS thread_name thread is aborting. Received aborted transaction, no data to spool. Severity ALRM_ EMERGENCY ALRM_ INFO
Situation Data sync is aborting Datasync received transaction that was aborted in first buffer, so there is nothing to spool to ATS/RIS
Table 8-5. Events for Class ID 34 Error String CDR CDR_subcomponent_name: bad replicate ID replicate_id Severity ALRM_ ATTENTION Situation RQM cannot find the replicate in the global catalog for which it has a transaction
8-16
Table 8-6. Events for Class ID 35 Error String Severity Situation Could not drop delete table while deleting the replicate from the local participant. Execution of the control command requested by the peer server failed at the local server. Control command execution at the peer server failed.
CDR: Could not drop delete table. SQL ALRM_ code sql_error_code, ISAM code ATTENTION isam_error_code. Table database_name:table_name. Please drop the table manually. CDR GC peer request failed: command: ALRM_ command_string, error error_code, CDR ATTENTION server CDR_server_ID CDR GC peer processing failed: command: command_string, error error_code, CDR server CDR_server_ID Table 8-7. Events for Class ID 37 Error String CDR CDR_subcomponent_name: bad replicate ID replicate_id Table 8-8. Events for Class ID 38 Error String CDR CDR_subcomponent_name memory allocation failed (reason). Severity ALRM_INFO Severity ALRM_ ATTENTION ALRM_ ATTENTION
Situation
Situation The specified Enterprise Replication component could not allocate memory
Table 8-9. Events for Class ID 39 Error String (blank) Severity ALRM_ EMERGENCY Situation An internal error has occurred that requires assistance from Technical Support
8-17
8-18
Part 3. Appendixes
Appendix A. Command-Line Utility Reference

The command-line utility (CLU) lets you configure and control Enterprise Replication from the command line on your UNIX or Windows operating system. This appendix covers the following topics: v Command Summary v Command Syntax v Interpreting the Command-Line Utility Syntax
Command Summary
The following table shows the commands and the page where the command is documented.
Command cdr alter cdr change replicate cdr change replicateset cdr cleanstart cdr connect server cdr define repair cdr define replicate cdr define replicateset cdr define server cdr define template cdr delete repair cdr delete replicate cdr delete replicateset cdr delete server cdr delete template cdr disconnect server cdr error cdr finderr Page A-3 A-5 A-7 A-9 A-10 A-11 A-15 A-23 A-25 A-29 A-33 A-34 A-36 A-38 A-41 A-42 A-43 A-45
A-1
Command cdr list repair cdr list replicate cdr list replicateset cdr list server cdr list template cdr modify replicate cdr modify replicateset cdr modify server cdr realize template cdr remaster cdr remove cdr repair cdr resume replicate cdr resume replicateset cdr resume server cdr start cdr start repair cdr start replicate cdr start replicateset cdr stop cdr stop repair cdr stop replicate cdr stop replicateset cdr suspend replicate cdr suspend replicateset cdr suspend server cdr swap shadow
Page A-46 A-48 A-52 A-54 A-57 A-60 A-64 A-66 A-68 A-73 A-68 A-76 A-77 A-79 A-81 A-83 A-84 A-86 A-89 A-92 A-93 A-94 A-96 A-98 A-100 A-102 A-104
Command Syntax
The next sections show the syntax for all the variations of the cdr commands.
A-2
cdr alter
The cdr alter command puts the specified tables in alter mode.
Syntax
cdr alter (1) Connect Option
--on --off
database:owner.table
Notes: 1 See page A-109.

Purpose The name of the database that contains the table Restrictions The database server must be registered with Enterprise Replications. This element is required. This element is required. Syntax Long Identifiers on page A-109 Long Identifiers on page A-109
Element database
owner
User ID of the owner of the table Specifies the name of the table to put in alter mode
table
The table must be an Long actual table. It cannot be a Identifiers on synonym or a view. page A-109 This element is required.
The following table describes the options to cdr alter.

Long Form --on --off Short Form -o -f Meaning Sets alter mode on. Unsets alter mode.
Usage
Use this command to place a table in or out of alter mode. Use alter mode when you need to alter an attached fragment to the table or you want to perform other alter operations manually. For more information, see Performing Alter Operations on Replicated Tables on page 7-17.
Examples
The following example puts table1 and table2 in alter mode:
cdr alter --on db1:owner1.table1 db2:owner2.table2
A-3
See Also
v cdr swap shadow on page A-104 v cdr remaster on page A-73
A-4
cdr change replicate

The cdr change replicate command allows you to modify an existing replicate by adding or deleting one or more participants.
Syntax
cdr change replicate (1) Connect Option
--add replicate
participant modifier --verify --autocreate
--delete replicate
participant

Purpose Specifies the rows and columns to replicate Specifies the database server and table for replication Name of the replicate to change Restrictions See Considerations for the SELECT Statement on page A-113. The participant must exist. The replicate must exist. Syntax Participant Modifier on page A-112 Participant on page A-110 Long Identifiers on page A-109
Element modifier
participant
replicate
The following table describes the options to cdr change replicate.

Long Form --add --delete --autocreate Short Form -a -d -u Meaning Add participants to a replicate. Remove participants from a replicate. For use with master replicates only. Specifies that if the tables in the master replicate definition do not exist in the databases on the target servers, then they are created automatically. However, the table cannot contain columns with user-defined data types. The tables are created in the same dbspace as the database.
A-5
Long Form --verify
Short Form -v
Meaning For use with master replicates only. Specifies that the cdr change template command verifies the database, tables, and column data types against the master replicate definition on all listed servers
Usage
Use this command to add or delete a participant from a replicate. You can define a replicate that has zero or one participants, but to be useful, a replicate must have at least two participants. Important: You cannot start and stop replicates that have no participants. Important: Enterprise Replication adds the participant to the replicate in an inactive state, regardless of the state of the replicate. To activate the new participant, run cdr start replicate with the name of the server group. See cdr start replicate on page A-86.
Examples
The following example adds two participants to the replicate named repl_1: db1@server1:antonio.table with the modifier select * from table1, and db2@server2:carlo.table2 with the modifier select * from table2:
cdr change repl -a repl_1 \ "db1@server1:antonio.table1" "select * from table1" \ "db2@server2:carlo.table2" "select * from table2"
The following example removes the same two participants from replicate repl_1:
cdr change repl -d repl_1 \ "db1@server1:antonio.table1" \ "db2@server2:carlo.table2"
See Also
v cdr define replicate on page A-15 v cdr delete replicate on page A-34 v v v v v v cdr cdr cdr cdr cdr cdr list replicate on page A-48 modify replicate on page A-60 resume replicate on page A-77 start replicate on page A-86 stop replicate on page A-94 suspend replicate on page A-98
A-6
cdr change replicateset

The cdr change replicateset (or cdr change replset) command changes a replicate set by adding or deleting replicates.
Syntax
cdr change replicateset (1) Connect Option --add --delete repl_set
replicate

Purpose Name of the replicate set to change Name of the replicates to add to or delete from the set Restrictions The replicate set must exist. The replicates must exist. Syntax Long Identifiers on page A-109 Long Identifiers on page A-109
Element repl_set
replicate
The following table describes the options to cdr change replicateset

Long Form --add --delete Short Form -a -d Meaning Add replicates to a replicate set. Remove replicates from a replicate set.
Usage
Use this command to add replicates to a replicate set or to remove replicates from an exclusive or non-exclusive replicate set: v If you add a replicate to an exclusive replicate set, Enterprise Replication changes the existing state and replication frequency settings of the replicate to the current properties of the exclusive replicate set. If you remove a replicate from an exclusive replicate set, the replicate retains the properties of the replicate set at the time of removal (not the state the replicate was in when it joined the exclusive replicate set). When you add or remove a replicate from an exclusive replicate set that is suspended or that is defined with a frequency interval, Enterprise
A-7
Replication transmits all the data in the queue for the replicates in the replicate set up to the point when you added or removed the replicate. For more information, see Suspending a Replicate Set on page 7-12 and Frequency Options on page A-114. v If you add or remove a replicate to a non-exclusive replicate set, the replicate retains its individual state and replication frequency settings.
Examples
The following example adds the replicates house and barn to replicate set building_set:
cdr change replicateset --add building_set house barn
The following example removes the replicates teepee and wigwam from replicate set favorite_set:
cdr change replset --delete favorite_set teepee wigwam
See Also
v v v v v v v v cdr cdr cdr cdr cdr cdr cdr cdr define replicate on page A-15 delete replicateset on page A-36 list replicateset on page A-52 modify replicateset on page A-64 resume replicateset on page A-79 start replicateset on page A-89 stop replicateset on page A-96 suspend replicateset on page A-100
A-8
cdr cleanstart
The cdr cleanstart command starts an Enterprise Replication server with empty queues.
Syntax
cdr cleanstart (1) Connect Option
Usage
The cdr cleanstart command starts an Enterprise Replication server, but first empties replication queues of pending transactions. Use this command if using the cdr define repair command to synchronization the server would be quicker than letting the queues process normally.
See Also
v cdr start on page A-83
A-9
cdr connect server

The cdr connect server command reestablishes a connection to a database server that has been disconnected with a cdr disconnect server command.
Syntax
cdr connect server (1) Connect Option server_group

Purpose Restrictions Syntax
Element server_group
Name of database server The database server Long group to resume group must be defined for Identifiers on replication and be page A-109 disconnected.
Usage
The cdr connect server command reestablishes a connection to the server server_group.
See Also
v cdr define server on page A-25 v cdr delete server on page A-38 v cdr disconnect server on page A-42 v v v v cdr cdr cdr cdr list server on page A-54 modify server on page A-66 resume server on page A-81 suspend server on page A-102
A-10
cdr define repair

The cdr define repair command defines a repair job.
Syntax
cdr define repair (1) Connect Option --syncdatasource=data_server --extratargetrows= delete keep merge job --replicate=replicate --replset=repl_set
--blocksize=size
--filter source_participant source_modifier target_server
target_participant
target_modifier
Notes: 1
Element data_server
See page A-109.

Purpose Restrictions Syntax Long Identifiers on page A-109 Long Identifiers on page A-109 The replicate must exist. The replicate set must exist. Long Identifiers on page A-109 Long Identifiers on page A-109 Must be a positive integer
The database server to use The database server must be a reference copy of the data currently active in Enterprise Replication. Name of the repair job Name of the replicate Name of the replicate set The number of user table rows to process together during a repair
job replicate repl_set size
source_modifier
Specifies the rows and The WHERE clause must select Participant columns on the source the same columns on both the Modifier on page server to use as the basis of source and target servers. Use A-112 the repair key columns or columns with static values. See Considerations for the SELECT Statement on page A-113. Name of the participant on The participant must exist in the source server to use as the specified replicate. The P, the basis of the repair R, O, and I options are ignored. Participant on page A-110
source_participant
A-11
Element target_modifier
Purpose Specifies the rows and columns to repair on the target server
Restrictions
Syntax
The WHERE clause must select Participant the same columns on both the Modifier on page source and target servers. Use A-112 key columns or columns with static values. See Considerations for the SELECT Statement on page A-113. The participant must exist in the specified replicate. The P, R, O, and I options are ignored. The database server must be currently active in Enterprise Replication. Participant on page A-110
target_participant
Name of the participant to repair
target_server
The database server on which the data is updated
Long Identifiers on page A-109
The following table describes the cdr define repair options.

Long Form --blocksize= Short Form -b Meaning Specifies the number of user table rows to process together during a repair. Set this option to a lower number to increase concurrency. If not set, then the blocksize is calculated internally depending on the primary key size of the table being repaired. Specifies how to handle rows found on the target server that are not present on the data source server (data_server): v delete: remove rows from the target server v keep: (default) retain rows on the target server v merge: retain rows on the target server and replicate them to the data source server --filter -f Specifies the job uses a filter to choose which columns to repair. This option requires a participant and modifier from both the source and target servers. The WHERE clauses in the modifiers must select the same set of rows on both the source and target servers. In the WHERE clauses, only reference columns that are exactly the same on the source and target nodes, and only columns that are not updated. Specifies the name of the replicate on which to perform the repair job. Specifies the name of the replicate set on which to perform the repair job. Specifies the name of the database server to use as the reference copy of the data.
--extratargetrows=
-e
--replicate= --replset= --syncdatasource=
-r -R -S
A-12
Usage
Use the cdr define repair command to define a repair job to repair inconsistent data between two Enterprise Replication servers. You can choose the level of granularity for the job by specifying the whole participant, or a specific portion of it defined by a SELECT statement. The server specified in the Connect Option must be a non-leaf server. To start the repair job, use the cdr start repair command. A repair job contains procedures based on referential constraints as they exist when you run the cdr define repair command. Therefore, you can only use a specific repair job one time.
Examples
The following example defines a repair job, repair_1, on the server utah for a specified portion of the participant:
cdr define repair repair_1\ --replicate=rep1 --syncdatasource=iowa\ --extratargetrows=delete\ --filter "db2@iowa.carlo.table2" \ "SELECT * FROM table2 WHERE customerid BETWEEN 100 AND 200" \ "db2@utah.carlo.table2" \ "SELECT * FROM table2 WHERE customerid BETWEEN 100 AND 200"
Line 2 of this example indicates that the replicate to repair is named rep1 and that the synchronization data source server containing the correct data is iowa. Line 3 indicates that if there are rows on the target server, utah, that are not present on the synchronization data server (iowa) then those rows are deleted during the repair job. Lines 4 through 7 show that the specific rows to repair on the utah server are those that have a customerid between 100 and 200. The following example starts a repair job, repair_2, on the server utah for the whole participant:
cdr define repair repair_2\ --replicate=rep1 --syncdatasource=iowa\ --extratargetrows=keep \ utah
Line 3 of this example indicates that if rows are found on the utah server that do not exist on the iowa server, then those rows should remain. Line 4 indicates that the target server is utah.
A-13
See Also
v v v v v cdr cdr cdr cdr cdr delete repair on page A-33 start repair on page A-84 stop repair on page A-93 list repair on page A-46 repair on page A-76
A-14
cdr define replicate

The cdr define replicate command defines a replicate in the global catalog.
Syntax
cdr define replicate (1) Connect Option
(3) Conflict Options (2) Master Replicate Options
(4) Scope Options Frequency Options
(5)
replicate (6) Special Options Shadow Replicate Options (7)
P R O I
database@server_group:owner.table
modifier
Notes: 1 2 3 4 5 6 7 See page A-109. See page A-16 See page A-17. See page A-18. See page A-114. See page A-19. See page A-20
A-15
Element modifier
Purpose Specifies the rows and columns to replicate Name of a participant in the replication Name of the new replicate
Restrictions See Considerations for the SELECT Statement on page A-113. The participant must exist. The replicate name must be unique.
Syntax Participant Modifier on page A-112 Participant on page A-110 Long Identifiers on page A-109
participant replicate
Usage
To be useful, a replicate must include at least two participants. You can define a replicate that has one or no participant, but before you can use that replicate, you must use cdr change replicate to add more participants. Important: You cannot start and stop replicates that have no participants. When you define a replicate, the replicate does not begin until you explicitly change its state to active. For more information, see cdr start replicate on page A-86. Important: Do not create more than one replicate definition for each row and column set of data to replicate. If the participant is the same, Enterprise Replication attempts to insert duplicate values during replication.
Master Replicate Options

The master replicate options specify whether Enterprise Replication defines the replicate as a master replicate. A master replicate uses saved dictionary information about the attributes of replicated columns to verify that participants conform to the specified schema. You must specify at least one participant when creating a master replicate. All participants specified are verified when the cdr define replicate or cdr change replicate command is executed. If any participant does not conform to the master definition, then the command fails and that local participant is disabled. If a participant you specify does not contain the master replicate table, Enterprise Replication automatically creates the table on the participant based on the master replicate dictionary information. All database servers containing master replicates must be able to establish a direct connection with the master replicate database server. For more information, see Defining Master Replicates on page 6-6.
A-16
Master Replicate Options:

--master=server --empty --name= y n --verify --autocreate
Element server
Purpose
Restrictions
Syntax
Name of the database The name must be the Long server from which to base name of a database server. Identifiers on the master replicate page A-109 definition
The following table describes the master replicate options.

Long Form --master= --empty Short Form -M -t Meaning Specifies that the replicate being created is a master replicate. Specifies that the participant on the server specified with the --master option is used as the basis of the master replicate, but is not added to the replicate. Specifies whether the master replicate has column name verification in addition to column data type verification. The default is to have column name verification (-n y). Specifies that the cdr define template command verifies the database, tables, and column data types against the master replicate definition on all listed servers Specifies that if the tables in the master replicate definition do not exist in the databases on the target servers, then they are created automatically. However, the table cannot contain columns with user-defined data types. The tables are created in the same dbspace as the database.
--name=
-n
--verify
-v
--autocreate
-u
Conflict Options
The conflict options specify how Enterprise Replication should resolve conflicts with data arriving at the database server. For more information, see Conflict Resolution on page 3-7.
Conflict Options:
A-17
--conflict=
always ignore SPL_routine --optimize timestamp , SPL_routine --optimize
Element SPL_routine
Purpose SPL routine for conflict resolution
Restrictions The SPL routine must exist.
Syntax Long Identifiers on page A-109
The following table describes the conflict options.

Long Form --conflict= Short Form -C Meaning Specifies the rule that will be used for conflict resolution. The action that Enterprise Replication takes depends upon the scope. If scope is not specified, the default scope is transaction. Use the always option if you do not want Enterprise Replication to resolve conflicts, but you do want replicated changes to be applied even if the operations are not the same on the source and target servers. Use the ignore option if you do not want Enterprise Replication to resolve conflicts. Use the timestamp option to have the row or transaction with the most recent timestamp take precedence in a conflict. Specifies that the SPL routine is optimized. An optimized SPL routine is called only when a collision is detected and the row to be replicated fails to meet one of the following two conditions: v It is from the same database server that last updated the local row on the target table. v It has a time stamp greater than or equal to that of the local row. When this option is not present, Enterprise Replication always calls the SPL routine defined for the replicate when a conflict is detected.
--optimize
-O
Scope Options
The scope options specify the scope of Enterprise Replication conflict resolution.
A-18
Scope Options:
--scope= row transaction
The following table describes the scope option.

Long Form --scope= Short Form -S Meaning Specifies the scope that will be invoked when Enterprise Replication encounters a problem with data or a conflict occurs. For more information, see Scope on page 3-13. If scope is not specified, the default scope is transaction. When specifying the scope, you can abbreviate transaction to tra.
Special Options
Special Options:
--ats --ris --floatieee --floatcanon --firetrigger --fullrow y n --ignoredel y n
The following table describes the special options to cdr define replicate.
Long Form --ats Short Form -A Meaning Activates aborted transaction spooling for replicate transactions that fail to be applied to the target database. For more information, see Setting Up Error Logging on page 6-10 and Chapter 8, Monitoring and Troubleshooting Enterprise Replication, on page 8-1.
A-19
Long Form --ris
Short Form -R
Meaning Activates row-information spooling for replicate row data that fails conflict resolution or encounters replication order problems. For more information, see Setting Up Error Logging on page 6-10 and Chapter 8, Monitoring and Troubleshooting Enterprise Replication, on page 8-1. Specifies to (y) replicate the full row and enable upserts or (n) replicate only changed columns and disable upserts. By default, Enterprise Replication always replicates the entire row and enables upserts. For more information, see Replicating Only Changed Columns on page 6-11. Transfers replicated floating-point numbers in either 32-bit (for SMALLFLOAT) or 64-bit (for FLOAT) IEEE floating-point format. Use this option for all new replicate definitions. For more information, see Using the IEEE Floating Point or Canonical Format on page 6-12. Transfers replicated floating-point numbers in machine-independent decimal representation. This format is portable, but can lose accuracy. This format is provided for backwardcompatibility only; use --floatieee for all new replicate definitions. For more information, see Using the IEEE Floating Point or Canonical Format on page 6-12. Specifies that the rows that this replicate inserts fire triggers at the destination. For more information, see Enabling Triggers on page 6-12. Specifies that rows are retained if they are deleted on other nodes in the Enterprise Replication system.
--fullrow y | n
-f y | n
--floatieee
-I
--floatcanon
-F
--firetrigger
-T
--ignoredel y | n
-D y | n
Shadow Replicate Options

A shadow replicate is a copy of an existing, or primary, replicate. You must create a shadow replicate to perform a manual remastering of a replicate that was defined with the -n option. After creating the shadow replicate, the next step in manual remastering is to switch the primary replicate and the shadow replicate using the cdr swap shadow command.
A-20
Shadow Replicate Options:

--mirrors primary_replicate shadow_replicate
Element primary_replicate
Purpose Name of the replicate on which to base the shadow replicate Name of the shadow replicate to create
Restrictions The replicate must exist. The replicate name must be unique. The replicate name must be unique.
Syntax Long Identifiers on page A-109 Long Identifiers on page A-109
shadow_replicate
The following table describes the shadow replicate options to cdr define replicate.
Long Form --mirrors Short Form -m Meaning Specifies that the replicate created is a shadow replicate based on an existing primary replicate.
Examples
The following example illustrates the use of cdr define replicate:
cdr define repl --conflict=timestamp,sp1 \ --scope=tran --ats --fullrow n --floatieee newrepl \ db1@iowa:antonio.table1 select * from table1 \ db2@utah:carlo.table2 select * from table2
Line 1 of the example specifies a primary conflict-resolution rule of timestamp. If the primary rule fails, the SPL routine sp1 will be invoked to resolve the conflict. Because no database server is specified here (or on any later line), the command connects to the database server named in the INFORMIXSERVER environment variable. Line 2 specifies that the replicate has a transaction scope for conflict-resolution scope and enables aborted transaction spooling. Enterprise Replication will only replicate the rows that changed and uses the IEEE floating point format to send floating-point numbers across dissimilar platforms. The final item specifies the name of the replicate, newrepl. Line 3 defines the first participant, "db1@iowa:antonio.table1", with the select statement "select * from table1". Line 4 defines a second participant, "db2@utah:carlo.table2", with the select statement "select * from table2".
A-21
The next example is the same as the preceding example with the following exceptions: Line 1 instructs Enterprise Replication to use the global catalog on database server ohio. Line 2 also specifies that the data should be replicated every five hours.
cdr def repl -c ohio -C timestamp,sp1 \ -S tran -A -e 5:00 -I newrepl \ "db1@iowa:antonio.table1" "select * from table1" \ "db2@utah:carlo.table2" "select * from table2"
The following example illustrates creating a master replicate:

cdr def repl -c iowa -M iowa \ -C timestamp -S tran -D y newrepl \ "db1@iowa:antonio.table1" "select * from table1"
Line 1 instructs Enterprise Replication to create a master replicate based on the replicate information from the database server iowa. Line 2 specifies the conflict and scope options, that delete operations are ignored, and that the name of the replicate is newrepl. Line 3 specifies the table and columns included in the master replicate. The next example is the same as the previous example except that it specifies a second participant in Line 4. The second participant (utah) does not have the table table1 specified in its participant and modifier syntax; the execution of the cdr define replicate command creates table1 on the utah server.
cdr def repl -c iowa -M iowa \ -C timestamp -S tran -D y newrepl \ "db1@iowa:antonio.table1" "select * from table1 \ "db2@utah:carlo.table1" "select * from table1"
See Also
v v v v v v v v v cdr cdr cdr cdr cdr cdr cdr cdr cdr change replicate on page A-5 delete replicate on page A-34 list replicate on page A-48 modify replicate on page A-60 resume replicate on page A-77 start replicate on page A-86 stop replicate on page A-94 suspend replicate on page A-98 swap shadow on page A-104
A-22
cdr define replicateset

The cdr define replicateset (or cdr define replset) command defines a replicate set. A replicate set is a collection of several replicates to be managed together. Important: Enterprise Replication supports replicate sets for IBM Informix Dynamic Server, Version 9.3 and later only. You cannot define or modify replicate sets to include replicates with participants that are Version 9.2 and earlier. In addition, replicate sets are different from and are incompatible with replicate groups (in Version 9.2 and earlier).
Syntax
cdr define replicateset (1) Connect Option
repl_set (2) Frequency Options --exclusive
replicate
Notes: 1 2 See page A-109. See page A-114.

Purpose Name of replicate set to create Name of a replicate to be included in the replicate set Restrictions Syntax
Element repl_set
The name must be unique Long and cannot be the same Identifiers on as a replicate name. page A-109 The replicate must exist. Long Identifiers on page A-109
replicate
The following table describes the option to cdr define replicateset.

Long Form --exclusive Short Form -X Meaning Creates an exclusive replicate set. For more information, see Exclusive Replicate Sets on page 6-13.
A-23
Usage
Use the cdr define replicateset command to define a replicate set. Any valid replicate can be defined as part of a replicate set. A replicate can belong to more than one non-exclusive replicate set, but to only one exclusive replicate set. For details on the differences between exclusive and non-exclusive replicate sets, see Defining Replicate Sets on page 6-13. When you create an exclusive replicate set, the state is initially set to inactive. For more information, see Displaying Information About Replicates on page A-49. To 1. 2. 3. 4. create an exclusive replicate set and set the state to active: Create an empty replicate set. Stop the replicate set. Add replicates to the replicate set. Set the state of the replicate set to active by running cdr start replicateset.
Because individual replicates in a non-exclusive replicate set can have different states, the non-exclusive replicate set itself has no state. Important: Once you create an exclusive replicate set, you cannot change it to non-exclusive, and vice versa.
Examples
The following example connects to the default server and defines the non-exclusive replicate set accounts_set with replicates repl1, repl2, and repl3:
cdr def replset accounts_set repl1 repl2 repl3
The following example connects to the server olive and defines the exclusive replicate set market_set with replicates basil and thyme:
cdr def replset --connect=olive --exclusive market_set basil thyme
See Also
v cdr change replicateset on page A-7 v v v v v v v cdr cdr cdr cdr cdr cdr cdr delete replicateset on page A-36 list replicateset on page A-52 modify replicateset on page A-64 resume replicateset on page A-79 start replicateset on page A-89 stop replicateset on page A-96 suspend replicateset on page A-100
A-24
cdr define server

The cdr define server command defines a database server group and all its members (that is, all database servers that are members of the database server group) for Enterprise Replication.
Syntax
cdr define server (1) Connect Option Options (2)
--init server_group --nonroot --leaf --sync=sync_server

Name of a database Must be the name of an server group to declare existing database server for Enterprise Replication group in SQLHOSTS. See Setting up Database Server Groups on page 4-4. Name of server to use for synchronization for all subsequent server definitions to an existing replication system Must be a server that is Long registered with Enterprise Identifiers on Replication. The server page A-109 must be online.
sync_server
The following table describes the long forms shown in the syntax diagram.
Long Form --init Short Form -I Meaning Adds server_group to the replication system. The server_group must be the same as the connection server. Defines the server as a leaf server. If neither leaf nor nonroot is specified, the server is defined as a root server. Defines the server as a nonroot server. If neither leaf nor nonroot is specified, the server is defined as a root server.
--leaf
-L
--nonroot
-N
A-25
Long Form --sync=
Short Form -S
Meaning Uses the global catalog on sync_server as the template for the global catalog on the new replication server, server_group. Use this option for adding subsequent server_groups to an existing replication system. For Hierarchical Routing (HR) topologies, Enterprise Replication also uses the sync_server as the new servers parent in the current topology.
Usage
The cdr define server command creates the Enterprise Replication global catalog and adds the database server from the server_group.
Options
The options allow you to modify the default behavior of cdr define server.
Options:
--ats=ats_dir --ris=ris_dir --idle=timeout
Element ats_dir
Purpose
Restrictions
Syntax Follows naming conventions on your operating system Follows naming conventions on your operating system
Name of the directory for Must be a full pathname. Aborted Transaction The path for the directory Spooling can be no longer than 256 bytes. Name of the directory for Must be a full pathname. Row Information The path for the directory Spooling can be no longer than 256 characters. Idle time-out for this replication server
ris_dir
timeout
Must be an integer Integer number of minutes. 0 indicates no time-out. The maximum value is 32,767.
A-26
The following table describes the options to cdr define server.

Long Form --ats= Short Form -A Meaning Activates aborted transaction spooling for replicate transactions that fail to be applied to the target database. For more information, see Chapter 8, Monitoring and Troubleshooting Enterprise Replication, on page 8-1. Activates row information spooling for replicate row data that fails conflict resolution or encounters replication-order problems. For more information, see Chapter 8, Monitoring and Troubleshooting Enterprise Replication, on page 8-1. Causes an inactive connection to be terminated after timeout minutes. If time-out is 0, the connection does not time out. The default value is 0.
--ris=
-R
--idle=
-i
Examples
The first example defines the first database server in a replication environment. The command connects to the database server stan, initializes Enterprise Replication, and sets the idle time-out to 500 minutes. The example also specifies that any files that ATS generates will go into the /cdr/ats directory.
cdr define server --connect=stan \ --idle=500 --ats=/cdr/ats --init g_stan
The following example adds a database server to the replication environment in the first example. The command connects to the database server oliver, initializes Enterprise Replication, synchronizes its catalogs with the catalogs on the existing database server stan, and defines the database server oliver with an idle time-out of 600 minutes. This command also specifies that any files that ATS generates will go into the /cdr/ats directory.
cdr define server -c oliver -i 600 -A /cdr/ats -I -S g_stan g_oliver
See Also
v v v v v cdr cdr cdr cdr cdr connect server on page A-10 delete server on page A-38 disconnect server on page A-42 list server on page A-54 modify server on page A-66
A-27
v cdr resume server on page A-81 v cdr suspend server on page A-102
A-28
cdr define template

The cdr define template command creates a template for replicates and a replicate set. Because templates define replicates, many of the syntax options for the cdr define template command are the same as for the cdr define replicate command.
Syntax
(2) cdr define template template (1) Connect Option Conflict Options
(3) Scope Options Frequency Options
(4)
(5) Special Options
--master=server_group --exclusive
--database=database
table --all --file=filename
Notes: 1 2 3 4 5 See page A-109. See page A-17. See page A-18. See page A-114. See page A-19.
Purpose Name of the template to create Restrictions The template name must be unique and cannot be the same as a replicate or replicate set name. Syntax Long Identifiers on page A-109
Element template
database
Name of the database used to define the template attributes
The database server must Long be registered with Identifiers on Enterprise Replication. page A-109
A-29
Element table
Purpose Name of the table to be included in the template
Restrictions
Syntax
The table must be an Long actual table. It cannot be Identifiers on a synonym or a view. For page A-109 ANSI databases, you must specify owner.tablename. Must be a full pathname and filename. The path and filename can be no longer than 256 bytes. Within the file, the table names can be separated by a space or placed on different lines. Must be the name of an existing database server group in SQLHOSTS. See Setting up Database Server Groups on page 4-4. Follows naming conventions on your operating system.
filename
The directory and filename of the file containing a list of tables to be included in the template
server_group
Name of a database server group to declare for Enterprise Replication
The following table describes the options to cdr define template.

Long Form --all --database= Short Form -a -d Meaning Specifies that all tables in the database are included in the template. Specifies which database the template is based on. If no tables or table list filename are listed after this option, then all tables in the database are included in the template. Creates an exclusive replicate set. The state of the replicate set is inactive until you apply the template. This option is required if you have referential integrity constraints on a table. For more information, see Exclusive Replicate Sets on page 6-13. Specifies the path and filename of a file that lists the tables to be included in the template. The file must contain only table names, either separated by spaces or each on its own line.
--exclusive
-X
--file=
-f
A-30
Long Form --master=
Short Form -M
Meaning Specifies the server that contains the database to be used as the basis of the template. If this option is not specified, then the server specified in the connect option is used. For more information on master replicates, see Defining Master Replicates on page 6-6.
Usage
A template consists of schema information about a database, a group of tables, column attributes, and the primary keys that identify rows. A template defines a group of master replicates and a replicate set. The replicate set can be exclusive or non-exclusive. Specify that the replicate set is exclusive if you have referential constraints placed on the replicated columns. If you create an exclusive replicate set using a template, you do not need to stop the replicate set to add replicates. The cdr define template command performs this task automatically. After you define a template using the cdr define template command, use the cdr realize template command to apply the template to your Enterprise Replication database servers. You cannot update a template. To modify a template, you must delete it and then re-create it with the cdr define template command.
Examples
The following example illustrates the cdr define template command:
cdr define template tem1 -c detroit\ -C timestamp -S tran \ --master=chicago\ --database=new_cars table1 table2 table3
Line 1 of the example specifies a template name of tem1 and that the connection is made to the server detroit. Line 2 specifies a conflict-resolution rule of timestamp and a transaction scope for conflict resolution. Line 3 specifies that the master replicate information is obtained from the server chicago. Line 4 specifies to use the new_cars database on the chicago server and to include only the tables table1, table2, and table3. The next example is the same as the first except that it has additional options and uses a file instead of a list of tables:
cdr define template tem1 -c detroit\ -C timestamp -S tran --master=chicago\ --ignoredel y\ --database=new_cars --file=tabfile.txt
A-31
Line 3 indicates that delete operations are not replicated. Retaining deleted rows on target servers is useful for consolidation models. Line 4 specifies a filename for a file that contains a list of tables to include in the template. The tabfile.txt file has the following contents:
table1 table2 table3 table4
See Also
v v v v cdr cdr cdr cdr list template on page A-57 realize template on page A-68 delete template on page A-41 define replicate on page A-15
A-32
cdr delete repair

The cdr delete repair command deletes a repair job.
Syntax
cdr delete repair (1) Connect Option --syncdatasource=source_server job

Purpose Specifies the name of the repair job to delete Restrictions The repair job must exist and must not be running Syntax Long Identifiers on page A-109
Element job
The following table describes the option to the cdr delete repair command.
Long Form --syncdatasource= Short Form -S Meaning Specifies the name of the database server designated as the reference copy of the data in the cdr define repair command.
Usage
Use the cdr delete repair command to delete an existing repair job. You cannot delete a repair job that is running. The server specified in the Connect Option must be a non-leaf server.
Examples
The following example deletes a repair job named parts_repair:
cdr delete repair parts_repair
See Also
v v v v cdr cdr cdr cdr define repair on page A-11 start repair on page A-84 stop repair on page A-93 list repair on page A-46
A-33
cdr delete replicate

The cdr delete replicate command deletes a replicate from the global catalog.
Syntax
cdr delete replicate (1) Connect Option
repl_ name

Purpose Name of the replicate to delete Restrictions The replicate must exist. Syntax Long Identifiers on page A-109
Element repl_name
Usage
The cdr delete replicate command deletes the replicate repl_name from the global catalog. All replication data for the replicate is purged from the send queue at all participating database servers. Warning: Avoid deleting a replicate and immediately re-creating it with the same name. If you re-create the objects immediately (before the operation finishes propagating to the other Enterprise Replication database servers in the network), failures might occur in the Enterprise Replication system at the time of the operation or later. For more information, see Operational Considerations on page 2-6.
Examples
The following command connects to the default database server specified by $INFORMIXSERVER and deletes the replicate smile:
cdr del rep smile
See Also
v v v v v v cdr cdr cdr cdr cdr cdr change replicate on page A-5 define replicate on page A-15 list replicate on page A-48 modify replicate on page A-60 resume replicate on page A-77 start replicate on page A-86
A-34
v cdr stop replicate on page A-94 v cdr suspend replicate on page A-98
A-35
cdr delete replicateset

The cdr delete replicateset (or cdr delete replset) command deletes a replicate set.
Syntax
cdr delete replicateset (1) Connect Option
repl_set

Purpose Name of replicate set to delete Restrictions The replicate set must exist. Syntax Long Identifiers on page A-109
Element repl_set
Usage
The cdr delete replicateset command deletes the exclusive or non-exclusive replicate set repl_set from the global catalog. The cdr delete replicateset command does not affect the replicates or associated data. When a replicate set is deleted, the individual replicates within the replicate set are unchanged. Warning: Do not delete time-based exclusive replicate sets. Doing so might result in inconsistent data. Warning: Avoid deleting a replicate set and immediately re-creating it with the same name. If you re-create the objects immediately (before the operation finishes propagating to the other Enterprise Replication database servers in the network), failures might occur in the Enterprise Replication system at the time of the operation or later. For more information, see Operational Considerations on page 2-6.
Examples
The following example connects to the default database server and deletes the replicate set accounts_set:
cdr del replset accounts_set
A-36
See Also
v v v v v v v cdr cdr cdr cdr cdr cdr cdr change replicateset on page A-7 define replicate on page A-15 list replicateset on page A-52 modify replicateset on page A-64 resume replicateset on page A-79 start replicateset on page A-89 stop replicateset on page A-96
v cdr suspend replicateset on page A-100
A-37
cdr delete server

The cdr delete server command deletes a database server from the global catalog.
Syntax
cdr delete server (1) Connect Option server_group

Purpose Restrictions Syntax Long Identifiers on page A-109
Name of database server The database server group to remove from group must be currently the global catalog defined in Enterprise Replication.
Usage
The cdr delete server command deletes the database server in server_group from the global catalog, removes the database server from all participating replicates, and purges all replication data from the send queues for the specified database server. The command shuts down Enterprise Replication on the database server and removes the global catalog from the database server. When you delete an Enterprise Replication server, you must issue the cdr delete server command twice: once on the server being deleted and once on another server in the enterprise. The first cdr delete server removes the Enterprise Replication server from the local global catalog and removes the Enterprise Replication connection to other hosts. The second cdr delete server removes the Enterprise Replication server from the other replication servers in the system. For more information, see the Examples on page A-39. You can issue the cdr delete server command from any replication server. The only limitation is that you cannot delete a server with children. You must delete the children of a server before deleting the parent server. You cannot delete a server from the enterprise if it is stopped. To delete a server with cdr delete server, you must issue a cdr start command first. Warning: Avoid deleting a replication server and immediately re-creating it with the same name. If you re-create the objects immediately (before the operation finishes propagating to the other Enterprise Replication database servers in the network), failures might occur in
A-38
the Enterprise Replication system at the time of the operation or later. For more information, see Operational Considerations on page 2-6.
Examples
This example removes the server g_italy from the replication environment. (assume that you issue the commands from the replication server g_usa):
cdr delete server g_italy cdr delete server -c italy g_italy
The first command performs the following actions: v Removes g_italy from the usa global catalog v Drops the connection from g_usa to g_italy v Removes g_italy from all participating replicates v Purges the replication data destined for g_italy from send queues v Broadcasts this delete server command to all other servers (other than g_italy) so that they can perform the same actions The second command connects to server italy and removes Enterprise Replication from italy. That is, it removes the syscdr database and removes or stops other components of Enterprise Replication. Figure A-1 shows a replication environment with three replication servers, g_usa, g_italy, and g_japan.
g_italy g_usa
g_japan
Figure A-1. Three Replication Servers
To remove Enterprise Replication from this environment, issue the following commands from the computer where the usa replication server resides. To remove Enterprise Replication from this environment: 1. Execute:
cdr delete server g_italy
A-39
This command removes connections between the italy replication server and all other servers in the replication system (usa and japan) and removes any queued data. 2. Execute:
cdr delete server -c italy g_italy
This command removes all replication information (including the syscdr database) from the italy database server. 3. Execute:
cdr delete server g_japan cdr delete server -c g_japan
These commands remove the japan replication server. 4. Execute:

cdr delete server g_usa
This command removes the replication information from the usa replication server itself.
See Also
v v v v v v v cdr cdr cdr cdr cdr cdr cdr connect server on page A-10 define server on page A-25 disconnect server on page A-42 list server on page A-54 modify server on page A-66 resume server on page A-81 suspend server on page A-102
A-40
cdr delete template

The cdr delete template command deletes a template from the replication domain. It also deletes any underlying replicate sets associated with the template (these will exist if the template has been realized). No replicates are deleted.
Syntax
cdr delete template (1) Connect Option template

Purpose Name of the template to delete Restrictions The template must exist. Syntax Long Identifiers on page A-109
Element template
Usage
Use the cdr delete template command to delete the template definition and the replicate set realized from the template. Any replicates created by realizing the template to a database server are unaffected by this command.
Examples
The following command deletes the template and replicate set tem1:
cdr delete template tem1
See Also
v cdr define template on page A-29 v cdr realize template on page A-68
A-41
cdr disconnect server

The cdr disconnect server command stops a server connection.
Syntax
cdr disconnect server (1) Connect Option server_group

Purpose Name of the database server group to disconnect Restrictions The database server group must be currently active in Enterprise Replication. Syntax Long Identifiers on page A-109
Usage
The cdr disconnect server command drops the connection (for example, for a dialup line) between server_group and the server specified in the --connect option. If the --connect option is omitted, the command drops the connection between server_group and the default database server ($INFORMIXSERVER).
Examples
The following example drops the connection between the default database server ($INFORMIXSERVER) and the server group g_store1:
cdr disconnect server g_store1
See Also
v v v v v v v cdr cdr cdr cdr cdr cdr cdr connect server on page A-10 define server on page A-25 delete server on page A-38 list server on page A-54 modify server on page A-66 resume server on page A-81 suspend server on page A-102
A-42
cdr error
The cdr error command manages the error table and provides convenient displays of errors.
Syntax
cdr error (1) Connect Option --seq=err_server:seqno --prune first , --zap last
--follow --all --nomark

Purpose Restrictions Syntax Long Identifiers on page A-109 Time of Day on page A-114 Time of Day on page A-114 Integer
Element err_server
Name of database server The server must be group that holds the registered for Enterprise error table Replication. Start date for a range Ending date for range Sequence number of a specific error You must provide a valid date and time. You must provide a later date and time than first. You must provide the number of an error in the error table.
first last seqno
The following table describes the options to cdr error:

Long Form (no options specified) Short Form Meaning Print the current list of errors. After the errors have been printed, mark them as reviewed. Enterprise Replication does not display errors marked as reviewed. -a -f -n Print all errors, including those already reviewed. Continuously monitor the error table. Do not mark errors as reviewed.
--all --follow --nomark
A-43
Long Form --prune
Short Form -p
Meaning Prune the error table to those times in the range from first to last. If first is omitted, then all errors earlier than last are removed. Remove the (single) error specified by server:seqno from the error table. Remove all errors from the error table.
--seq --zap
-s -z
Usage
The cdr error command allows you to examine replication errors on any replication server. Sometimes a command succeeds on the server on which it is executed but fails on one of the remote servers. For example, if you execute cdr define replicate on server1, but the table name is misspelled on server2, the command succeeds on server1 and appears to have completed successfully. You can use cdr error -c server2 to see why replication is failing. The cdr error command also allows you to administer the cdr error table remotely. The reviewed flag lets you watch for new errors while keeping the old errors in the table. For example, you could run cdr error periodically and append the output to a file.
Examples
The following command displays the current list of errors on database server hill:
cdr error --connect=hill
After the errors are displayed, Enterprise Replication marks the errors as reviewed. The following command connects to the database server lake and removes from the error table all errors that occurred before the time when the command was issued:
cdr error -c lake --zap
The following command deletes all errors from the error table that occurred at or before 2:56 in the afternoon on May 1, 2000:
cdr error -p 2000-05-01 14:56:00
The following command deletes all errors from the error table that occurred at or after noon on May 1, 2000 and before or at 2:56 in the afternoon on May 1, 2000:
cdr error -p 2000-05-01 14:56:00,2000-05-01 12:00:00
A-44
cdr finderr
The cdr finderr command looks up a specific Enterprise Replication error number and displays the corresponding error text.
Syntax
cdr finderr ER_error_number
Element ER_error_number
Purpose Enterprise Replication error number to look up.
Restrictions Must be a positive integer.
You can also view the Enterprise Replication error messages in the file $INFORMIXDIR/incl/esql/cdrerr.h.
A-45
cdr list repair

The cdr list repair command displays information about repair jobs.
Syntax
cdr list repair (1) Connect Option job

Purpose Name of the repair job Restrictions The job must exist Syntax Long Identifiers on page A-109
Element job
Usage
Use the cdr list repair command to display information about repair jobs. If no repair jobs are named, the command lists all repair jobs on the current server. If one or more repair jobs are named, the command displays detailed information about those jobs.
Examples
The following command displays a list of repair jobs:
cdr list repair
The output from the previous command might be the following:

RESYNCHJOB REPLICATE/REPLSET STATE ----------------------------------------------------------------------tell_rsnc tell_repl1 Defined acct_rsnc acct_repl1 Completed
The following command lists details of the acct_rsnc job:

cdr list repair acct_rsnc

RESYNCHJOB REPLICATE/REPLSET STATE ----------------------------------------------------------------------acct_rsnc acct_repl1 Completed SOURCE -----bank@g_serv1:rajakum.account select acct_id,branch_name,acct_addr,acct_balance, last_tran_date from rajakum.account
A-46
TARGET ------bank@g_serv2:rajakum.account select acct_id,branch_name,acct_addr,acct_balance, last_tran_date from rajakum.account BLOCK SIZE: TARGET ROW OPTION: PROCESSED ROWS: START TIME: END TIME: VIOLATIONS TABLE: 20 Delete 400 2004-02-28 17:06:29 2004-02-28 17:07:34 cdr_viotab_000001
See Also
v v v v cdr cdr cdr cdr define repair on page A-11 delete repair on page A-33 stop repair on page A-93 list repair on page A-46
A-47
cdr list replicate

The cdr list replicate command displays information about the replicates on the current server.
Syntax
full cdr list replicate (1) Connect Option replicate brief

Purpose Name of the replicates Restrictions The replicates must exist. Syntax Long Identifiers on page A-109
Element replicate
Usage
The cdr list replicate command displays information about replicates (the full option). If no replicates are named, the command lists all replicates on the current server. If one or more replicates are named, the command displays detailed information about those replicates. To display only replicate names and participant information, use the brief option. You do not need to be user informix to use this command. In hierarchical topology, leaf servers have limited information about other database servers in the Enterprise Replication domain. Therefore, when cdr list replicate is executed against a leaf server, it displays incomplete information about the other database servers.
Examples
The following example displays a list of the replicates on the current server with full details:
cdr list replicate

CURRENTLY DEFINED REPLICATES --------------------------------------------REPLICATE: Repl1 STATE: Inactive
A-48
CONFLICT: FREQUENCY: QUEUE SIZE: PARTICIPANT: OPTIONS: REPLTYPE: REPLICATE: STATE: CONFLICT: FREQUENCY: QUEUE SIZE: PARTICIPANT: OPTIONS: REPLTYPE: PARENT REPLICATE:
Ignore immediate 0 bank:joe.teller row,ris,ats Master Repl2 Inactive Ignore immediate 0 bank:joe.account row,ris,ats Master,Shadow Repl1
The PARENT REPLICATE field only appears if the replicate is a shadow replicate. The following example displays a list of the replicates on the current server with brief details:
cdr list replicate brief

REPLICATE TABLE SELECT ---------------------------------------------------------------Repl1 bank@g_newyork:joe.teller select * from joe.teller Repl1 bank@g_sanfrancisco:joe.teller select * from joe.teller Repl2 bank@g_portland:joe.teller select * from joe.teller Repl2 bank@g_atlanta:joe.teller select * from joe.teller
The following example specifies the names of replicate:

cdr list repl Repl1 brief
The following output might result from the previous command:

REPLICATE TABLE SELECT ---------------------------------------------------------------Repl1 bank@g_newyork:joe.teller select * from joe.teller Repl1 bank@g_sanfrancisco:joe.teller select * from joe.teller
Displaying Information About Replicates The STATE field can include the following values.
Value Active Definition Failed Inactive Description Specifies that Enterprise Replication captures data from the logical log and transmits it to participants Indicates that the replication definition failed on a peer server Specifies that no database changes are captured, transmitted, or processed
A-49
Pending Quiescent Suspended
Indicates that a cdr delete replicate command has been issued and the replicate is waiting for acknowledgement from the participants Specifies that no database changes are captured for the replicate or participant Specifies that the replicate captures and accumulates database changes but does not transmit any of the captured data
The CONFLICT field can include the following values.

Value Ignore Timestamp Procedure Description Specifies that the replicate uses the ignore conflict-resolution rule Specifies that the replicate uses the time stamp conflict-resolution rule Specifies that the replicate uses an SPL routine as the conflict-resolution rule
The FREQUENCY field can include the following values.

Value immediate every hh:mm at day.hh:mm Description Specifies that replication occurs immediately Specifies that replications occur at intervals (for example, 13:20 specifies every thirteen hours and 20 minutes) Specifies that replications occur at a particular time on a particular day (for example, 15.18:30 specifies on the 15th day of the month at 6:30 P.M.)
The REPLTYPE field can include the following values. If the REPLTYPE is not shown, the replicate is a classic replicate (neither a master or a shadow replicate).
Value Master Shadow Description Indicates that the replicate is defined as a master replicate. Indicates that the replicate is a shadow replicate. A shadow replicate can also be a master replicate.
The PARENT REPLICATE field appears only for shadow replicates. It shows the name of the replicate on which the shadow replicate is based.
A-50
See Also
v v v v v v v cdr cdr cdr cdr cdr cdr cdr change replicate on page A-5 define replicate on page A-15 delete replicate on page A-34 modify replicate on page A-60 resume replicate on page A-77 start replicate on page A-86 stop replicate on page A-94
v cdr suspend replicate on page A-98
A-51
cdr list replicateset

The cdr list replicateset (or cdr list replset) command displays information about the replication sets defined on the current server.
Syntax
cdr list replicateset (1) Connect Option repl_set

Purpose Name of the replicates Restrictions The replicates must exist. Syntax Long Identifiers on page A-109
Element repl_set
Usage
The cdr list replicateset command displays a list of the replicate sets that are currently defined. To list the information about each of the replicates within the replicate set, use cdr list replicateset repl_set. For more information, see Displaying Information About Replicates on page A-49. In hierarchical topology, leaf servers have limited information about other database servers in the Enterprise Replication domain. Therefore, when cdr list replicateset is executed against a leaf server, it displays incomplete information about the other database servers. You do not need to be user informix to use this command.
Examples
The following example displays a list of the replicate sets on the current server:
cdr list replicateset

Ex T REPLSET N N Y Y g1 g2 PARTICIPANTS Repl1, Repl4 Repl2, Repl3, Repl5 -----------------------------------------------
A-52
The Ex field show whether the replicate set is exclusive. The T field shows whether the replicate set was created from a template. This example displays information for all the replicates in the replicate set g1:
cdr list replset g1

REPLICATE SET:g1 [Exclusive] CURRENTLY DEFINED REPLICATES ---------------------------------------------------------------------REPLICATE: Repl1 STATE: Inactive CONFLICT: Ignore FREQUENCY: immediate QUEUE SIZE: 0 PARTICIPANT: bank:arthur.account OPTIONS: row,ris,ats REPLTYPE: Master REPLICATE: STATE: CONFLICT: FREQUENCY: QUEUE SIZE: PARTICIPANT: OPTIONS: REPLTYPE: Repl4 Inactive Ignore immediate 0 bank:arthur.teller row,ris,ats Master
See Also
v v v v v v v v cdr cdr cdr cdr cdr cdr cdr cdr change replicateset on page A-7 define replicate on page A-15 delete replicateset on page A-36 modify replicateset on page A-64 resume replicateset on page A-79 start replicateset on page A-89 stop replicateset on page A-96 suspend replicateset on page A-100
A-53
cdr list server

The cdr list server command displays a list of the Enterprise Replication servers that are visible to the current server.
Syntax
cdr list server (1) Connect Option server_group

Name of the server group The database server groups must be defined for Enterprise Replication.
Usage
The cdr list server command displays information about servers. You do not need to be user informix to use this command. Listing All Enterprise Replication Servers When no server-group name is given, the cdr list server command lists all database server groups that are visible to the current replication server. In hierarchical topology, leaf servers only have information about their parent database servers in the Enterprise Replication domain. Therefore, when cdr list server is executed against a leaf server, it displays incomplete information about the other database servers. For example, cdr list server might give the following output:
SERVER ID STATE STATUS QUEUE CONNECTION CHANGED -------------------------------------------------------------g_newyork 1 Active Local 0 g_portland 2 Active Connected 0 Mar 19 13:48:44 g_sanfrancisco 3 Active Connected 0 Mar 19 13:48:40
The SERVER and ID Columns: The SERVER and ID columns display the name and unique identifier of the Enterprise Replication server group. The STATE Column: The STATE column can have the following values.
Active Indicates that the server is active and replicating data
A-54
Deleted Quiescent Suspended
Indicates that the server has been deleted and that it is not capturing or delivering data and the queues are being drained Indicates that the server is in the process of being defined Indicates that delivery of replication data to the server is suspended
The STATUS Column: The STATUS column can have the following values.
Connected Connecting Disconnect Dropped Error Local Timeout Indicates that the server connection is up Indicates that the server is attempting to connect Indicates that the server connection is down in response to an explicit disconnect Indicates that the server connection is down due to a network error because the server is unavailable Indicates that an error has occurred (check the log and contact customer support, if necessary) Identifies that this server is the local server as opposed to a remote server Indicates that the connection is down due to an idle time-out
The QUEUE Column: The QUEUE column displays the size of the queue for the server group. The CONNECTION CHANGED Column: The CONNECTION CHANGED column displays the most recent time that the status of the server connection was changed. Displaying Details about a Single Replication Server When the cdr list server command includes the name of a database server group, the command displays the attributes of that database server. For example, cdr list server g_usa might give the following output:
NAME ID ATTRIBUTES ----------------------------------------------------g_usa 3 timeout=15,atsdir=/w/ats risdir=/w/ris
Examples
In Figure A-2 and in the following examples, usa and italy are root servers, denver and boston are nonroot servers, and miami is a leaf server. The usa server is the parent of denver and boston, and boston is the parent of miami.
A-55
usa
italy
denver
boston
miami
Figure A-2. cdr list server example
The example is created by running the following commands:

cdr list server g_usa g_usa 1 timeout=15 hub cdr list server -c denver g_denver g_denver 27 root=g_usa cdr list server -c italy g_denver g_denver 27 root=g_usa forward=g_usa cdr list server g_miami g_miami 4 root=g_boston leaf
See Also
v v v v v v v v cdr cdr cdr cdr cdr cdr cdr cdr connect server on page A-10 define server on page A-25 delete server on page A-38 disconnect server on page A-42 modify server on page A-66 resume server on page A-81 start on page A-83 suspend server on page A-102
A-56
cdr list template

The cdr list template command displays information about the templates on the current server.
Syntax
BRIEF cdr list template (1) Connect Option template FULL

Purpose Name of the template Restrictions The templates must exist. Syntax Long Identifiers on page A-109
Element template
Usage
The cdr list template command displays information about templates. If no templates are named, the command lists all templates in the Enterprise Replication domain. If one or more templates are named, the command displays the names, database names, and table names for those templates. To display detailed information for your templates, use the FULL option. You do not need to be user informix to use this command. In hierarchical topology, leaf servers have limited information about other database servers in the Enterprise Replication domain. Therefore, when cdr list template is executed against a leaf server, it displays incomplete information about the other database servers.
Examples
The following example displays detailed information about the templates on the current server:
cdr list template

TEMPLATE DATABASE TABLES ============================================== tem1 newcars table1 newcars table2
A-57
tem2
newcars carparts carparts
table3 table1 table3
The following example displays detailed information about the template tem1:
cdr list template tem1

CURRENTLY DEFINED TEMPLATES =========================== TEMPLATE: tem1 TEMPLATE ID: 6553605 SERVER: utah DATABASE: newcars REPLICATE: tem1_utah_2_1_table1 OWNER: pravin TABLE: table1 TEMPLATE: TEMPLATE ID: SERVER: DATABASE: REPLICATE: OWNER: TABLE: TEMPLATE: TEMPLATE ID: SERVER: DATABASE: REPLICATE: OWNER: TABLE: tem1 6553605 utah newcars tem1_utah_2_2_table2 pravin table2 tem1 6553605 utah newcars tem1_utah_2_3_table3 pravin table3
Generated Replicate and Replicate Set Names When you apply a template, Enterprise Replication generates the replicate and replicate set names. The generated replicate set name is the same as the template name. The generated replicate name has the following format: template_server_cdrserverid_n_table
template server cdrserverid n table The name of the template The name of the database The server ID as set in the SQLHOSTS file A unique sequence number The name of the table
A-58
See Also
v cdr define template on page A-29 v cdr realize template on page A-68
A-59
cdr modify replicate

The cdr modify replicate command modifies replicate attributes.
Syntax
cdr modify replicate (1) Connect Option --name=n
replicate (2) Conflict Options (3) Scope Options (4) Frequency Options (5) Special Options participant
Notes: 1 2 3 4 5 See page A-109. See page A-17. See page A-18. See page A-114. See page A-19.
Purpose Name of a participant in the replication Name of the replicate to modify Restrictions Syntax
Element participant replicate
The participant must be a Participant on member of the replicate. page A-110 The replicate name must exist. Long Identifiers on page A-109
The following table describes the option to cdr modify replicate.

Long Form --name=n Short Form -n n Meaning Removes the name verification attribute from a master replicate. For more information, see Creating Strict Master Replicates on page 6-8.
A-60
Usage
The cdr modify replicate command modifies the attributes of a replicate or of one or more participants in the replicate. You can also change the mode of a participant. If the command does not specify participants, the changes apply to all participants in the replicate. For attribute information, see cdr define replicate on page A-1. To add or delete a participant, see cdr change replicate on page A-5. Important: If you change the conflict-resolution rule with cdr modify replicate, you must also explicitly state SCOPE parameter, even if the SCOPE value does not change. Restrictions The attributes for cdr modify replicate are the same as the attributes for cdr define replicate, with the following exceptions: v You cannot change the machine-independent decimal representation (--floatcanon) or IEEE floating point (--floatieee) formats. v You cannot change the conflict resolution from ignore to a non-ignore option (time stamp, SPL routine, or time stamp and SPL routine). You cannot change a non-ignore conflict resolution option to ignore. However, you can change from time stamp resolution to SPL routine resolution or from SPL routine resolution to time stamp. v The --ats, --ris, --firetrigger, and --fullrow options require a yes (y) or no (n) argument.
Special Options
Special Options:
--ats
y n --ris y n --firetrigger --fullrow y n
y n
The following table describes the special options to cdr modify replicate. For more information on these options, see Special Options on page A-19.
A-61
Long Form --ats y | n
Short Form -A y | n
Meaning Activates (y) or deactivates (n) aborted-transaction spooling for replicate transactions that fail to be applied to the target database. Activates (y) or deactivates (n) row-information spooling for replicate row data that fails conflict resolution or encounters replication-order problems. Causes the rows inserted by this replicate to fire (y) or not fire (n) triggers at the destination. Specifies to (y) replicate the full row and enable upserts (default) or (n) replicate only changed columns and disable upserts.
--ris y | n
-R y | n
--firetrigger y | n --fullrow y | n
-T y | n -f y | n
Examples
The following example modifies the frequency attributes of replicate smile to replicate every five hours:
cdr modify repl -every=300 smile
The following example modifies the frequency attributes of replicate smile to replicate daily at 1:00 A.M.:
cdr modify repl -a 01:00 smile
The following example modifies the frequency attributes of replicate smile to replicate on the last day of every month at 5:00 A.M., to generate ATS files, and not to fire triggers:
cdr modify repl -a L.5:00 -A y -T n smile
The following example changes the mode of the first participant listed to receive-only and the mode of the second to primary.
cdr mod repl smile R db1@server1:antonio.table1 \ P db2@server2:carlo.table2
See Also
v cdr change replicate on page A-5 v cdr define replicate on page A-15 v v v v cdr cdr cdr cdr delete replicate on page A-34 list replicate on page A-48 resume replicate on page A-77 start replicate on page A-86
v cdr stop replicate on page A-94
A-62
v cdr suspend replicate on page A-98
A-63
cdr modify replicateset

The cdr modify replicateset (or cdr modify replset) command modifies all the replicates in a replicate set.
Syntax
cdr modify replicateset (1) Connect Option (2) Frequency Options
repl_set

Purpose Name of replicate set to modify Restrictions The replicate set must exist. Syntax Long Identifiers on page A-109
Element repl_set
Usage
The cdr modify replicateset command modifies the attributes of all the replicates in the replicate set repl_set. To add or delete replicates from a replicate set, use the cdr change replicateset command (cdr change replicateset on page A-7). Important: Once you create a replicateset, you cannot change it from exclusive to non-exclusive or vice versa.
Examples
The following example connects to the default server ($INFORMIXSERVER) and modifies the replicate set sales_set to process replication data every hour:
cdr mod replset --every 60 sales_set
See Also
v v v v v v cdr cdr cdr cdr cdr cdr change replicateset on page A-7 define replicate on page A-15 delete replicateset on page A-36 list replicateset on page A-52 resume replicateset on page A-79 start replicateset on page A-89
A-64
v cdr stop replicateset on page A-96 v cdr suspend replicateset on page A-100
A-65
cdr modify server

The cdr modify server command modifies the Enterprise Replication attributes of a database server.
Syntax
cdr modify server (1) Connect Option --idle=interval --mode primary receive-only --ats=ats_dir --ris=ris_dir
server_group

Purpose Name of a database server group to modify Idle time-out for this server Name of Aborted Transaction Spooling directory Name of the Row Information Spooling directory Restrictions The database server group must be defined in Enterprise Replication. The value must be an integer >=0. 0 indicates no time-out. The directory must be a full pathname. Integer number of minutes. Directory name on your operating system. Directory name on your operating system. Syntax
interval
ats_dir
ris_dir
The directory must be a full pathname.
Usage
The cdr modify server command modifies the replication server server_group. The following table describes the options to cdr modify server.
Long Form --idle Short Form -i Meaning Causes an inactive connection to be terminated after idle time
A-66
Long Form --mode --ats
Short Form -m -A
Meaning Changes the mode of all replicates using this server to primary (p) or to receive-only (r) Activates aborted-transaction spooling for replicate transactions that fail to be applied to the target database. For more information, see Chapter 8, Monitoring and Troubleshooting Enterprise Replication, on page 8-1. Activates row-information spooling for replicate-row data that fails conflict resolution or encounters replication-order problems. For more information, see Chapter 8, Monitoring and Troubleshooting Enterprise Replication, on page 8-1.
--ris
-R
Examples
The following example connects to the database server paris and modifies the idle time-out of server group g_rome to 10 minutes. ATS files go into the directory /cdr/atsdir.
cdr modify server -c paris -i 10 -A /cdr/atsdir g_rome
The following example connects to the default database server and sets the modes of all participants on g_geometrix to primary:
cdr mod ser -m primary g_geometrix
See Also
v v v v v v v cdr cdr cdr cdr cdr cdr cdr connect server on page A-10 define server on page A-25 delete server on page A-38 disconnect server on page A-42 list server on page A-54 resume server on page A-81 suspend server on page A-102
A-67
cdr realize template

The cdr realize template command realizes a template on the database servers within the replication domain.
Syntax
cdr realize template (1) Connect Option template
--syncdatasource=data_server --extratargetrows= delete keep merge
--verify --autocreate --dbspace=dbspace
--target
P R
database@server_group:table --applyasowner

Purpose The database server from which the data is copied to all other database servers listed The name of the database Restrictions The database server must be defined in Enterprise Replication. If you do not specify the database name, the name of the database specified in the cdr define template command is used. Syntax
Element data_server
database
A-68
Element dbspace
Purpose The name of the dbspace for Enterprise Replication to use when creating tables
Restrictions The dbspace must exist on all the database servers listed. If you do not specify a dbspace name and new tables are created, they are created in the rootdbs dbspace, which is not recommended by IBM The database server must be defined in Enterprise Replication. The template must exist. Use the cdr define template command to create the template. For more information, see cdr define template on page A-29.
Syntax
server
The database server on which to realize the template The name of the template
template
The following table describes the special options to cdr realize template.
Long Form --applyasowner Short Form -o Meaning Specifies that the template is realized by the owner of the table specified when the template was defined. By default, the template is realized by the user informix. Specifies that if the tables in the template definition do not exist in the databases on the target servers, then they are created automatically. However, the table cannot contain columns with user-defined data types. Specifies the name of the dbspace for Enterprise Replication. If you do not include this option, the dbspace rootdbs is used.
--autocreate
-u
--dbspace=
-D
A-69
Long Form --extratargetrows=
Short Form -e
Meaning Specifies how to handle rows found on the target servers that are not present on the data source server from which the data is being copied (data_server): v delete: remove rows from the target servers v keep: (default) retain rows on the target servers v merge: retain rows on the target servers and replicate them to the data source server This option applies to the initial data synchronization operation only; it does not affect the behavior of the replicate.
--target
-t
Specifies that all servers listed except the data source server are receive-only target servers. This option is superseded by the P option. Specifies which server is the source of the data that is used to synchronize all the other servers listed in the cdr realize template command. Specifies that the cdr realize template command verifies that the database, tables, column data types are correct on all listed servers, but does not realize the template.
--syncdatasource=
-S
--verify
-v
Tip: The P and R options shown in the syntax diagram refer to participant type as primary (P) or secondary (receive-only, R) as described in Participant Type on page A-112.
Usage
Templates provide an efficient way to create replicates and a replicate set, create the participant tables, and synchronize data. The cdr realize template and cdr define template commands are an alternative to using the cdr define replicate and cdr start replicate commands once each for every replicate, plus the cdr define replicateset command. Before you can use the cdr realize template command, you must define Enterprise Replication servers using the cdr define server command and define the template using the cdr define template command. You should also create the database to be replicated on all database servers in the replication domain. However, only the database on the synchronization data source server needs to be populated with data. The cdr realize template command performs the following tasks:
A-70
v If you specify the --verify option, verifies the database, tables, column data types, and primary keys on all participating servers; however, the template is not realized. v If you specify the --syncdatasource option, synchronizes the data from the source database with all other participating databases. v Verifies the database and table attributes to ensure that proper replication can be performed on each database. v Creates replicates as master replicates. v Creates a replicate set for the new replicates. v Starts the replicates. The replicates and replicate set created from a template have generated names. Use the cdr list template command to see the names of the replicates and replicate set associated with a particular template.
Examples
The following example illustrates the cdr realize template command:
cdr realize template tem1 -c detroit\ new_cars@detroit new_cars0@chicago new_cars1@newark\ new_cars2@columbus
Line 1 specifies that the template name is tem1 and the server to connect to is the detroit server. Line 2 lists the names of the databases and database servers on which to realize the template. The following example illustrates realizing the template, creating the databases and tables, and loading data on the target database servers:
cdr realize template tem1 -c detroit\ --syncdatasource=detroit --extratargetrows=keep\ --receiveonly P detroit chicago newark columbus
Line 2 specifies to use the detroit server as the source of the data to replicate to all other participating servers. If Enterprise Replication encounters any rows on the chicago, newark, or columbus servers that do not exist on the detroit server, those rows are kept. Line 3 specifies the participant type for each server. The --receiveonly option makes all servers except the detroit server target participants. The detroit server is a primary participant because the P option supersedes the --receiveonly option. The following example verifies the database and table attributes on the chicago, newark, and columbus servers; the template is not realized on these servers:
A-71
cdr realize template tem1 -c detroit\ --verify chicago newark columbus
See Also
v v v v cdr cdr cdr cdr define template on page A-29 define server on page A-25 list template on page A-57 delete template on page A-41
A-72
cdr remaster
The cdr remaster command changes the SELECT clause or the server from which to base the master replicate definition of an existing master replicate. You can also use this command to convert a classic (non-master) replicate to a master replicate.
Syntax
cdr remaster (1) Connect Option --master server replicate
modifier

Purpose Specifies the rows and columns to replicate Name of the replicate to be mastered Restrictions See Considerations for the SELECT Statement on page A-113. The replicate must exist. Syntax Participant Modifier on page A-112 Long Identifiers on page A-109 Long Identifiers on page A-109
Element modifier
replicate
server
Name of the database The name must be the server from which to base database server group the master replicate name. definition
The following table describes the option to cdr remaster.

Long Form --master= Short Form -M Meaning Specifies that the replicate being created is a master replicate.
Important: To use the cdr remaster command, the master replicate definition must have been created with name verification turned on (--name option of the cdr define replicate command set to y, which is the default). As part of its processing, the cdr remaster command creates a shadow replicate. The shadow replicate is named as follows:
Shadow_4_basereplicatename_GMTtime_GIDlocalCDRID_PIDpid
A-73
basereplicatename is the name of the replicate being remastered (up to 64 characters of this name are used) localCDRID is the CDR group ID of the server you specified with the --connect option. You can obtain this ID using the onstat -g cat servers command or by looking in the SQLHOSTS file. Alternatively, you can query the syscdrserver view in the sysmaster database. pid is the process ID of the client An example of a shadow replicate name is:
Shadow_4_Repl1_GMT1090373046_GID10_PID28836
Usage
Use the cdr remaster command to perform one of the following tasks: v Convert a classic replicate to a master replicate. Master replicates ensure schema consistency among the participants in the replicates. v Update the definition of a master replicate whose participant was changed in an alter operation. You can change the SELECT clause or the server from which to base the master replicate definition.
Examples
The following example shows the original definition of the master replicate before the alter operation:
cdr define repl --master delhi -C timestamp\ newrepl "test@delhi.tab" "select col1, col2 from tab"\
This example shows the cdr remaster command adding a new column, col3, in the newrepl participant:
cdr remaster --master delhi newrepl\ "select col1, col2, col3 from tab"
A-74
cdr remove
The cdr remove command removes Enterprise Replication from an HDR database server.
Syntax
cdr remove
Usage
Use this command to remove Enterprise Replication from an HDR primary server after it has been started using the oninit -D command. For more information, see HDR Failure on page 5-8. The cdr remove command removes Enterprise Replication from a database server by deleting its global catalog information. Unlike the cdr delete command, this command can only be issued when Enterprise Replication is not active. The database server this command affects is the one specified by the value of the $INFORMIXSERVER environment variable. Warning: Do not use this command on a database server that does not participate in HDR.
A-75
cdr repair
The cdr repair command synchronizes data based on ATS or RIS files.
Syntax
cdr repair ats ats_file ris ris_file
Element ats_file
Purpose Name of the file for Aborted Transaction Spooling Name of the file for Row Information Spooling
Restrictions Must be a full pathname and filename. The path for the directory can be no longer than 256 bytes. Must be a full pathname and filename. The path for the directory can be no longer than 256 characters.
Syntax Follows naming conventions on your operating system Follows naming conventions on your operating system
ris_file
Usage
The cdr repair command reconciles rows that failed to be applied based on the information in the specified ATS or RIS file. If a row does not exist on the source database server, then it is deleted from the target database server. Run the cdr repair command on the server where the ATS or RIS file is located. Enterprise Replication must be able to connect to the source server of the ATS or RIS file.
Examples
The following example repairs inconsistencies found in the ATS file generated for an inconsistency found between the g_beijing and g_amsterdam servers:
cdr repair ats\ ats.g_beijing.g_amsterdam.D_2.000529_23:27:16.6
See Also
v cdr define repair on page A-11
A-76
cdr resume replicate

The cdr resume replicate command resumes delivery of replication data.
Syntax
cdr resume replicate (1) Connect Option
repl_name

Purpose Name of the replicate to change to active state. Restrictions The replicate must be suspended. Syntax Long Identifiers on page A-109
Element repl_name
Usage
The cdr resume replicate command causes all participants in the replicate repl_name to enter the active state. For more information on replicate states, refer to The STATE Column on page A-54. Important: If a replicate belongs to an exclusive replicate set (Exclusive Replicate Sets on page 6-13), you cannot run cdr resume replicate to resume that individual replicate. You must use cdr resume replicateset to resume all replicates in the exclusive replicate set. If a replicate belongs to a non-exclusive replicate set, you can resume the individual replicates in the set.
Examples
The following example connects to the default database server ($INFORMIXSERVER) and resumes the replicate smile:
cdr res repl smile
See Also
v v v v v cdr cdr cdr cdr cdr change replicate on page A-5 define replicate on page A-15 delete replicate on page A-34 list replicate on page A-48 modify replicate on page A-60
A-77
v cdr start replicate on page A-86 v cdr stop replicate on page A-94 v cdr suspend replicate on page A-98
A-78
cdr resume replicateset

The cdr resume replicateset (or cdr resume replset) command resumes delivery of replication data for all the replicates in a replicate set.
Syntax
cdr resume replicateset (1) Connect Option
repl_set

Purpose Name of replicate set to resume Restrictions None Syntax Long Identifiers on page A-109
Element repl_set
Usage
The cdr resume replicateset command causes all replicates contained in the replicate set repl_set to enter the active state for all participants. Important: If not all the replicates in a non-exclusive replicate set are suspended, the cdr resume replicateset command displays a warning and only resumes the replicates that are currently suspended. For more information on replicate states, refer to The STATE Column on page A-54.
Examples
The following example connects to the default database server ($INFORMIXSERVER) and resumes the replicate set accounts_set:
cdr res replset accounts_set
See Also
v v v v v v cdr cdr cdr cdr cdr cdr change replicateset on page A-7 define replicate on page A-15 delete replicateset on page A-36 list replicateset on page A-52 modify replicateset on page A-64 start replicateset on page A-89
A-79
A-80
cdr resume server

The cdr resume server command resumes delivery of replication data to a suspended database server.
Syntax
cdr resume server (1) Connect Option to_server_group
from_server_group
Notes: 1
Element to_server_group
See page A-109.

Purpose Name of database server group to which to resume delivery of replication data Name of the database server group from which to resume sending data to to_server_group Restrictions The database server group must be currently active in Enterprise Replication. The database server group must be currently active in Enterprise Replication.
from_server_group
Usage
The cdr resume server command resumes delivery of replication data to the to_server_group database server from the database servers included in the from_server_group list. If the from_server_group list is omitted, the command resumes replication of data from all database servers participating in the Enterprise Replication system to the to_server_group. Replication data must have previously been suspended to the server with the cdr suspend server command (cdr suspend server on page A-102).
Examples
The following example connects to the default server ($INFORMIXSERVER) and resumes replication of data to the server g_iowa from the servers g_ohio and g_utah:
cdr sus serv g_iowa g_ohio g_utah
See Also
v cdr connect server on page A-10 v cdr define server on page A-25
A-81
v v v v v
cdr cdr cdr cdr cdr
delete server on page A-38 disconnect server on page A-42 list server on page A-54 modify server on page A-66 suspend server on page A-102
A-82
cdr start
The cdr start command starts Enterprise Replication processing.
Syntax
cdr start (1) Connect Option
Usage
Use cdr start to restart Enterprise Replication after you stop it with cdr stop. When you issue cdr start, Enterprise Replication brings up all connections to other connected replication servers. Replication servers, replicates, and replicate sets that were suspended before the cdr stop command was issued remain suspended; no data is sent for the suspended servers, replicates, or sets. Enterprise Replication resumes evaluation of the logical log (if required for the instance of Enterprise Replication) at the replay position. The replay position is the position where Enterprise Replication stops evaluating the logical log when cdr stop is executed. If the evaluation process is running and the logical log ID for the replay position no longer exists when Enterprise Replication is started, then the restart partially fails (the database server log contains an error message stating that the replay position is invalid). If the restart partially fails, no database updates performed on the local database server are replicated. Warning: Issue cdr start and cdr stop with extreme caution.
Examples
The following example restarts Enterprise Replication processing on database server utah:
cdr sta -c utah
See Also
v cdr stop on page A-92
A-83
cdr start repair

The cdr start repair command starts a repair job to repair inconsistent data.
Syntax
cdr start repair (1) Connect Option job

Element job
Usage
Use the cdr start repair command to start a repair job that was previously defined with the cdr define repair command. You must run this command while connected to the source server for the job, as specified in the cdr define repair command by the --syncdatasource server option. If you specify a server in the Connect Option, it must be must be a non-leaf server and must be the source server for the repair job. The source server and the target server must be able to establish a direct connection. Repair jobs have the following limitations: v The replicate must be in online mode during a repair. v You cannot suspend, stop, or place the replicate in alter mode during a repair. v You cannot start a repair job for a replicate that uses timestamp conflict resolution. v You cannot run a specific repair job more than one time because the job contains procedures based on referential constraints as they exist at the time the job is defined with the cdr define repair command. If Enterprise Replication stops during a repair job, the job is automatically restarted with Enterprise Replication restarts. To stop a repair job that is in progress, use the cdr stop repair command.
A-84
Examples
The following example runs a repair job named parts_repair:
cdr start repair parts_repair
See Also
v v v v cdr cdr cdr cdr define repair on page A-11 delete repair on page A-33 stop repair on page A-93 list repair on page A-46
A-85
cdr start replicate

The cdr start replicate command starts the capture and transmittal of replication transactions.
Syntax
cdr start replicate (1) Connect Option repl_name
server_group
--syncdatasource=data_server --extratargetrows=
delete keep merge

Element data_server
The database server from The database server must which the data is copied be defined in Enterprise to all other database Replication. servers listed Name of the replicate to start The replicate must exist. Long Identifiers on page A-109
repl_name
server_group
Name of database server The database server groups on which to start groups must be defined the replicate for Enterprise Replication.
The following table describes the cdr start replicate options.

Long Form --syncdatasource= Short Form -S Meaning Specifies the name of the database server to use as the reference copy of the data.
A-86
Short Form -e
Usage
The cdr start replicate command causes the replicate repl_name to enter the active state (capture-send) on the database servers in server_group. If no server is specified, the repl_name starts on all servers that are included in the replicate. A replicate can have both active and inactive participants. When at least one participant is active, the replicate is active. Important: You cannot start replicates that have no participants. Important: If a replicate belongs to an exclusive replicate set, you cannot run cdr start replicate to start that individual replicate. You must use cdr start replicateset to start all replicates in the exclusive replicate set. Because Enterprise Replication does not process log records that were produced before the cdr start replicate command took place, transactions that occur during this period might be partially replicated. To avoid problems, either issue the cdr start replicate command on an idle system (no transactions are occurring) or use the BEGIN WORK WITHOUT REPLICATION statement until after you successfully start the replicate.
Examples
The following command starts the replicate accounts on the server groups g_svr1 and g_svr2:
cdr sta rep accounts g_svr1 g_svr2
See Also
v v v v v cdr cdr cdr cdr cdr change replicate on page A-5 define replicate on page A-15 delete replicate on page A-34 list replicate on page A-48 modify replicate on page A-60
A-87
v cdr resume replicate on page A-77 v cdr stop replicate on page A-94 v cdr suspend replicate on page A-98
A-88
cdr start replicateset

The cdr start replicateset (or cdr start replset) command starts the capture and transmittal of replication transactions for all the replicates in a replicate set.
Syntax
cdr start replicateset (1) Connect Option repl_set
server_group
--syncdatasource=data_server --extratargetrows=
delete keep merge

Purpose The database server from which the data is copied to all other database servers listed Name of replicate set to start Names of database server groups on which to start the replicate set Restrictions The database server must be defined in Enterprise Replication. The replicate set must exist. The database server groups must be defined for Enterprise Replication. Long Identifiers on page A-109 Syntax
Element data_server
repl_set
server_group
The following table describes the cdr start replicateset options.

Long Form --syncdatasource= Short Form -S Meaning Specifies the name of the database server to use as the reference copy of the data.
A-89
Short Form -e
Usage
The replicates defined in the replicate set repl_set enter the active state (capture-send) on the database servers in server_group. If the server_group list is omitted, the replicate set repl_set enters the active state for all database servers participating in the replicate set. Because Enterprise Replication does not process log records that were produced before the cdr start replicateset command took place, transactions that occur during this period might be partially replicated. To avoid problems, either issue the cdr start replicateset command on an idle system (no transactions are occurring) or use the BEGIN WORK WITHOUT REPLICATION statement until after you successfully start the replicates in the replicate set. Important: If not all the replicates in a non-exclusive replicate set are inactive, the cdr start replicateset command displays a warning and only starts the replicates that are currently inactive.
Examples
The following example connects to the default database server specified by $INFORMIXSERVER and starts the replicate set accounts_set on the server groups g_hill and g_lake:
cdr sta replset accounts_set g_hill g_lake
See Also
v v v v v v cdr cdr cdr cdr cdr cdr change replicateset on page A-7 define replicate on page A-15 delete replicateset on page A-36 list replicateset on page A-52 modify replicateset on page A-64 resume replicateset on page A-79
A-90
A-91
cdr stop
The cdr stop command stops Enterprise Replication processing.
Syntax
(1) cdr stop Connect Option
Usage
In most situations, Enterprise Replication starts when cdr define server is first executed. The replication threads remain running until the database server is shut down or until the local database server is deleted with the cdr delete server command. If you shut down the database server while Enterprise Replication is running, replication begins again when you restart the database server. Under rare conditions, you might want to temporarily stop the Enterprise Replication processing without stopping the database server. The cdr stop command shuts down all Enterprise Replication threads in an orderly manner; however no data to be replicated is captured. When the shutdown of Enterprise Replication is complete, the message CDR shutdown complete appears in the database server log file. After issuing the cdr stop command, replication threads remain stopped (even if the database server is stopped and restarted) until you issue a cdr start command. You cannot delete a server from the enterprise if it is stopped. To delete a server with cdr delete server, you must issue a cdr start command first. Warning: If you issue cdr stop and database activity continues, the database server from which the command is issued and the other database servers participating in replicates will become inconsistent. To ensure consistency, verify that no database update activity occurs while Enterprise Replication is stopped.
Examples
The following example stops Enterprise Replication processing on database server paris. Processing does not resume until a cdr start command restarts it:
cdr stop -c paris
See Also
v cdr start on page A-83
A-92
cdr stop repair

The cdr stop repair command stops a repair job that is in progress.
Syntax
cdr stop repair (1) Connect Option job

Element job
Usage
Use the cdr stop repair command to stop a repair job that is in progress. To restart the repair job, use the cdr start repair command. You must run this command while connected to the source server for the job, as specified in the cdr define repair command by the --syncdatasource server option. If you specify the Connect Option, it must be the source server.
Examples
The following example stops a repair job named parts_repair:
cdr stop repair parts_repair
See Also
v cdr define repair on page A-11 v cdr delete repair on page A-33 v cdr start repair on page A-84 v cdr list repair on page A-46
A-93
cdr stop replicate

The cdr stop replicate command stops the capture and transmittal of transactions for replication.
Syntax
cdr start replicate (1) Connect Option repl_name
at_server_group
Notes: 1
Element repl_name
See page A-109.

Purpose Name of the new replicate Restrictions The replicate must be active and not in an exclusive replicate set. Syntax Long Identifiers on page A-109
at_server_group
List of database server The database server groups groups on which to stop the must be defined for Enterprise replicate Replication.
Usage
The cdr stop replicate command changes the state of the replicate repl_name to inactive (no capture, no send) on the replication servers in the specified at_server_group list. In addition, this command deletes any data in the send queue for the stopped replicate. Important: You cannot stop replicates that have no participants. Warning: If there were any data in the send queue when you issued the cdr stop replicate command, or if any database activity occurs while the replicate is stopped, the replication servers will get out of sync. For information on resynchronizing replication servers, see Resynchronizing Data Among Replication Servers on page 7-14. If you omit the at_server_group list, the replicate enters the inactive state on all database servers participating in the replicate and all send queues for the replicate are deleted.
A-94
Important: If a replicate belongs to an exclusive replicate set, you cannot run cdr stop replicate to stop that individual replicate. You must use cdr stop replicateset to stop all replicates in the exclusive replicate set.
Examples
The following command connects to the database server lake and stops the replicate aRepl on server groups g_server1 and g_server2:
cdr sto rep -c lake aRepl g_server1 g_server2
See Also
v cdr change replicate on page A-5 v cdr define replicate on page A-15 v cdr delete replicate on page A-34 v cdr list replicate on page A-48 v cdr modify replicate on page A-60 v cdr resume replicate on page A-77 v cdr start replicate on page A-86 v cdr suspend replicate on page A-98
A-95
cdr stop replicateset

The cdr stop replicateset (or cdr stop replset) command stops capture and transmittal transactions for all the replicates in a replicate set.
Syntax
cdr stop replicateset (1) Connect Option repl_set
server_group

Purpose Name of replicate set to stop Name of database server group on which to stop the replicate group Restrictions The replicate set must exist The database server groups must be defined for Enterprise Replication. Syntax Long Identifiers on page A-109
Element repl_set
server_group
Usage
The cdr stop replicateset command causes all replicates in the replicate set repl_set to enter the inactive state (no capture, no send) on the database servers in the server_group list. If the server_group list is omitted, the replicate set repl_set enters the inactive state for all database servers participating in the replicate set. Important: If not all the replicates in the non-exclusive replicate set are active, the cdr stop replicateset command displays a warning and only stops the replicates that are currently active.
Examples
The following example connects to the database server paris and stops the replicate set accounts_set on server groups g_utah and g_iowa:
cdr sto replset --connect=paris accounts_set g_utah g_iowa
A-96
See Also
v v v v v v v cdr cdr cdr cdr cdr cdr cdr change replicateset on page A-7 define replicate on page A-15 delete replicateset on page A-36 list replicateset on page A-52 modify replicateset on page A-64 resume replicateset on page A-79 start replicateset on page A-89
v cdr suspend replicateset on page A-100
A-97
cdr suspend replicate

The cdr suspend replicate command suspends delivery of replication data.
Syntax
cdr suspend replicate (1) Connect Option
repl_name

Purpose Name of the replicate Restrictions The replicate must be active. Syntax Long Identifiers on page A-109
Element repl_name
Usage
The cdr suspend replicate command causes the replicate repl_name to enter the suspend state (capture, no send) for all participants. Warning: When a replicate is suspended, Enterprise Replication holds the replication data in the send queue until the replicate is resumed. If a large amount of data is generated for the replicate while it is suspended, the send queue space can fill, causing data to be lost. Warning: Enterprise Replication does not synchronize transactions if a replicate is suspended. For example, a transaction that updates tables X and Y will be split if replication for table X is suspended. Important: If a replicate belongs to an exclusive replicate set, you cannot run cdr suspend replicate to suspend that individual replicate. You must use cdr suspend replicateset to suspend all replicates in the exclusive replicate set.
Examples
The following example connects to the database server stan and suspends the replicate house:
cdr sus repl --connect=stan house
See Also
v cdr change replicate on page A-5 v cdr define replicate on page A-15
A-98
v v v v v v
cdr cdr cdr cdr cdr cdr
delete replicate on page A-34 list replicate on page A-48 modify replicate on page A-60 resume replicate on page A-77 start replicate on page A-86 stop replicate on page A-94
A-99
cdr suspend replicateset

The cdr suspend replicateset (or cdr suspend replset) command suspends delivery of replication data for all the replicates in a replicate set.
Syntax
cdr suspend replicateset (1) Connect Option
repl_set

Purpose Name of replicate set to suspend Restrictions The replicate set must exist Syntax Long Identifiers on page A-109
Element repl_set
Usage
The cdr suspend replicateset command causes all the replicates in the replicate set repl_set to enter the suspend state. Information is captured, but no data is sent for any replicate in the set. The data is queued to be sent when the set is resumed. Warning: When a replicate set is suspended, Enterprise Replication holds the replication data in the send queue until the set is resumed. If a large amount of data is generated for the replicates in the set while it is suspended, the send queue space can fill, causing data to be lost. Warning: Enterprise Replication does not synchronize transactions if a replicate in a replicate set is suspended. For example, a transaction that updates tables X and Y will be split if replication for table X is suspended. Important: If not all the replicates in the non-exclusive replicate set are active, the cdr suspend replicateset command displays a warning and only suspends the replicates that are currently active.
Examples
The following example connects to the default database server specified by $INFORMIXSERVER and suspends the replicate set accounts_set:
cdr sus replset account_set
A-100
See Also
v v v v v v v cdr cdr cdr cdr cdr cdr cdr change replicateset on page A-7 define replicate on page A-15 delete replicateset on page A-36 list replicateset on page A-52 modify replicateset on page A-64 resume replicateset on page A-79 start replicateset on page A-89
v cdr stop replicateset on page A-96
A-101
cdr suspend server

The cdr suspend server command suspends the delivery of replication data to a database server from either a specified list of database servers or from all database servers in the enterprise.
Syntax
cdr suspend server (1) Connect Option to_server_group
from_server_group

Purpose Name of database server group to which to suspend delivery of replication data Name of the database server group from which to stop sending data to to_server_group Restrictions The database server group must be currently active in Enterprise Replication. The database server group must be currently active in Enterprise Replication. Syntax
Element to_server_group
from_server_group
Usage
The cdr suspend server command suspends delivery of replication data to the to_server_group database server from the database servers included in the from_server_group list. If the from_server_group list is omitted, the command suspends replication of data from all database servers participating in the Enterprise Replication system to the to_server_group. The connection to the suspended server is unaffected, and control and acknowledge messages continue to be sent to that server. Enterprise Replication continues to replicate data between all database servers unaffected by the cdr suspend server command.
A-102
Examples
The following example connects to the default server ($INFORMIXSERVER) and suspends replication of data to the server g_iowa from the servers g_ohio and g_utah:
cdr sus serv g_iowa g_ohio g_utah
See Also
v v v v v v v cdr cdr cdr cdr cdr cdr cdr connect server on page A-10 define server on page A-25 delete server on page A-38 disconnect server on page A-42 list server on page A-54 modify server on page A-66 resume server on page A-81
A-103
cdr swap shadow

The cdr swap shadow command switches a replicate with its shadow replicate during manual remastering.
Syntax
cdr swap shadow (1) Connect Option --primaryid=repl_ID --shadowname=shadow_name --shadowid=shadow_ID --primaryname=repl_name
Notes: 1
Element repl_name
See page A-109.

Purpose Name of the primary replicate Restrictions Syntax
The primary replicate Long Identifiers participant attributes state, type on page A-109 (P or R), and table owner (O or I) must match the shadow replicate participant attributes. See Participant on page A-110 for information about the P, R, O and I options.
repl_ID
Internal Enterprise Replication identification code for the primary replicate Name of the shadow replicate The shadow replicate state must match the primary replicate state. Shadow replicate participants must match the primary replicate participants. Long Identifiers on page A-109
shadow_name
shadow_ID
Internal Enterprise Replication identification code for the shadow replicate
The following table describes the cdr swap shadow options.

Long Form --primaryname --primaryid Short Form -p -P Meaning Specifies the name of the primary replicate Specifies the ID of the primary replicate
A-104
Long Form --shadowname --shadowid
Short Form -s -S
Meaning Specifies the name of the shadow replicate Specifies the ID of the shadow replicate
Usage
Use the cdr swap shadow command to switch a replicate with its shadow replicate as the last step in manually remastering a replicate that was created with the --name=n option. You create a shadow replicate using the cdr define replicate command with the --mirrors option. For more information on manual remastering, see Remastering a Replicate on page 7-18. Use the onstat -g cat repls command to obtain the repl_ID, and shadow_ID. Alternatively, you can query the syscdrrepl view in the sysmaster database.
See Also
v cdr define replicate on page A-15 v cdr list replicate on page A-48
A-105
Interpreting the Command-Line Utility Syntax

This section defines the terminology and conventions used in the descriptions of the command-line utility (CLU). Each command follows the same approximate format, with the following components: v Command and its variation The command specifies the action that should be taken. v Options The options modify the action of the command. Each option starts with a minus (-) or a double-minus (--). v Target The target specifies the Enterprise Replication object that should be acted upon. v Other objects Other objects specify objects that are affected by the change to the target. If you enter an incorrect cdr command at the command-line prompt, the database server returns a usage message that summarizes the cdr commands. For a more detailed usage message, enter cdr variation -h. For example, cdr list server -h. Important: You must be the Enterprise Replication server administrator to execute any of the CLU commands except the cdr list options. For more information, see Enterprise Replication Server Administrator on page 2-3. This section covers the following topics: v Command Abbreviations v Option Abbreviations v Option Order v Long Command-Line Examples v Long Identifiers v Connect Option v Participant v Return Codes v Frequency Options
A-106
Command Abbreviations
For most commands, each of the words that make up a cdr command variation can be abbreviated to three or more characters. For example, the following commands are all equivalent:
cdr define replicate cdr define repl cdr def rep
The exceptions to this rule are the replicateset commands, which can be abbreviated to replset. For example, the following commands are equivalent:
cdr define replicateset cdr def replset
Option Abbreviations
Each option for a command has a long form and a short form. You can use either form, and you can mix long and short forms within a single command. UNIX Only For example, using long forms on UNIX you can write:
cdr define server --connect=ohio --idle=500 \ --ats=/cdr/ats --initial utah
End of UNIX Only Windows Only On Windows, this command line might look like:
cdr define server --connect=ohio --idle=500 \ --ats=D:\cdr\ats --initial utah
End of Windows Only Using short forms, you can write the previous examples as follows: UNIX Only
cdr def ser -c ohio -i 500 -A /cdr/ats -I utah
End of UNIX Only Windows Only

cdr def ser -c ohio -i 500 -A D:\cdr\ats -I utah
A-107
End of Windows Only The long form is always preceded by a double minus (--). Most (but not all) long forms require an equal sign (=) between the option and its argument. The short form is preceded by a single minus (-) and is the first letter of the long form. The short form never requires an equal sign. However, sometimes the short form is capitalized and sometimes not. To find the correct syntax for the short form, check the table that accompanies each command variation. Tip: Use the long forms of options to increase readability. With the exception of the keyword transaction, all keywords (or letter combinations) that modify the command options must be written as shown in the syntax diagrams. For example, in the Conflict Options on page A-17, the option (conflict) can be abbreviated, but the keyword ignore cannot be abbreviated. Both of the following forms are correct:
--conflict=ignore -C ignore
Option Order
You can specify the options of the CLU commands in any order. Some of the syntax diagrams in this chapter show the options in a specific order because it makes the diagram easier to read. Do not repeat any options. The following fragment is incorrect because -c appears twice. In most cases, the CLU will catch this inconsistency and flag it as an error. However, if no error is given, the database server uses the last instance of the option. In the following example, the database server uses the value -c utah:
-c ohio -i 500 -c utah
Tip: For ease of maintenance, always use the same order for your options.
Long Command-Line Examples

The examples in this guide use the convention of a backslash (\) to indicate that a long command line continues on the next line. The following two commands are equivalent. The first command is too long to fit on a single line, so it is continued on the next line. The second example, which uses short forms for the options, fits on one line. UNIX Only
cdr define server --connect=katmandu --idle=500 \ --ats=/cdrfiles/ats cdr def ser -c katmandu -i 500 -A /cdrfiles/ats
A-108
End of UNIX Only Windows Only On Windows, these command lines might look like:
cdr define server --connect=honolulu --idle=500 \ --ats=D:\cdrfiles\ats cdr def ser -c honolulu -i 500 -A D:\cdr\ats
End of Windows Only For information on how to manage long lines at your command prompt, check your operating system documentation.
Long Identifiers
Identifiers are the names of objects, such as database servers, databases, columns, replicates, replicate sets, and so on, that Dynamic Server and Enterprise Replication use. An identifier is a character string that must start with a letter or an underscore. The remaining characters can be letters, numbers, or underscores. On IBM Informix Dynamic Server, all identifiers, including replicates and replicate sets, can be 128 bytes long. However, if you have any database servers in your replication environment that are an earlier version, you must follow the length restrictions for that version. For more information about identifiers, see the IBM Informix: Guide to SQL Syntax. The location of files, such as the location of the ATS files, can be 256 bytes. User login IDs can be a maximum of 32 bytes. The owner of a table is derived from a user ID and is thus limited to 32 bytes.
Connect Option
The --connect option causes the command to use the global catalog that is on the specified server. If you do not specify this option, the connection defaults to the database server specified by the INFORMIXSERVER environment variable.
-cserver --connect=server -cserver_group --connect=server_group
A-109
Element server
Purpose Name of the database server to connect to Name of the database server group that includes the database server to connect to
Restrictions The name must be the name of a database server. The name must be the name of an existing database server group.
Syntax Long Identifiers on page A-109 Long Identifiers on page A-109
server_group
You must use the --connect option when you add a database server to your replication environment with the cdr define server command. You might use the --connect option if the database server to which you would normally attach is unavailable. For more information about the global catalog, refer to Global Catalog on page 2-5.
Participant
A participant defines the data (database, table, and columns) on a database server to be replicated. A replicate contains two or more participants. The participant definition includes the following information: v Database server group (Setting up Database Server Groups on page 4-4) v Database in which the table resides v Table name v Table owner (Table Owner on page A-111) v Participant type (Participant Type on page A-112) v SELECT statement (Participant Modifier on page A-112) Important: You cannot start and stop replicates that have no participants. You must include the server group, database, table owner, and table name when defining a participant, and enclose the entire participant definition in quote marks.
P R O I database@server_group:owner.table
Element database
Purpose
Restrictions
Syntax
Name of the database The database server must Long that includes the table to be registered with Identifiers on be replicated Enterprise Replication. page A-109
A-110
Element owner
Purpose User ID of the owner of the table to be replicated Name of the database server group that includes the server to connect to
Restrictions
server_group
The database server group name must be the name of an existing Enterprise Replication server group in SQLHOSTS. The table must be an actual table. It cannot be a synonym or a view.
table
Name of the table to be replicated
Important: Do not create more than one replicate definition for each row and column set of data to replicate. If the participant overlaps, Enterprise Replication attempts to insert duplicate values during replication. You can define participants with the following commands: v cdr define replicate v cdr modify replicate v cdr change replicate v cdr define template Table Owner The O (owner) option causes permission checks for owner to be applied to the operation (such as insert or update) that is to be replicated and to all actions fired by any triggers. When the O option is omitted, all operations are performed with the privileges of user informix. UNIX Only If a trigger requires any system-level commands (as specified using the system( ) command in an SPL statement), the system-level commands are executed as the table owner, if the participant includes the O option. End of UNIX Only Windows Only If a trigger requires any system-level commands, the system-level commands are executed as a less privileged user because, on Windows, you cannot impersonate another user without having the password, whether or not the
A-111
participant includes the O option. End of Windows Only Use the I option to disable the table-owner option. Participant Type In a primary-target replicate, specify the participant type using the P (primary) and R (receive-only or target) options in the participant definition. v A primary participant both sends and receives replicate data. v A target participant only receives data from primary participants. The replicate can contain multiple primary participants. In an update-anywhere replicate, do not specify either P or R for the participant. Enterprise Replication defines the participant as primary in an update-anywhere replication system. For example, in the following definition, replicate Rone is update-anywhere:
cdr define repl -c serv1 -C timestamp -S tran Rone \ "db@serv1:owner.table" "select * from table" \ "db@serv2:owner.table" "select * from table"
In replicate Rtwo, serv2 is the primary and serv1 is receive-only.

cdr define repl -c serv1 -C ignore -S tran Rtwo \ "R db@serv1:owner.table" "select * from table" \ "P db@serv2:owner.table" "select * from table"
For more information, see Primary-Target Replication System on page 3-1. Participant Modifier The participant modifier is a restricted SELECT statement. The participant modifier specifies the rows and columns that will be replicated. The participant modifier must be enclosed in quotation marks.
, SELECT * column FROM table WHERE_Clause
Element column
Purpose Name of a column in the table specified by the participant
Restrictions The column must exist.
A-112
Element table
Purpose The table specified by the participant
Restrictions This must be the table name only. You cannot specify an owner or a database server. You cannot specify a synonym or a view.
WHERE_Clause
Clause that specifies a subset of table rows to be replicated
WHERE clause syntax; refer to IBM Informix: Guide to SQL Syntax
Considerations for the SELECT Statement: The following guidelines apply to a SELECT statement that is used as a participant modifier: v The statement cannot include a join or a subquery. v The FROM clause of the SELECT statement can reference only a single table. v The table in the FROM clause must be the table specified by the participant. v The columns selected must include the primary key. v The columns selected can include any columns in the table, including those that contain smart large objects and TEXT and BYTE data. v The statement cannot perform operations on the selected columns. v The statement can include an optional WHERE clause. The WHERE clause of the SELECT statement of the participant modifier can reference an opaque UDT, as long as the UDT is always stored in row. For more information, see Considerations for Replicating Opaque Data Types on page 2-19. For detailed information about the SELECT statement and WHERE clause, refer to the IBM Informix: Guide to SQL Syntax. It is recommended that, except for replicating between SERIAL and INT and between BYTE/TEXT and BLOB/CLOB, you only replicate between like data types. For example, do not replicate between the following: v CHAR(40) to CHAR(20) v INT to FLOAT
Return Codes
If the command encounters an error, the database server returns an error message and a return-code value. The message briefly describes the error. For information on interpreting the return code, use the cdr finderr command.
A-113
Frequency Options
The following commands allow you to specify the interval between replications or the time of day when an action should occur. If you do not specify a time, the action occurs immediately: v v v v v cdr cdr cdr cdr cdr define replicate define replicateset define template modify replicate modify replicateset
Frequency Options:
--immed --every=interval --at=time
Element interval time
Purpose Time interval for replication Specific time for replication
Restrictions The smallest interval in minutes.
Syntax Intervals on page A-115
Time is given with respect Time of Day to a 24-hour clock. on page A-114
The following table describes the frequency options.

Long Form --immed --every --at Short Form -i -e -a Meaning Action occurs immediately. Action occurs immediately and repeats at the frequency specified by interval. Action occurs at the specified day and time.
Time of Day Enterprise Replication always gives the time of day in 24-hour time. For example, 19:30 is 7:30 P.M. Enterprise Replication always gives times with respect to the local time, unless the $TZ environment variable is set. However, Enterprise Replication stores times in the global catalog in Greenwich Mean Time (GMT). The -a time option lets you specify the day on which an action should occur. The string time can have the following formats: v Day of week
A-114
To specify a specific day of the week, give either the long or short form of the day, followed by a period and then the time. For example, --at=Sunday.18:40 or -a Sun.18:40 specifies that the action should occur every Sunday at 6:40 P.M. The day of the week is given in the locale of the client. For example, with a French locale, you might have --at=Lundi.3:30 or -a Lun.3:30. The time and day are in the time zone of the server. v Day of month To specify a specific day in the month, give the date, followed by a period, and then the time. For example, 1.3:00 specifies that the action should occur at 3:00 A.M. on the first day of every month. The special character L represents the last day of the month. For example, L.17:00 is 5:00 P.M. on the last day of the month. v Daily To specify that replication should occur each day, give only the time. For example, 4:40 specifies that the action should occur every day at 4:40 AM. Intervals The -e interval option lets you specify the interval between actions. The interval of time between replications can be either of the following formats: v The number of minutes To specify the number of minutes, specify an integer value. For example, -e 60 indicates 60 minutes between replications. If you specify the interval of time between replications in minutes, the longest interval allowed is 1966020. v The number of hours and minutes To specify hours and minutes, give the number of hours, followed by a colon, and then the number of minutes. For example, -e 5:45 indicates 5 hours and 45 minutes between replications. Important: If you specify the length of time in hours and minutes, the longest interval allowed is 32767:59.
A-115
A-116
Appendix B. Configuration Parameter and Environment Variable Reference

The database server configuration file ($ONCONFIG) includes the following configuration parameters that affect the behavior of Enterprise Replication: v CDR_DBSPACE v v v v v v v v v v v v v CDR_DSLOCKWAIT CDR_ENV CDR_EVALTHREADS CDR_MAX_DYNAMIC_LOGS CDR_NIFCOMPRESS CDR_QDATA_SBSPACE CDR_QHDR_DBSPACE CDR_QUEUEMEM CDR_SERIAL CDR_SUPPRESS_ATSRISWARN ENCRYPT_CDR ENCRYPT_CIPHER ENCRYPT_MAC
v ENCRYPT_MACFILE v ENCRYPT_SWITCH Important: If you use both DBSERVERNAME and DBSERVERALIASES, DBSERVERNAME should refer to the network connection and not to a shared-memory connection. For information about database server aliases, refer to the IBM Informix: Dynamic Server Administrator's Guide. Use the CDR_ENV configuration parameter to set the following environment variables that affect the behavior of Enterprise Replication: v CDR_LOGDELTA v CDR_PERFLOG v CDR_ROUTER v CDR_RMSCALEFACT
B-1
CDR_DBSPACE Configuration Parameter

units takes effect any valid dbspace when Enterprise Replication is initialized
The CDR_DBSPACE configuration parameter specifies the dbspace where the syscdr database is created. If it is not set, then syscdr is created in the root dbspace.
CDR_DSLOCKWAIT Configuration Parameter

default value units takes effect 5 seconds when shared memory is initialized
The CDR_DSLOCKWAIT configuration parameter specifies the number of seconds the Datasync (data synchronization) component waits for database locks to be released. The CDR_DSLOCKWAIT parameter behaves similarly to the SET LOCK MODE statement. Although the SET LOCK MODE is set by the end user application, CDR_DSLOCKWAIT is used by Enterprise Replication while applying data at the target database. This parameter is useful in conditions where different sources require locks on the replicated table. These sources could be a replicated transaction from another server or a local application operating on that table. Transactions that receive updates and deletes from another server in the replicate can abort because of locking problems. If you experience transaction aborts in the Datasync due to lock timeouts like this, you might want to increase the value of this parameter.
CDR_ENV Configuration Parameter

takes effect when Enterprise Replication is initialized
The CDR_ENV configuration parameter sets the Enterprise Replication environment variables CDR_LOGDELTA, CDR_PERFLOG, CDR_ROUTER, or CDR_RMSCALEFACT. The ONCONFIG file can contain multiple entries for CDR_ENV. You can specify only one environment variable per CDR_ENV entry. For example, to set the CDR_LOGDELTA environment variable to 30 and the CDR_ROUTER environment variable to 1, include the following lines in the ONCONFIG file:
B-2
CDR_ENV CDR_LOGDELTA=30 CDR_ENV CDR_ROUTER=1
Important: Use the CDR_LOGDELTA, CDR_PERFLOG, CDR_ROUTER, and CDR_RMSCALEFACT environment variables only if instructed to do so by Technical Support.
CDR_EVALTHREADS Configuration Parameter

default value units 1,2 evaluator thread instances
range of values 1 to 129 * the number of CPU VPs for each value takes effect when shared memory is initialized
Enterprise Replication evaluates the images of a row in parallel to assure high performance. Figure B-1 illustrates how Enterprise Replication uses parallel processing to evaluate transactions for replication.
Evaluating transactions for replication Transaction list

INV# 1234 1235 Product chandelier candlestick
Enterprise Replication message queue
Fan out
Thread
Logical log
Thread
INV# 3421 3427
Product clock china
Thread
INV# 4325 4367
Product crystal silverware
Figure B-1. Processing in Parallel for High Performance
The CDR_EVALTHREADS configuration parameter specifies the number of grouper evaluator threads to create when Enterprise Replication starts and enables parallelism. The format is:
(per-cpu-vp,additional)
Thread
INV# 6798 6520
Product pottery ceramic_tile
B-3
The following table provides four examples of CDR_EVALTHREADS.

Number of Threads 1,2 2 2,0 0,4 Explanation 1 evaluator thread per CPU VP, plus 2 2 evaluator threads per CPU VP 2 evaluator threads per CPU VP 4 evaluator threads for any database server Example For a 3 CPU VP server: (3 * 1) + 2 = 5 For a 3 CPU VP server: (3 * 2) = 6 For a 3 CPU VP server: (3* 2)+0 = 6 For a 3 CPU VP server: (3 * 0) +4 = 4
Warning: Do not configure the total number of evaluator threads to be smaller than the number of CPU VPs in the system.
CDR_MAX_DYNAMIC_LOGS Configuration Parameter

default value range of values v -1 add dynamic log files indefinitely v 0 disable dynamic log addition v >0 number of dynamic logs that can be added takes effect when shared memory is initialized and the DYNAMIC_LOGS configuration parameter is set to 2. For more information on the DYNAMIC_LOGS configuration parameter, see the IBM InformixDynamic Server Administrator'sReference. 0
The CDR_MAX_DYNAMIC_LOGS configuration parameter specifies the number of dynamic log file requests that Enterprise Replication can make in one server session. For more information, see Preventing DDRBLOCK Mode on page 8-9.
CDR_NIFCOMPRESS Configuration Parameter

default value range of values v -1 specifies no compression v 0 specifies to compress only if the target server expects compression v 1 - 9 specifies increasing levels of compression 0
B-4
takes effect
when Enterprise Replication is initialized
The CDR_NIFCOMPRESS (network interface compression) configuration parameter specifies the level of compression that the database server uses before sending data from the source database server to the target database server. Network compression saves network bandwidth over slow links but uses more CPU to compress and decompress the data. The values have the following meanings.
Value -1 0 1 9 Meaning The source database server never compresses the data, regardless of whether or not the target site uses compression. The source database server compresses the data only if the target database server expects compressed data. The database server performs a minimum amount of compression. The database server performs the maximum possible compression.
When Enterprise Replication is defined between two database servers, the CDR_NIFCOMPRESS values of the two servers are compared and changed to the higher compression values. The compression values determine how much memory can be used to store information while compressing, as follows:
0 = 1 = 2 = ... 6 = ... 8 = 9 = no additional memory 128k + 1k = 129k 128k + 2k = 130k 128k + 32k = 160k
128k + 128k = 256k 128k + 256k = 384k
Higher levels of CDR_NIFCOMPRESS cause greater compression. Different sites can have different levels. For example, Figure B-2 shows a set of three root servers connected with LAN and a nonroot server connected over a modem. The CDR_NIFCOMPRESS configuration parameter is set so that connections between A, B, and C use no compression. The connection from C to D uses level 6.
B-5
A C
Figure B-2. Database Servers with Different Compression Levels
Important: Do not disable NIF compression if the network link performs compression in hardware.
CDR_QDATA_SBSPACE Configuration Parameter

default value separators none comma
range of values up to 128 characters for each sbspace name; up to 32 sbspace names. Use a comma to separate each name in the list. At least one sbspace name must be specified. takes effect when Enterprise Replication is initialized
The CDR_QDATA_SBSPACE configuration parameter specifies the list of up to 32 names of sbspaces that Enterprise Replication uses to store spooled transaction row data. Enterprise Replication creates one smart large object per transaction. If CDR_QDATA_SBSPACE is configured for multiple sbspaces, then Enterprise Replication uses all appropriate sbspaces in round-robin order. Important: You must set the CDR_QDATA_SBSPACE configuration parameter and create the sbspaces specified by CDR_QDATA_SBSPACE before defining a server for replication. If the configuration parameter is not set in ONCONFIG or the sbspace names specified by CDR_QDATA_SBSPACE are invalid, Enterprise Replication fails to define the server. For more information, see Row Data sbspaces on page 4-11 and Defining Replication Servers on page 6-3. Warning: Do not change the value of CDR_QDATA_SBSPACE while Enterprise Replication is running.
B-6
CDR_QHDR_DBSPACE Configuration Parameter

default value the name of the dbspace specified by the ROOTNAME configuration parameter For more information, see the IBM Informix: Administrator's Reference. takes effect when Enterprise Replication is initialized
The CDR_QHDR_DBSPACE configuration parameter specifies the location of the dbspace that Enterprise Replication uses to store the transaction record headers spooled from the send and receive queues. By default, Enterprise Replication stores the transaction record headers in the root dbspace. For more information, see Transaction Record dbspace on page 4-10. Warning: Do not change the value of CDR_QHDR_DBSPACE after you initialize Enterprise Replication.
CDR_QUEUEMEM Configuration Parameter

default value units 4096 kilobytes
range of values > = 500 takes effect when shared memory is initialized
The CDR_QUEUEMEM configuration parameter specifies the maximum amount of memory that is used for the send and receive queues. If your logical logs are large, the Enterprise Replication reads a large amount of data into queues in memory. You can use CDR_QUEUEMEM to limit the amount of memory devoted to the queues. The maximum memory used for queued elements on a replication server is the total number of database servers involved in replication, multiplied by the value of CDR_QUEUEMEM. When you increase the value of CDR_QUEUEMEM, you reduce the number of elements that must be written to disk, which can eliminate I/O overhead. Therefore, if elements are frequently stored on disk, increase the value of CDR_QUEUEMEM. Conversely, if you set the value of CDR_QUEUEMEM too high, you might adversely impact the performance of your system. High values for CDR_QUEUEMEM also increase the time necessary for recovery. Tune the value of CDR_QUEUEMEM for the amount of memory available on your computer.
B-7
CDR_SERIAL Configuration Parameter

default value units 0,0 delta, offset
range of values 0,0 disable control of serial column value generation >0,>0 enable control of serial column value generation takes effect when Enterprise Replication is initialized
The CDR_SERIAL configuration parameter enables control over generating values for serial and SERIAL8 columns in tables defined for replication. This is useful for generating unique serial column primary keys in an Enterprise Replication environment. The format is:
CDR_SERIAL delta,offset
where: delta offset determines the incremental size of the serial column values determines the specific number within the delta that will be generated.
Resulting Value for the SERIAL Column 1, 101, 201, 301, and so on 2, 202, 402, 602, and so on
Example CDR_SERIAL Value CDR_SERIAL 100,1 CDR_SERIAL 200,2
You should set the delta to greater than the expected number of servers within your enterprise and make sure the offset is unique on each server. When you set CDR_SERIAL, only tables that are marked as the source of a replicate use this method of serial column generation. By default, CDR_SERIAL is set to 0 to disable control over generating SERIAL and SERIAL8 values. For more information, see SERIAL Data Types and Primary Keys on page 2-9.
CDR_SUPPRESS_ATSRISWARN Configuration Parameter

default value separators none commas or as range of values specified with a hyphen
B-8
takes effect
when Enterprise Replication is initialized
The CDR_SUPPRESS_ATSRISWARN configuration parameter specifies the Datasync error and warning code numbers to be suppressed in ATS and RIS files. For example, you can set CDR_SUPPRESS_ATSRISWARN to 2-5, 7 to suppress the generation of error and warning messages 2, 3, 4, 5, and 7. For a list of error and message numbers see Appendix G, Datasync Warning and Error Messages, on page G-1.
ENCRYPT_CDR Configuration Parameter

default value 0
range of values 0 do not encrypt 1 encrypt when possible 2 always encrypt takes effect when Enterprise Replication is initialized
The ENCRYPT_CDR configuration parameter sets the level of encryption for Enterprise Replication. If the ENCRYPT_CDR configuration parameter is set to 1, then encryption is used for Enterprise Replication transactions only when the database server being connected to also supports encryption. This option allows unencrypted communication with versions of Dynamic Server prior to 9.40. If the ENCRYPT_CDR configuration parameter is set to 2, then only connections to encrypted database servers are allowed. If you use both encryption and compression (by setting the CDR_NIFCOMPRESS configuration parameter), then compression occurs before encryption.
ENCRYPT_CIPHER Configuration Parameter

syntax ENCRYPT_CYPHER all|allbut:<list of ciphers and modes>|cipher:mode{,cipher:mode ...} v all Specifies to include all available ciphers and modes, except ECB mode. For example: ENCRYPT_CIPHER all v allbut:<list of ciphers and modes>
B-9
Specifies to include all ciphers and modes except the ones in the list. Separate ciphers or modes with a comma. For example: ENCRYPT_CIPHER allbut:<cbc,bf> v cipher:mode Specifies the ciphers and modes. Separate cipher-mode pairs with a comma. For example: ENCRYPT_CIPHER des3:cbc,des3:ofb default value takes effect allbut:<ecb> when Enterprise Replication is initialized
The ENCRYPT_CIPHER configuration parameter defines all ciphers and modes that can be used by the current database session. The cipher list for allbut can include unique, abbreviated entries. For example, bf can represent bf-1, bf-2, and bf-3. However, if the abbreviation is the name of an actual cipher, then only that cipher is eliminated. Therefore, des eliminates only the des cipher, but de eliminates des, des3, and desx. Important: The encryption cipher and mode used is randomly chosen among the ciphers common between the two servers. It is strongly recommended that you do not specify specific ciphers. For security reasons, all ciphers should be allowed. If a specific cipher is discovered to have a weakness, then that cipher can be eliminated by using the allbut option. The following ciphers are supported. For an updated list, see the Release Notes.
des des3 desx DES (64-bit key) Triple DES Extended DES (128-bit key) bf-1 bf-2 bf-3 Blow Fish (64-bit key) Blow Fish (128-bit key) Blow Fish (192-bit key)
The following modes are supported. ecb cbc ocb ofb Electronic Code Book (ECB) Cipher Block Chaining Cipher Feedback Output Feedback
All ciphers support all modes, except the desx cipher, which only supports the cbc mode.
B-10
Because cdb mode is considered weak, it is only included if specifically requested. It is not included in the all or the allbut list.
ENCRYPT_MAC Configuration Parameter

default value medium
range of values One or more of the following options, separated by commas: v off does not use MAC generation. v low uses XOR folding on all messages. v medium uses SHA1 MAC generation for all messages greater than 20 bytes long and XOR folding on smaller messages. v high uses SHA1 MAC generation on all messages. For example: ENCRYPT_MAC medium,high takes effect when Enterprise Replication is initialized
The ENCRYPT_MAC configuration parameter controls the level of message authentication code (MAC) generation. The level is prioritized to the highest value. For example, if one node has a level of high and medium enabled and the other node has only low enabled, then the connection attempt fails. Use the off entry between servers only when a secure network connection is guaranteed.
ENCRYPT_MACFILE Configuration Parameter

default value units builtin pathnames, up to 1536 bytes in length
range of values One or more full path and filenames separated by commas, and the optional builtin keyword. For example: ENCRYPT_MACKFILE /usr/local/bin/mac1.dat, /usr/local/bin/mac2.dat,builtin takes effect when Enterprise Replication is initialized
The ENCRYPT_MACFILE configuration parameter specifies a list of the full path names of MAC key files. To specify the built-in key, use the keyword builtin. Using the builtin option provides limited message verification (some validation of the received message and determination that it appears to have come from a Dynamic Server client or server). The strongest verification is done by a site-generated MAC key file.
B-11
To generate a MAC key file: 1. Execute the following command from the command line: GenMacKey o filename The filename is the name of the MAC key file. 2. Update the ENCRYPT_MACFILE configuration parameter on all Enterprise Replication servers to include the location of the new MAC key file. 3. Distribute the new MAC key file. Each of the entries for the ENCRYPT_MACFILE configuration parameter is prioritized and negotiated at connect time. The prioritization for the MAC key files is based on their creation time by the GenMacKey utility. The builtin option has the lowest priority. Because the MAC key files are negotiated, you should periodically change the keys.
ENCRYPT_SWITCH Configuration Parameter

syntax ENCRYPT_SWITCH cipher_switch_time, key_switch_time v cipher_switch_time specifies the minutes between cipher renegotiation v key_switch_time specifies the minutes between secret key renegotiation 60,60 minutes
default value units
range of values positive integers takes effect when Enterprise Replication is initialized
The ENCRYPT_SWITCH configuration parameter defines the frequency at which ciphers or secret keys are renegotiated. The longer the secret key and encryption cipher remains in use, the more likely the encryption rules might be broken by an attacker. To avoid this, cryptologists recommend changing the secret keys on long-term connections. The default time that this renegotiation occurs is once an hour.
Environment Variables
The following environment variables affect the behavior of Enterprise Replication. For a complete list of environment variables, and how to set them, see the IBM Informix: Guide to SQL Reference. v CDR_LOGDELTA v CDR_PERFLOG
B-12
v v v v
CDR_RMSCALEFACT CDR_ROUTER CDRSITES_731 CDRSITES_92X
CDR_LOGDELTA Environment Variable

default value 30
range of values positive numbers takes effect when Enterprise Replication is initialized
The CDR_LOGDELTA environment variable determines when the send and receive queues are spooled to disk as a percentage of the logical log size. Use the CDR_ENV configuration parameter to set this environment variable. For more information, see CDR_ENV Configuration Parameter on page B-2. Important: Do not use the CDR_LOGDELTA environment variable unless instructed to do so by Technical Support.
CDR_PERFLOG Environment Variable

default value 0
range of values positive number takes effect when Enterprise Replication is initialized
The CDR_PERFLOG environment variable enables queue tracing, which can be displayed with the onstat -g que perf command. Use the CDR_ENV configuration parameter to set this environment variable. For more information, see CDR_ENV Configuration Parameter on page B-2. Important: Do not use the CDR_PERFLOG environment variable unless instructed to do so by Technical Support.
CDR_RMSCALEFACT Environment Variable

default value 4
range of values positive number takes effect when Enterprise Replication is initialized
The CDR_RMSCALEFACT environment variable sets the number of DataSync threads started for each CPU VP. Specifying a large number of threads can
B-13
result in wasted resources. Use the CDR_ENV configuration parameter to set this environment variable. For more information, see CDR_ENV Configuration Parameter on page B-2. Important: Do not use the CDR_RMSCALEFACT environment variable unless instructed to do so by Technical Support.
CDR_ROUTER Environment Variable

default value 0
range of values any number takes effect when Enterprise Replication is initialized
When set to 1, the CDR_ROUTER environment variable disables intermediate acknowledgements of transactions in hierarchical topologies. The normal behavior for intermediate servers is to send acknowledgements if they receive an acknowledgment from the next server in the replication tree (can be a leaf server) or if the transaction is stored in the local queue. Use the CDR_ENV configuration parameter to set this environment variable. For more information, see CDR_ENV Configuration Parameter on page B-2. If CDR_ROUTER is set at the hub server, an acknowledgement will be sent only if the hub server receives acknowledgement from all of its leaf servers. Transactions will not be acknowledged even if they are stored in the local queue of the hub server. If CDR_ROUTER is not set at hub server, the hub server will send an acknowledgement if the transaction is stored in the local queue at the hub server or if the hub server received acknowledgement from all of its leaf servers. Important: Do not use the CDR_ROUTER environment variable unless instructed to do so by Technical Support.
CDRSITES_731 Environment Variable

units cdrIDs, which are the unique identifiers for the database server in the Options field of the SQLHOSTS file ( i = unique_ID)
B-14
In mixed-version Enterprise Replication environments that involve post 7.3x/7.20x/7.24x servers, the NIF does not properly report its version when it responds to a new server. When a new server sends an initial protocol message to a sync server, the sync server, instead of properly giving its version, gives back the version of the new server. If a 10.0/9.40/9.30 server tries to synchronize with a 7.3x/7.20x/7.24x server, the older server responds to the 10.0/9.40/9.30 server that it is a 10.0/9.40/9.30 server and will subsequently fail. To prevent this malfunction: If you have Version 7.3x/7.20x/7.24x servers in your Enterprise Replication environment, set the CDRSITES_731 environment variable, as appropriate, for 9.30, 9.40, or 10.0 database servers by setting the CDRSITES_731 cdrID for these Version 7.x database servers. The cdrID is the unique identifier for the database server in the Options field of the SQLHOSTS file ( i = unique_ID). For example, suppose that you have 5 Informix Dynamic Servers, Version 7x servers whose cdrID values range from 1 through 7 (cdrIDs = 1, 4, 5, 6, and 7) If you upgrade database server cdrID 6 to Version 10.0/9.40/9.30, you must set the CDRSITES_731 environment variable for the other server cdrIDs before bringing the Version 10.0/9.40/9.30 database server online: setenv CDRSITES_731 1,4,5,7
CDRSITES_92X Environment Variable

units cdrIDs, which are the unique identifiers for the database server in the Options field of the SQLHOSTS file ( i = unique_ID)
In mixed-version Enterprise Replication environments that involve 9.21/9.20 servers, the NIF does not properly report its version when it responds to a new server. When a new server sends an initial protocol message to a sync server, the sync server, instead of properly giving its version, gives back the version of the new server. If a 10.0/9.40/9.30 server tries to synchronize with a 9.21/9.20 server, the older server responds to the 10.0/9.40/9.30 server that it is a 10.0/9.40/9.30 server and will subsequently fail. To prevent this malfunction:
B-15
If you have Version 9.21/9.20 servers in your Enterprise Replication environment, set the CDRSITES_92X environment variable, as appropriate, for 9.30, 9.40, or 10.0 database servers by setting the CDRSITES_92x cdrID for these Version 9.20 and 9.21 servers. The cdrID is the unique identifier for the database server in the Options field of the SQLHOSTS file ( i = unique_ID). For example, suppose that you have 5 Informix Dynamic Servers, Version 9.21/9.20 whose cdrID values range from 2 through 10 (cdrIDs = 2, 3, 8, 9, and 10) If you upgrade database server cdrID 8 to Version 10.0/9.40/9.30, you must set the CDRSITES_92X environment variable for the other server cdrIDs before bringing the Version 10.0/9.40/9.30 database server online: setenv CDRSITES_92x 2,3,9,10
B-16
Appendix C. onstat Command Reference

This appendix describes forms of the onstat command that are relevant to Enterprise Replication. The onstat utility reads shared-memory structures and provides statistics about the database server that are accurate at the instant that the command executes. The system-monitoring interface (SMI) also provides information about the database server. For general information about onstat and SMI, refer to the IBM Informix: Administrator's Reference. For information specific to Enterprise Replication, see Appendix D, SMI Table Reference, on page D-1
onstat -g Command Summary

Command onstat -g ath onstat -g cat onstat -g ddr onstat -g dss onstat -g dtc onstat -g grp onstat -g nif onstat -g que onstat -g rcv onstat -g rep onstat -g rqm Page C-1 C-2 C-4 C-5 C-6 C-7 C-14 C-15 C-16 C-19 C-19
The onstat -g commands are provided for support and debugging only. You can include only one of these options with each onstat -g command. This appendix describes the following onstat -g commands:
onstat -g ath
The onstat -g ath command prints information about all threads. The following table summarizes the threads that Enterprise Replication uses. You can use this information about threads when you evaluate memory use. For more information, see the utilities chapter of the IBM Informix: Administrator's Reference.
C-1
Number of Threads 1
Thread Name ddr_snoopy
Thread Description Performs physical I/O from logical log, verifies potential replication, and sends applicable log-record entries to Enterprise Replication Runs during queue recovery to monitor the log and sets blockout mode if the log position advances too far before replication resumes Receives log entries and passes entries to evaluator thread Evaluates log entry to determine if it should be replicated (n is the number of evaluator threads specified by CDR_EVALTHREADS) This thread also performs transaction compression on the receipt of COMMIT WORK and queues completed replication messages. Performs the physical IO for the temporary smart large object that holds paged transaction records Grouper paging is activated for a transaction when its size is 10 percent of the value of SHMVIRTSIZE or CDR_QUEUEMEM or when it includes more than 100,000 records. Parses all SQL statements for replicate definitions Sending thread for site Receiving thread for site Accepts acknowledgments from site At least 2, up to a maximum of the number of active connections Replays transaction on the target system (DataSync thread) At least one thread is created for each CPU virtual processor (VP). The maximum number of threads is 4*(number of CPU VPs). Schedules internal Enterprise Replication events Monitors and adjusts DataSync performance for optimum performance (on the target) Deletes (cleans) rows from the deleted rows shadow table when they are no longer needed
preDDR
1 n
CDRGfan CDRGevaln
1 per large transaction
CDRPager
1 1 per connection 1 per connection 2...n
CDRCparse CDRNsTnCDRNsAn CDRNrn CDRACK_n
# CPUs...
CDRD_n
1 0 or 1 0 or 1
CDRSchedMgr CDRM_Monitor CDRDTCleaner
onstat -g cat
The onstat -g cat command prints information from the Enterprise Replication global catalog. The global catalog contains a summary of information about the defined servers, replicates, and replicate sets on each of the servers within
C-2
the enterprise. If a replicated table is undergoing an alter operation, the onstat -g cat command shows that it is in alter mode. For example, use this command to determine: v How many servers and how many replicates are configured v Which table matches a given replicate v Whether a server is a root or leaf server v The current bitmap mask for a given server. You can use the bitmap mask with the output from the onstat -g rqm command to determine which server Enterprise Replication is waiting on for an acknowledgement. The onstat -g cat command has the following formats:
onstat -g cat onstat -g cat scope onstat -g cat replname
The following table describes replname and scope.

Modifier replname scope Description The name of a replicate One of the following values: serversPrint information on servers only replsPrint information on replicates only fullPrint expanded information for both replicate servers and replicates
This sample output from the onstat -g cat repls command shows that the table tab is in alter mode. The replicate rep1 is defined on this table, its replicate ID is 6553601.
IBM Informix Dynamic Server Version 10.00.UC1 -- On-Line -- Up 00:01:39 -- 28672 Kbytes GLOBAL-CATALOG CACHE STATISTICS
REPLICATES ------------------Parsed statements: Id 6553601 table tab Id 6553602 table tab12 Inuse databases: test(2) Name: rep1, Id: 6553601 State: ACTIVE Flags: 0x800000 ALTERMODE use 0 lastexec Wed Dec 31 18:00:00 1969 Local Participant: test:nagaraju.tab Attributes: TXN scope, Enable ATS, Enable RIS, all columns sent in updates Conflict resolution: [TIMESTAMP] Column Mapping: ON, columns INORDER, offset 8, uncomp_len 12 Column Name Verifcation: ON
C-3
No Replicated UDT Columns Name: rep12, Id: 6553602 State: ACTIVE Flags: 0x800000 use 0 lastexec Wed Dec 31 18:00:00 1969 Local Participant: test:nagaraju.tab12 Attributes: TXN scope, Enable ATS, Enable RIS, all columns sent in updates Conflict resolution: [TIMESTAMP] Column Mapping: ON, columns INORDER, offset 8, uncomp_len 2064 Column Name Verifcation: ON No Replicated UDT Columns
onstat -g ddr
The onstat -g ddr command prints the status of the Enterprise Replication database log reader. The ddr, or ddr_snoopy, is an internal component of Enterprise Replication that reads the log buffers and passes information to the grouper. You can use the information from the onstat -g ddr command to monitor replay position in the log file and ensure replay position is never overwritten (which can cause loss of data). The replay position is the point from where, if a system failure occurs, Enterprise Replication starts re-reading the log information into the log update buffers. All the transactions generated before this position at all the target servers have been applied by Enterprise Replication or safely stored in stable queue space. The onstat -g ddr output shows you a snapshot of the replay position, the snoopy position, and the current position. The snoopy position identifies the position of the ddr_snoopy thread in the logical logs. The ddr_snoopy has read the log records up until this point. The current position is the position where the server has written its last logical log record. The log needs position is based on replay position and is set at a certain distance from replay position, for example, at seventy percent of the log file. The remainder of the circular log file comprises the DDR BLOCK zone. As messages are acknowledged or stored in the stable queue, the replay position, and hence also the log needs position, should advance. If you notice that replay position is not advancing, this can mean that the stable queue is full or a remote server is down. If log reading is blocked, data might not be replicated until the problem is resolved. If the block is not resolved, the database server might overwrite the read (ddr_snoopy) position, which means that data will not be replicated. If this occurs, you must manually resynchronize the source and target databases. If you are running servers prior to Version 9.3, to avoid these problems, IBM recommends that you: v Have 24 hours of online log space available
C-4
v Keep the log file size consistent. Instead of having a single large log file, implement several smaller ones. v Avoid switching logical logs more than once per hour. v Keep some distance between LTXHWM (long-transaction high-watermark) and LTXENHWM (long-transaction, exclusive-access, high-watermark). For servers of Version 9.4, and later, you can enable dynamic log creation by setting the CDR_MAX_DYNAMIC_LOGS configuration parameter in the ONCONFIG file. If the current position reaches the log needs position, instead of going into a blocked state, Enterprise Replication automatically adds another log file. If this option is set, the onstat -g ddr command prints the number of dynamic log requests made. The following sample output from the onstat ddr command shows the replay position, snoopy position, and current position highlighted.
DDR -- Running # Event Buffers 528 Snoopy ID 24 Snoopy Position 165018 Replay ID 24 Replay Position 6a018 From Disk 111 Current Current ID Position 24 Tossed (LBC full) 0 166000
Log Pages Snooped:
From Cache 247
Total dynamic log requests: 0 DDR events queue Type TX id Partnum Row id
onstat -g dss
The onstat -g dss command prints detailed statistical information about the activity of individual data sync threads. The data sync thread applies the transaction on the target server. Statistics include the number of applied transactions and failures and when the last transaction from a source was applied. The onstat -g dss command has the following formats:
onstat -g dss onstat -g dss modifier
C-5
The following table describes the values for modifier.

Modifier UDR UDRx Action Prints summary information about any UDR invocations by the data sync threads. Prints expanded information (including a summary of error information) about any UDR invocations by the data sync threads. The Procid column lists the UDR procedure ID.
In the following example, only one data sync thread is currently processing the replicated data. It has applied a total of one replicated transaction and the transaction was applied at 2004/09/13 18:13:10. The Processed Time field shows the time when the last transaction was processed by this data sync thread.
IBM Informix Dynamic Server Version 10.00.UC1 -- On-Line -- Up 00:00:28 -- 28672 Kbytes DS thread statistic cmtTime Tx Tx Tx Last Tx Name < local Committed Aborted Processed Processed Time ------------ ------- --------- ------- --------- ----------------CDRD_1 18:13:10 0 1 0 1 (1095117190) 2004/09/13
Tables (0.0%): Databases: test CDR_DSLOCKWAIT = 1 CDR_DSCLOSEINTERVAL = 60
onstat -g dtc
The onstat -g dtc command prints statistics about the delete table cleaner. The delete table cleaner removes rows from the delete table when they are no longer needed. The -g dtc option is used primarily as a debugging tool and by Technical Support. In the following example, the thread name of the delete table cleaner is CDRDTCleaner. The total number of rows deleted is 1. The last activity on this thread occurred at 2004/09/13 18:47:19. The delete table for replicate rep1 was last cleaned at 2004/09/13 18:28:25.
IBM Informix Dynamic Server Version 10.00.UC1 -- Up 00:59:15 -- 28672 Kbytes thread rows deleted = 49 <CDRDTCleaner> = 1 -- On-Line
-- Delete Table Cleanup Status as of (1095119368) 2004/09/13 18:49:28
C-6
lock timeouts list size last activity Id Database Replicate 000001 test 18:28:25 rep1 /09/13 18:28:25 rep1 /09/13 18:28:25 000002 test
= 0 = 3 = (1095119239) 2004/09/13 18:47:19 Last Cleanup Time Server Last Log Change (1095118105) 2004/09/13 g_bombay g_delhi (1095118105) 2004 (1095118105) 2004 <never cleaned>
cleanup interval = 300
=========================================================
onstat -g grp
The onstat -g grp command prints statistics about the grouper. The grouper evaluates the log records, rebuilds the individual log records into the original transaction, packages the transaction, and queues the transaction for transmission. The -g grp option is used primarily as a debugging tool and by Technical Support. The onstat -g grp command has the following formats:
onstat -g grp onstat -g grp modifier
C-7

Modifier A E Ex G L Lx M Mz P pager R S Action Prints all the information printed by the G, T, P, E, R, and S modifiers Prints grouper evaluator statistics Prints grouper evaluator statistics, expands user-defined routine (UDR) environments Prints grouper general statistics Prints grouper global list Prints grouper global list, expands open transactions Prints grouper compression statistics Clears grouper compression statistics Prints grouper table partition statistics Prints grouper paging statistics Prints grouper replicate statistics Prints grouper serial list head (The serial list head is the first transaction in the list, that is, the next transaction that will be placed in the send queue.) Prints grouper serial list (The serial list is the list of transactions, in chronological order.) Prints grouper serial list, expands open transactions Prints grouper transaction statistics Prints summary information about any UDR invocations by the grouper threads Prints expanded information (including a summary of error information) about any UDR invocations by the grouper threads The Procid column lists the UDR procedure ID.
Sl Sx T UDR UDRx
The rest of this section contains sample output from various onstat -g grp modifier commands. The following sample shows output for the onstat -g grp command.
IBM Informix Dynamic Server Version 10.00.UC1 -- Up 01:47:07 -- 28672 Kbytes Grouper at 0xb014018: Last Idle Time: (1095122236) 2004/09/13 19:37:16 RSAM interface ring buffer size: 528 RSAM interface ring buffer pending entries: 0 Eval thread interface ring buffer size: 48 Eval thread interface ring buffer pending entries: 0 -- On-Line
C-8
Log update buffers in use: 0 Max log update buffers used at once: 5 Log update buffer memory in use: 0 Max log update buffer memory used at once: 320 Updates from Log: 16 Log update links allocated: 512 Blob links allocated: 0 Conflict Resolution Blocks Allocated: 0 Memory pool cache: Empty Last Tx to Queuer began : (1095118105) 2004/09/13 18:28:25 Last Tx to Queuer ended : (1095118105) 2004/09/13 18:28:25 Last Tx to Queuer log ID, position: 12,23 Open Tx: 0 Serial Tx: 0 Tx not sent: 0 Tx sent to Queuer: 2 Tx returned from Queuer: 2 Events sent to Queuer: 7 Events returned from Queuer: 7 Total rows sent to Queuer: 2 Open Tx array size: 1024 Table tab at 0xae8ebb0 [ CDRShadow ] Table tab12 at 0xae445e0 [ CDRShadow ] Grouper Table Partitions: Slot Slot 312... 770... tab 1048888 tab12 3145730 Slot 1026... tab12 4194306 Repl links on global free list: 2 Evaluators: 3 Evaluator at 0xb03d030 ID 0 [Idle:Idle] Protection:unused Eval iteration: 1264 Updates evaluated: 0 Repl links on local free list: 256 UDR environment table at 0xb03d080 Number of environments: Table memory limit Table memory used : : 0 25165 0
C-9
SAPI memory limit SAPI memory used
: :
131072 0 0
Count failed UDR calls: Eval iteration: 1265 Updates evaluated: 2 Repl links on local free list: 254 UDR environment table at 0xb03d128 Number of environments: Table memory limit Table memory used SAPI memory limit SAPI memory used : : : :
Evaluator at 0xb03d0d8 ID 1 [Idle:Idle] Protection:unused
0 25165 0 131072 0 0
Count failed UDR calls: Eval iteration: 1266 Updates evaluated: 4 Repl links on local free list: 256 UDR environment table at 0xb03d1d0 Number of environments: Table memory limit Table memory used SAPI memory limit SAPI memory used Total Free Repl links 768 Replication Group 6553601 at 0xb0a8360 : : : :
Evaluator at 0xb03d180 ID 2 [Idle:Idle] Protection:unused
0 25165 0 131072 0 0
Count failed UDR calls:
Replication at 0xb0a82b0 6553601:6553601 (tab) [ NotifyDS FullRowOn ] Column Information [ CDRShadow VarUDTs InOrder Same ] CDR Shadow: offset 0, size 8 In Order: offset 8, size 10 Replication Group 6553602 at 0xb0a8480 Replication at 0xb0a83d0 6553602:6553602 (tab12) [ Ignore Stopped NotifyDS FullRowOn ] Column Information [ CDRShadow VarUDTs InOrder Same ] CDR Shadow: offset 0, size 8 In Order: offset 8, size 16
C-10
The following example shows output for the onstat -g grp E command. The field Evaluators: 4 indicates that there are four evaluation threads configured for the system.
IBM Informix Dynamic Server Version 10.00.UC1 -- Up 02:07:10 -- 36864 Kbytes Repl links on global free list: 0 Evaluators: 4 Evaluator at 0xba71840 ID 0 [Idle:Idle] Protection: unused Eval iteration: 1007 Updates evaluated: 0 Repl links on local free list: 256 UDR environment table at 0xba71890 Number of environments: Table memory limit Table memory used SAPI memory limit SAPI memory used : : : : 0 16777 0 131072 0 0 -- On-Line
Count failed UDR calls: Eval iteration: 1007 Updates evaluated: 0 Repl links on local free list: 256 UDR environment table at 0xba71940 Number of environments: Table memory limit Table memory used SAPI memory limit SAPI memory used : : : :
Evaluator at 0xba718f0 ID 1 [Idle:Idle] Protection: unused
0 16777 0 131072 0 0
Count failed UDR calls: Eval iteration: 1007 Updates evaluated: 0 Repl links on local free list: 256 UDR environment table at 0xba8c2b0 Number of environments: Table memory limit Table memory used SAPI memory limit SAPI memory used : : : :
Evaluator at 0xba8c260 ID 2 [Idle:Idle] Protection: unused
0 16777 0 131072 0 0
C-11
Evaluator at 0xbaac2a0 ID 3 [Idle:Idle] Protection: unused Eval iteration: 1007 Updates evaluated: 0 Repl links on local free list: 256 UDR environment table at 0xbaac2f0 Number of environments: Table memory limit Table memory used SAPI memory limit SAPI memory used Total Free Repl links 1024 : : : : 0 16777 0 131072 0 0
The following example shows output for the onstat -g grp G command.
IBM Informix Dynamic Server Version 10.00.UC1 -- Up 02:08:56 -- 36864 Kbytes Grouper at 0xb8ab020: Last Idle Time: (1095115397) 2004/09/13 17:43:17 RSAM interface ring buffer size: 1040 RSAM interface ring buffer pending entries: 0 Eval thread interface ring buffer size: 64 Eval thread interface ring buffer pending entries: 0 Log update buffers in use: 0 Max log update buffers used at once: 1 Log update buffer memory in use: 0 Max log update buffer memory used at once: 64 Updates from Log: 1 Log update links allocated: 512 Blob links allocated: 0 Conflict Resolution Blocks Allocated: 0 Memory pool cache: Empty -- On-Line
The following example shows output for the onstat -g grp P command. In the following example, the grouper is evaluating rows for the account, teller and customer tables.
IBM Informix Dynamic Server Version 10.00.UC1 -- Up 02:11:39 -- 36864 Kbytes -- On-Line
Table teller at 0xb851480 [ CDRShadow VarChars ] Table account at 0xb7faad8 [CDRShadow VarChars VarUDTs Floats Blobs] Table customer at 0xbbe67a8 [CDRShadow VarChars VarUDTs]
C-12
Grouper Table Partitions: Slot Slot Slot 387... 389... 394... account 1048707 teller 1048709 customer 1048714
The following example shows output for the onstat -g grp pager command. The sample output shows the grouper large transaction evaluation statistics.
IBM Informix Dynamic Server Version 10.00.UC1 -- Up 00:20:42 -- 28672 Kbytes Grouper Pager statistics: Number of active big transactions: 0 Total number of big transactions processed: 0 Spool size of the biggest transaction processed: 0 Bytes -- On-Line
The following example shows output for the onstat -g grp R command. In this example, the grouper is configured to evaluate rows for replicates with IDs 6553601 and 6553602 (you can use the onstat -g cat repls command to obtain the replicate names). The Ignore attribute of replicate ID 6553602 shows that the grouper is currently not evaluating rows for this replicate. This can happen if the replicate state is not ACTIVE. You can obtain the replicate state using the onstat -g cat repls command.
IBM Informix Dynamic Server Version 10.00.UC1 -- Up 00:04:47 -- 28672 Kbytes Replication Group 6553601 at 0xb0a8360 Replication at 0xb0a82b0 6553601:6553601 (tab) [ NotifyDS FullRowOn ] Column Information [ CDRShadow VarUDTs InOrder Same ] CDR Shadow: offset 0, size 8 In Order: offset 8, size 10 Replication Group 6553602 at 0xb0a8480 Replication at 0xb0a83d0 6553602:6553602 (tab12) [ Ignore Stopped NotifyDS FullRowOn ] Column Information [ CDRShadow VarUDTs InOrder Same ] CDR Shadow: offset 0, size 8 In Order: offset 8, size 16 -- On-Line
The following example shows output for the onstat -g grp T command. In this example, the grouper evaluated and queued 1 transaction to the send queue. The Tx sent to Queuer field shows the total number of transactions evaluated and queued to the send queue for propagating to all the replicate
C-13
participants. The Total rows sent to Queuer field shows the total number of rows queued to the send queue for propagating to all the replicate participants.
IBM Informix Dynamic Server Version 10.00.UC1 -- On-Line -- Up 00:14:51 -- 28672 Kbytes Last Tx to Queuer began : (1095116676) 2004/09/13 18:04:36 Last Tx to Queuer ended : (1095116676) 2004/09/13 18:04:36 Last Tx to Queuer log ID, position: 5,3236032 Open Tx: 0 Serial Tx: 0 Tx not sent: 0 Tx sent to Queuer: 1 Tx returned from Queuer: 0 Events sent to Queuer: 0 Events returned from Queuer: 0 Total rows sent to Queuer: 1 Open Tx array size: 1024
onstat -g nif
The onstat -g nif command prints statistics about the network interface. The output shows which sites are connected and provides a summary of the number of bytes sent and received by each site. This can help you determine that a site is in a hung state, if it is not sending or receiving bytes. The -g nif option is used primarily as a debugging tool and by Technical Support. The onstat -g nif command has the following formats:
onstat -g nif onstat -g nif modifier

Modifier all sites serverid sum Action Prints the sum and the sites Prints the NIF site context blocks Prints information about the replication server whose groupID is serverID Prints the sum of the number of buffers sent and received for each site
C-14
The following example shows output for the onstat -g nif command. In this example, the local server is connected to the server group g_bombay and its CDR ID is 200. The connection status is set to running. The server group g_bombay NIF version is 7. The local server has sent three messages to the server g_bombay and it has received two messages from g_bombay.
IBM Informix Dynamic Server Version 10.00.UC1 -- Up 00:02:34 -- 28672 Kbytes NIF anchor Block: af01610 nifGState RetryTimeout CDR connections: Id Name State RUN Version 7 Sent 3 Received 2 ----------------------------------------------------200 g_bombay RUN 300 -- On-Line
onstat -g que
The onstat -g que command prints statistics that are common to all queues. The queuer manages the logical aspects of the queue. The RQM (reliable queue manager) manages the physical queue. The -g que option is used primarily as a debugging tool and by Technical Support. In the following example, Element high water mark shows the maximum size of the transaction buffer header data (metadata) allowed in memory, shown in kilobytes. Data high water mark shows the maximum size of transactions for user data allowed in memory, shown in kilobytes.
IBM Informix Dynamic Server Version 10.00.UC1 -- Up 00:40:28 -- 28672 Kbytes CDR Queuer Statistics: Queuer state Local server Data high water mark # of times txns split Total # of split txns allowed log delta maximum delta detected Control Key Synchronization Key Replay Table: Replay Posn (Disk value): 12/00000018 (12/00000018) Replay save interval : 10
-- On-Line
: 2 : 100 : 131072 : 0 : 0 : 30 : 4 : 0/00000007 : 0/00000003
Element high water mark : 131072
C-15
Replay updates Replay # saves Replay last save time Send Handles Server ID Send state,count
: 10 : 17 : (1095118157) 2004/09/13 18:29:17 : 200 : 0,0
RQM hdl for trg_send: Traverse handle (0xaf8e018) for thread CDRACK_0 at Head_of_Q, Flags: None RQM hdl for control_send: Traverse handle (0xaf74018) for thread CDRACK_0 at Head_of_Q, Flags: None RQM hdl for sync_send: Traverse handle (0xadc6018) for thread CDRACK_0 at Head_of_Q, Flags: None Server ID Send state,count : 200 : 0,0
RQM hdl for trg_send: Traverse handle (0xac8b018) for thread CDRACK_1 at Head_of_Q, Flags: None RQM hdl for control_send: Traverse handle (0xb1ce018) for thread CDRACK_1 at Head_of_Q, Flags: None RQM hdl for sync_send: Traverse handle (0xadc5018) for thread CDRACK_1 at Head_of_Q, Flags: None Server ID Send state,count : 200 : 0,0
RQM hdl for trg_send: Traverse handle (0xaea71d8) for thread CDRNsA200 at Head_of_Q, Flags: None RQM hdl for ack_send: Traverse handle (0xae8c1d8) for thread CDRNsA200 at Head_of_Q, Flags: None RQM hdl for control_send: Traverse handle (0xae9e1d8) for thread CDRNsA200 at Head_of_Q, Flags: None
onstat -g rcv
The onstat -g rcv command prints statistics about the receive manager. The receive manager is a set of service routines between the receive queues and data sync. The onstat -g rcv command has the following formats:
onstat -g rcv onstat -g rcv serverid onstat -g rcv full
The serverID modifier causes the command to print only those output messages received from the replication server whose groupID is serverid. The full modifier causes the command to print all statistics. The onstat -g rcv command includes the Receive Manager global section. In this section, the following fields have the meanings shown:
C-16
Field cdrRM_DSParallelPL cdrRM_DSNumLockTimeout cdrRM_DSNumLockRB cdrRM_DSNumDeadLocks cdrRM_acksinList
Description Shows the current level of Apply Parallelism, 0 (zero) being the highest Indicate the number of collisions between various apply threads
Shows acknowledgements that have been received but not yet processed
The onstat -g rcv command includes the Receive Parallelism Statistics section, a summary of the data sync threads by source server.
Field Server Tot.Txn. Pending Active MaxPnd MaxAct AvgPnd AvgAct CommitRt Description Source server ID Total number of transactions applied from this source server Number of current transactions in the pending list for this source server Number of current transactions currently being applied from this source server Maximum number of transactions in the pending list queue Maximum number of transaction in the active list queue Average depth of the pending list queue Average depth of the active list queue Commit rate of transaction from this source server based on transactions per second
The Statistics by Source section of the onstat -g rcv command shows the following information for each source server. For each replicate ID: v The number of transactions applied from the source servers v The number of inserts, deletes, and updates within the applied transactions v The timestamp of the most recently applied transaction on the target server v The timestamp of the commit on the source server for the most recently applied transaction The -g rcv option is used primarily as a debugging tool and by Technical Support. If you suspect that acknowledgement messages are not being applied, you can use this option to check. The following example shows output for the onstat -g rcv full command.
Receive Manager global block 0D452018
C-17
cdrRM_inst_ct: cdrRM_State: cdrRM_numSleepers: cdrRM_DsCreated: cdrRM_MinDSThreads: cdrRM_MaxDSThreads: cdrRM_DSBlock cdrRM_DSParallelPL cdrRM_DSFailRate cdrRM_DSNumRun: cdrRM_DSNumLockTimeout cdrRM_DSNumLockRB cdrRM_DSNumDeadLocks cdrRM_DSNumPCommits cdrRM_ACKwaiting cdrRM_totSleep: cdrRM_Sleeptime: cdrRM_Workload: cdrRM_optscale: cdrRM_MinFloatThreads: cdrRM_MaxFloatThreads: cdrRM_AckThreadCount: cdrRM_AckWaiters: 00000000 3 3 1 4 0 0
0.000000 35 0 0 0 0 0 77 153 0 4 2 7 2 2
cdrRM_AckCreateStamp:Wed Sep 08 11:47:49 2004 cdrRM_DSCreateStamp: Wed Sep 08 14:16:35 2004 cdrRM_acksInList: cdrRM_BlobErrorBufs: Receive Parallelism Statistics Srvr Tot.Txn. Pnding Active MaxPnd MaxAct AvgPnd AvgAct CommitRt 1 5 6 35 3 6 0 0 0 0 0 0 21 1 1 3 1 1 7.00 1.00 1.00 1.63 1.00 1.00 0.00 0.02 0.21 0 0
Tot Pending:0 Tot Active:0 Avg Pending:5.77 Avg Active:1.50 Commit Rate:0.01 Time Spent In RM Parallel Pipeline Levels Lev. TimeInSec 0 1 2 0 0 Pcnt. 0.00% 0.00% 17405 100.00%
Statistics by Source
C-18
Server 1 Repl 65541 65542 65545 Repl 65541 Repl 65548 Txn Ins Del Upd Last Target Apply 23 11 1 0 0 0 Last Source Commit 1 616 2004/09/08 14:20:15 2004/09/08 14:20:15 0 253 2004/09/08 14:19:33 2004/09/08 14:19:33 67 0 2004/09/08 14:20:37 2004/09/08 14:20:37 Last Source Commit
Server 5 Txn Ins Del Upd Last Target Apply 3 0 0 81 2004/09/08 16:36:10 2004/09/08 16:36:09 Last Source Commit
Server 6 Txn Ins Del Upd Last Target Apply 6 0 0 42 2004/09/08 16:37:59 2004/09/08 16:37:58
onstat -g rep
The onstat -g rep command prints events that are in the queue for the schedule manager. The -g rep option is used primarily as a debugging tool and by Technical Support. The onstat -g rep command has the following formats:
onstat -g rep onstat -g rep replname
The repl_name modifier limits the output to those events originated by the replicate named repl_name. The following example shows sample output for the onstat -g rep command:
IBM Informix Dynamic Server Version 10.00.UC1 -- Up 00:30:10 -- 28672 Kbytes Event CDRDS Thread CDREvent When 00:00:20 -- On-Line
Schedule manager Cb: add7e18 State: 0x8100 <CDRINIT,CDRRUNNING> ============================================
onstat -g rqm
The onstat -g rqm command prints statistics and contents of the low-level queues (send queue, receive queue, ack send queue, sync send queue, and control send queue) managed by the Reliable Queue Manager (RQM). The RQM manages the insertion and removal of items to and from the various queues. The RQM also manages spooling of the in-memory portions of the queue to and from disk. The -g rqm option displays the contents of the queue, size of the transactions in the queue, how much of the queue is in memory and on disk, the location of various handles to the queue, and the contents of the various progress tables. You can choose to print information for all queues or for just one queue by using one of the modifiers described below.
C-19
If a queue is empty, no information is printed for that queue. The onstat -g rqm command has the following formats:
onstat -g rqm onstat -g rqm modifier

Modifier ACKQ CNTRLQ RECVQ SENDQ SYNCQ FULL BRIEF Action Prints the ack send queue Prints the control send queue Prints the receive queue Prints the send queue Prints the sync send queue Prints full information about every in-memory transaction for every queue Prints a brief summary of the number of transactions in each of the queues and the replication servers for which the data is queued Use this modifier to quickly identify sites where a problem exists. If large amounts of data are queued for a single server, then that server is probably down or off the network. Prints all the buffer headers in memory
VERBOSE
When you specify a modifier to select a specific queue, the command prints all the statistics for that queue and information about the first and last in-memory transactions for that queue. The other modifiers of the onstat -g rqm command are used primarily as a debugging tool and by Technical Support. The output for the SENDQ modifier contains the following sections: v RQM Statistics for Queuea summary of current and historical information for the queue. This includes the number of transactions in the queue, how many are spooled, how many bytes they are using, some maximum statistics, and the high water marks that will trigger stably storing transactions in the syscdr tables. v First Txninformation about the first transaction in the queue. To check if the queue is draining, you can run onstat -g rqm several times and see if the first transactions RQM key is changing. The RQM key has the following format: Server_ID/Commit_unique_logID/Commit_log_position/Sequence. If it is not draining, the target server may be offline or some other problem is occurring. The NeedAck field shows from which server the transaction is
C-20
waiting for an acknowledgement. You can use this bitmap mask with the output from the onstat -g cat command to determine the name of the server which server Enterprise Replication is waiting on for an acknowledgement. v Last Txninformation about the last transaction in the queue v Traverse handlelists the handles used for threads v Progress tableprovides information about the progress of each replicate under the headers: Server, Group, Bytes Queued, Acked, and Sent. The Group field shows the replicate ID. The Acked field shows what has been acknowledged. The Sent field shows which entries are now in transit. Both the Acked and the Sent field show the RQM key, which has the following format: Server_ID/Commit_unique_logID/Commit_log_position/Sequence. The following example shows output for the onstat -g rqm SENDQ command.
RQM Statistics for Queue (0x0D3DF018) trg_send Transaction Spool Name: trg_send_stxn Insert Stamp: 35/0 Flags: SEND_Q, SPOOLED, PROGRESS_TABLE, NEED_ACK Txns in queue: Log Events in queue: Txns in memory: Txns in spool only: Txns spooled: Unspooled bytes: Size of Data in queue: Real memory in use: Pending Txn Buffers: Pending Txn Data: Max Real memory hdrs used Total data queued: Total Txns queued: Total Txns spooled: Total Txns restored: Total Txns recovered: Spool Rows read: Total Txns deleted: Total Txns duplicated: Total Txn Lookups: First Txn (0x0D60C018) Key: 35 0 35 0 0 176206 176206 Bytes 176206 Bytes 0 0 Bytes 65988 (2457600) Bytes 176206 Bytes 35 0 0 0 0 0 0 363 1/9/0x000d4bb0/0x00000000
Max Real memory data used: 176206 (2457600) Bytes
Txn Stamp: 1/0, Reference Count: 0.

C-21
Txn Flags: Notify Txn Commit Time: (1094670993) 2004/09/08 14:16:33 Txn Size in Queue: 5908 First Bufs (0x0D31C9E8) Queue Flags: Resident First Bufs Buffer Flags: TRG, Stream NeedAck: Waiting for Acks from <[0004]> No open handles on txn. Last Txn (0x0D93A098) Key: Txn Flags: Notify Txn Commit Time: (1094671237) 2004/09/08 14:20:37 Txn Size in Queue: 6298 First Bufs (0x0D92FFA0) Queue Flags: Resident First Bufs Buffer Flags: TRG, Stream NeedAck: Waiting for Acks from <[0004]> Traverse handle (0x0D045018) for thread CDRNsA3 at txn (0x0D93A098) End_of_Q,Flags: None Traverse handle (0x0D08E018) for thread CDRNsA4 at txn (0x0D93A098) End_of_Q,Flags: None Traverse handle (0x0D523018) for thread CDRNsA5 at txn (0x0D93A098) End_of_Q,Flags: None Traverse handle (0x0D0D9018) for thread CDRNsA6 at txn (0x0D93A098) End_of_Q,Flags: None Traverse handle (0x0D4041D8) for thread CDRNsA2 at Head_of_Q, Flags: None Traverse handle (0x0D3F01D8) for thread CDRNrA2 at Head_of_Q, Flags: None Traverse handle (0x0D045018) for thread CDRNsA3 at txn (0x0D93A098) End_of_Q,Flags: None Traverse handle (0x0D31C018) for thread CDRNrA3 at Head_of_Q, Flags: None Traverse handle (0x0D08E018) for thread CDRNsA4 at txn (0x0D93A098) End_of_Q,Flags: None Traverse handle (0x0D4C8018) for thread CDRNrA4 at Head_of_Q, Flags: None Traverse handle (0x0D523018) for thread CDRNsA5 at txn (0x0D93A098) End_of_Q,Flags: None Traverse handle (0x0D57F018) for thread CDRNrA5 at Head_of_Q, Flags: None Traverse handle (0x0D0D9018) for thread CDRNsA6 at txn (0x0D93A098) End_of_Q,Flags: None Server Group Bytes Queued Acked Sent ---------------------------------------------------------1/9/0x00138ad8/0x00000000 Txn Stamp: 35/0, Reference Count: 0.
C-22
6 5 4 3
0x10009 0x10009 0x10009 0x10009
0 1/9/138ad8/0 0 1/9/138ad8/0 0 1/9/138ad8/0 0 1/9/138ad8/0
1/9/138ad8/0 1/9/138ad8/0 1/9/138ad8/0 1/9/138ad8/0
2 0x10009 - 1//138ad8/0 6 5 4 3 0x10006 0x10006 0x10006 0x10006
4154 efffffff/efffffff/efffffff/efffffff 0 1/9/12d8f8/0 0 1/9/12d8f8/0 0 1/9/12d8f8/0 0 1/9/12d8f8/0 1//12d8f8/0 1//12d8f8/0 1/9/12d8f8/0 1/9/12d8f8/0
2 0x10006 1/9/12d8f8/0
31625 efffffff/efffffff/efffffff/efffffff
C-23
C-24
Appendix D. SMI Table Reference

The system-monitoring interface (SMI) tables in the sysmaster database provide information about the state of the database server. Enterprise Replication uses the SMI tables listed in SMI Table Summary to access information about database servers declared to Enterprise Replication.
SMI Table Summary

Table syscdr_rqm syscdrack_buf syscdrack_txn syscdrctrl_buf syscdrctrl_txn syscdrerror syscdrlatency syscdrpart syscdrprog syscdrq syscdrqueued syscdrrecv_buf syscdrrecv_stats syscdrrecv_txn syscdrrepl syscdrreplset syscdrs syscdrsend_buf syscdrsend_txn syscdrserver syscdrsync_buf syscdrsync_txn
Description Statistics and contents of the low-level queues Buffers for the acknowledge queue Transactions in the acknowledge queue Buffers for the control queue Transactions in the control queue Enterprise Replication error information Statistics about Enterprise Replication latency Participant information Contents of the Enterprise Replication progress tables Queued data information (brief) Queued data information (detailed) Buffers in the receive queue Statistics about the receive manager Transactions in the receive queue Replicate information Replicate set information Server information Buffers in the send queue Transactions in the send queue Database server information Buffers in the synchronization queue Transactions in the synchronization queue
Reference page D-2 page D-3 page D-4 page D-4 page D-4 page D-4 page D-5 page D-6 page D-6 page D-7 page D-8 page D-8 page D-8 page D-8 page D-9 page D-11 page D-11 page D-12 page D-12 page D-12 page D-13 page D-13
D-1
Table syscdrtx
Description Transaction information
Reference page D-14
SMI Tables for Enterprise Replication

The following sections describe the individual tables of the sysmaster database that refer to Enterprise Replication.
syscdr_rqm
The syscdr_rqm table contains statistics and contents of the low-level queues (send queue, receive queue, ack send queue, sync send queue, and control send queue) managed by the Reliable Queue Manager (RQM). The RQM manages the insertion and removal of items to and from the various queues. The RQM also manages spooling of the in-memory portions of the queue to and from disk.
D-2
Column rqm_idx rqm_name rqm_flags rqm_txn rqm_event rqm_txn_in_memory rqm_txn_in_spool_only rqm_txn_spooled rqm_unspooled_bytes rqm_data_in_queue rqm_inuse_mem rqm_pending_buffer rqm_pending_data rqm_maxmemdata rqm_maxmemhdr rqm_totqueued rqm_tottxn rqm_totspooled rqm_totrestored rqm_totrecovered rqm_totspoolread rqm_totdeleted rqm_totduplicated rqm_totlookup
Type integer char(128) integer integer integer integer integer integer int8 int8 int8 integer int8 int8 int8 int8 integer integer integer integer integer integer integer integer
Description Index number Queue name Flags Transactions in queue Events in queue Transaction in memory Spool-only transactions Spooled transactions Unspooled bytes Data in queue Real memory in use Pending buffers Pending buffers Maximum memory in use by data Maximum memory in use by headers Total data queued Total transactions queued Total transactions spooled Total transactions stored Total transactions recovered Total rows read from spool Total transactions deleted Total transactions duplicates Total transaction lookups
syscdrack_buf
The syscdrack_buf table contains information about the buffers that form the acknowledgment queue. When the target database server applies transactions, it sends an acknowledgment to the source database server. When the source database server receives the acknowledgment, it can then delete those transactions from its send queue. For information on the columns of the syscdrack_buf table, refer to Columns of the Buffer Tables on page D-15.
D-3
syscdrack_txn
The syscdrack_txn table contains information about the acknowledgment queue. When the target database server applies transactions, it sends an acknowledgment to the source database server. When the source database server receives the acknowledgment, it can then delete those transactions from its send queue. The acknowledgment queue is an in-memory only queue. That is, it is a volatile queue that is lost if the database server is stopped. For information on the columns of the syscdrack_txn table, refer to Columns of the Transaction Tables on page D-15.
syscdrctrl_buf
The syscdrctrl_buf table contains buffers that provide information about the control queue. The control queue is a stable queue that contains control messages for the replication system. For information on the columns of the syscdrctrl_buf table, refer to Columns of the Buffer Tables on page D-15.
syscdrctrl_txn
The syscdrctrl_txn table contains information about the control queue. The control queue is a stable queue that contains control messages for the replication system. For information on the columns of the syscdrctrl_txn table, refer to Columns of the Transaction Tables on page D-15.
syscdrerror
The syscdrerror table contains information about errors that Enterprise Replication has encountered.
D-4
Column errornum errorserv errorseqnum errortime
Type integer char(128) integer datetime year to second char(128) char(1) text
Description Error number Database server name where error occurred Sequence number that can be used to prune singleerror table Time error occurred
sendserv reviewed errorstmnt
Database server name, if applicable, that initiated error behavior Y if reviewed and set by DBA N if not reviewed Error description
syscdrlatency
The syscdrlatency table contains statistics about Enterprise Replication latency (the time it takes to replicate transactions).
Column source replid txncnt inserts deletes updates last_tgt_apply last_src_apply Type integer integer integer integer integer integer integer integer Description Source of transaction (cdrid) Replicate ID The number of transactions on this source replicate Number of INSERT statements Number of DELETE statements Number of UPDATE statements The time of the last transaction to be applied to the target (cdrtime) The time of the last transaction to be applied on the source (cdrtime)
D-5
syscdrpart
The syscdrspart table contains participant information.
Column replname servername partstate partmode dbsname owner tabname Type lvarchar char(128) char(50) char(1) lvarchar lvarchar lvarchar Description Replicate name Database server name Participant state: ACTIVE, INACTIVE P = primary database server (read-write) R = target database server (receive only) Database name Owner name Table name
syscdrprog
The syscdrprog table lists the contents of the Enterprise Replication progress tables. The progress tables keep track of what data has been sent to which servers and which servers have acknowledged receipt of what data. Enterprise Replication uses the transaction keys and stamps to keep track of this information. The progress table is two dimensional. For each server to which Enterprise Replication sends data, the progress tables keep progress information on a per-replicate basis.
D-6
Column dest_id repl_id source_id key_acked_srv key_acked_lgid key_acked_lgpos key_acked_seq tx_stamp_1
Type integer integer integer integer integer integer integer integer
Description Server ID of the destination server The ID that Enterprise Replication uses to identify the replicate for which this information is valid Server ID of the server from which the data originated Last key for this replicate that was acknowledged by this destination Logical log ID Logical log position Logical log sequence Together with tx_stamp2, forms the stamp of the last transaction acknowledged for this replicate by this destination Together with tx_stamp1, forms the stamp of the last transaction acknowledged for this replicate by this destination
tx_stamp_2
integer
syscdrq
The syscdrq table contains information about Enterprise Replication queues.
Column srvid repid srcid Type integer integer integer Description The identifier number of the database server The identifier number of the replicate The server ID of the source database server In cases where a particular server is forwarding data to another server, srvid is the target and srcid is the source that originated the transaction. The name of the database server Replicate name The name of the source database server Number of bytes queued
srvname replname srcname bytesqueued
char(128) char(128) char(128) integer
D-7
syscdrqueued
The syscdrqueued table contains data-queued information.
Column servername name bytesqueued Type char(128) char(128) decimal(32,0) Description Sending to database server name Replicate name Number of bytes queued for the server servername
syscdrrecv_buf
The syscdrrecv_buf table contains buffers that provide information about the data-receive queue. When a replication server receives replicated data from a source database server, it puts this data on the receive queue for processing. On the target side, Enterprise Replication picks up transactions from this queue and applies them on the target. For information on the columns of the syscdrrecv_buf table, refer to Columns of the Buffer Tables on page D-15.
syscdrrecv_stats
The syscdrrecv_stats table contains statistics about the receive manager. The receive manager is a set of service routines between the receive queues and Datasync.
Column source txncnt pending active maxpending maxactive avg_pending avg_active cmtrate Type integer integer integer integer integer integer float float float Description The source server (cdrid) Number of transactions from this source The transaction currently pending on this source The transaction currently active on this source Maximum pending transactions on this source Maximum active transactions on this source Average pending transactions on this source Average active transactions on this source Average commit rate from this source
syscdrrecv_txn
The syscdrrecv_txn table contains information about the data receive queue. The receive queue is an in-memory queue.
D-8
When a replication server receives replicated data from a source database server, it puts this data on the receive queue, picks up transactions from this queue, and applies them on the target. For information on the columns of the syscdrrecv_txn table, refer to Columns of the Transaction Tables on page D-15.
syscdrrepl
The syscdrrepl table contains replicate information.
D-9
Column replname replstate freqtype
Type lvarchar char(50) char(1)
Description Replicate name Replicate state For possible values, refer to The STATE Column on page A-54. Type C = I = T = M = W = of replication frequency: continuous interval time based day of month day of week
freqmin freqhour freqday scope
smallint smallint smallint char(1)
Minute (after the hour) refresh should occur Null if continuous Hour refresh should occur Null if continuous Day of week or month refresh should occur Replication scope: T = transaction R = row-by-row Y = row spooling is invoked N = no row spooling is invoked Y = transaction spooling is invoked N = no transaction spooling is invoked Type I = T = S = of primary conflict resolution: ignore time stamp SPL routine
invokerowspool invoke transpool primresolution
char(1) char(1) char(1)
secresolution
char(1)
Type of secondary conflict resolution: S = SPL routine Null = not configured Name of SPL routine for secondary conflict resolution Null if not defined. C= converts floating point numbers to canonical format I= converts floating point numbers to IEEE format N = does not convert floating point numbers (sends in native format) Y = triggers are invoked N = triggers are not invoked Y = sends the full row and enables upserts N = sends only changed columns and disables upserts.
storedprocname floattype
lvarchar char(1)
istriggerfire isfullrow
char(1) char(1)
D-10
syscdrreplset
The syscdrreplset table contains replicate set information.
Column replname replsetname Type lvarchar lvarchar Description Replicate name Replicate set name
syscdrs
The syscdrs table contains information about database servers that have been declared to Enterprise Replication.
Column servid servname cnnstate Type integer char(128) char(1) Description Server identifier Database server name Status of connection to this database server: C = Connected D = Connection disconnected (will be retried) T = Idle time-out caused connection to terminate X = Connection closed by user command Connection unavailable until reset by user Time that connection state was last changed Status of database server: A = Active S = Suspended Q = Quiescent (initial sync state only) Y = Server is a hub N = Server is not a hub A hub is any replication server that forwards information to another replication server. Y = Server is a leaf server N = Server is not a leaf server The identifier of the root server The identifier of the parent server Idle timeout
cnnstatechg servstate
integer char(1)
ishub
char(1)
isleaf rootserverid forwardnodeid timeout
char(1) integer integer integer
Although not directly connected, a nonroot server is similar to a root server except it forwards all replicated messages through its parent (root) server. All nonroot servers are known to all root servers and other nonroot servers. A nonroot server can be a terminal point in a tree or it can be the parent for another nonroot server or a leaf server. Nonroot and root servers are aware of all replication servers in the replication environment, including all the leaf servers.
D-11
A leaf server is a nonroot server that has a partial catalog. A leaf server has knowledge only of itself and its parent server. It does not contain information about replicates of which it is not a participant. The leaf server must be a terminal point in a replication hierarchy.
syscdrsend_buf
The syscdrsend_buf table contains buffers that give information about the send queue. When a user performs transactions on the source database server, Enterprise Replication queues the data on the send queue for delivery to the target servers. For information on the columns of the syscdrsend_buf table, refer to Columns of the Buffer Tables on page D-15.
syscdrsend_txn
The syscdrsend_txn table contains information about the send queue. When a user performs transactions on the source database server, Enterprise Replication queues the data on the send queue for delivery to the target servers. For information on the columns of the syscdrsync_txn table, refer to Columns of the Transaction Tables on page D-15.
syscdrserver
The syscdrserver table contains information about database servers declared to Enterprise Replication.
D-12
Column servid servername connstate
Type integer char(128) char(1)
Description Replication server ID Database server group name Status of connection to this database server: C = Connected D = Connection disconnected (will be retried) T = Idle time-out caused connection to terminate X = Connection closed by user command Connection unavailable until reset by user Time that connection state was last changed Status of this database server: A = Active S = Suspended Q = Quiescent (initial sync state only) Y = Server is a hub N = Server is not a hub Y = Server is a leaf server N = Server connection is not a leaf server The identifier of the root server The identifier of the parent server Idle time-out ATS directory spooling name RIS directory spooling name
connstatechange servstate
integer char(50)
ishub isleaf rootserverid forwardnodeid idletimeout atsdir risdir
char(1) char(1) integer integer integer lvarchar lvarchar
syscdrsync_buf
The syscdrsync_buf table contains buffers that give information about the synchronization queue. Enterprise Replication uses this queue only when defining a replication server and synchronizing its global catalog with another replication server. For information on the columns of the syscdrsync_buf table, refer to Columns of the Buffer Tables on page D-15.
syscdrsync_txn
The syscdrsync_txn table contains information about the synchronization queue. This queue is currently used only when defining a replication server and synchronizing its global catalog with another replication server. The synchronization queue is an in-memory-only queue. For information on the columns of the syscdrsync_txn table, refer to Columns of the Transaction Tables on page D-15.
D-13
syscdrtx
The syscdrtx table contains information about Enterprise Replication transactions.
Column srvid srvname txprocssd txcmmtd txabrtd rowscmmtd rowsabrtd txbadcnt Type integer char(128) integer integer integer integer integer integer Description Server ID Name of database server from which data is received Transaction processed from database server srvname Transaction committed from database server srvname Transaction aborted from database server srvname Rows committed from database server srvname Rows aborted from database server srvname Number of transactions with source commit time (on database server srvname) greater than target commit time
Enterprise Replication Queues

One group of sysmaster tables shows information about Enterprise Replication queues. The sysmaster database reports the status of these queues in the tables that have the suffixes _buf and _txn. The name of each table that describes an Enterprise Replication queue is composed of the following three pieces: v syscdr, which indicates that the table describes Enterprise Replication v An abbreviation that indicates which queue the table describes v A suffix, either _buf or _txn, which specifies whether the table includes buffers or transactions Selecting from these tables provides information about the contents of each queue. For example, the following SELECT statement returns a list of all transactions queued on the send queue:
SELECT * FROM syscdrsend_txn
The following example returns a list of all transactions queued on the in-memory send queue and returns the number of buffers and the size of each buffer for each transaction on the send queue:
SELECT cbkeyserverid,cbkeyid,cbkeypos,count(*),sum(cbsize) from syscdrsend_buf group by cbkeyserverid, cbkeyid, cbkeypos order by cbkeyserverid, cbkeyid, cbkeypos
D-14
All queues are present on all the replication servers, regardless of whether the replication server is a source or a target for a particular transaction. Some of the queues are always empty. For instance, the send queue on a target-only server is always empty. Each queue is two-dimensional. Every queue has a list of transaction headers. Each transaction header in turn has a list of buffers that belong to that transaction.
Columns of the Transaction Tables

All the tables whose names end with _txn have the same columns and the same column definitions. The information in the tables represents only transactions in memory and not those spooled to disk. The ctstamp1 and ctstamp2 columns combine to form the primary key for these tables.
Column ctkeyserverid Type integer Description Server ID of the database server where this data originated This server ID is the group ID from the sqlhosts file or the SQLHOSTS registry key. Logical log ID Position in the logical log on the source server for the transaction represented by the buffer Sequence number for the buffer within the transaction Together with ctstamp2, forms an insertion stamp that specifies the order of the transaction in the queue Together with ctstamp1, forms an insertion stamp that specifies the order of the transaction in the queue Time when the transaction represented by this buffer was committed Login ID of the user who committed this transaction Server ID of the server that sent this transaction Used only in hierarchical replication
ctkeyid ctkeypos ctkeysequence ctstamp1
integer integer integer integer
ctstamp2
integer
ctcommittime ctuserid ctfromid
integer integer integer
Columns of the Buffer Tables

The tables whose names end with _buf give information about the buffers that form the transactions listed in the _txn table. All the _buf tables have the same columns and the same column definitions.
D-15
Column cbflags cbsize cbkeyserverid
Type integer integer integer
Description Internal flags for this buffer Size of this buffer in bytes Server ID of the database server where this data originated This server ID is group ID from the sqlhosts file or the SQLHOSTS registry key. Login ID of the user who originated the transaction represented by this buffer Log position on the source server for the transaction represented by this buffer Sequence number for this buffer within the transaction Replicate identifier for the data in this buffer Time when the transaction represented by this buffer was committed
cbkeyid cbkeypos cbkeysequence cbreplid cbcommittime
integer integer integer integer integer
The following columns combine to form the primary key for this table: cbkeyserverid, cbkeyid, cbkeypos, cbkeysequence. The columns cbkeyserverid, cbkeyid, and cbkeypos form a foreign key that points to the transaction in the _txn table that the buffer represents.
D-16
Appendix E. Replication Examples

This appendix contains simple examples of replication using the command-line utility (CLU). Appendix A, Command-Line Utility Reference, on page A-1 documents the CLU.
Replication Example Environment

To run the replication examples in this chapter, you need three Informix database servers. Each database server must be in a database server group. This example uses the following environment: v Three computers (s1, s2, and s3) are hosts for the database servers usa, italy, and japan, respectively. Each computer has active network connections to the other two computers. v The database servers usa, italy, and japan are members of the database server groups g_usa, g_italy, and g_japan, respectively. For information about database server groups, see Setting up Database Server Groups on page 4-4. UNIX Only The UNIX sqlhosts file for each database server contains the following connectivity information.
g_usa usa g_italy italy g_japan japan group ontlitcp group ontlitcp group ontlitcp s1 s2 s3 techpubs1 techpubs2 techpub6 i=1 g=g_usa i=8 g=g_italy i=6 g=g_usa
End of UNIX Only Windows Only See Appendix F, SQLHOSTS Registry Key (Windows), on page F-1 for information on how to prepare the SQLHOSTS connectivity information using
E-1
the information shown in the above UNIX sqlhosts file. End of Windows Only The ONCONFIG file contains the following CDR_QDATA_SBSPACE entry:
CDR_QDATA_SBSPACE sbspace #CDR queue smart blob space
You must create an sbspace for the row data and set the CDR_QDATA_SBSPACE parameter to the location of that sbspace. For more information, see Setting Up Send and Receive Queue Spool Areas on page 4-10 and CDR_QDATA_SBSPACE Configuration Parameter on page B-6. All commands in this example, except for creation of the sample databases on italy and japan, are issued from the computer s1. The databases for the examples in this chapter are identical stores_demo databases with logging, as follows: v Create a database named stores on the usa database server:
s1> dbaccessdemo -log stores
v Create a database named stores on the italy database server:

s1> rlogin s2 s2> dbaccessdemo -log stores
v Create a database named stores on the japan database server:

s1> rlogin s3 s2> dbaccessdemo -log stores
For information on preparing data for replication, see Data Preparation Example on page 4-23.
Primary-Target Example
This section contains a simple example of primary-target replication. In primary-target replication, only changes to the primary table are replicated to the other tables in the replicate. Changes to the secondary tables are not replicated.
Preparing for a Primary-Target Replication

In this example, define the g_usa and g_italy database server groups as Enterprise Replication servers and create a replicate, repl1. To define the database server groups and create the replicate: 1. Create and populate the database that defines the usa database server as a replication server:
cdr define server --init g_usa
E-2
Before replicating data, you must define the database servers as replication servers. A replication server is a database server that has an extra database that holds replication information. The --init option specifies that this server is a new replication server. When you define a replication server, you must use the name of the database server group (g_usa) rather than the database server name. 2. Display the replication server that you defined to verify that the definition succeeded:
cdr list server
The command returns the following information:

SERVER ID STATE STATUS QUEUE CONNECTION CHANGED ---------------------------------------------------------g_usa 1 Active Local 0
3. Define the second database server, italy, as a replication server:

cdr define server --connect=italy --init \ --sync=g_usa g_italy
The --connect option allows you to define italy (on the s2 computer) while working at the s1 (usa) computer. The --sync option instructs the command to use the already-defined replication server (g_usa) as a pattern for the new definition. The --sync option also links the two replication servers into a replication environment. Tip: In all options except the --connect option, Enterprise Replication uses the name of the database server group to which a database server belongs, instead of the name of the database server itself. 4. Verify that the second definition succeeded:
cdr list server

SERVER ID STATE STATUS QUEUE CONNECTION CHANGED
---------------------------------------------------------------------g_italy g_usa 8 1 Active Active Connected Local 0 0 JUN 14 14:38:44 2000
5. Define the replicate repl1:

cdr define replicate --conflict=ignore repl1 \ "P stores@g_usa:informix.manufact" \ "select * from manufact" \ "R stores@g_italy:informix.manufact" \ "select * from manufact"
These lines are all one command. The backslashes (\) at the end of the lines indicate that the command continues on the next line.
E-3
This step specifies that conflicts should be ignored and describes two participants, usa and italy, in the replicate: v The P indicates that in this replicate usa is a primary server. That is, if any data in the selected columns changes, that changed data should be sent to the secondary servers. v The R indicates that in this replicate italy is a secondary server (receive-only). The specified table and columns receive information that is sent from the primary server. Changes to those columns on italy are not replicated. 6. Display the replicate that you defined, so that you can verify that the definition succeeded:
cdr list replicate

CURRENTLY DEFINED REPLICATES -----------------------------------------------REPLICATE: repl1 STATE: Inactive CONFLICT: Ignore FREQUENCY: immediate QUEUE SIZE: 0 PARTICIPANT: g_usa:informix.manufact g_italy:informix.manufact
Step 5 defines a replicate but does not make the replicate active. The output of step 6 shows that the STATE of the replicate is INACTIVE. 7. Make the replicate active:
cdr start replicate repl1
8. Display the replicate so that you can verify that the STATE has changed to ACTIVE:
cdr list replicate

CURRENTLY DEFINED REPLICATES -----------------------------------------------REPLICATE: repl1 STATE: Active CONFLICT: Ignore FREQUENCY: immediate QUEUE SIZE: 0 PARTICIPANT: g_usa:informix.manufact g_italy:informix.manufact
If any changes are made to the manufact table, the changes will be replicated to the other participants in the replicate.
Cause a Replication
Now you can modify the manufact table on the usa database server and see the change reflected in the manufact table on the italy database server.
E-4
To cause a replication: 1. Use DBAccess to insert a value into the manufact table on usa:
INSERT INTO stores@usa:manufact \ VALUES (AWN,Allwyn,8);
2. Observe the changes on usa and on italy:

SELECT * from stores@usa:manufact SELECT * from stores@italy:manufact
To Not Cause a Replication

In repl1, usa is the primary database server and italy is the target. Changes made to the manufact table on italy do not replicate to usa. To not cause a replication: 1. Use DBAccess to insert a value into the manufact table on italy:
INSERT INTO stores@italy:manufact \ VALUES (ZZZ,Zip,9);
2. Verify that the change occurred on italy but did not replicate to the manufact table on usa:
SELECT * from stores@usa:manufact SELECT * from stores@italy:manufact
Update-Anywhere Example
This example builds on the previous example and creates a simple update-anywhere replication. In update-anywhere replication, changes to any table in the replicate are replicated to all other tables in the replicate. In this example, any change to the stock table of the stores database on any database server in the replicate will be replicated to the stock table on the other database servers.
Preparing for an Update-Anywhere Replication

In this example, define the repl2 replicate. To prepare for update-anywhere replication: 1. Define the replicate, repl2:
cdr define replicate --conflict=ignore repl2 \ "stores@g_usa:informix.stock" "select * from stock" \ "stores@g_italy:informix.stock" "select * from stock"
These lines are all one command. The backslashes (\) at the end of the lines indicate that the command continues on the next line. This step specifies that conflicts should be ignored and describes two participants, usa and italy (including the table and the columns to replicate) in the replicate.
E-5
Because neither P (primary) nor R (receive-only) is specified, the replicate is defined as update-anywhere. If any data in the selected columns changes, on either participant, that changed data should be sent to the other participants in the replicate. 2. Display all the replicates so that you can verify that your definition of repl2 succeeded:
cdr list replicate

CURRENTLY DEFINED REPLICATES --------------------------------------------------------REPLICATE: repl1 STATE: Active CONFLICT: Ignore FREQUENCY: immediate QUEUE SIZE: 0 PARTICIPANT: g_usa:informix.manufact g_italy:informix.manufact REPLICATE: STATE: CONFLICT: FREQUENCY: QUEUE SIZE: PARTICIPANT: repl2 Inactive Ignore immediate 0 g_usa:informix.stock g_italy:informix.manufact
Although this output shows that repl2 exists, it does not show the participant modifiers (the SELECT statements) for repl2. 3. Display the participant modifiers for repl2:
cdr list replicate repl2
This command returns the following information:

REPLICATE TABLE SELECT
---------------------------------------------------------------------repl2 repl2 stores@g_usa:informix.stock stores@g_italy:informix.stock select * from stock select * from stock
4. Add the japan database server to the replication system already defined in the previous example:
cdr define server --connect=japan --init \ --sync=g_usa g_japan
You can use either g_usa or g_italy in the --sync option. Enterprise Replication maintains identical information on all servers that participate in the replication system. Therefore, when you add the japan database server, information about that server is propagated to all previously-defined replication servers (usa and italy).
E-6
5. Display the replication servers so that you can verify that the definition succeeded:
cdr list server

---------------------------------------------------------------------g_italy g_japan g_usa 8 6 1 Active Active Active Connected Connected Local 0 0 JUN 14 14:38:44 2000 JUN 14 14:38:44 2000
6. Add the participant and participant modifier to repl2:

cdr change replicate --add repl2 \ "stores@g_japan:informix.stock" "select * from stock"
7. Display detailed information about repl2 after adding the participant in step 6:
cdr list replicate repl2

REPLICATE TABLE SELECT
---------------------------------------------------------------------repl2 repl2 repl2 stores@g_usa:informix.stock stores@g_italy:informix.stock select * from stock select * from stock
stores@g_japan:informix.stock
select * from stock
8. Make the replicate active:

cdr start replicate repl2
Changes made to the stock table on usa are reflected in the stock tables on both italy and japan. 9. Display a list of replicates so that you can verify that the STATE of repl2 has changed to ACTIVE:
cdr list replicate

CURRENTLY DEFINED REPLICATES -----------------------------------------------------REPLICATE: repl1 STATE: Active CONFLICT: Ignore FREQUENCY: immediate QUEUE SIZE: 0 PARTICIPANT: g_usa:informix.manufact
E-7
g_italy:informix.manufact REPLICATE: STATE: CONFLICT: FREQUENCY: QUEUE SIZE: PARTICIPANT: repl2 Active Ignore immediate 0 g_usa:informix.stock g_italy:informix.manufact g_japan:informix.manufact
Cause a Replication
Now you can modify the stock table on one database server and see the change reflected on the other database servers. To cause a replication: 1. Use DBAccess to insert a line into the stock table on usa:
INSERT INTO stores@usa:stock VALUES (401, PRC, ski boots, 200.00, pair, pair);
2. Observe the change on the italy and japan database servers:

SELECT * from stores@italy:stock; SELECT * from stores@japan:stock;
To update the stock table on the japan database server: 1. Use DBAccess to change a value in the stock table on japan:
UPDATE stores@japan:stock SET unit_price = 190.00 WHERE stock_num = 401;
2. Verify that the change has replicated to the stock table on usa and on italy:
SELECT * from stores@usa:stock WHERE stock_num = 401; SELECT * from stores@italy:stock WHERE stock_num = 401;
Hierarchy Example
The example in this section adds a replication tree to the fully-connected environment of the usa, italy, and japan replication servers. The nonroot servers boston and denver are children of usa. (The leaf server miami is a child of boston.) Figure E-1 shows the replication hierarchy.
E-8
italy root japan root usa
root
boston denver nonroot miami leaf nonroot
Figure E-1. Hierarchical Tree Example
Preparing for a Hierarchy Example

To try this example, you need to prepare three additional database servers: boston, denver, and miami. To prepare the database servers, use the techniques described in Replication Example Environment on page E-1.
Defining a Hierarchy
The following example defines a replication hierarchy that includes denver, boston, and miami and, whose root is usa. To define a hierarchy: 1. Add boston to the replication hierarchy as a nonroot server attached to the root server usa:
cdr define server --connect=boston --nonroot --init \ --sync g_usa g_boston
The backslash (\) indicates that the command continues on the next line. 2. Add denver to the replication hierarchy as a nonroot server attached to the root server usa:
cdr define server -c denver -I -N --ats=/ix/myats \ -S g_usa g_denver
This command uses short forms for the connect, init, and sync options. (For information about the short forms, refer to Option Abbreviations on page A-107.) The command also specifies a directory for collecting information about failed replication transactions, /ix/myats. 3. List the replication servers as seen by the usa replication server:
cdr list server
E-9
The root server usa is fully connected to all the other root servers. Therefore usa knows the connection status of all other root servers and of its two child servers, denver and boston. The command returns the following information:
---------------------------------------------------------------------g_boston g_denver g_italy g_japan g_usa 3 27 8 6 1 Active Active Active Active Active Connected Connected Connected Connected Local 0 0 0 0 0 Aug 19 14:20:03 2000 Aug 19 14:20:03 2000 Aug 19 14:20:03 2000 Aug 19 14:20:03 2000
4. List the replication servers as seen by the denver replication server:

cdr list server --connect=denver
The nonroot server denver has a complete global catalog of replication information, so it knows all the other servers in its replication system. However, denver knows the connection status only of itself and its parent, usa. The command returns the following information:
---------------------------------------------------------------------g_boston g_denver g_italy g_japan g_usa 3 27 8 6 1 Active Active Active Active Active Connected Local 0 0 0 0 0 Aug 19 14:20:03 2000
5. Define miami as a leaf server whose parent is boston:

cdr define server -c miami -I --leaf -S g_boston g_miami
6. List the replication servers as seen by miami:

cdr list server -c miami
As a leaf replication server, miami has a limited catalog of replication information. It knows only about itself and its parent.
E-10

---------------------------------------------------------------------g_boston g_miami 3 4 Active Active Connected Local 0 0 Aug19 14:35:17 2000
7. List details about the usa replication server:

cdr list server g_usa
The server is a hub; that is, it forwards replication information to and from other servers. It uses the default values for idle timeout, send queue, receive queue, and ATS directory. The command returns the following information:
NAME ID ATTRIBUTES
---------------------------------------------------------------------g_usa 1 timeout=15 hub sendq=rootdbs recvq=rootdbs atsdir=/tmp
E-11
E-12
Appendix F. SQLHOSTS Registry Key (Windows)

When you install the database server, the setup program creates the following key in the Windows registry:
HKEY_LOCAL_MACHINE\SOFTWARE\INFORMIX\SQLHOSTS
This branch of the HKEY_LOCAL_MACHINE subtree stores the sqlhosts information. Each key on the SQLHOSTS branch is the name of a database server. When you click the database server name, the registry displays the values of the HOST, OPTIONS, PROTOCOL, and SERVICE fields for that particular database server. Each computer that hosts a database server or a client must include the connectivity information either in the sqlhosts registry key or in a central registry. When the client application runs on the same computer as the database server, they share a single sqlhosts registry key.
The Location of the SQLHOSTS Registry Key

When you install the database server on Windows, the installation program asks where you want to store the SQLHOSTS registry key. You can specify one of the following two options: v The local computer where you are installing the database server v Another computer in the network that serves as a central, shared repository of sqlhosts information for multiple database servers in the network
Local SQLHOSTS Registry Key

If you use the SQLHOSTS registry key on the local computer, for all database servers, the correct SQLHOSTS registry key must exist on all computers involved in replication. In addition, the hosts and services files on each computer must include information about all database servers. For example, to set up replication between the server instance srv1 on the computer host1 and the server instance srv2 on host2, you must ensure the following: v Both host1 and host2 include SQLHOSTS registry key entries for srv1 and srv2. v The services file on both computers includes the details of the services used by both database server instances.
F-1
Shared SQLHOSTS Registry Key

If you use a shared SQLHOSTS registry key, you do not need to maintain the same sqlhosts information on multiple computers. However, the hosts and services files on each computer must contain information about all computers that have database servers. If you specify a shared sqlhosts registry key, you must set the environment variable INFORMIXSQLHOSTS on your local computer to the name of the Windows computer that stores the registry. The database server first looks for the sqlhosts registry key on the INFORMIXSQLHOSTS computer. If the database server does not find an sqlhosts registry key on the INFORMIXSQLHOSTS computer, or if INFORMIXSQLHOSTS is not set, the database server looks for an sqlhosts registry key on the local computer. You must comply with Windows network-access conventions and file permissions to ensure that the local computer has access to the shared sqlhosts registry key. For information about network-access conventions and file permissions, see your Windows documentation.
Preparing the SQLHOSTS Connectivity Information

Preparing the SQLHOSTS connectivity information consists of setting up registry keys on each computer that hosts a database server that participates in a replicate. To prepare the SQLHOSTS connectivity information: 1. Set up the SQLHOSTS registry key on the local computer. 2. Set up the database server group registry key on the local computer. See Setting Up the Database Server Group Registry Key on page F-4. 3. Set up the SQLHOSTS and group registry keys on all computers that are participants in the replicate. See Setting up the Registry Keys on All Computers on page F-6. 4. Ensure that the services files on each computer include entries for all database servers that are participants in the replicate. See Verifying the services Files on All Computers on page F-6.
Setting up the SQLHOSTS Registry with ISA

Important: It is strongly recommended that you use IBM Informix Server Administrator (ISA), rather than regedt32, to set up the SQLHOSTS registry key and database server group registry key on your Windows system. In addition, ISA allows you to administer your replication system from a web browser.
F-2
See the online help for ISA for details on setting up the SQLHOSTS registry key and database server group registry key.
Setting up the SQLHOSTS Registry Key with regedt32

It is recommended that you use ISA to set up the SQLHOSTS registry key. Important: Use extreme caution with regedt32. If you make mistakes when editing the registry, you can destroy the configurations, not only of your IBM Informix products, but of your other applications. To set up SQLHOSTS with regedt32: 1. Run the Windows program, regedt32. 2. In the Registry Editor window, select the window for the HKEY_LOCAL_MACHINE subtree. 3. Click the folder icons to select the \SOFTWARE\INFORMIX\ SQLHOSTS branch. 4. With the SQLHOSTS key selected, choose Edit > Add Key. 5. In the Add Key dialog box, type the name of the database server in the Key Name dialog box. Leave the Class dialog box blank. Click OK. 6. Select the new key that you just made (the key with the database server name). 7. Choose Edit > Add Value. 8. In the Add Value dialog box, type one of the fields of the sqlhosts information (HOST, OPTIONS, PROTOCOL, SERVICE) in the Value Name dialog box. Do not change the Data Type box. Click OK. 9. In the String Editor dialog box, type the value for the field that you selected and click OK. 10. Repeat steps 8 and 9 for each field of the sqlhosts information. Figure F-1 illustrates the location and contents of the SQLHOSTS registry key.
F-3
Figure F-1. sqlhosts Information in the Windows Registry
Setting Up the Database Server Group Registry Key

After you create the registry key for the database server, you must make a registry key for the database server group that includes the database server. For more information, refer to Verifying SQLHOSTS on page 4-3. Tip: In this manual (and in Figure F-2 on page F-6), each of the names of the database server groups are the database server names prefixed by g_. The g_ prefix is not a requirement; it is just the convention that this manual uses. To set up the database server group registry key: 1. With the SQLHOSTS key selected, choose Edit > Add Key. 2. In the Add Key dialog box, type the name of the database server group in the Key Name dialog box. This value must correspond to the Options value in the database server name key. Leave the Class dialog box blank. Click OK. 3. Select the new key that you just made (the key with the database server group name). 4. Choose Edit > Add Value.
F-4
5. In the Add Value dialog box, type one of the fields of the sqlhosts information (HOST, OPTIONS, PROTOCOL, SERVICE) in the Value Name dialog box. Do not change the Data Type dialog box. Click OK. 6. In the String Editor dialog box, type the value for the field that you selected and click OK. For a database server group, enter the following values:
HOST OPTIONS PROTOCOL SERVICE i=unique-integer-value group -
Each database server group must have an associated identifier value (i=) that is unique among all database servers in your environment. Enter a minus (-) for HOST and SERVICE to indicate that you are not assigning specific values to those fields. 7. With the database server group key selected, choose Edit > Add Key. 8. In the Add Key dialog box, type the name of the database server in the Key Name field. This value must correspond to the database server key, whose OPTIONS value was set to the database server group key selected in step 7. If you are combining Enterprise Replication with HDR, create keys for primary and secondary HDR servers under the same database server group. 9. Repeat steps 1 to 8 for each field of the sqlhosts information. Figure F-2 illustrates the contents of the database server group registry key after you add the values to the keys.
F-5
Figure F-2. Database Server Group Information in the Windows Registry
10. Exit from the Registry Editor.
Setting up the Registry Keys on All Computers

Now, update the registry keys on all computers that participate in replication. To update the registry keys on all computers: 1. Set up the SQLHOSTS registry key on all computers that participate in replication. See Setting up the SQLHOSTS Registry Key with regedt32 on page F-3. 2. Set up the database server group registry key on all computers that participate in replication. See Setting Up the Database Server Group Registry Key on page F-4.
Verifying the services Files on All Computers

Finally, on each computer that participates in replication, make sure that the services file (located in the C:\Windows/system32/drivers/etc/ directory) contains entries for all the database servers. To verify the services files on all computers: 1. Check the services file on the first host (for example, host1). The file might look like this:
F-6
techpubs27 techpubs28
4599/tcp 4600/tcp
# service for online instance denver # service for online instance boston
2. Check the services file on the second host (for example, host2). The file might should look the same as the file on host1:
techpubs27 techpubs28 4599/tcp 4600/tcp # service for online instance denver # service for online instance boston
F-7
F-8
Appendix G. Datasync Warning and Error Messages

This appendix lists Datasync warning and error messages that you can suppress from being written to the ATS and RIS files. To specify which warnings and errors to suppress, use the CDR_SUPPRESS_ATSRISWARN configuration parameter. For more information, see CDR_SUPPRESS_ATSRISWARN Configuration Parameter on page B-8.
Warning or Error Code DSROWCOMMITTED DSEROW DSEReplInsertOrder Number 0 1 2 Warning: Insert exception, row already exists in target table, converted to update Warning: Update exception, row does not exist in target table, converted to insert Warning: Delete exception, row does not exist in target table, saved in delete table Error: Insert aborted, row already exists in target table Error: Update aborted, row does not exist in target table Error: Delete aborted, row does not exist in target table Error: Length of replicated row is greater than row size in target table Error: Unknown db operation Error: Missing cdrserver and/or cdrtime columns in target table Error: Unknown conflict resolution rule defined Error: Failed conflict resolution rule Error: Global catalog cannot translate replicate server id to name Error: Unable to remap columns selected for replication Description
DSEReplUpdateOrder
DSEReplDeleteOrder
DSEReplInsert DSEReplUpdate DSEReplDelete DSERowLength DSEDbopType DSENoServerTimeCol DSEConflictRule DSELostConflictRes DSENoServerName DSEColMap
5 6 7 8 9 10 13 14 15 16
G-1
Warning or Error Code DSEColUncomp DSESPRetTypeOp DSESPAbortRow DSESPSelCols
Number 17 18 19 20
Description Error: Invalid char/length in VARCHAR column Error: Invalid data type or unknown operation returned by stored procedure Error: Row aborted by stored procedure Error: Number of columns returned by stored procedure not equal to the number of columns in select statement Error: Invalid data type or length for selected columns returned by stored procedure Error: Error returned by users stored procedure Error: Internal error (buffer too small for stored procedure arguments Error: No matching key delete row for key insert Error: SQL error encountered Error: ISAM error encountered Warning: Local delete row has been reinserted on local server Warning: Unable to determine if the local delete row should be updated to the delete table Warning: Row already exists in delete table for the given local delete row Warning: Row failed conflict resolution rule but one or more blob columns were accepted Warning: One or more blob columns were set to NULL because data could not be sent Warning: One or more blob columns were not changed because data could not be sent Error: Invalid user action defined for blob columns Error: Row aborted by users stored procedure due to unsent blobs
DSESPColTypeLen
21
DSESPError DSESPInternal DSENoMatchKeyInsert DSESql DSEIsam DSELocalDReExist DSELocalDOddState
22 23 24 25 26 27 28
DSELocalDInDelTab DSEBlobOrder
29 30
DSEBlobSetToNull
31
DSEBlobKeepLocal
32
DSEBlobInvalidFlag DSEBlobAbortRow
33 34
G-2
Warning or Error Code DSESPBlobRetOp DSEReplDel DSENoUDTHeader DSENoUDTTrailer DSEStreamHandle DSEAttachUDREnv DSECdrreceiveSetup DSECdrreceiveCall DSECdrreceiveRetCode DSECdrreceiveRetGarbage DSEStream DSEStreamAborted DSEValStore DSECdrreceiveRetType DSEStreamOptType DSEStreamOptLen DSEStreamOptBitmap DSEUnStreamColl DSEUnStreamRowType DSEStreamFormat DSEStack DSEInternal DSESmartBlobCreate DSESmartBlobWrite DSEStreamColConv
Number 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59
Description Error: Invalid action returned by users stored procedure on blob columns
cdrreceive returned error cdrreceive returned garbage Error reading from stream Stream aborted by sender
cdrreceive returned wrong type Unrecognized stream option Stream option has bad length Error in changed col bitmap Error while unstreaming collection Eerror while unstreaming rowtype Unexpected or invalid data in stream Out of stack space Generic internal problem Error creating sblob Error writing sblob Error converting column data from the master dictionary formatsto the local dictionary format
Appendix G. Datasync Warning and Error Messages
G-3
G-4
Appendix H. Synchronization Failures Table

The name of the synchronization failures table is cdr_viotab_viotabid, where viotabid is the ID number of the table. To find the failures table that corresponds to a user table, query the cdrviotabdef table in syscdr to find the value of viotabid for the table in which you are interested. The cdrviotabdef table has the following columns:
Column Name tabname owner viotabid dbname Data Type CHAR(256) CHAR(64) SERIAL CHAR(256) Description Replicate table name Replicate table owner Unique ID number Database name
To determine the name of the synchronization failures table for a specific repair job, use the cdr list repair command. For more information, see cdr list repair on page A-46. Synchronization failures tables reside in the user databases in the target server of the repair job. These tables are not automatically tidied up; when you no longer need these tables, you need to delete them. The format of the synchronization failures tables is:
Column Name replop srcservid srccommtime dserror Data Type INTEGER INTEGER INTEGER INTEGER Description The replication operation The ID of the server from where the transaction came The time that the transaction committed on the source server The datasync error. See Appendix G, Datasync Warning and Error Messages for more information. The error number of the SQL error that caused the repair operation to fail. You can use finderr to obtain more information about this error. You can use finderr to obtain more information about this error. Has the same name as the first primary key column in the target table
sqlerror
INTEGER
isamerror pk_col_1
INTEGER pk_col_1_type
H-1
Column Name ... pk_col_n
Data Type
Description
pk_col_n_type
Has the same name as the nth primary key column in the target table
The synchronization failures table includes the SQL error that caused the repair operation to fail. Use this error to determine what corrective action needs to be taken. Any rows that fail to be repaired for any reason are written to the synchronization failures table. Often, rows are written to the synchronization failures table under the following circumstances: v Missing parent rows Child rows for which a parent row cannot be found are written to the synchronization failures table. To minimize these errors, repair tables that have referential integrity constraints set up between them as a group, by defining the repair job for a replicate set. Enterprise Replication first synchronizes the parent tables, then the dependent child tables. v Check constraint violations Enterprise Replication compares the check constraints for replicated columns on the source with those on the target server. Any rows that violate a constraint when the source and target server constraints do not match are written to the synchronization failures table.
H-2
Appendix I. Accessibility
The syntax diagrams in the HTML version of this manual are available in dotted decimal syntax format, which is an accessible format that is available only if you are using a screen reader.
Dotted Decimal Syntax Diagrams

In dotted decimal format, each syntax element is written on a separate line. If two or more syntax elements are always present together (or always absent together), the elements can appear on the same line, because they can be considered as a single compound syntax element. Each line starts with a dotted decimal number; for example, 3 or 3.1 or 3.1.1. To hear these numbers correctly, make sure that your screen reader is set to read punctuation. All syntax elements that have the same dotted decimal number (for example, all syntax elements that have the number 3.1) are mutually exclusive alternatives. If you hear the lines 3.1 USERID and 3.1 SYSTEMID, your syntax can include either USERID or SYSTEMID, but not both. The dotted decimal numbering level denotes the level of nesting. For example, if a syntax element with dotted decimal number 3 is followed by a series of syntax elements with dotted decimal number 3.1, all the syntax elements numbered 3.1 are subordinate to the syntax element numbered 3. Certain words and symbols are used next to the dotted decimal numbers to add information about the syntax elements. Occasionally, these words and symbols might occur at the beginning of the element itself. For ease of identification, if the word or symbol is a part of the syntax element, the word or symbol is preceded by the backslash (\) character. The * symbol can be used next to a dotted decimal number to indicate that the syntax element repeats. For example, syntax element *FILE with dotted decimal number 3 is read as 3 \* FILE. Format 3* FILE indicates that syntax element FILE repeats. Format 3* \* FILE indicates that syntax element * FILE repeats. Characters such as commas, which are used to separate a string of syntax elements, are shown in the syntax just before the items they separate. These characters can appear on the same line as each item, or on a separate line with the same dotted decimal number as the relevant items. The line can also show another symbol that provides information about the syntax elements. For example, the lines 5.1*, 5.1 LASTRUN, and 5.1 DELETE mean that if you use more than one of the LASTRUN and DELETE syntax elements, the elements
I-1
must be separated by a comma. If no separator is given, assume that you use a blank to separate each syntax element. If a syntax element is preceded by the % symbol, this identifies a reference that is defined elsewhere. The string following the % symbol is the name of a syntax fragment rather than a literal. For example, the line 2.1 %OP1 means that you should refer to a separate syntax fragment OP1. The following words and symbols are used next to the dotted decimal numbers: ? Specifies an optional syntax element. A dotted decimal number followed by the ? symbol indicates that all the syntax elements with a corresponding dotted decimal number, and any subordinate syntax elements, are optional. If there is only one syntax element with a dotted decimal number, the ? symbol is displayed on the same line as the syntax element (for example, 5? NOTIFY). If there is more than one syntax element with a dotted decimal number, the ? symbol is displayed on a line by itself, followed by the syntax elements that are optional. For example, if you hear the lines 5 ?, 5 NOTIFY, and 5 UPDATE, you know that syntax elements NOTIFY and UPDATE are optional; that is, you can choose one or none of them. The ? symbol is equivalent to a bypass line in a railroad diagram. Specifies a default syntax element. A dotted decimal number followed by the ! symbol and a syntax element indicates that the syntax element is the default option for all syntax elements that share the same dotted decimal number. Only one of the syntax elements that share the same dotted decimal number can specify a ! symbol. For example, if you hear the lines 2? FILE, 2.1! (KEEP), and 2.1 (DELETE), you know that (KEEP) is the default option for the FILE keyword. In this example, if you include the FILE keyword but do not specify an option, default option KEEP is applied. A default option also applies to the next higher dotted decimal number. In this example, if the FILE keyword is omitted, default FILE(KEEP) is used. However, if you hear the lines 2? FILE, 2.1, 2.1.1! (KEEP), and 2.1.1 (DELETE), the default option KEEP only applies to the next higher dotted decimal number, 2.1 (which does not have an associated keyword), and does not apply to 2? FILE. Nothing is used if the keyword FILE is omitted. Specifies a syntax element that can be repeated zero or more times. A dotted decimal number followed by the * symbol indicates that this syntax element can be used zero or more times; that is, it is optional and can be repeated. For example, if you hear the line 5.1* data-area, you know that you can include more than one data area or
I-2
you can include none. If you hear the lines 3*, 3 HOST, and 3 STATE, you know that you can include HOST, STATE, both together, or nothing. Notes: 1. If a dotted decimal number has an asterisk (*) next to it and there is only one item with that dotted decimal number, you can repeat that same item more than once. 2. If a dotted decimal number has an asterisk next to it and several items have that dotted decimal number, you can use more than one item from the list, but you cannot use the items more than once each. In the previous example, you could write HOST STATE, but you could not write HOST HOST. 3. The * symbol is equivalent to a loop-back line in a railroad syntax diagram. + Specifies a syntax element that must be included one or more times. A dotted decimal number followed by the + symbol indicates that this syntax element must be included one or more times. For example, if you hear the line 6.1+ data-area, you must include at least one data area. If you hear the lines 2+, 2 HOST, and 2 STATE, you know that you must include HOST, STATE, or both. As for the * symbol, you can only repeat a particular item if it is the only item with that dotted decimal number. The + symbol, like the * symbol, is equivalent to a loop-back line in a railroad syntax diagram.
Appendix I. Accessibility
I-3
I-4
Notices
IBM may not offer the products, services, or features discussed in this document in all countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the users responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A. For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to: IBM World Trade Asia Corporation Licensing 2-31 Roppongi 3-chome, Minato-ku Tokyo 106-0032, Japan The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make
J-1
improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact: IBM Corporation J46A/G4 555 Bailey Avenue San Jose, CA 95141-1003 U.S.A. Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee. The licensed program described in this information and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement, or any equivalent agreement between us. Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurements may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.
J-2
All statements regarding IBMs future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only. All IBM prices shown are IBMs suggested retail prices, are current and are subject to change without notice. Dealer prices may vary. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBMs application programming interfaces. Each copy or any portion of these sample programs or any derivative work, must include a copyright notice as follows: (your company name) (year). Portions of this code are derived from IBM Corp. Sample Programs. Copyright IBM Corp. (enter the year or years). All rights reserved. If you are viewing this information softcopy, the photographs and color illustrations may not appear.
Notices
J-3
Trademarks
AIX; DB2; DB2 Universal Database; Distributed Relational Database Architecture; NUMA-Q; OS/2, OS/390, and OS/400; IBM Informix; C-ISAM; Foundation.2000; IBM Informix 4GL; IBM InformixDataBladeModule; Client SDK; Cloudscape; Cloudsync; IBM InformixConnect; IBM InformixDriver for JDBC; Dynamic Connect; IBM InformixDynamic Scalable Architecture(DSA); IBM InformixDynamic Server; IBM InformixEnterprise Gateway Manager (Enterprise Gateway Manager); IBM InformixExtended Parallel Server; i.Financial Services; J/Foundation; MaxConnect; Object Translator; Red Brick; IBM Informix SE; IBM Informix SQL; InformiXML; RedBack; SystemBuilder; U2; UniData; UniVerse; wintegrateare trademarks or registered trademarks of International Business Machines Corporation. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. Windows, Windows NT, and Excel are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. UNIX is a registered trademark in the United States and other countries licensed exclusively through X/Open Company Limited. Other company, product, and service names used in this publication may be trademarks or service marks of others.
J-4
Index
Special characters
--add option cdr change replicate 7-6, A-3, A-5 cdr change replicateset 7-10, A-7 --all option cdr define template A-30 cdr error A-43 --applyasowner option 6-17, A-69 --at option 6-10, A-114 time formats A-114 --ats option 6-4, 6-10, 8-2, A-19 cdr define server A-27 cdr modify replicate A-62 cdr modify server A-67 --autocreate option cdr define replicate A-17 cdr realize template 6-17, A-69 --conflict option 6-9, A-18 --connect option and database server name 6-3 connecting to another replication server --database option cdr define template A-30 --dbspace option 6-17, A-69 --delete option 7-6, 7-10 cdr change replicate A-3, A-5 cdr change replicateset A-7 --empty option 6-7, A-17 --every option 6-10, A-114 --exclusive option 6-13, A-23 cdr define template A-30 --extratargetrows option 6-15 cdr realize template A-70 --file option 6-16 cdr define template A-30 --filter option 7-15 --firetrigger option 6-12, A-20 modifying replicates A-62 --floatcanon option 6-12, A-20 --follow option, cdr error A-43 --fullrow option 6-11, A-20 modifying replicates A-62 --idle option cdr define server 6-3, A-27 cdr modify server A-66 --immed option 6-10, A-114 --init option 6-3, A-25 --leaf option 6-4, A-25 --master option 6-6, A-17 Copyright IBM Corp. 1996, 2004 --master option (continued) cdr define template A-31 --mirrors option 6-8, A-21 --name option 6-7, 7-19, A-17 --nonroot option 6-4, A-25 --optimize option 6-9, A-18 --primaryid option A-104 --primaryname option A-104 --ris option 6-4, 6-10, 8-6, A-20 cdr define server A-27 cdr modify replicate A-62 cdr modify server A-67 --shadowid option A-104 --shadowname option A-104 --sync option 6-3, A-26 --syncdatasource option 6-15, 6-17 cdr realize template A-70 --target option 6-18 cdr realize template A-70 --verify option cdr realize template 6-17, A-17, A-70 -e option cdr start replicate 4-24, 6-15 -f option 7-15 -S option cdr start replicate 4-24, 6-15 /etc/hosts file 4-2 /etc/hosts.equiv file 4-3 /etc/services file 4-3 .rhosts file 4-3 $INFORMIXDIR/bin directory xi $INFORMIXDIR/gls/cv9 directory 2-14 $INFORMIXDIR/incl/esql/cdrerr.h file A-45 \etc\hosts file 4-2 \etc\hosts.equiv file 4-3 \etc\services file 4-3
7-3
A
Abbreviations cdr define replicate set A-107 commands A-107 options A-107 Aborted rows, and ATS files 8-2 Aborted Transaction Spooling. See ATS. Accessibility xxiii dotted decimal format of syntax diagrams I-1 syntax diagrams, reading in a screen reader I-1 Activating ATS A-19, A-27
X-1
Activating (continued) RIS A-20, A-27 triggers A-20 Active state defined 7-7 replicates A-49 server A-54 ADD CRCOLS defining shadow columns 4-20 Adding chunks to storage spaces 8-11 columns 7-18 participants to replicates 4-23, 7-6, A-5 replicates to replicate sets 7-10, A-7 rowids 2-12 Administering Enterprise Replication CLU 1-6 ISA 1-6 overview 2-2 Alarms event 8-13 ALTER FRAGMENT statement 7-18 Alter mode 7-17 ALTER TABLE statement See also IBM Informix Guide to SQL ADD and DROP CRCOLS 4-21 in-place alters 4-21 restrictions 7-18 Altering replicated columns 7-20 replicated tables 7-17 Always-apply conflict-resolution rule 3-8, 3-13 Application specific routines 3-12 Applying data, process 1-14 Argument SPL routine 3-11 Asynchronous data replication 1-2 propagation, considerations 2-6 ATS activating A-19, A-27 capacity planning 4-15 filenames, description 8-3 files BLOB and CLOB information 8-5 BYTE and TEXT data 8-4 changed column information 8-5 configuring 6-10 defined 8-2 naming conventions 8-3 preparing to use 8-2 repair using 7-14, 7-15 smart large objects 8-5 UDT information 8-5
ATS (continued) files (continued) UDTs 8-5 modifying directory 7-2 specifying directory 6-4, A-26, A-66, A-76 Attaching fragments 7-18 Attribute replicate, changing 7-6 viewing 7-3 Automatic remastering 7-19 Automatic table creation 6-7, 6-17 Average large object size. See AVG_LO_SIZE configuration parameter. AVG_LO_SIZE configuration parameter 4-12
B
Backup databases, considerations 2-7 Batch jobs 2-12 BEGIN WORK WITHOUT REPLICATION behavior 4-18 DB-Access 4-19 ESQL/C 4-19 example 4-23 running batch jobs 2-12 Bitmap information in logical log files 6-12 BLOB data type information ATS files 8-5 RIS files 8-8 spooled row data 4-11 Blobs. See Simple large object. Blobspace inconsistent replicated data 2-16 replicating 2-15 storing simple large objects 2-15 Blocking replication 4-18 Boldface type xiv Buffers tables, columns D-15 transaction, spooling to disk 4-10, 8-8 Business models, primary-target systems 3-2 BYTE data ATS files 8-4 distributing 2-18 loading with deluxe mode 4-22 RIS files 8-7 SPL conflict resolution 2-17 storing in tblspaces 2-16
C
Canonical format 6-12, A-20
X-2
Capacity planning for delete tables 4-9 primary-target 3-5 spooling directories 4-15 update-anywhere 3-7 Capture mechanisms log-based data capture 1-3 trigger-based data capture 1-3 trigger-based transaction capture 1-3 Cascading deletes considerations 2-9 cdr alter 7-18, A-3 cdr change replicate adding and deleting participants 7-6 examples A-6 syntax A-5 cdr change replicateset adding 7-10 adding or deleting replicates A-7 examples A-8 cdr change replset. See cdr change replicateset. cdr cleanstart A-9 cdr connect server 7-14, A-10 cdr define repair 7-14 options A-12 syntax A-11 cdr define replicate 6-6, 7-19 defining participants 6-5 examples A-15, A-21 options A-69 cdr define replicateset abbreviation A-107 creating replicate sets 6-13 examples A-23, A-24 cdr define replset. See cdr define replicateset. cdr define server defining replication servers 6-3 examples A-25, A-27 options A-26, A-27 cdr define template 1-6, 6-16, A-29 cdr delete repair 7-15, A-33 cdr delete replicate deleting a replicate from the global catalog 7-9 examples A-34 cdr delete replicateset deleting a replicate set 7-12 examples A-36 cdr delete replset. See cdr delete replicateset. cdr delete server deleting a replication server 7-5 examples A-38, A-39, A-40 cdr delete template 1-6, 6-16, 6-17, 6-18, 7-13, A-41
cdr disconnect server dropping Enterprise Replication network connection 7-13 examples A-42 cdr error --nomark option A-43 --prune option A-44 --seq option A-44 --zap option A-44 examples A-44 options A-43 cdr finderr A-45, A-113 cdr list repair 7-15, A-46 cdr list replicate 7-19 brief A-49 examples A-48, A-49 viewing properties of replicate 7-7 cdr list replicateset examples A-52 syntax A-52 viewing properties of replicate set 7-11 cdr list replset. See cdr list replicateset. cdr list server CONNECTION CHANGED column A-55 description of output A-54 determining current state of server 7-2 examples A-54, A-55 QUEUE column A-55 STATE column A-54 STATUS column A-55 syntax A-54 viewing network connection status 7-13 cdr list server output QUEUE column A-55 cdr list template 1-6, 6-16, 7-13, A-57 cdr modify replicate changing attributes of a replicate 7-6 examples A-62 options A-61 restrictions A-61 syntax A-60 cdr modify replicateset changing replication frequency 7-11 examples A-64 syntax A-64 cdr modify replset. See cdr modify replicateset. cdr modify server --mode option A-67 changing attributes of server 7-2 examples A-67 options A-66 syntax A-66 cdr realize template 1-6, 6-16, 6-17, A-68
Index
X-3
CDR record type 6-12 cdr remaster 7-18, A-73 cdr remove A-75 cdr repair 7-15, A-76 cdr resume replicate examples A-77 resuming a suspended replicate to active 7-9 syntax A-77 cdr resume replicateset 7-12, A-79 cdr resume replset. See cdr resume replicateset. cdr resume server 7-4, A-81 cdr start examples A-83 repair A-84 restarting on a stopped server 7-4 syntax A-83 cdr start repair 7-14 cdr start replicate 4-23, 6-15 changing replicate state to active 7-7 examples A-87 syntax A-86 cdr start replicateset 6-15 changing state of all replicates in a replicate set to active 7-11 examples A-90 syntax A-89 cdr start replset. See cdr start replicateset. cdr stop examples A-92 stopping capture of data 7-3 syntax A-92 cdr stop repair 7-15, A-93 cdr stop replicate examples A-95 stopping a replicate 7-8 syntax A-94 cdr stop replicateset examples A-96 stopping replicates in a replicate set 7-11 syntax A-96 cdr stop replset. See cdr stop replicateset. cdr suspend replicate examples A-98 halting processing for a replicate 7-8 syntax A-98 cdr suspend replicateset examples A-100 suspending replicates in a replicate set 7-12 syntax A-100 cdr suspend replset. See cdr suspend replicateset.
cdr suspend server examples A-81, A-103 suspending replication of data to the server 7-4 syntax A-102 cdr swap shadow 6-8, 7-19, A-104 CDR_DBSPACE configuration parameter 4-16, B-2 CDR_DSLOCKWAIT configuration parameter B-2 CDR_ENV configuration parameter B-2 CDR_EVALTHREADS configuration parameter B-3, B-4 CDR_LOGDELTA environment variable B-13 CDR_MAX_DYNAMIC_LOGS configuration parameter 8-10, B-4 CDR_NIFCOMPRESS configuration parameter B-5 CDR_PERFLOG environment variable B-13 CDR_QDATA_SBSPACE configuration parameter 4-11, 4-13, 4-17, B-6 CDR_QHDR_DBSPACE configuration parameter 4-11, 4-16, B-7 CDR_QUEUEMEM configuration parameter 4-10, 4-16, B-7 CDR_RMSCALEFACT environment variable B-13 CDR_ROUTER environment variable B-14 CDR_SBSPACE configuration parameter 6-3 CDR_SERIAL configuration parameter 4-17, B-8 CDR_SUPPRESS_ATSRISWARN configuration parameter B-9 cdr_viotab_viotabid table H-1 cdrerr.h file A-45 cdrserver shadow column See also Shadow columns. behavior with BEGIN WORK WITHOUT REPLICATION 4-18 cdrserver 2-8, 2-16 CDRSITES_731 environment variable B-14 CDRSITES_92X environment variable B-15 cdrtime shadow column See also Shadow columns. behavior with BEGIN WORK WITHOUT REPLICATION 4-18 defined 4-9 defining 2-8 Enterprise Replication recording value of 2-16 cdrviotabdef table H-1 Central registry SQLHOSTS F-1 Changing column information in ATS files 8-5 in RIS files 8-8 columns, replicating 6-11 database triggers 7-6 participant mode A-61 replicate attributes 7-6 replicate set state A-79
X-4
Child database server 3-16 Choosing a replication network topology Chunk adding to storage spaces 8-11 Cipher encryption B-10 CLOB type ATS files 8-5 RIS files 8-8 spooled row data 4-11 Clock synchronization 2-13, 8-12 CLU. See Command-line utility. Code, sample, conventions for xix Codeset conversion files 2-14 Collision defined 1-15 example 1-15 Columns adding to replicated tables 7-18 altering size 7-20 altering type 7-20 dropping replicated columns 7-19 in transaction tables D-15 primary key 6-11 replicating changed only 6-11 shadow See Shadow columns. virtual 2-20 Command abbreviations A-107 cdr alter A-3 cdr change replicate 7-6, A-5 cdr change replicateset 7-10, A-7 cdr cleanstart A-9 cdr connect server 7-14, A-10 cdr define repair A-11 cdr define replicate 6-5, A-15 cdr define replicateset 6-13, A-23 cdr define replset. See cdr define replicateset. cdr define server 6-3, A-25 cdr define template A-29 cdr delete repair A-33 cdr delete replicate 7-9, A-34 cdr delete replicateset 7-12, A-36 cdr delete replset See cdr delete replicateset. cdr delete server 7-5, A-38 cdr delete template A-41 cdr disconnect server 7-13, A-42 cdr error A-43 cdr finderr A-45, A-113 cdr list repair A-46
3-14
Command (continued) cdr list replicate 7-7, A-48 cdr list replicateset 7-11, A-52 cdr list replset. See cdr list replicateset. cdr list server 7-2, 7-13, A-54 cdr list template A-57 cdr modify replicate 7-6, A-60 cdr modify replicateset 7-11, A-64 cdr modify replset. See cdr modify replicateset. cdr modify server 7-2, A-66 cdr realize template A-68 cdr remaster A-73 cdr remove A-75 cdr repair A-76 cdr resume replicate 7-9, A-77 cdr resume replicateset 7-12, A-79 cdr resume replset. See cdr resume replicateset. cdr resume server 7-4, A-81 cdr start 7-4, A-83 cdr start repair A-84 cdr start replicate 7-7, A-86 cdr start replicateset 7-11, A-89 cdr start replset. See cdr start replicateset. cdr stop 7-3, A-92 cdr stop repair A-93 cdr stop replicate 7-8, A-94 cdr stop replicateset 7-11, A-96 cdr stop replset. See cdr stop replicateset. cdr suspend replicate 7-8, A-98 cdr suspend replicateset 7-12, A-100 cdr suspend replset. See cdr suspend replicateset. cdr suspend server 7-4, A-102 cdr swap shadow A-104 dbaccess 4-7 error return codes A-113 net time 2-14 oninit 6-2 onmode 6-2 onspaces 4-10, 4-12, 8-11 onstat 8-1, 8-11, C-1, C-20 onstat -g ath C-1 onstat -g cat C-2 onstat -g ddr C-4 onstat -g dss C-5 onstat -g dtc C-6 onstat -g grp C-7 onstat -g nif C-14 onstat -g que C-15 onstat -g rcv C-16
Index
X-5
Command (continued) onstat -g rep C-19 onstat -g rqm C-19 ping 4-7 rdate 2-14 starts 6-2 summary A-1 synchronizing clocks 2-14 Command-line conventions how to read xvii sample diagram xvii Command-line utility 1-6 --connect option 6-3 See also Command. administering Enterprise Replication 1-6 commands 1-6 defined A-1 syntax, interpreting A-106 terminology A-106 Communications support module not allowed with ER 4-6 Compliance with industry standards xxvi Configuration problems, solving 8-12, 8-13 Configuration parameter See also Parameters, configuration. CDR_SERIAL 4-17, B-8 DBSERVERALIASES 4-16, B-1 DBSERVERNAME 4-16, B-1 Configuring ATS and RIS files 6-10 logical logs files, for Enterprise Replication 4-8 trusted environment 4-3 CONFLICT field cdr list replicate output A-50 Conflict resolution and table hierarchies 2-20 BYTE data 2-17 cdrserver 2-16 cdrtime 2-16 considerations for SPL routine 3-12 CRCOLS, adding and dropping 2-12 defined 3-7 delete tables 3-10, 4-9 options A-17 preparing tables for 4-20 rules 3-7 always apply 3-13 behavior 3-13 changing 7-6 ignore 3-8, 6-9 replicating only changed columns 6-11 shadow columns 3-8 specifying 6-9
Conflict resolution (continued) rules (continued) SPL routine 3-10, 6-9 time synchronization 3-10 timestamp 3-9, 6-9 valid combinations 3-8 scope changing 7-6 options A-18 row 3-13, 6-9 specifying 6-9 transaction 3-13, 6-9 shadow columns 2-16 simple large objects 2-16 specifying options A-17 SPL 2-17 support for UDRs 3-10 TEXT data 2-17 timestamp 2-13, 2-16 transactional integrity 3-14 triggers 2-10 update-anywhere 3-6 Conflicts, and asynchronous propagation 2-6 Connecting to a database server A-10 CONNECTION CHANGED column, cdr list server output A-55 Connection security option 4-7 Connection status, replication servers A-55 Connections testing network 4-7 Considerations distributed transactions 2-11 large transactions 2-11 memory use C-1 planning to use Enterprise Replication 2-6 primary-target replication systems 3-5 replicating changed columns only 6-11 extensible data types 2-19 replication environment 2-13 volume 2-11 SELECT statement A-113 SPL routines for conflict resolution 3-12 transaction processing 2-11 Consistency ensuring 4-17 Consolidation replication. See Many-to-one replication. Constraints 2-8, 2-10, 3-14, 6-10, 6-15, 7-16, 7-17, H-1 Contact information xxvii Conventions ATS files 8-3 command-line xvii command-line utility A-106
X-6
Conventions (continued) database server groups 4-4 documentation xiii sample-code xix syntax diagrams xv syntax notation xv typographical xiv CRCOLS. See Shadow columns. CREATE TABLE statement 4-21 Creating databases with unbuffered logging 2-7 demonstration databases xi replicate sets 6-13 row data sbspace 4-11, 4-12 Creating templates 1-6, 6-16 Cross-replication, between simple large objects and smart large objects 2-16 Customizing replicate sets 6-14 replicates 6-4 replication server definition 6-3
D
Data applying 1-14 capture types 1-3 distributing 1-14 inconsistent 2-16 integrity 6-7 loading 4-21 maintaining consistency 1-4 preparing 4-17, 4-18 repair 7-14 synchronization 7-14 unloading 4-21 Data delivery resuming A-77, A-79, A-81 suspending for replicate sets A-100 for replicates A-98 for replication servers A-102 Data dissemination model, defined 3-2 Data propagation, considerations for asynchronous 2-6 Data replication asynchronous, defined 1-2 capture mechanisms log-based data capture 1-3 trigger-based data capture 1-3 trigger-based transaction capture 1-3 defined 1-1 synchronous, defined 1-2 Data type built-in 1-5
Data type (continued) extensible 2-19 FLOAT 6-12 floating-point 2-15 SERIAL 2-9 SERIAL and SERIAL8 2-15 SERIAL8 2-9 SMALLFLOAT 6-12 support for 2-19 supported 2-14 user-defined 1-5 user-defined. See User-defined data types. Data-consolidation model, defined 3-2 Database considerations backing up 2-7 restoring 2-7 creating demonstration xi with unbuffered logging 2-7 designing, considerations 2-7 locking 2-12 logging 4-21 triggers, changing 7-6 unbuffered logging 2-7 Database server aliases 4-4, 4-5 connecting to A-10 declaring for Enterprise Replication 6-1 disconnecting from A-42 initializing 6-2 listing A-54 preparing environment 4-16 preparing for HDR 5-5 removing from Enterprise Replication A-38 resuming data delivery A-81 specifying type 6-4 suspending data delivery A-102 Database server groups conventions 4-4 HDR, defining for 5-6 registry key F-4 SQLHOSTS file 2-3, 4-4 UNIX 4-4 usage 4-4, 6-3 Windows 4-5 DataBlade modules preparing for HDR 5-7 Datasync row-specific errors G-1 DB-Access dbaccess command 4-7, 4-19 testing network environment 4-7 utility BEGIN WORK WITHOUT REPLICATION 4-19
Index
X-7
DB-Access (continued) utility (continued) included databases xi dbexport utility 4-22 dbimport utility 4-22 dbname column H-1 DBSERVERALIASES configuration parameter 4-5, 4-16, B-1 DBSERVERNAME configuration parameter 4-5, 4-16, B-1 dbservername, defined 4-5 Dbspace delete table storage 4-9 increasing size 8-11 monitoring disk usage 8-11 pathname limitations 4-11 root 4-10 size of transaction record 4-10 spooled transaction records 4-10 transaction record 4-10 DDRBLOCK mode, preventing 8-9 Deadlock situation, defined 3-8 Decision support systems data consolidation business model 3-3 Declaring database server for Enterprise Replication 6-1 Default behavior of Enterprise Replication 6-11 dbspace for transaction records 4-10 locale x spooling directories 4-15 values 7-17 Defining participants 6-5 replicate sets A-23 replicates 6-4, 6-13, A-15 replication servers 6-1, 6-3, A-25 shadow columns 4-20 Definition Failed state A-49 Delete tables capacity planning 4-9 defined 1-15, 4-9 disk space 4-9 in conflict resolution 3-10, 3-11 storage 4-9 timestamp conflict resolution rule 4-9 Deleted state, server A-55 Deletes, cascading. See Cascading deletes. Deleting columns 7-19 Enterprise Replication objects 2-6 participants from replicates 7-6, A-5 replicate sets 7-12, A-36 replicates from global catalog 7-9, A-34
Deleting (continued) replicates from replicate sets 7-10, A-7 replication servers 7-5, A-38 templates 1-6, 6-16, 6-17, 7-13, A-41 Deluxe mode without replication 4-22 Demonstration databases xi Dependencies, software x Deployment 1-6, 6-16 Designing databases and tables 2-7 Determining size logical log files 4-8 spooled row data sbspace 4-11 transaction record dbspace 4-10 Dictionary information 6-6 Directory INFORMIXDIR/bin xi INFORMIXDIR/gls/cv9 2-14 specifying ATS location 6-4 RIS location 6-4 spooling, planning for capacity 4-15 Disabilities, visual reading syntax diagrams I-1 Disconnect status, replication servers A-55 Disconnecting server connection A-42 Discrepancies, between constraints 2-10, 6-15, 7-16, H-1 Disk preparing for Enterprise Replication 4-7 Disk space requirements delete table 4-9 message queue spooling 4-10 planning 4-8 shadow columns 4-9 Disk usage, monitoring 8-11 Displaying information about replicates A-49 Distributed transactions defined 2-11 two-phase commit 2-11 Distributing BYTE and TEXT data 2-18 data, process for 1-14 Distribution replication. See One-to-many replication. DNS. See Domain Name Service. Documentation conventions xiii Documentation Notes xxi Documentation set of all manuals xxiii Documentation, types of xx machine notes xxi online manuals xxiii printed manuals xxiii
X-8
Domain Name Service 4-2 Dotted decimal format of syntax diagrams I-1 DRINTERVAL configuration parameter 5-10 DROP CRCOLS statement 4-21 DROP TABLE statement 2-12, 7-20 Dropped network connections, reestablishing 7-14 Dropped status, replication servers A-55 Dropping columns 7-19 network connection 7-13 rowids 2-12 shadow columns 4-21 dserror column H-1 DSS. See Decision support systems. Dynamic logs setting CDR_MAX_DYNAMIC_LOGS B-4
E
Easy set up 1-6, 6-16 Empty master replicate 6-7 en_us.8859-1 locale x Enabling triggers 6-12 ENCRYPT_CDR configuration parameter 4-6, 4-17, B-9 ENCRYPT_CIPHER configuration parameter 4-17, B-10 ENCRYPT_MAC configuration parameter 4-17, B-11 ENCRYPT_MACFILE configuration parameter 4-17, B-11 ENCRYPT_SWITCH configuration parameter 4-17, B-12 Encryption cipher renegotiation B-12 combining with client/server in SQLHOSTS 4-6 configuration parameters for 4-17 enabling with ENCRYPT_CDR B-9 HDR, not supported with 5-5 MAC files, specifying B-11 message authentication code generation B-11 overview 1-7 specifying ciphers and modes B-10 English locale 2-14 Enterprise Replication administering 1-6 administration overview 2-2 and cascading deletes 2-9 and triggers 2-10 batch jobs 2-12 consistency 1-4 data types 2-14 database server groups for HDR 5-6 default behavior 6-11 defined 1-1 deleting and recreating objects 2-6
Enterprise Replication (continued) encryption, configuring 4-17 event alarms 8-13 flexible architecture 1-5 high availability 1-3, 1-4 managing 2-2 performance 1-3 process for replicating data 1-7 queues D-14 role of logical log files 2-7 selecting replication systems 3-1 server administrator 2-3 defined 2-3 definitions in global catalog 2-5 starting A-83 stopping A-92 supported database servers 2-6 synonyms 2-6 terminology 2-3 threads list of C-1 restarting 7-4 stopping 7-3 using Global Language Support 2-14 views 2-6 Environment database server, preparing 4-16 network preparing 4-2 testing 4-7 trusted, configuring 4-3 Environment variable CDR_LOGDELTA B-13 CDR_PERFLOG B-13 CDR_RMSCALEFACT B-13 CDR_ROUTER B-14 CDRSITES_731 B-14 CDRSITES_92X B-15 INFORMIXDIR 4-16 INFORMIXSERVER 4-4, 4-16, 6-3, 7-3 INFORMIXSQLHOSTS 4-16, F-2 setting 4-16 TZ A-114 Environment variables xiv Error datasync row-specific G-1 interpreting error numbers A-45 logging changing 7-6 setting up 6-10 message files cdrerr.h A-45 replication server status A-55 return codes A-113
Index
X-9
Error (continued) table managing A-43 Error messages xxii ESQL/C, BEGIN WORK WITHOUT REPLICATION 4-19 Evaluating data for replication 1-8 data, examples of 1-12 rows 1-8, 1-10 Event alarm 8-13 Examples adding replicates to replicate sets 7-10 ATS filenames 8-3 BEGIN WORK WITHOUT REPLICATION 4-19 BYTE and TEXT data in ATS files 8-4, 8-5 in RIS files 8-7, 8-8 cdr change replicate A-6 cdr change replicateset A-8 cdr define replicate A-21 cdr define replicateset A-24 cdr define server A-27 cdr delete replicate A-34 cdr delete replicateset A-36 cdr delete server A-39, A-40 cdr disconnect server A-42 cdr error A-44 cdr list replicate A-48, A-49 cdr list replicate brief A-49 cdr list replicateset A-52 cdr list server A-54, A-55 cdr modify replicate A-62 cdr modify replicateset A-64 cdr modify server A-67 cdr resume replicate A-77 cdr resume replicateset A-79 cdr start A-83 cdr start replicate A-87 cdr start replicateset A-90 cdr stop A-92 cdr stop replicate A-95 cdr stop replicateset A-96 cdr suspend replicate A-98 cdr suspend replicateset A-100 cdr suspend server A-81, A-103 changing frequency for replicate sets 7-11 collision 1-15 connecting to global catalog 7-3 DB-Access 4-19 defining replicate sets 6-14 deleting replicate sets 7-12 replicates 7-9
Examples (continued) deleting (continued) replicates from replicate sets 7-10 replication servers 7-5 evaluating data 1-12 hierarchy E-8 hosts.equiv 4-3 non-exclusive replicate sets 6-14 participant definition 6-6 preparing data for replication 4-23 primary-target E-2 replicate sets A-96, A-100 replication E-1, E-11 replication environment E-1 resuming replicate sets 7-12 replicates 7-9 replication servers 7-5 RIS filenames 8-7 services file 4-3 SQLHOSTS file 4-4 starting replicate sets 7-11 replicates 7-7 stopping replicate sets 7-11 replicates 7-8 suspending replicate sets 7-12 replicates 7-9 replication 7-4 unloading shadow columns 4-22 update-anywhere E-5 updating shadow columns 4-19 using ESQL/C 4-19 Exclusive lock 2-12 Exclusive replicate sets --exclusive option 6-13, A-23, A-30 adding replicates to 7-10 characteristics of 6-13 defined 6-13 managing replicates 7-5 referential constraints 6-10 resuming replicates 7-9 starting replicates 7-8 stopping replicates 7-8 suspending replicates 7-9 Extended data types support for 2-19 Extent size 7-17
F
Fail-safe replication system 3-6 Failed rows, repair jobs 2-10, 6-15, 7-16, H-1
X-10
Failed transactions and RIS files 6-10, 8-6 recorded in ATS files 6-10, 8-2 Failure of replication 1-5, 7-14 Features new xi, xiii File /etc/hosts 4-2 /etc/hosts.equiv 4-3 /etc/services 4-3 .rhosts 4-3 \etc\hosts 4-2 \etc\hosts.equiv 4-3 \etc\services 4-3 cdrerr.h A-45 hosts 4-2 hosts.equiv 4-3 logical-log 4-9 ONCONFIG 2-9, 4-16 services 4-3 SQLHOSTS 4-3, 4-4, 4-16 Fixed and Known Defects File xxi FLOAT data type 6-12 Floating-point data types 2-15 numbers canonical format A-20 IEEE format A-20 values, and canonical message format 6-12 Forbidden SQL statements 2-12 Forest of trees combining with HDR 5-4 defined 3-17 illustrated 3-17 network topology 1-5 Fragments 7-17 attaching 7-18 Frequency attributes description of 6-10 examples A-62 defined A-114 replication, specifying 6-10 FREQUENCY field, cdr list replicate output A-50 Full row replication, changing 7-6 Fully connected topology defined 3-14 support for 1-5 using HDR with 3-15 Functions, writing for UDT replication 2-19
Global catalog (continued) leaf servers 2-5, 4-6 root and nonroot servers 4-6 synchronizing 6-3 Global Language Support defined x locale of date A-115 support of 1-6 using with Enterprise Replication 2-14 GLS. See Global Language Support. Grouper 7-19 Grouper paging file, setting up 4-14 Groups. See Database server groups. Guidelines for configuring logical log files 4-8
H
Hardware platforms dissimilar 6-12 heterogeneous 2-15 HDR. See High-Availability Data Replication. Help xxiii Heterogeneous hardware, replicating on 2-15 Hierarchical routing topologies combing with HDR 5-3 SQLHOSTS 4-6 supported types 3-15 synchronization server 3-16, 6-3 terminology 3-15 Hierarchical tree defined 3-16 network topology 1-5 using HDR with 3-17 Hierarchies replicating table hierarchies 2-20 replication examples E-8 High availability planning primary-target 3-5 using Enterprise Replication for 1-4 High-Availability Data Replication database server groups 4-4 database server groups, defining 5-6 DRINTERVAL setting 5-10 encryption not supported 5-5 forest of trees topology 5-4 hierarchical routing topologies 5-3 loading data 5-8 logging sbspaces for spooled row data 4-13 managing 5-8, 5-10 oninit -D command 5-9 onmode -d standard command 5-8 performance 5-10
G
Global catalog contents of 2-5 defined 2-5
Index
X-11
High-Availability Data Replication (continued) preparing servers 5-5 primary server failure 5-8 primary-target replication systems 5-2 replication system 5-1 secondary server, switching to 5-8 spooled row data sbspace logging 5-8 starting primary without ER or HDR 5-9 UDRs, preparing for 5-7 UDTs, preparing for 5-7 update-anywhere replication 5-3 with fully connected topology 3-15 with hierarchical tree topology 3-17 High-availability replication system 5-1 High-Performance Loader 4-22 HKEY_LOCAL_MACHINE F-1 hostname, in sqlhosts 4-5 Hosts file, preparing 4-2 hosts.equiv file 4-3 HPL. See High-Performance Loader.
Installation Guides xx Installing UDTs 2-19 Instantiating templates 1-6, 6-16, 6-17 Integrity, data 6-7 Interval formats A-115 Invalid sbspace 6-3 IP address specifying in hosts file 4-2 isamerror column H-1 ISO 8859-1 code set x
K
Keys primary and constraints 2-8 and SERIAL data types 2-9 and UDT columns 2-20 removing constraints 2-12 Keywords in syntax diagrams xviii
I
IBM Informix Server Administrator 1-6 setting up SQLHOSTS registry 4-5, F-2 ID column, cdr list server output A-54 Identifier A-109 Idle timeout modifying 7-2 setting 6-3 specifying A-26 IEEE floating point format 6-12, A-20 Ignore conflict-resolution rule 3-7, 3-8, 6-9, A-50 database action 3-8 Immediate frequency A-50 In-place alters ADD and DROP CRCOLS 4-21 Inactive state defined 7-8, A-49 Inconsistent data with blobspaces or sbspaces 2-16 Increasing storage space size 8-11 Indexes reclustering 7-17 Industry standards, compliance with xxvi Information consistency, update-anywhere 3-6 Informix Dynamic Server documentation set xxiii informix user 2-3 Informix-Admin group, Windows 2-3 INFORMIXDIR environment variable 4-16 INFORMIXSERVER environment variable 4-4, 4-16, 6-3, 7-3 INFORMIXSQLHOSTS environment variable 4-16, F-2 Initial synchronization 1-4, 2-10, 6-14, 6-15, H-1 Initializing database server 6-2
L
Large objects replicating only changed columns 6-11 Large transactions grouper paging file 4-14 Large transactions, considerations for Enterprise Replication 2-11 Leaf servers defined 3-16 global catalog 2-5, 4-6 limited catalog 2-5 specifying 6-4 SQLHOSTS information 4-6 Limitations, SPL conflict resolution 3-10 Limited SQL statements 2-12 Listing Enterprise Replication servers A-54 replicate sets A-52 replicates A-48 LOAD statement 4-21, 4-23 Loading data ER servers 4-21 HDR servers 5-8 Local status, replication servers A-55 Locale different 2-14 Enterprise Replication 2-14 specifying nondefault 2-14 Locking 7-17 Locking databases 2-12 Locks, exclusive. See Exclusive lock. Log-based data capture 1-3
X-12
Logging aborted transactions 8-2 databases, preparing 4-21 errors 6-10 unbuffered 2-7, 4-21 LOGGING configuration parameter 4-12 Logging mode, for spooled row data sbspaces 4-13 Logical log files 4-9 and maximum transaction size 4-8 bitmap information about updated columns 6-12 capacity planning 4-8 configuration guidelines 4-8 determining size 4-8 disk space, error 8-13 disk space, requirements 4-8 dynamically adding 8-10 increasing size 8-9 overwriting 8-9 reading of 1-8 role in Enterprise Replication 2-7 size 4-8 switching 4-8 Logical Log Record reduction option, and Enterprise Replication 4-8 Long identifiers A-109 LRD label, RIS files 8-7 LRH label, RIS files 8-7 LRS label, RIS files 8-7 LTXEHWM configuration parameter 4-8 LTXHWM configuration parameter 4-8
Message authentication code files B-11 Message formats canonical 6-12 IEEE 6-12 Message queues CDR_QUEUEMEM configuration parameter 4-10 defined 4-10 planning disk space 4-10 Mode changing participant A-61 mode option, cdr modify server A-67 Modes encryption B-10 Modifying primary-key constraint 2-12 replicate attributes A-60 replicate sets 7-10, 7-11, A-64 replicates 7-6 replication servers 7-2, 7-7, A-66 templates 6-18, 7-13 Monitoring dbspaces, onstat command 8-11 disk usage 8-11 sbspaces 8-11 oncheck command 8-11 onstat command 8-11 Multiple references to a smart large object 2-19 Multiple updates to the same row 1-10
N
net time command, synchronizing clocks 2-14 nettype defined 4-5 Network connections dropping 7-13 encryption, setting up for 4-6 managing 7-13, 7-14 reestablishing 7-14 troubleshooting 8-9 viewing status 7-13 Network environment preparing 4-2 testing 4-7 Network topologies choosing 3-14 forest of trees 1-5 fully connected 1-5 hierarchical tree 1-5 supported types 3-14 New features xi, xiii New table, bringing up-to-date 1-4, 6-14 Non-exclusive replicate sets adding replicates 7-10 characteristics 6-13 defined 6-13
M
Machine notes xxi Machine-independent format 6-12, A-20 Maintaining consistency 1-4 Managing Enterprise Replication, overview 2-2 replicate sets 7-10, 7-12 replicates 7-5, 7-9 in exclusive replicate sets 7-5 replication server network connections 7-13, 7-14 replication servers 7-2, 7-5 templates 7-13 Manual remastering 6-8, 7-19 Manual repair 7-14, 7-16 Many-to-one replication 3-2 Master replicates 6-6, 7-18 defined 2-4 strict 6-8 Maximum transaction size, and logical log files 4-8 Memory queues preventing overflows 8-8 Memory use considerations C-1
Index
X-13
Non-exclusive replicate sets (continued) example 6-14 Nonoptimized SPL routine 3-13 Nonroot servers defined 3-16 global catalog 2-5, 4-6 specifying type 6-4 SQLHOSTS information 4-6
O
OLTP data dissemination business model 3-2 oncheck command, monitoring sbspaces 8-11 ONCONFIG configuration file configuration parameters B-1, B-12 configuring encryption 4-17 setting DBSERVERALIASES 4-5 DBSERVERNAME 4-5 parameters 2-9, 4-16 ONCONFIG configuration parameter See Parameters, configuration. One-to-many replication 3-1 oninit -D command 5-9 oninit command initializing database servers 6-2 Online help xxiii Online manuals xxiii Online notes xx, xxi Online transaction processing. See OLTP. onload utility 4-22 onmode -d standard command 5-8 onmode command 6-2 onspaces command adding chunks 8-11 creating row data sbspace 4-12 transaction record dbspace 4-10 onstat command 8-1, C-1, C-20 onstat utility -g ath command C-1 -g cat command 7-19, C-2 -g ddr command C-4 -g dss command C-5 -g dtc command C-6 -g grp command C-7 -g nif command C-14 -g que command C-15 -g rcv command C-16 -g rep command C-19 -g rqm command C-19 monitoring dbspaces 8-11 sbspaces 8-11
onunload utility 4-21, 4-22 Operating system synchronizing time 2-13, 8-12 Optical devices, not supported 2-15 Optimized SPL routine, defined 3-12 Options --add 7-6, 7-10, A-3, A-5, A-7 --all A-30, A-43 --applyasowner 6-17, A-69 --at 6-10, A-114 --ats 6-4, 6-10, 8-2, A-19, A-27, A-62, A-67 --autocreate 6-17, A-17 --conflict 6-9, A-18 --connect 6-3, 7-3, A-109 --dbspace 6-17, A-69 --delete 7-6, 7-10, A-3, A-5, A-7 --empty 6-7, A-17 --every 6-10, A-114 --exclusive 6-13, A-23, A-30 --extratargetrows 6-15, A-70 --file 6-16, A-30 --firetrigger 6-12, A-20, A-62 --floatcanon 6-12, A-20 --follow A-43 --fullrow 6-11, A-20, A-62 --idle 6-3, A-27, A-66 --immed 6-10, A-114 --init 6-3, A-25 --leaf 6-4, A-25 --master 6-6, A-17 --mirrors 6-8, A-21 --mode A-67 --name 6-7, 7-19, A-17 --nomark A-43 --nonroot 6-4, A-25 --optimize 6-9, A-18 --primaryid A-104 --primaryname A-104 --prune A-44 --ris 6-4, 6-10, 8-6, A-20, A-27, A-62, A-67 --scope 6-9, A-19 --seq A-44 --shadowid A-104 --shadowname A-104 --sync 6-3, A-26 --syncdatasource 6-15, 6-17, A-70 --target 6-18, A-70 --verify 6-17, A-17, A-70 --zap A-44 abbreviations A-107 conflict resolution A-17 frequency A-114 order A-108 participant owner A-111 primary A-112
X-14
Options (continued) read-only A-112 scope A-18 SQLHOSTS defined 4-5 Out-of-row data, sharing during replication 2-19 Overflowing memory queues, preventing 8-8 Overwriting logical log files 8-9 owner column H-1 Owner, table 6-17
P
Parameters, configuration AVG_LO_SIZE 4-12 CDR_DBSPACE 4-16, B-2 CDR_DSLOCKWAIT B-2 CDR_ENV B-2 CDR_EVALTHREADS B-3, B-4 CDR_MAX_DYNAMIC_LOGS B-4 CDR_NIFCOMPRESS B-5 CDR_QDATA_SBSPACE 4-11, 4-13, 4-17, B-6 CDR_QHDR_DBSPACE 4-11, 4-16, B-7 CDR_QUEUEMEM 4-10, 4-16, B-7 CDR_SBSPACE 6-3 CDR_SUPPRESS_ATSRISWARN B-9 configuration B-1, B-12 ENCRYPT_CDR B-9 ENCRYPT_CIPHER B-10 ENCRYPT_MAC B-11 ENCRYPT_MACFILE B-11 ENCRYPT_SWITCH B-12 LOGGING 4-12 LTXEHWM 4-8 LTXHWM 4-8 Parameters, configuration CDR_SUPPRESS_ATSRISWARN B-9 setting in ONCONFIG file 2-9, 4-16 Parent database server 3-16 Parent-child defined 3-16 Participant definition contents 6-5 example 6-6 Participant modifiers defined A-110 restrictions 2-20, A-113 Participant type changing 7-6 default 6-5 Primary 6-5 Target 6-5 Participants adding to replicates 4-23, 7-6 changing mode A-61 defined 2-4, 6-2, A-110
Participants (continued) defining 6-5, A-110 deleting from replicates 7-6 modifier A-112 new 1-4, 6-14 owner option A-111 primary option A-112 read-only option A-112 specifying type A-112 update-anywhere 6-6 Pathname ATS and RIS directories 4-16 dbspaces 4-11 sbspaces 4-12 Pending state, defined A-50 Performance Enterprise Replication 1-3 Permitted SQL statements 2-13 ping command, testing network connection 4-7 Planning considerations 2-6 disk space requirements 4-8 Port numbers services file 4-3 Preparing consistent data 4-18 data for replication defined 4-17 example 4-23 database server environment 4-16 disk Enterprise Replication 4-7 hosts file 4-2 logging databases 4-21 network environment 4-2 services file 4-3 SQLHOSTS connectivity information F-2 tables for conflict resolution 4-20 UDR replication 4-20 UDT replication 4-20 using ATS 8-2 using RIS 8-6 Preventing DDRBLOCK mode 8-9 memory queues from overflowing 8-8 Primary option A-112 participant type 6-5 Primary conflict-resolution rule 3-8 Primary key constraints 2-8 modifying column 2-12 removing constraint 2-12 replicating changed columns 6-11 SERIAL data types 2-9
Index
X-15
Primary key (continued) synchronization failures table H-1 UDT columns 2-20 updates 1-10 Primary-target example E-2 replication systems 3-5 business models 3-2 combining with HDR 5-2 considerations 3-5 defined 3-1 Printed manuals xxiii Problems solving configuration 8-12, 8-13 Procedure conflict-resolution rule A-50 Properties replicate sets 7-11
Q
QUEUE column cdr list server output Queues. See Memory queues. Quiescent state defined A-50 server A-55 A-55
R
RAW table unsupported 2-8 rdate command, synchronizing clocks 2-14 Read-only option A-112 participant type. See Target participant type. Realizing templates 1-6, 6-17, A-68 Receive queues See also Memory queues. defined 1-11, 4-10 Receive-only servers 6-18 Reclustering indexes 7-17 Recording failed transactions, in ATS files 8-2 Recreating Enterprise Replication objects 2-6 replicate sets 7-12 replicates 7-9 replication servers 7-5 Reestablishing network connections 7-14 Referential constraint 6-13 time-based replication 6-10 Referential integrity 2-10, 6-15, 7-16, H-1 replicate sets 6-13 regedt32 program and sqlhosts registry F-3 Registering UDTs 2-19
Release Notes xxi Reliable Queue Manager 4-10 Remastering replicates 7-18 Remastering, manual 6-8 Removing primary key constraint 2-12 RENAME COLUMN statement 7-20 RENAME TABLE statement 2-12, 7-20 Repair jobs 1-5, 2-10, 6-15, 7-14, 7-15, A-33, A-46, H-1 Repairing data 7-14 and log files 7-14 ATS, RIS files 7-14, 7-15 manually 7-14, 7-16 partial row 7-15 Replicate definitions 6-6 Replicate information storage 4-10 Replicate sets adding and deleting replicates 7-10 changing replication frequency 7-11 changing state A-79 creating 6-13 customizing 6-14 defined 2-4 defining A-23 deleting 7-12, A-36 examples A-79, A-90, A-96, A-100 exclusive 6-13 frequency 6-14 listing A-52 managing 7-10, 7-12 modifying 7-10, 7-11, A-64 non-exclusive 6-13 recreating 7-12 referential constraints 6-10 resuming 7-12, A-79 starting 7-11, A-89 stopping 7-11, A-96 supported versions A-23 suspending 7-12, A-100 viewing properties 7-11 Replicates activating ATS A-19 RIS A-20 active state 7-7 adding participants A-5 replicate sets 7-10 CONFLICT field A-50 conflict options A-17 customizing 6-4 defined 2-4, 6-2 defining 6-4, 6-13, A-15
X-16
Replicates (continued) deleting global catalog 7-9, A-34 participants A-5 replicate sets 7-10 displaying information about A-49 FREQUENCY field A-50 inactive state 7-8 listing A-48 managing 7-5, 7-9 modifying 7-6, A-60 recreating 7-9 resuming 7-9, A-77 exclusive replicate sets 7-9 starting 7-7, A-86 exclusive replicate sets 7-8 STATE field A-49 stopping 7-8, A-94 exclusive replicate sets 7-8 suspending 7-8, A-98 exclusive replicate sets 7-9 viewing properties 7-7 Replicating changed columns only 6-11 extensible data types considerations 2-19 floating-point values 6-12 large objects 6-11 multiple references to a smart large object 2-19 simple large objects 2-15, 2-19 smart large objects 2-15, 2-19 table hierarchies 2-20 UDTs 2-19 Replicating data capturing transactions 1-8 evaluating data 1-8 row images 1-8 process 1-7 Replicating only changed columns, advantages 6-11 Replication blocking 4-18 choosing network topology 3-14 environment considerations 2-13 managing 2-2 examples E-1, E-11 frequency changing 7-6, 7-11 replicate sets 6-14 specifying 6-10 models primary-target 1-2 update-anywhere 1-2 order error, defined 1-15
Replication (continued) restarting 7-4 stopping 7-3 suspending 7-4 tree, illustrated 3-17 volume 2-11 Replication failure 1-5, 7-14 Replication servers connecting 7-3 customizing 6-3 defined 2-3, 6-2 defining 6-1, 6-3, A-25 deleting 7-5, A-38 listing A-54 managing 7-2, 7-5 modifying 7-2, 7-7, A-66 recreating 7-5 resuming 7-4 resynchronizing 7-16 state, defined 7-2 suspending A-102 synchronizing 6-3 troubleshooting 8-9 viewing attributes 7-3 Replication systems high-availability 5-1 primary-target 3-1, 3-5 supported by Enterprise Replication 3-1 update-anywhere 3-6 Replication topologies forest of trees 3-17 fully-connected 3-14 hierarchical 3-15 hierarchical tree 3-16 terminology 3-15 replop column H-1 Requirements disk space delete tables 4-9 logical log files 4-8 message queue spooling 4-10 planning 4-8 shadow columns 4-9 Restarting replication 7-4 Restoring databases, considerations 2-7 Restrictions cdr modify replicate A-61 participant modifiers A-113 Resuming data delivery replicate sets A-79 replicates A-77 replication servers A-81 replicate sets 7-12
Index
X-17
Resuming (continued) suspended replicates 7-9 replication servers 7-4 Resynchronizing replication servers 7-16 Return codes defined A-113 RIS files 7-14, 7-15 activating A-20, A-27 BLOB and CLOB information 8-8 BYTE and TEXT data 8-7 capacity planning 4-15 changed column information 8-8 configuring 6-10 defined 8-6 filenames, defined 8-6 modifying directory 7-2 preparing to use 8-6 specifying directory 6-4, A-26, A-66, A-76 UDT information 8-8 root dbspace transaction records 4-10 Root servers defined 3-16 global catalog 2-5, 4-6 SQLHOSTS information 4-6 Routines application-specific 3-12 Row replicating entire 6-11 Row conflict resolution scope 3-9, 3-13, 6-9, 8-2 Row data creating sbspace 4-11 storage 4-10 Row Information Spooling. See RIS. Rowids adding and dropping 2-12 RQM. See Reliable Queue Manager. RRD label, ATS files 8-4 RRH label, ATS files 8-4 RRS label, ATS files 8-4 Rules See also Conflict resolution. conflict resolution 3-7 extensible data types 2-20 simple large objects 2-17 smart large objects 2-18 time-stamp 3-10
S
Sample-code conventions xix sbspace 2-15 grouper paging file 4-14
sbspace (continued) guidelines for spooled data 4-11 inconsistent replicated data 2-16 increasing sizes 8-11 invalid 6-3 monitoring disk usage 8-11 pathname limitations 4-12 row data 4-11, 4-14 spooled row data 4-10, 4-11 SBSPACETEMP configuration parameter 4-15 Scope --scope option 6-9, A-19 See also Conflict resolution. defined 3-13 options A-18 row 3-9, 3-13 transaction 3-9 Screen reader reading syntax diagrams I-1 Secondary conflict-resolution rule 3-8 Security, connections 4-7 Security. See Encryption. SELECT statement considerations A-113 limitations A-113 participant modifier A-112 shadow columns 4-22 Send queues See also Memory queues. defined 1-11, 4-10 Sequence objects 2-10 SERIAL columns 7-17 SERIAL data type 2-9, 2-15 SERIAL8 data type 2-9, 2-15 Server administrator, Enterprise Replication 2-3 SERVER column, cdr list server output A-54 Server connections, stopping A-42 Server definitions, global catalog 2-5 Server groups. See Database server groups. Server state, global catalog 2-5 Server. See Database server. servicename, defined 4-5 services file example 4-3 preparing 4-3 Sets. See Replicate sets. Setting AVG_LO_SIZE configuration parameter 4-12 CDR_QDATA_SBSPACE configuration parameter 4-13 environment variables 4-16
X-18
Setting (continued) idle timeout 6-3 LOGGING parameter 4-12 Setting up easy 1-6, 6-16 error logging 6-10 SQLHOSTS file 4-3 SQLHOSTS registry F-1 SQLHOSTS registry key F-3 Shadow columns ADD CRCOLS 4-20 adding 2-12 ATS files 8-4 behavior with BEGIN WORK WITHOUT REPLICATION 4-18 cdrserver 2-8, 2-16 cdrtime 2-8, 2-16 conflict resolution rules 3-8 creating 2-8, 4-9, 8-13 defined 4-20 disk space requirements 4-8, 4-9 dropping 2-12, 4-21 High-Performance Loader 4-22 loading and unloading data 4-22 UNLOAD statement 4-23 updating with DB-Access 4-19 WITH CRCOLS statement 4-20 Shadow replicates 6-8, 7-17, A-20, A-73 defined 2-4 Simple large object conflict resolution 2-16 cross-replication 2-16 replicating 2-15, 2-19 from blobspaces 2-15 from tblspaces 2-15 SPL conflict resolution 2-17 storing blobspaces 2-15 tblspaces 2-15 timestamp conflict resolution 2-16 Size altering columns 7-20 storage spaces 8-11 transaction record dbspace 4-10 SMALLFLOAT data type 6-12 Smart blobs. See Smart large object. Smart large object ATS files 8-5 cross replication 2-16 multiple references 2-19 replicating 2-15, 2-19 replicating only changed columns 6-11 specifying default behavior 4-12 SPL conflict resolution 2-18
Smart large object (continued) spooled row data 4-11 storing in sbspaces 2-15 SMI table summary D-1 syscdr_rqm D-2 syscdrack_buf D-3 syscdrack_txn D-4 syscdrctrl_buf D-4 syscdrctrl_txn D-4 syscdrerror D-4, D-13 syscdrpart D-6 syscdrprog D-6 syscdrq D-7 syscdrqueued D-8 syscdrrecv_buf D-8 syscdrrecv_stats D-8 syscdrrecv_txn D-8 syscdrrepl D-9 syscdrreplset D-11 syscdrs D-11 syscdrsend_buf D-12 syscdrsend_txn D-12 syscdrserver D-12 syscdrtx D-14 Software dependencies x Solving configuration problems 8-12, 8-13 Source server, synchronization 6-15 Specifying ATS directory A-26, A-66, A-76 conflict resolution options A-17 rules 6-9 scope 6-9 database server type 6-4 default behavior for smart large objects 4-12 idle timeout A-26 location ATS directory 6-4 RIS directory 6-4 replication frequency 6-10 RIS directory A-26, A-66, A-76 SPL conflict resolution limitations 3-10 rule 3-7, 3-10, 6-9 simple large object 2-17 smart large object 2-18 SPL routine arguments 3-11 considerations 3-12 delete table 3-11 information passed by Enterprise Replication 3-11 limitations for conflict resolution 2-20 nonoptimized 3-13 optimized 3-12
Index
X-19
Spooled row data sbspace changing logging mode 4-14 dropping 4-14 guidelines for creating 4-11 logging and HDR 5-8 logging mode 4-13 Spooled transactions defined 4-10 storage 4-10 troubleshooting 8-8 Spooling directories ATS and RIS 3-9 capacity planning 4-15 default 4-15 more than usual, causes of 8-10 planning for disk space 4-10 SQL checks 7-17 SQL code xix SQL statement forbidden 2-12 limited 2-12 permitted 2-13 supported 2-12 sqlerror column H-1 SQLHOSTS hierarchical routine topologies 4-6 INFORMIXSQLHOSTS environment variable leaf servers 4-6 nonroot servers 4-6 on UNIX E-1 on Windows F-1 preparing connectivity information F-2 registry key F-1, F-7 local F-1 setting up F-3 shared F-2 root servers 4-6 setting up with ISA 4-5, F-2 specifying registry host machine 4-16 SQLHOSTS file database server groups for HDR 5-6 encryption, setting up 4-6 example 4-4 format 8-12 server group 2-3 setting up 4-3 specifying location 4-16 UNIX 4-4 srccommtime column H-1 Starting data delivery for replicate sets A-89 for replicates A-86 Enterprise Replication A-83
F-2
Starting (continued) replicate sets 7-11 replicates 7-7 starts command 6-2 STATE column, cdr list server output A-54 STATE field, cdr list replicate output A-49 Statements ALTER TABLE 4-21 BEGIN WORK WITHOUT REPLICATION CREATE TABLE 4-21 DROP CRCOLS 4-21 LOAD 4-21, 4-23 SELECT 4-22 SQL, supported 2-12 UNLOAD 4-23 WITH CRCOLS 4-20 States active 7-7 inactive 7-8 STATUS column, cdr list server output A-55 Stopping data capture replicate sets A-96 replicates A-94 Enterprise Replication A-92 repair jobs 7-15 replicate sets 7-11 replicates 7-8 replication 7-3 server connection A-42 Storage delete tables 4-9 increasing size of spaces 8-11 spooled transactions 4-10 Stored Procedure Language. See SPL routine. stores_demo database xi Storing data in tblspaces 2-16 streamread support function 2-19, 4-20 streamwrite support function 2-19, 4-20 Strict master replicates 6-8 Summary commands A-1 SMI tables D-1 superstores_demo database xi Support functions replicating UDTs 2-19, 4-20 streamread 2-19, 4-20 streamwrite 2-19, 4-20 writing 2-19, 4-20 Supported data types 2-14 database servers 2-6 SQL statements 2-12
4-18
X-20
Supported (continued) table types 2-8 Suspended state defined A-50 server A-55 Suspending data delivery replicate sets A-100 replicates A-98 database servers A-102 replicate sets 7-12 replicates 7-8 replication 7-4 Swap log position 7-19 Switching logical log files 4-8 Synchronization 1-4, 6-14 servers 3-16, 6-3 times 3-10 Synchronization failures table 2-10, 6-15, 7-15, 7-16, H-1 Synchronizing clocks net time command 2-14 rdate command 2-14 data 7-14 onload and onunload utilities 4-22 using DB-Access 4-19 using ESQL/C 4-19 global catalog 6-3 operating system times 2-13, 8-12 Synchronous data replication defined 1-2 two-phase commit technology 1-2 Synonyms, and Enterprise Replication 2-6 Syntax command-line utility A-106 participant definition A-110 Syntax diagrams conventions for xv keywords in xviii reading in a screen reader I-1 variables in xviii Syntax segment xvii syscdr database 2-5 syscdr_rqm table D-2 syscdrack_buf table D-3 syscdrack_txn table D-4 syscdrctrl_buf table D-4 syscdrctrl_txn table D-4 syscdrerror table D-4, D-13 syscdrlatency table D-5 syscdrpart table D-6 syscdrprog table D-6 syscdrq table D-7 syscdrqueued table D-8
syscdrrecv_buf table D-8 syscdrrecv_stats table D-8 syscdrrecv_txn table D-8 syscdrrepl table D-9 syscdrreplset table D-11 syscdrs table D-11 syscdrsend_buf table D-12 syscdrsend_txn table D-12 syscdrserver table D-12 syscdrtx table D-14 sysmaster database SMI tables D-1 System Monitoring Interface. See SMI table. System name hosts file 4-2 System requirements database x software x
T
Table buffer D-15 designing, considerations 2-7 locking 2-12 preparing for conflict resolution 4-20 RAW 2-8 SMI D-1, D-16 temporary 2-8 transaction D-15 unsupported 2-8 Table creation automatic 6-7, 6-17 templates 1-6, 6-16, 6-17 Table hierarchy replicating 2-20 Table type unsupported 2-8 tabname column H-1 Target participant type 6-5 Tblspace storing BYTE and TEXT data 2-15, 2-16 Templates 1-6, 6-16, A-31 defined 2-4 deleting 7-13, A-41 displaying information A-57 managing 7-13 modifying 6-18, 7-13 realizing A-68 verification option 6-17 viewing 7-13, A-57 Temporary tables 2-8 Terminology command-line utility A-106 Enterprise Replication 2-3
Index
X-21
Terminology (continued) Enterprise Replication servers 2-3 global catalog 2-5 hierarchical topology 3-15 master replicate 2-4 participant 2-4 replicate 2-4 replicate set 2-4 replication servers 2-3 shadow replicate 2-4 templates 2-4 Testing network environment 4-7 trusted environment 4-7 TEXT data ATS files 8-4 distributing 2-18 RIS files 8-7 SPL conflict resolution 2-17 storing in tblspaces 2-16 types, loading 4-22 Threads used by Enterprise Replication C-1 Time formats A-114 Time synchronization 2-13, 3-10, 8-12 Timeout idle, setting 6-3 status, replication servers A-55 Timestamp conflict resolution rule 3-7, 3-9, 6-9, A-50 database action 3-10 defined 3-9 delete table 4-9 simple large object 2-16 TOC Notes xxi Tools for loading and unloading data 4-21 Topology, choosing network 3-14 Transaction conflict resolution scope 3-9, 3-13, 6-9 Transaction records default dbspace 4-10 storage 4-10 Transactional integrity 3-14 Transactions buffers, spooling to disk 4-10, 8-8 constraint checking 3-14 distributed 2-11 evaluation examples 1-12, 1-14 evaluation logic 1-9 failed, ATS and RIS files 6-10, 8-2 large 2-11 processing 2-11 tables D-15 Tree defined 3-16 topology, illustrated 3-16 Triggers activating A-20
Triggers (continued) changing 7-6 data capture 1-3 defined 1-3 enabling 6-12 errors with Enterprise Replication 2-10 firing A-62 permissions A-111 primary key updates 1-10 transaction capture 1-3 Troubleshooting configuration problems 8-12, 8-13 spooled transactions 8-8 TRUNCATE statement 2-12 Trusted environment configuring 4-3 testing 4-7 Two-phase commit protocol defined 1-2 distributed transactions 2-11 TXH label, ATS files 8-4 Types altering 7-20 Typographical conventions xiv TZ environment variable A-114
U
UDRs HDR servers, preparing 5-7 installing 4-20 preparing to replicate 4-20 registering 4-20 SPL conflict resolution 3-10 UDTs. See User-defined data types Unbuffered logging 2-7, 4-21 UNIX database server groups 4-4 oninit command 6-2 onmode command 6-2 SQLHOSTS file 4-4, 4-16 UNLOAD statement 4-23 unload utility 4-22 Unloading data 4-21, 4-22 Unsupported table types 2-8 Up-to-date, with replication 1-4, 6-14 Update-anywhere examples E-5 participants 6-6 replication system combining with HDR 5-3 defined 3-6 Update-anywhere replication systems 3-6 Updates multiple-row images 1-10
X-22
Updates (continued) primary key 1-10 WHERE clause column 1-10 Updating shadow columns 4-19 UPSERTs defined 6-11 replicating only changed columns User-defined data types ATS files 8-5 columns, primary key 2-20 HDR servers, preparing 5-7 information in ATS files 8-5 information in RIS files 8-8 installing 4-20 installing and registering 2-19 loading with deluxe mode 4-22 preparing to replicate 4-20 registering 4-20 replicating only changed columns 6-11 preparation 2-19 spooled row data 4-11 support 2-19 support functions 2-19 Users, informix 2-3 Utilities dbexport 4-22 dbimport 4-22 onunload 4-21 unload 4-22
6-11
Windows database server groups 4-5 Informix-Admin group 2-3 onmode command 6-2 SQLHOSTS registry host 4-16 starts command 6-2 WITH CRCOLS statement defining shadow columns 4-20 Workflow replication business model 3-4 Workload partitioning business model 3-3 Writing support functions 2-19 transaction buffers to disk 8-8
V
Values, sending floating-point 6-12 Variables, in syntax diagrams xviii Variables. See Environment variable. Verification, master replicate 6-7 Viewing Enterprise Replication 2-6 network connection status 7-13 repair jobs A-46 replicate attributes 7-7 replicate set attributes 7-11 replication server attributes 7-3 templates 1-6, 6-16, 6-17, 7-13, A-57 viotabid column H-1 Virtual column support 2-20 Visual disabilities reading syntax diagrams I-1
W
WHERE clause column updates 1-10
Index
X-23
X-24
Printed in USA
G251-2279-00
Spine information:
IBM DB2 IBM Informix
Version 10.0

IBM Informix-Ent Repl Guide

Uploaded by

IBM Informix-Ent Repl Guide

Uploaded by

DB2 IBM Informix

IBM Informix Dynamic Server Enterprise Replication Guide

DB2 IBM Informix

IBM Informix Dynamic Server Enterprise Replication Guide

Part 1. Introducing Enterprise Replication

Copyright IBM Corp. 1996, 2004

Applying Replicated Data

Part 2. Setting Up and Managing Enterprise Replication

IBM Informix Dynamic Server Enterprise Replication Guide

IBM Informix Dynamic Server Enterprise Replication Guide

Appendix E. Replication Examples .

Appendix F. SQLHOSTS Registry Key (Windows) .

IBM Informix Dynamic Server Enterprise Replication Guide

About This Manual

Assumptions About Your Locale

IBM Informix Dynamic Server Enterprise Replication Guide

New Features in Dynamic Server, Version 10.0

IBM Informix Dynamic Server Enterprise Replication Guide

Configuration Parameter Changes

v Syntax diagrams v Command-line conventions v Example code conventions

Feature, Product, and Platform

IBM Informix Dynamic Server Enterprise Replication Guide

>--------------------------------------------->< --------SELECT-----------+-----------------+--------LOCAL------ ---+-----ALL-------+--+--DISTINCT-----+ ---UNIQUE------

---+------------------+--+--FOR UPDATE-----+ --FOR READ ONLY-- .---NEXT---------. ----+----------------+--+---PRIOR--------+ ---PREVIOUS-----

IBM Informix Dynamic Server Enterprise Replication Guide

Component represented in PDF

Component represented in HTML .-------,-----------. V | ---+-----------------+--+---index_name---+ ---table_name---

>>-| Table Reference |->< Table Reference |--+-----view--------+--| +------table------+ ----synonym------

Reference to a syntax segment. Syntax segment.

-t table (1) Setting the Run Mode -S server -T target

Notes: 1 See page 17-4

IBM Informix Dynamic Server Enterprise Replication Guide

Example Code Conventions

IBM Informix Dynamic Server Enterprise Replication Guide

Online File TOC Notes

Fixed and Known Defects File

Informix Error Messages

IBM Informix Dynamic Server Enterprise Replication Guide

DataBlade API Programmers Guide

Guide to SQL: Reference Guide to SQL: Syntax Guide to SQL: Tutorial

IBM Informix Dynamic Server Enterprise Replication Guide

SNMP Subagent Guide

JDBC Driver Programmers Guide .NET Provider Reference Guide

Compliance with Industry Standards

IBM Informix Dynamic Server Enterprise Replication Guide

IBM Welcomes Your Comments

IBM Informix Dynamic Server Enterprise Replication Guide

Part 1. Introducing Enterprise Replication

Copyright IBM Corp. 1996, 2004

IBM Informix Dynamic Server Enterprise Replication Guide

Chapter 1. About IBM Informix Enterprise Replication

IBM Informix Enterprise Replication

Copyright IBM Corp. 1996, 2004

Asynchronous Data Replication

IBM Informix Dynamic Server Enterprise Replication Guide

Log-Based Data Capture

Chapter 1. About IBM Informix Enterprise Replication

Consistent Information Delivery

Repair and Initial Data Synchronization

IBM Informix Dynamic Server Enterprise Replication Guide

Chapter 1. About IBM Informix Enterprise Replication

IBM Informix Dynamic Server Enterprise Replication Guide

How Enterprise Replication Replicates Data

Chapter 1. About IBM Informix Enterprise Replication

Evaluating Data for Replication

IBM Informix Dynamic Server Enterprise Replication Guide

Initial Image INSERT

Final Image DELETE

INSERT with final row image Nothing

DELETE with initial row image Nothing

IBM Informix Dynamic Server Enterprise Replication Guide

Chapter 1. About IBM Informix Enterprise Replication

DELETE FROM employee WHERE emp_id=927 COMMIT WORK;

Figure 1-1. Insert Followed by a Delete

IBM Informix Dynamic Server Enterprise Replication Guide

Figure 1-2. Insert Followed by an Update