Teradata Database. Teradata Replication Services Using Oracle GoldenGate

Transcription

1 Teradata Database Teradata Replication Services Using Oracle GoldenGate Release 13.0 B A April 2011

2 The product or products described in this book are licensed products of Teradata Corporation or its affiliates. Teradata, BYNET, DBC/1012, DecisionCast, DecisionFlow, DecisionPoint, Eye logo design, InfoWise, Meta Warehouse, MyCommerce, SeeChain, SeeCommerce, SeeRisk, Teradata Decision Experts, Teradata Source Experts, WebAnalyst, and You ve Never Seen Your Business Like This Before are trademarks or registered trademarks of Teradata Corporation or its affiliates. Adaptec and SCSISelect are trademarks or registered trademarks of Adaptec, Inc. AMD Opteron and Opteron are trademarks of Advanced Micro Devices, Inc. BakBone and NetVault are trademarks or registered trademarks of BakBone Software, Inc. EMC, PowerPath, SRDF, and Symmetrix are registered trademarks of EMC Corporation. GoldenGate is a trademark of Oracle. Hewlett-Packard and HP are registered trademarks of Hewlett-Packard Company. Intel, Pentium, and XEON are registered trademarks of Intel Corporation. IBM, CICS, RACF, Tivoli, and z/os are registered trademarks of International Business Machines Corporation. Linux is a registered trademark of Linus Torvalds. LSI and Engenio are registered trademarks of LSI Corporation. Microsoft, Active Directory, Windows, Windows NT, and Windows Server are registered trademarks of Microsoft Corporation in the United States and other countries. Novell and SUSE are registered trademarks of Novell, Inc., in the United States and other countries. QLogic and SANbox are trademarks or registered trademarks of QLogic Corporation. SAS and SAS/C are trademarks or registered trademarks of SAS Institute Inc. SPARC is a registered trademark of SPARC International, Inc. Oracle, Java, and Solaris are registered trademarks of Oracle and/or its affiliates. Symantec, NetBackup, and VERITAS are trademarks or registered trademarks of Symantec Corporation or its affiliates in the United States and other countries. Unicode is a collective membership mark and a service mark of Unicode, Inc. UNIX is a registered trademark of The Open Group in the United States and other countries. Other product and company names mentioned herein may be the trademarks of their respective owners. THE INFORMATION CONTAINED IN THIS DOCUMENT IS PROVIDED ON AN AS-IS BASIS, WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION MAY NOT APPLY TO YOU. IN NO EVENT WILL TERADATA CORPORATION BE LIABLE FOR ANY INDIRECT, DIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS OR LOST SAVINGS, EVEN IF EXPRESSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. The information contained in this document may contain references or cross-references to features, functions, products, or services that are not announced or available in your country. Such references do not imply that Teradata Corporation intends to announce such features, functions, products, or services in your country. Please consult your local Teradata Corporation representative for those features, functions, products, or services available in your country. Information contained in this document may contain technical inaccuracies or typographical errors. Information may be changed or updated without notice. Teradata Corporation may also make improvements or changes in the products or services described in this information at any time without notice. To maintain the quality of our products and services, we would like your comments on the accuracy, clarity, organization, and value of this document. Please teradata-books@lists.teradata.com Any comments or materials (collectively referred to as Feedback ) sent to Teradata Corporation will be deemed non-confidential. Teradata Corporation will have no obligation of any kind with respect to Feedback and will be free to use, reproduce, disclose, exhibit, display, transform, create derivative works of, and distribute the Feedback and derivative works thereof without limitation on a royalty-free basis. Further, Teradata Corporation will be free to use any ideas, concepts, know-how, or techniques contained in such Feedback for any purpose whatsoever, including developing, manufacturing, or marketing products or services incorporating Feedback. Copyright by Teradata Corporation. All Rights Reserved.

3 Preface Purpose This book describes Teradata Replication Services Using Oracle GoldenGate, a suite of products that supports near-real-time movement and synchronization of data between instances of Teradata Database, and between Teradata Database and other supported source or subscriber databases. Teradata Replication Services Using Oracle GoldenGate consists of Teradata Database and Oracle GoldenGate Replication Products. This book: Introduces features and benefits of using Teradata Replication Services Using Oracle GoldenGate Discusses product components, architecture, and interoperability with other Teradata Database features Describes the major tasks performed to implement Teradata Replication Services Using Oracle GoldenGate Directs readers to sources of more detailed information about implementing and maintaining Teradata Replication Services Using Oracle GoldenGate in an enterprise Audience This book is intended for: System and application programmers responsible for writing programs to access data from the Teradata Database System administrators Database administrators and relational database developers Users and business decision makers Other implementers Teradata Professional Services associates Supported Releases This book supports the following releases: Teradata Database 13.0 Oracle GoldenGate Replication Products version 10.0 or later Teradata Tools and Utilities 13.0 Teradata Replication Services Using Oracle GoldenGate 3

4 Preface Changes to This Book Changes to This Book Release April 2011 Teradata Database 13.0 August 2010 Teradata Database 13.0 Description Added information about the Replicat Checkpoint table. Updated the: Description and examples of the DataRSG parameter. The DataRSG parameter values now map the IP address to the node name and RSG vproc ID. Process for determining values for the ControlRSG TAM parameter. Examples in Appendix B. Added information about: UDT and LOB support DDL replication SQL statements SET SESSION SUBSCRIBER, CREATE/REPLACE REPLICATION RULESET, and DROP REPLICATION RULESET Data object replication User-defined replication rule sets Enhanced replication support for triggers and identity columns Hot standby node restrictions Removed references to Table Copy, which is no longer supported. Additional Information URL Description Use the Teradata Information Products Publishing Library site to: View or download a manual: 1 Under Online Publications, select General Search. 2 Enter your search criteria and click Search. Download a documentation CD-ROM: 1 Under Online Publications, select General Search. 2 In the Title or Keyword field, enter CD-ROM, and click Search. Order printed manuals: Under Print & CD Publications, select How to Order. 4 Teradata Replication Services Using Oracle GoldenGate

5 Preface Recommended Reading URL developer.teradata.com/ Description The Teradata home page provides links to numerous sources of information about Teradata. Links include: Executive reports, case studies of customer experiences with Teradata, and thought leadership Technical information, solutions, and expert advice Press releases, mentions and media resources Teradata Customer Education designs, develops and delivers education that builds skills and capabilities for our customers, enabling them to maximize their Teradata investment. Use Your Service to access Orange Books, technical alerts, and knowledge repositories, view and join forums, and download software patches. Teradata Developer Exchange provides articles on using Teradata products, technical discussion forums, and code downloads. To maintain the quality of our products and services, we would like your comments on the accuracy, clarity, organization, and value of this document. Please teradatabooks@lists.teradata.com Recommended Reading There are no prerequisites. However, Teradata recommends that technical implementers also read the documents listed in Oracle GoldenGate Documentation and Training on page 14, and Teradata Replication Documentation by Task on page 15. Teradata Replication Services Using Oracle GoldenGate 5

6 Preface Recommended Reading 6 Teradata Replication Services Using Oracle GoldenGate

7 Table of Contents Preface Purpose Audience Supported Releases Changes to This Book Additional Information Recommended Reading Chapter 1: Introduction About Teradata Replication Services Using Oracle GoldenGate How To Use This Book Oracle GoldenGate Documentation and Training Teradata Replication Documentation by Task Chapter 2: Architecture Overview Source Teradata System Replication Groups Replication Privileges Relay Services Gateway (RSG) Vprocs Teradata SQL Replicated Changes Replication Server and Oracle GoldenGate for Teradata Extract Server and Oracle GoldenGate Extract Software Server Location and Configuration Teradata Access Module (TAM) Extract, Sort, and Trail Files Data Pump Replicat Server and Oracle GoldenGate Replicat Software Server Location and Configuration Teradata Replication Services Using Oracle GoldenGate 7

8 Table of Contents Data Application and Trail Files Data Integrity Handling Identity Columns and Triggers Subscriber Teradata System Initial Loading Oracle GoldenGate User Interfaces Oracle Management Pack for GoldenGate (formerly named Director) GGSCI Oracle GoldenGate Manager Chapter 3: Replication in Your Environment Criteria for Replication Use Dual System Architectures Disaster Recovery Active/Standby Dual Active Teradata Dual Active Solutions Teradata Systems Comparison of Data Synchronization Methods Teradata Query Director Teradata Multi-System Manager Benefits of Teradata Dual Active Solutions Teradata Dual Active Documentation Requirements for New Feature Support Software and Operating System Requirements Storage Requirements Chapter 4: System Set-up and Operations Setting Up the Replication Server Hardware Configuration Options Clustering Physical Placement Considerations Parameter Files Setting Up Teradata Replication Services Using Oracle GoldenGate Software Set Up TAM Configure RSG Vprocs Set Up Replication Security Teradata Replication Services Using Oracle GoldenGate

9 Table of Contents Load Exact Copies of Tables onto the Subscriber System Operational Considerations Oracle GoldenGate Parameter Settings Customized for Teradata Database DBS Control Utility Fields Affecting Replication Avoiding Replication While Loading Teradata Transaction Commit Protocols Handling Disconnections Between Servers Handling Backlog Change Data Setting Up Replication Groups Creating a Replication Group Creating a Replication Rule Set DDL Replication Requirements Configuring with Multiple Replication Groups Viewing Detailed Information on a Replication Group Replication Group Best Practices During Bulk Loading Teradata Parallel Data Pump (TPump) MultiLoad Bulk SQL Replication Recovery Procedures Overview Switchover Procedure Subscriber System Outage Considerations Down Node Handling Procedure To Reset Identity Column Sequence Generators Replication Server Failure Replicat Checkpoint Table Detailed Replication Recovery Procedures Character Sets and Replication Disk Space Considerations Replication and the Archive/Recovery Utility Table Keys and Uniqueness Constraints Preventing Uniqueness Violations Replication Limits Replication-Related Restrictions Chapter 5: TAM Initialization Parameters Using the TAM Parameters Creating the TAM Initialization File Recovery Enabling TAM Tracing Teradata Replication Services Using Oracle GoldenGate 9

10 Table of Contents TAM Initialization Parameters Determining the Values for the ControlRSG Parameter Chapter 6: Teradata SQL ALTER REPLICATION GROUP COMMENT (Comment Placing Form) COMMENT (Comment Retrieving Form) CREATE REPLICATION GROUP CREATE REPLICATION RULESET/REPLACE REPLICATION RULESET DROP REPLICATION GROUP DROP REPLICATION RULESET GRANT REPLCONTROL HELP REPLICATION GROUP REVOKE REPLCONTROL SET SESSION OVERRIDE REPLICATION SET SESSION SUBSCRIBER SHOW REPLICATION GROUP Appendix A: Notation Conventions Syntax Diagram Conventions Appendix B: Configuration and Setup Verification Examples About These Examples Directory Path Separators Prerequisite Checklist High-Level Architecture Using Data Pumps Process Overview: Change Data Capture Example Task 1: Create Teradata Objects and Replication Group Create User 1: Source Teradata System (Sandbox) Create User 1: Subscriber Teradata System (Sandbox2) Grant Privileges Create a Table and a Replication Group (Source Teradata System) Teradata Replication Services Using Oracle GoldenGate

11 Table of Contents Create Identical Tables on the Subscriber Task 2: Create Oracle GoldenGate Parameter (.prm) and TAM Initialization (.ini) Files on the Extract Server Step 1: Create a Manager Parameter File (/ggs/dirprm/mgr.prm) Step 2: Create an Extract Parameter File (/ggs/dirprm/ext.prm) Step 3: Create a Sort Parameter File (/ggs/dirprm/sort.prm) Step 4: Create a Pump Parameter File (/ggs/drprm/pump) Step 5: Create a TAM Initialization File (/ggs/tamini/tam.ini) Task 3: Create Oracle GoldenGate Parameter Files on the Replicat Server Step 1: Create the Manager Parameter File (/ggs/dirprm/mgr.prm) Step 2: Create the Replicat Parameter File (/ggs/dirprm/rep.prm) Task 4: Start GGSCI and Manager (Extract and Replicat Servers) Task 5: Add the Extract Processes Step 1: Configure Extract Step 2: Configure Unsorted Trail Files Step 3: Configure Sort (Extract) Step 4: Configure Sorted Trail Files Step 5: Configure Pump (Extract) Step 6: Configure Remote Trail Files Step 7: Check Status Task 6: Add the Replicat Processes Step 1: Set up the Extract Server Step 2: Check Status Task 7: Start the Extract and Replicat Servers Task 8: Use a Simple Insert To Check for Proper Operation Step 1: Check the Stats Before the SQL INSERT Step 2: Issue SQL INSERT to Teradata Source System Step 3: Check That the Row Is Applied on the Replicat Server Step 4: Check That the Row Is Applied on the Subscriber System Task 9: Clean Up DDL Replication Setup Example Task 1: Create a Replication Group, Rule Set, and Tables on the Source System Task 2: Create a Replication Group, Rule Set, and Tables on the Subscriber System Task 3: Create the TAM Initialization File on the Replication Server: tamini\ext1.ini Task 4: Create the Extract Parameter File on the Replication Server: dirprm\ext1.prm Task 5: Create the Sort Extract Parameter File on the Replication Server: dirprm\ext2.prm Task 6: Create the Replicat Parameter File on the Replication Server: dirprm\rep1.prm Task 7: Add the Extracts, Replicat, and Trail File Teradata Replication Services Using Oracle GoldenGate 11

12 Table of Contents Task 8: Create the dirdat Directory for Pext1 and Pext2 Trails Task 9: Add the ODBC DSNs for the Source and Subscriber Systems Task 10: Start the Extract and Replicat in GGSCI Task 11: Check the Status Task 12: Issue DDLs Task 13: Check Statistics and the Report File Task 14: Terminate and Stop the Extract and Replicat ODBC Data Sources for Windows Sample ODBC Initialization Files for Linux Sample ODBC.ini for TTU Troubleshooting Appendix C: Replication Between Teradata and Other Databases Supported Source and Subscriber Systems Appendix D: Moveable Drive Configuration and Failover Example Setup Procedure Failover Procedure Glossary Index Teradata Replication Services Using Oracle GoldenGate

13 CHAPTER 1 Introduction This chapter introduces Teradata Replication Services Using Oracle GoldenGate and describes the information available for understanding it. About Teradata Replication Services Using Oracle GoldenGate Teradata Replication Services Using Oracle GoldenGate preserves and synchronizes businesscritical data by capturing row changes made to tables in one database and applying those changes to the same tables in other databases in near-real time. Replication ensures the safety and integrity of data by allowing one system to pass control to another during planned system downtime or an unplanned outage. This technology replicates data from active systems without interruption and limits the impact on system resources because only changes to userselected tables are copied. The changes captured and replicated can include inserts, updates, and deletes resulting from SQL DML statements or the execution of utilities, such as MultiLoad and Teradata TPump. The changes can be replicated between Teradata systems located across the street from each other or across the world. Teradata Replication Services Using Oracle GoldenGate supports both an Active/Active configuration, in which both Teradata systems actively process transactions or an Active/ Standby configuration, in which one system actively processes transactions and the other receives duplicate changes and stands by to become the active system if needed. Hardware and software from both Oracle Corporation and Teradata are required to implement Teradata Replication Services Using Oracle GoldenGate. How To Use This Book This book has a Teradata perspective. It addresses issues, concerns, and interoperability considerations unique to the Teradata environment. Oracle GoldenGate for Teradata can replicate data to and from Teradata Database and databases from other vendors. See Supported Source and Subscriber Systems on page 137. This book, however, focuses on Teradata-to-Teradata replication. This book cannot be used alone. Software from both Oracle and Teradata are required in a Teradata replication environment. Therefore, you need to use this book with Oracle Teradata Replication Services Using Oracle GoldenGate 13

14 Chapter 1: Introduction Oracle GoldenGate Documentation and Training GoldenGate documentation. See Oracle GoldenGate Documentation and Training on page 14. Oracle GoldenGate Documentation and Training Oracle GoldenGate documentation is available from Under Media Pack Search, Select a Product Pack menu, choose Oracle Fusion Middleware. Then select the media pack whose name begins with Oracle GoldenGate for Non Oracle Database. This Resource... Oracle GoldenGate for Teradata Installation and Setup Guide Oracle GoldenGate for Windows and UNIX Administrator Guide Oracle GoldenGate for Windows and UNIX Reference Guide Oracle GoldenGate for Windows and UNIX Troubleshooting and Performance Tuning Guide Oracle Management Pack for GoldenGate Administration Guide Oracle GoldenGate Training Provides... information specific to the setup of the Oracle GoldenGate solution in a Teradata environment. information on: Oracle GoldenGate components how to design, configure, and implement Oracle GoldenGate on the Windows, Linux, and UNIX operating systems detailed information about Oracle GoldenGate parameters, commands, and functions. suggestions for improving the performance of Oracle GoldenGate in different situations, and provides solutions to common problems. information on how to use Oracle Management Pack for GoldenGate (formerly known as Director) to define, configure, manage, and report on all Oracle GoldenGate transactional data synchronization processes. information on how to set up Oracle GoldenGate for Teradata and run replication in various server configurations. The courseware includes tutorial and practice lab documents. Oracle requires training for all customers purchasing Oracle GoldenGate. 14 Teradata Replication Services Using Oracle GoldenGate

15 Chapter 1: Introduction Teradata Replication Documentation by Task Teradata Replication Documentation by Task This section provides a quick reference to replication tasks and concepts and other documents that describe them. For... information on the tables and views containing replication group names and associated information how Teradata Database client utilities handle insert, update, and delete functions that generate replication source data how to set up the ODBC Driver for Teradata Database detailed recovery procedures best practices, limitations, troubleshooting, and performance considerations See... Data Dictionary Teradata Parallel Data Pump Reference Teradata MultiLoad Reference ODBC Driver for Teradata User Guide Replication Services Recovery Procedure Document for Teradata Database 13.0 at: Under Knowledge, select Asset Repository Sites Search. Under Select Repositories to Search, select Asset Repository. This web site is available to Teradata associates only. Customers who need this document should contact their Teradata representative. the orange book for Teradata Replication Services Using Oracle GoldenGate. For access, register through Your Service, available from the Support & Downloads link on Teradata Replication Services Using Oracle GoldenGate 15

16 Chapter 1: Introduction Teradata Replication Documentation by Task 16 Teradata Replication Services Using Oracle GoldenGate

17 CHAPTER 2 Architecture Teradata Replication Services Using Oracle GoldenGate relies on functionality provided by both Teradata and Oracle. This chapter describes: The components required How those components work together (the process flow) A simple architecture with two replication servers For more information about the many different configuration possibilities, see Setting Up the Replication Server Hardware on page 31. Overview Teradata Replication Services Using Oracle GoldenGate requires software and hardware components. The hardware includes two servers running database management systems: One server, known as the source system, runs the database management system (DBMS) that is the source of the changes to be replicated. The DBMS running on this server captures the changes to be replicated. The other server, known as the subscriber system, runs the DBMS that is the subscriber (or recipient) of the replicated changes. Changes are applied to this DBMS. In some configurations, known as active/active, each system can act as both source and subscriber, serving as the source for some tables and the subscriber for other tables. The DBMS running on the source must be Teradata Database 12.0 or Teradata Database For information about other supported database systems, see Supported Source and Subscriber Systems on page 137. For information about supported Teradata Database versions, see Software and Operating System Requirements on page 29. Between the source and subscriber systems are one or more servers, known as replication servers, that extract row changes from transactions on the source system and apply them in the same order to the subscriber system so the data for the selected tables are synchronized between the two systems. Teradata Replication Services Using Oracle GoldenGate 17

18 TCP/IP Chapter 2: Architecture Overview Figure 1: Interaction Between the Major Components of Teradata Replication Services Using Oracle GoldenGate Teradata Platform A (Source) Extract Server Change Data Capture RSG vprocs Extract Teradata Access Module 4 Queued change data on disk (trail files) 5 Data Pump Trail Files 6 Replicat Trail Files Teradata Platform B (Subscriber) 7 ODBC Replicat Server 1. Control connection 2. Data connection 3. Dictionary queries 4. Write to disk 5. Read trails 6. Send to Replicat 7. Apply data 1152C Teradata Replication Services Using Oracle GoldenGate

19 Chapter 2: Architecture Source Teradata System Source Teradata System The first component of Teradata Replication Services is the source Teradata system running Teradata Database. Teradata Database features that support replication include: Replication groups Replication privileges Relay Services Gateway (RSG) vprocs Teradata SQL Replication Groups To replicate changes in Teradata Database, you must select a set of tables to be replicated. This set is known as a replication group. A table must be a member of a replication group in order to be replicated. Issue the SQL statement CREATE REPLICATION GROUP to put existing tables in a replication group. You can later add to or change a replication group by issuing the SQL statement ALTER REPLICATION GROUP or DROP REPLICATION GROUP. For more information on creating or configuring a replication group on the source Teradata Database, see Setting Up Replication Groups on page 44. For more information on the Teradata SQL required to manage replication groups, see Chapter 6: Teradata SQL. Replication Privileges To create a replication group and perform other, more specialized replication functions, a user must be granted the REPLCONTROL privilege. For more information on replication security and the privileges required for implementing replication, see Set Up Replication Security on page 35. Relay Services Gateway (RSG) Vprocs Teradata SQL RSG vprocs on the source system run replication tasks and connect to the replication server. The connection implements the TCP/IP protocol. Each node has one RSG. When a transaction begins that involves tables in a replication group, Teradata Database assigns the transaction to an RSG vproc. AMPs send all changes to the assigned RSG vproc. The RSG vproc collects transaction changes in memory until the end transaction record is received. If a transaction generates many changes, Teradata Replication Services spills the data to disk temporarily, as described in Handling Backlog Change Data on page 43. Then Teradata Database transmits changes to the replication server via Teradata software residing on the replication server. The Teradata SQL required to implement replication is described in Chapter 6: Teradata SQL. Teradata Replication Services Using Oracle GoldenGate 19

20 Chapter 2: Architecture Replication Server and Oracle GoldenGate for Teradata Replicated Changes Replicated changes can also include changes affecting the object definition of the following: Global temporary tables Views Macros Hash indexes Join indexes Triggers Replication groups Replication Server and Oracle GoldenGate for Teradata There are two types of replication servers, which run Oracle GoldenGate for Teradata and are responsible for passing transaction changes from the source system to the subscriber system: Server Type Function Software Extract Capture changes from source system Extract Replicat Apply changes to subscriber system Replicat Other components of the Oracle GoldenGate for Teradata architecture include: Teradata Access Module (TAM) Trail files Data pump User interfaces Manager Extract Server and Oracle GoldenGate Extract Software Server Location and Configuration Teradata recommends the following: Locate the Extract server near the source system. Cluster the Extract server for highest availability. 20 Teradata Replication Services Using Oracle GoldenGate

21 Chapter 2: Architecture Replicat Server and Oracle GoldenGate Replicat Software For more information about these considerations, see Setting Up the Replication Server Hardware on page 31. Teradata Access Module (TAM) Teradata Access Module (TAM) is Teradata software that resides on the extract server and communicates with the RSG vproc on the source system. It passes messages and data between the source system and the Extract software. The TAM initialization parameters control the connection between TAM and Teradata Database. These parameters are required when you create a replication group. For more information on the TAM initialization parameters, see Using the TAM Parameters on page 57. Extract, Sort, and Trail Files The Extract software reads the source database changes it receives from TAM and writes the data to disk on the replication server in one or more trail files. Checkpoints, which record to disk the current read and write positions of a process, prevent redundant processing if there is a failure. Oracle GoldenGate queues the row changes in the trail files in the order in which they occurred on the source. Next, the sort process sorts the multiple trail files to ensure that data is sequenced properly. Data Pump The Data Pump software then reads the sorted trail files and sends them to the Replicat server. Replicat Server and Oracle GoldenGate Replicat Software Server Location and Configuration Teradata recommends the following: Locate the Replicat server in the same data center as the subscriber system. Cluster the Replicat server for highest availability. For more information about the benefits, drawbacks, and considerations involved with server placement, see Setting Up the Replication Server Hardware on page 31. Data Application and Trail Files The Replicat software retrieves the data from the trail created by the Extract software, connects to the subscriber system via ODBC, and applies the data to the subscriber database. Replicat uses checkpoints in the trail to track its position and ensure all records are posted to the subscriber database. Teradata Replication Services Using Oracle GoldenGate 21

22 Chapter 2: Architecture Subscriber Teradata System Data Integrity Handling To ensure data and referential integrity, by default Replicat mimics the source database by: Capturing changes only if the transaction commits on the source DBMS Applying changes in the same order as they were committed in the source database Grouping operations logically into transactions the same as in the source database Identity Columns and Triggers Note: Oracle GoldenGate allows you to apply changes in parallel instead of sequential order and to modify the logical grouping of changes by using the parameters GROUPTRANSOPS and BATCHSQL and the BATCHTRANSOPS option. For more information on these parameters, see Oracle GoldenGate Parameter Settings Customized for Teradata Database on page 37 and Oracle GoldenGate for Windows and UNIX Reference Guide. Oracle GoldenGate for Teradata handles identity columns and triggers as follows: Identity columns: Oracle GoldenGate always replicates identity column values from the source, even when the column has been defined with the GENERATED ALWAYS attribute. Triggers: Oracle GoldenGate replicates triggered effects directly as changes to the affected tables as long as all affected tables are in the same replication group as the source table. Triggers and the automatic generation of identity column values can be suppressed on the subscriber via the Teradata SQL statement SET SESSION SUBSCRIBER. When set to ON, triggered actions are suppressed in the current session and automatic generation of identity columns is overridden by a user-supplied value. Specify this statement explicitly in the Oracle GoldenGate Replicat parameter file during set up. For more information, see SET SESSION SUBSCRIBER on page 104. Subscriber Teradata System Initial Loading The subscriber Teradata system runs Teradata Database and receives changes resulting from transactions on the source system. The subscriber system can be near the source system or on another continent. Before replication begins, you must load onto the subscriber system a copy of the same tables, replication groups, and databases that are involved in replication on the source system. To do this, you can use one of several different Teradata utilities. For more information, see Replication Group Best Practices During Bulk Loading on page Teradata Replication Services Using Oracle GoldenGate

23 Chapter 2: Architecture Oracle GoldenGate User Interfaces Oracle GoldenGate User Interfaces Use the following methods to control and monitor Oracle GoldenGate processing: Oracle Management Pack for GoldenGate Oracle GoldenGate Software Command Interface (GGSCI) Oracle Management Pack for GoldenGate (formerly named Director) Oracle Management Pack for GoldenGate provides a graphical user interface that allows you to monitor and manage Oracle GoldenGate from a remote client or the web. Teradata Multi- Systems Manager uses Oracle Management Pack for GoldenGate to monitor data synchronization between the two Teradata systems. For information on... See... Teradata Multi-Systems Manager Teradata Multi-System Manager on page 27. the requirements for running Oracle Management Pack for GoldenGate using Oracle Management Pack for GoldenGate Software and Operating System Requirements on page 29. Oracle Management Pack for GoldenGate Administration Guide GGSCI GGSCI is the Oracle GoldenGate command-line interface. You can use GGSCI to issue the commands that configure, control, and monitor Oracle GoldenGate. If you have a UNIX client connected to the replication server, you can issue Oracle GoldenGate commands from a script by running GGSCI and calling an input file. For information on... Oracle GoldenGate commands issuing batch and shell scripts from the GGSCI See... Oracle GoldenGate for Windows and UNIX Reference Guide. Oracle GoldenGate for Windows and UNIX Administrator Guide. Teradata Replication Services Using Oracle GoldenGate 23

24 Chapter 2: Architecture Oracle GoldenGate Manager Oracle GoldenGate Manager Manager is the control process of Oracle GoldenGate. Manager must run on each server where Oracle GoldenGate software is installed. Manager must be started before Extract or Replicat can be started and must remain running while those processes are running so it can perform resource management functions. Manager: Starts Oracle GoldenGate processes Performs trail management Creates event, error, and threshold reports Communicates with the user interfaces used to start and stop the Extract process and obtain the status of replication. 24 Teradata Replication Services Using Oracle GoldenGate

25 CHAPTER 3 Replication in Your Environment This section discusses how replication fits into the customer environment, including when Teradata Replication Services Using Oracle GoldenGate is optimal and when other solutions or a combination of replication and other solutions may be more appropriate. Criteria for Replication Use Teradata Replication Services is optimal when: Data is updated on the source system with SQL by interactive or other non-batch applications. The batch job or transaction size is moderate (10,000 rows or fewer). Note: There is no exact limit; smaller batch sizes minimize the replication time lag. It is important to minimize the lag time in updates between two Teradata systems. Other data synchronization strategies you can use instead of or in addition to replication are described in Comparison of Data Synchronization Methods on page 27. Dual System Architectures Disaster Recovery Active/Standby Replication can be part of a dual system environment, which can include these architectures: Disaster recovery Active/standby Dual active In a disaster recovery architecture, one system is active and the other is not during normal operations. Disaster recovery requires the time to restore data from backup archives and bring the second system online for processing. You can explore this option through the Teradata Recovery Center, which mirrors critical customer data and applications on a Teradata system at Teradata Corporation. For more information about this option, see your Teradata representative. In an active/standby architecture, one system is used for all normal operations while the other is used only to maintain a copy of critical data. The second system does not have any active Teradata Replication Services Using Oracle GoldenGate 25

26 Chapter 3: Replication in Your Environment Teradata Dual Active Solutions users or applications during normal operations and is used only in the event of an unplanned outage to the first system. An active/standby architecture is used primarily for disaster recovery. Active/standby offers faster recovery than a disaster recovery solution. Dual Active In a dual active architecture, both systems are active during normal operations and both maintain copies of critical data, as described in the following section. Teradata Dual Active Solutions Teradata Dual Active Solutions: Allows business operations to continue if a planned or unplanned outage occurs Provides quick restoration of access to system resources Enables businesses to experience consistent levels of service from their systems Figure 2: Teradata Dual Active Solutions ETL Teradata System A Data Synchronization Teradata Multi-System Manager IP Switch Users/ Applications Table Copy Replication Monitoring Administration Operational Control Teradata Query Director Users/ Applications Dual Load Users/ Applications Load Teradata System B Data Synchronization System & Query Routing 3020A007 Teradata Systems The components of a Teradata Dual Active Solution and their interactions are summarized in the following sections. Dual Active uses two Teradata systems, each actively processing queries. The system requirements are flexible. The two Teradata systems can have different: System size (processing performance or disk capacity) Operating systems 26 Teradata Replication Services Using Oracle GoldenGate

27 Chapter 3: Replication in Your Environment Teradata Dual Active Solutions Hardware generations Database versions Data (only mission-critical data and applications are on both systems) Comparison of Data Synchronization Methods Mission critical information must be mirrrored on both systems. There are several methods to ensure that data is the same on both systems. Data Synchronization Method Data Mover Dual Load Replication Recommended Use Copy complete tables (or partial tables based on a timestamp or batch number) from one system to another on an automated periodic schedule. Load large amounts of data external to the Teradata systems onto both Teradata systems at once. Replicate moderate-sized changes from SQL transactions from one Teradata system to another in real-time. Teradata Query Director Teradata Query Director routes queries between dual active systems for load balancing and failover based on rules you set up in advance, for example: Marketing users are normally routed to System A, which gives them an average 2 second response time. Finance users are normally routed to System B, which gives them an average 5 second response time. If System A is down, all users are transparently and automatically routed to System B, with Marketing users receiving processing priority. Marketing users still see 2 second response times, while Finance users may see 30 second response times. Users do not have to log in to the other system and do not notice the rerouting. Teradata Multi-System Manager Teradata Multi-System Manager (Teradata MSM) intelligently monitors dual system performance and, through Teradata Query Director, acts where necessary to ensure high availability and failover protection. For example, Teradata MSM can detect that System A is experiencing a slowdown and data currency is not keeping up with System B. Teradata MSM then does the following: Determines which users and applications are affected Determines which users among those affected have mission-critical applications Communicates with Teradata Query Director, which routes those users and their data to System B Teradata Replication Services Using Oracle GoldenGate 27

28 Chapter 3: Replication in Your Environment Requirements for New Feature Support Benefits of Teradata Dual Active Solutions Better Value from Investment. Dual active uses the second system actively, allowing no idle resources, like in traditional active/standby or disaster recovery solutions. The second active system also provides workload balancing. Extended Return on Investment. Flexible system requirements allow you to repurpose existing equipment as the second system. Align IT Investment to Value. Dual Active Solutions allows you to be selective about the data you duplicate, protecting only mission-critical data and applications, while less critical information and applications can be backed up from tape. Dual Active Solutions also allows you more control over which users you route to each system, ensuring that business-critical work receives priority and experiences no downtime. Teradata Dual Active Documentation For information on... See... Teradata Multi-Systems Manager Teradata Multi-Systems Manager User Guide Teradata Multi-Systems Manager Implementation Guide Teradata Data Mover Teradata Query Director Teradata Data Mover User Guide Teradata Query Director User Guide For other information about Teradata Dual Active Solutions, search for dual active on the Teradata Web site: Requirements for New Feature Support The following are required to support DDL replication, the period data type, the large decimal data type, large objects (LOBs), and the replication of tables with user-defined type (UDT) columns: TAM 13.0 GoldenGate for Teradata Version 10.0 or later In addition, the following subscriber system requirements apply: For DDL replication: Teradata Database 13.0 or later. For LOB support: Teradata Database V2R5.1 or later with Teradata ODBC Driver or later. For replication of tables with UDT columns: Teradata Database V2R6.1 or later. Note: To replicate tables with UDT columns, the type definitions must already exist on both the source and subscriber systems. 28 Teradata Replication Services Using Oracle GoldenGate

29 Chapter 3: Replication in Your Environment Software and Operating System Requirements Teradata Database 13.0 can operate with TAM 12.0 as long as DDL replication, period and large decimal data types, LOBs, and replication of tables with UDT columns are not required. Software and Operating System Requirements Separate software and operating system requirements apply for Teradata Database and Oracle GoldenGate Replication Products, as shown in the following table. Product Name Teradata Database Version Windows 2000 (32- and 64-bit**) Windows XP (32- and 64-bit**) Windows 2003 (32- and 64-bit**) Linux Redhat 4.0 (32-bit) Linux SLES 9 or 10 Solaris HP- UX AIX ODBC Version Other Software MultiLoad Oracle Golden- Gate for Teradata 10.0x (Extract) * 6.2 *** 6.2 only 6.2 only Y Y 12.0 or later only N N N 12.0 or higher TAM 12.0 TAM for 6.2, 7.08 or higher Oracle Golden- Gate for Teradata 10.0x (Replicat) * only 6.2 only Y Y 12.0 or later only Y Y Y 12.0 or higher N/A N/A Oracle Management Pack for Golden- Gate 2.x (formerly Golden- Gate Director 1.x ) N/A Y Y Y Y N Y Y Y 12.0 or higher N/A N/A ** Windows 64-bit is supported with the 32-bit version of TAM and Oracle GoldenGate software. ***V2R6.2 support ended in September Version 12.0 or higher is highly recommended to obtain the most recent software patches. Note: You must download TAM from Teradata. To download TAM, contact your Teradata representative. Storage Requirements Teradata recommends the use of high availability storage devices to store the trail and checkpoint files. Teradata Replication Services Using Oracle GoldenGate 29

30 Chapter 3: Replication in Your Environment Storage Requirements 30 Teradata Replication Services Using Oracle GoldenGate

31 CHAPTER 4 System Set-up and Operations This chapter summarizes the considerations and steps involved in implementing and maintaining an installation of Teradata Replication Services Using Oracle GoldenGate. Setting Up the Replication Server Hardware Configuration Options When setting up the replication servers, consider the following: The roles the servers will perform and how many are needed in each role How to configure for no single point of failure Physical placement for performance and reliability The parameter files that guide the operation of the servers There are several possible roles for a replication server: Extract Replicat Combination Extract and Replicat Standby When you set up your system, consider how many replication servers you need for each role. If you have 50 replication groups, you may decide to distribute them across 50 Extract servers. If you have a larger system, you may need more servers to replicate your system. Note: In a failover scenario, the roles of the servers hosting Extract and Replicat are reversed. You should decide not only which role each server should have but also how many servers you need for each role. Clustering To keep replication running continuously, Oracle recommends clustering the replication server, as shown in the following two figures. In a clustered configuration, each replication server has a standby server that performs the same functions. Oracle GoldenGate works with many different types of clustering software. While Oracle has not certified any one clustering solution, Oracle GoldenGate supports clustering. Teradata Replication Services Using Oracle GoldenGate 31

32 Chapter 4: System Set-up and Operations Setting Up the Replication Server Hardware Figure 3: Recommended Clustered Configuration in a Local Data Center Director Console Teradata Source System Replication Server Extract Replication Server Replicat Teradata Subscriber System Standby Server Extract Standby Server Replicat Reliable Disk Storage Reliable Disk Storage 1152A028 Figure 4: Recommended Clustered Configuration in Remote Data Centers Data Center #1 Data Center #2 Director Console Teradata Source System Replication Server Extract Replication Server Replicat Teradata Subscriber System Director Console Standby Server Extract Standby Server Replicat Reliable Disk Storage Reliable Disk Storage 1152A029 Note: Clustering or having a standby server does not necessarily protect against a data center failure, even if distributed SAN storage is used. For a simpler configuration that is practical in some situations, see Appendix D: Moveable Drive Configuration and Failover Example. 32 Teradata Replication Services Using Oracle GoldenGate

33 Chapter 4: System Set-up and Operations Setting Up Teradata Replication Services Using Oracle GoldenGate Software Physical Placement Considerations Parameter Files The Extract and Replicat servers can be co-located with the source and subscriber servers, or they can be remote from both. These considerations are most important when using Maximum Protection mode. See Teradata Transaction Commit Protocols on page 41. Since the components are connected by networking, you have several options for physical placement of the servers. However, performance is especially affected by network latency between the Extract server and the source database. To minimize transaction latency, consider co-locating the Extract server with the source system. One drawback to this configuration is that if there is a site-wide failure at the source system location, committed changes that are recorded in the trail file and not yet processed may be lost. Parameter files are used for configuring, running, and managing Oracle GoldenGate processes and TAM. To set up the replication server, establish parameter files for Extract, Replicat, the Manager process, and TAM. For information on... the initialization file for TAM parameters Extract, Replicat, and Manager processes See... Chapter 5: TAM Initialization Parameters. Oracle GoldenGate for Teradata Installation and Setup Guide. Setting Up Teradata Replication Services Using Oracle GoldenGate Software Before using Teradata Replication Services Using Oracle GoldenGate, perform the following procedures: Set Up TAM Configure RSG Vprocs Set Up Replication Security Load Exact Copies of Tables onto the Subscriber System Creating a Replication Rule Set Teradata Replication Services Using Oracle GoldenGate 33

34 Chapter 4: System Set-up and Operations Setting Up Teradata Replication Services Using Oracle GoldenGate Software Set Up TAM Do the following: 1 Contact your Teradata representative to download TAM. 2 Verify that the Oracle GoldenGate software is installed on the replication server and locate the installation directory. 3 Copy the TAM library file into the installation directory created by the Oracle GoldenGate software installation. If TAM is provided in compressed format (for example, as a.zip file), extract the file into this directory. 4 Set the values for the TAM initialization parameters. For details, see Chapter 5: TAM Initialization Parameters. Configure RSG Vprocs Define RSG Vprocs The Parallel Upgrade Tool (PUT) provides the Configure Teradata user interface for adding the RSG required for each node on the source system. 1 In PUT, select Custom Configuration. 2 Select the RSG box. 3 Restart your system. For information about using this interface, see the appropriate document for your Teradata Database platform: Parallel Upgrade Tool (PUT) for Microsoft Windows User Guide Parallel Upgrade Tool (PUT) for MP-RAS and Linux User Guide Create the RSG Spill File Directory If a transaction generates unusually large volumes of change data, Teradata Database uses a spill file on disk to store the transaction data. The RSG creates a directory for the spill file automatically if none exists. Ensure that there is sufficient disk space for the directory as part of preparing the source system. You must arrange your batch sizes not to exceed this limit. The default directory paths and the threshold defining when a spill file will be used are tunable parameters in the DBS Control utility. For more information, see DBS Control Utility Fields Affecting Replication on page Teradata Replication Services Using Oracle GoldenGate

35 Chapter 4: System Set-up and Operations Setting Up Teradata Replication Services Using Oracle GoldenGate Software Set Up Replication Security Consider these three aspects when setting up security for your replication system: Privileges Encryption Authentication Privileges The REPLCONTROL privilege provides security for Teradata Replication Services Using Oracle GoldenGate. The privilege is a total system privilege in the same manner that ROLE and PROFILE are total system privileges; that is, the privilege is not granted and revoked on specific tables, databases, or users. The super-user DBC can grant the REPLCONTROL privilege to any other user along with the GRANT option. The REPLCONTROL privilege controls: Defining and managing replication groups Creating replication rule sets Overriding normal replication controls for a session and suppressing change data capture when a DML or DDL statement is executed. For information about defining the REPLCONTROL privilege, see GRANT REPLCONTROL on page 93. Note: The Oracle GoldenGate user that logs on to the subscriber sessions must be granted privileges to insert/update/delete on all the replicated tables. Rights on the database that contains the replicated objects (for DDL replication) Insert/update/delete rights on all the replicated tables Encryption When you configure the TAM parameter file, you choose whether or not to encrypt replication messages. If you choose encryption, you can include control messages, data messages, or both. Note: Passwords cannot be encrypted in the TAM parameter file. As an alternative, you can define the passwords in ODBC or change the permission on the TAM parameter file to be read-only by owner. For more information about replication encryption, see: Security Administration Oracle GoldenGate Administrator Guide for Windows and UNIX Authentication When you create a replication group, a group identifier and security token are automatically generated that are unique to the replication group. For example: CREATE REPLICATION GROUP testgrp(gguser1.t1); Teradata Replication Services Using Oracle GoldenGate 35

36 Chapter 4: System Set-up and Operations Operational Considerations Returns this response from Teradata Database: Group Identifier Security Token 2195 C9E5AB02F47632AD Note: When you create a replication group, be sure to record the Group Identifier and Security Token. You will need these later for the TAM initialization file. For more information, see Chapter 5: TAM Initialization Parameters. Load Exact Copies of Tables onto the Subscriber System There are several choices for loading tables from the source database to the subscriber database when setting up a replication system. Consider the following when deciding which method to use: Utility Considerations Benefits Drawbacks Teradata Archive/ Recovery Copies data and metadata and has database-level commands that can copy many tables in a database at a time. Offers simplicity and good performance if you have many tables that are in one or a few databases. You must drop the table from the replication group on the subscriber system before you can restore it. Supports large objects (LOBs). TPump or MultiLoad Issue the SET SESSION OVERRIDE REPLICATION ON statement before using the utility. Prerequisites include that the tables: Must already exist Must be defined on the subscriber system Can load into a populated table (perform incremental loads). Do not support large objects (LOBs). MultiLoad also does not support: NoPI tables Queue tables Unique secondary indexes Join indexes Operational Considerations Consider the following before setting up Teradata Replication Services Using Oracle GoldenGate. 36 Teradata Replication Services Using Oracle GoldenGate

37 Chapter 4: System Set-up and Operations Operational Considerations Oracle GoldenGate Parameter Settings Customized for Teradata Database The default setting of most Oracle GoldenGate parameters works well for Teradata replication systems. However, Teradata recommends a customized setting for some parameters. For a complete parameter list, see Oracle GoldenGate for Windows and UNIX Reference Guide, Version The following table describes only the Oracle GoldenGate parameters whose settings are customized for Teradata. Parameter Type Parameter Name Purpose Extract EOFDELAYCSECS Specifies how often the process checks for new data after it has reached the end of the current data in its data source. Teradata Recommendation Extract: 0 Pump Extract: 1 PASSTHRU Controls whether Extract processes tables in pass-through mode or normal mode, in which the Extract process looks up table definitions. Using pass-through mode, you can cascade the extracted data to a data pump on a replication server that has no database installed on it. Use pass-through mode for sort extract and pump extract. PASSTHRU prevents metadata conflicts that lead to replication failure. Replicat BATCHSQL Causes Replicat to organize similar SQL statements into batches and apply them at an accelerated rate. If BATCHSQL is not specified, Replicat applies one SQL statement at a time. Use to increase the performance of Replicat. BATCHTRANSOPS option Controls the maximum number of batch operations that can be grouped into a transaction before requiring a commit. When BATCHTRANSOPS is reached, the operations are applied to the subscriber. 500 BYTESPERQUEUE option Sets the maximum number of bytes that one queue can contain. After BYTESPERQUEUE is reached, a subscriber transaction is executed. The default is 20 MB. However, Teradata strongly recommends setting this value to 1,000,000. Otherwise, Oracle GoldenGate may overwrite the ODBC buffer, causing Replicat to fail. 1,000,000 GROUPTRANSOPS Controls the number of records that are grouped into a Replicat transaction. 1,000 Teradata Replication Services Using Oracle GoldenGate 37

38 Chapter 4: System Set-up and Operations Operational Considerations Parameter Type Parameter Name Purpose Manager AUTOSTART Starts Extract and Replicat processes when Manager starts. This can be useful, for example, if you want Oracle GoldenGate to start immediately when you start the system, assuming Manager is part of the startup routine. The command syntax is: Teradata Recommendation Set to start the primary Extract and Replicat processes if the replication server restarts. AUTOSTART ER EXTRACT REPLICAT A A group_name wildcard 1152A Teradata Replication Services Using Oracle GoldenGate

39 Chapter 4: System Set-up and Operations Operational Considerations DBS Control Utility Fields Affecting Replication You can use the DBS Control utility to change operating fields. They are in the General category and are referenced by number, as shown in the following table. Field Default Valid Values 34. Memory limit per transaction Recommended Value 2 pages pages 10 pages 35. Client reset timeout 300 seconds 0-65,535 sec 300 seconds 36. TempStoragePageSize 4 KB (4,096 bytes) 1-1,024 KB 80 KB 37. Spill file path MP-RAS: /var/tdrsg Linux: /var/opt/teradata/ tdtemp/tdrsg Windows: TDAT\tdTemp\tdrsg where TDAT is typically: C:\Program Files\Teradata\TDAT Any existing path None 49. TempLargePageSize 64 KB 64-1,024 KB Greater than or equal to TempStorage PageSize 50. RepCacheSegSize 512 KB 64-4,096 KB 512 KB where: Field Memory limit per transaction Client reset timeout Description The maximum amount of in-memory storage that the RSG can use to store the records for one transaction. If a transaction exceeds this storage, it is moved to a disk spill file. The purpose of this limit is to prevent a few large transactions from swamping memory. Set this limit large enough to accommodate most expected transactions. How long the RSG should wait for Oracle GoldenGate to reconnect after a communication failure or reset before spilling transactions to disk. Teradata Replication Services Using Oracle GoldenGate 39

40 Chapter 4: System Set-up and Operations Operational Considerations Field Temporary storage page size Spill file path TempLargePageSize RepCacheSegSize Description The memory allotment for RSG temporary storage. If a transaction contains any record that exceeds the page size, the RSG allocates memory from the large page size defined by the TempLargePageSize field. If the large page size cannot hold the record, the entire transaction is spilled to disk. A directory that is used by the RSG for spill files. On Windows and Linux platforms, you can specify a path that is relative to the tdtemp directory. Specifies the size of the large memory allocation page used for temporary storage in the RSG. If a transaction contains any record that exceeds the standard page size defined by the Temporary Storage Page Size field, the RSG allocates memory using the large page size. If the record exceeds the large page size, the entire transaction is spilled to disk. Specifies the size of the cache segment in each AMP that stores data objects used specifically for replication. These data objects consist of executable code and related metadata used to convert row images into an external format. There is a unique replication data object for each replicated table. Teradata Replication Services references this object each time it processes a row image for replication. Therefore, the cache segment must be large enough to contain this object for each table actively being replicated. A typical 20-column table uses about 5,500 bytes of cache. Note: These fields are global for a server, not specific to a particular replication group. Therefore, consider the worst case scenario when setting these fields. Avoiding Replication While Loading If you are loading a table (via MultiLoad, Tpump, or BTEQ), but you do not want the loaded rows to be replicated (for example, because they are being dual loaded, or it is an ELT operation, where the final results of the transforms will be replicated), issue the SET SESSION OVERRIDE REPLICATION ON statement to prevent replication for that session only. The operations of other sessions on the tables are replicated normally. 40 Teradata Replication Services Using Oracle GoldenGate

41 Chapter 4: System Set-up and Operations Teradata Transaction Commit Protocols Teradata Transaction Commit Protocols If tables defined as part of a replication group have constant update activity, Teradata Database continually sends information about the updates to Oracle GoldenGate. The update messages contain: Begin and end transaction records, which delimit each set of change records for an SQL transaction. A count of change records in the transaction Choosing a transaction commit mode is required as part of replication group setup on the source system. There are two modes of transaction commit available for a replication group. Commit Mode Maximum Protection Maximum Performance Description Offers the highest level of data protection for replication. Transactions are not committed in Teradata Database until Oracle GoldenGate acknowledges receipt of all data for the transaction. Teradata strongly recommends that you use Maximum Protection mode. Maximum Protection mode employs a two-phase commit protocol between the source database and the Extract process to ensure that no transactions are lost or applied more than once in the event of a hardware or software failure. Use of this protocol results in increased transaction latency and reduced throughput. Note: Two-phase commit is used only for DML transactions. DDL transactions never have an in-doubt phase. Extracts change data with the minimum impact to normal Teradata Database performance. Transactions are committed on the Teradata platform and back to the client at the same time as transaction data is sent to Oracle GoldenGate. If the replication server disconnects while Teradata is transmitting transaction change data, the data for that transaction is lost. To recover transactions that might be lost in the event of failure, Teradata recommends that you use checkpoints and other resynchronization techniques. DDL replication is not supported in this mode. Handling Disconnections Between Servers If the connection between Extract and the source Teradata Database is interrupted, Teradata Database handles the uncommitted data depending on the transaction commit mode chosen. For details beyond the following overview, see the Replication Services Recovery Procedures Document for Teradata Database at: Under Knowledge, select Asset Repository Sites Search. Under Select Repositories to Search, select Asset Repository. Teradata Replication Services Using Oracle GoldenGate 41

42 Chapter 4: System Set-up and Operations Teradata Transaction Commit Protocols Note: This web site is restricted to Teradata associates only. Customers who need this document should contact their Teradata representative. Under Maximum Protection Mode If the connection between Extract and the source Teradata Database is interrupted under maximum protection mode, Teradata Database still processes transactions, but they are not committed back to the client. Transaction processing continues until the threshold set in the Client Reset Timeout field of the DBS Control utility is reached. For more information, see DBS Control Utility Fields Affecting Replication on page 39. IF Oracle GoldenGate reconnects... THEN... before the time limit expires the system sends Oracle GoldenGate the changed data for all transactions held by the server. the transactions are committed to the client. after time limit expires The Teradata dynamic workload management software blocks all incoming transactions to tables in replication groups. The DBS aborts all transactions not acknowledged by Oracle GoldenGate. Note: The aborted transactions may include some transactions sent to Oracle GoldenGate before the disconnection occurred. The system records each aborted transaction as a row in the DBC.InDoubtResLog table. When Oracle GoldenGate reconnects after the timeout period, TAM: Reads the rows in DBC.InDoubtResLog to find the in-doubt transactions that the server aborted. Notifies Oracle GoldenGate to abort those transactions. If the replication server resets while Oracle GoldenGate is disconnected, any outstanding transactions remain in the in-doubt state and the timer is started again. If Oracle GoldenGate reconnects: Before the time limit expires, Oracle GoldenGate and Teradata Database coordinate to determine which transactions Oracle GoldenGate received. The received transactions are committed, while the remaining in-doubt transactions are rolled back. After the time limit expires, the outstanding transactions are aborted. 42 Teradata Replication Services Using Oracle GoldenGate

43 Chapter 4: System Set-up and Operations Teradata Transaction Commit Protocols Under Maximum Performance Mode If the connection between Extract and the source Teradata Database is interrupted under maximum performance mode, updates to replicated tables are allowed to continue. The system extracts and maintains the change data on the server up to the time limit specified by Client Reset Timeout field of the DBS Control utility. Transactions that were extracted at the time of the disconnection but not yet committed to the trail file will be lost. For more information, see DBS Control Utility Fields Affecting Replication on page 39. IF Oracle GoldenGate reconnects... THEN... before the time limit expires the system sends Oracle GoldenGate the changed data for all transactions held by the server. after time limit expires The RSG stops collecting change data but updates to tables in the replication group are allowed to continue. Change data already extracted from the server is discarded. If the replication server resets while Oracle GoldenGate is: Disconnected, the change data for transactions committed during that period is lost. Connected, transactions committed back to the client but not yet fully received by Oracle GoldenGate are lost. Transactions not yet committed to the client are rolled back, and an error is returned to the client process. Handling Backlog Change Data If a transaction generates large volumes of change data, Teradata Replication Services Using Oracle GoldenGate spills the in-memory transaction data to disk on the nodes on which RSG vprocs are configured. The system writes to a separate disk file for each transaction so that transactions can be transmitted to Oracle GoldenGate and deleted from disk as they are committed. Teradata Replication Services Using Oracle GoldenGate generates a unique file name for the data of each transaction. The system writes all files to the spill file directory, located as specified in Configure RSG Vprocs on page 34. If disk space is exhausted, the effect is the same as if the timeout interval expired. A single error log entry is created. Teradata Replication Services Using Oracle GoldenGate 43

44 Chapter 4: System Set-up and Operations Setting Up Replication Groups Setting Up Replication Groups Creating a Replication Group The first step in replicating changes in Teradata is to create a replication group on the source Teradata Database. Either: Issue the CREATE REPLICATION GROUP statement (using BTEQ or Teradata SQL Assistant). Specify at least one existing table for which you want to extract changes. You may add more tables to the group later by using the ALTER REPLICATION GROUP statement. You may also define rules for automatically capturing new tables as they are created. A table can belong to only one replication group. Write down the Group ID and the Security Token that result from creating a replication group and manually insert them into the TAM initialization file. Specify the CreateGroupStmtFile TAM initialization parameter (giving it the name of a file that contains the CREATE REPLICATION GROUP statement). Using this method, the Extract process scans the TAM.ini file, executes the CREATE REPLICATION GROUP statement, updates the TAM.ini file with the Security Token and the Group Id, and begins replication. You can only use this method the first time you use TAM. For information on... the SQL syntax for defining, changing, and using replication groups the TAM initialization parameters, including CreateGroupStmtFile See... Chapter 6: Teradata SQL. Chapter 5: TAM Initialization Parameters. Creating a Replication Rule Set To make just-created tables part of a replication group automatically and to replicate SQL changes on objects that are not tables, create a replication rule set using the CREATE REPLICATION RULESET statement. This statement creates one or more rules, names the rule set, and associates it with a specified replication group. After you create a rule set, a Data Definition Language (DDL) statement will be replicated if it: Changes a table that is in a replication group Changes a replication group itself Matches a user-defined rule You can create a replication rule set in addition to a replication group. You must create a rule set (which could even be empty) if you want to enable automatic replication of DDL. The following sections describe how DDL statements are applied after you define a rule set for a replication group. 44 Teradata Replication Services Using Oracle GoldenGate

45 Chapter 4: System Set-up and Operations Setting Up Replication Groups DDL Affecting Group Members These DDL statements affecting the definition of a table in a replication group will be automatically captured: ALTER TABLE <table name> ALTER TRIGGER <table name> COLLECT STATISTICS ON <table name> COMMENT ON COLUMN <table name>.<column name> COMMENT ON TABLE <table name> CREATE [UNIQUE] INDEX ON <table name> DROP INDEX ON <table name> DROP STATISTICS ON <table name> DROP TABLE <table name> GRANT ON <table name> RENAME TABLE <table name> TO REVOKE ON <table name> There are two forms of the COMMENT statement. Only the DDL form, COMMENT (Comment-Placing Form), is captured for replication. See COMMENT (Comment Placing Form) on page 73. There are two forms of the COLLECT STATISTICS and DROP STATISTICS statements and only the Optimizer forms of each are captured for replication. The system does not capture the Query Capture Database forms of these statements for replication. DDL Affecting Replication Group Properties These DDL statements changing a replication group itself will be automatically captured: ALTER REPLICATION GROUP, with ADD and/or DROP clauses CREATE REPLACE REPLICATION RULESET DROP REPLICATION RULESET DDL Matching User-Defined Rules The following will be captured automatically if they match user-defined rules: Newly created tables Global temporary tables Views Macros Hash indexes Join indexes Triggers Teradata Replication Services Using Oracle GoldenGate 45

46 Chapter 4: System Set-up and Operations Setting Up Replication Groups DDL Replication Requirements Do the following to avoid the failure of DDL replication: Define object definitions, replication groups, and replication rule sets identically on the source and subscriber systems. Use the ASSUMETARGETDEFS parameter in the Replicat parameter file. Specify the PASSTHRU parameter in the parameter files for sort extract and pump extract. For examples, see Step 3: Create a Sort Parameter File (/ggs/dirprm/sort.prm) on page 121 and Step 4: Create a Pump Parameter File (/ggs/drprm/pump) on page 121. PASSTHRU prevents conflicting versions of metadata that cause replication failure. Do not use the UTF-16 character encoding for UNICODE. DDL replication is not supported for UTF-16. Do not use the GoldenGate RANGE option for applying data. It is not supported with DDL replication. Do not use Maximum Performance mode, which does not support DDL replication. For information on... the PASSTHRU and ASSUMETARGETDEFS parameters See... the Oracle GoldenGate Reference Guide. setting up DDL replication DDL Replication Setup Example on page 129. Configuring with Multiple Replication Groups If you have multiple applications, each with a unique set of tables, you can: Create separate replication groups for the tables for each application. Configure a separate Extract process for each replication group. An Extract process can belong to only one replication group at a time. Configure Sort Extracts and Pump Extracts to follow each initial Extract process. The following figures show two configurations for replicating tables for the same applications, A (tables A1 - An), B (tables B1 - Bn), and C (tables C1 - Cn). Figure 5: Configuration with all tables in one replication group and connected to all RSGs. Node Node Node Node Extract for replication group X, containing tables for applications A, B, and C Replication Server Apply Teradata Platform 1152A Teradata Replication Services Using Oracle GoldenGate

47 Chapter 4: System Set-up and Operations Setting Up Replication Groups The following figure shows each set of tables in a separate replication group, and connected to the replication server via all RSGs. Figure 6: Recommended configuration with tables separated into different replication groups and connected to all RSGs. Node Node Node Teradata Platform Extract for replication group A, containing tables for application A Extract for replication group B, containing tables for application B Extract for replication group C, containing tables for application C Replication Server Apply Apply Apply 1152A023 The advantages of separating the tables into as many replication groups as possible are: You can configure multiple replication servers if the total replication rate exceeds the throughput capacity of a single server. You can divide the applications between the servers (have some active on one server and others on the other server) to get maximum effectiveness from both servers. Remember, however, that transactions must be wholly contained within a replication group. Throughput is better. With multiple groups, the overall capacity can be more than that of any single group. With multiple Extracts, you can optimize the use of the replication server. This is important because the system processes the data transfer phase of SQL DML one DML statement at a time (although the rest of the transaction is processed in parallel). You can manage each group individually. This is an advantage because any action that involves a state change to the replication group or the Oracle GoldenGate processes can impact all the tables in the group. Viewing Detailed Information on a Replication Group Submit a HELP REPLICATION GROUP request to see the group name, group identifier, table states, and transaction commit mode for a specific replication group. For more information, see HELP REPLICATION GROUP on page 95. Teradata Replication Services Using Oracle GoldenGate 47

48 Chapter 4: System Set-up and Operations Replication Group Best Practices During Bulk Loading Replication Group Best Practices During Bulk Loading IF the tables... are maintained exclusively by bulk loading may be loaded concurrently are dependent and must be updated simultaneously THEN... dedicate one replication group per table. If that is not feasible, put tables with similar load methods and batch volumes in the same group. put them into separate replication groups to minimize competition for the same resources. put them into one group to preserve data integrity. Teradata Parallel Data Pump (TPump) Because TPump generates many concurrent transactions, the replication workload is distributed across all the RSGs that are assigned to the replication group. The PACK parameter value you select in the TPump BEGIN LOADING statement determines the transaction size, which in turn affects the use of RSG temporary storage. For best performance, set these DBS Control fields as follows: The RSG page size (TempStoragePageSize) should be larger than the change row size or if update before images are being extracted (see theupdatebeforeimages TAM parameter), twice the size of the change row image. Memory limit per transaction should be large enough to accommodate all the change data for most transactions. MultiLoad The replication workload generated by MultiLoad is distributed across all the RSGs assigned to the replication group and applied as SQL INSERT/UPDATE/DELETE statements on the subscriber. Unlike SQL DML, a MultiLoad batch is not committed to the replication system as a single transaction. Individual block updates are committed to disk on the source and treated as pseudo-transactions. MultiLoad pseudo-transactions require special best practices and transaction handling considerations. MultiLoad Best Practices To achieve the best performance and reliability with MultiLoad: Set the DBS Control field TempStoragePageSize large enough to accommodate a complete set of changed row images for one data block. Prevent ambiguous table states during failovers: 48 Teradata Replication Services Using Oracle GoldenGate

49 Chapter 4: System Set-up and Operations Replication Group Best Practices During Bulk Loading If the replication group contains only tables that are loaded using MultiLoad exclusively, stop Replicat before starting MultiLoad and resume it only after the MultiLoad job completes successfully. All of the changes for the batch are sent to the trail file. If a failover occurs while Replicat is stopped, you can switch the MultiLoad job that was active on the source to the subscriber (with SET SESSION OVERRIDE REPLICATION ON). You can then discard the source trail. Use separate replication groups for tables that are loaded using MultiLoad and tables that are not. Therefore, only the groups using MultiLoad have to stop replication while a load job finishes. Transaction Handling Considerations The MultiLoad pseudo-transactions also effect transaction handling: MultiLoad cannot use the two-phase commit protocol because the pseudo-transactions do not correspond to real transactions on the source. Updates may be duplicated if MultiLoad is restarted after an interruption (for example, a DBS restart) because MultiLoad resubmits the data from its last checkpoint. To recover the MultiLoad job, at recovery time, add the REPERROR parameter to the Replicat parameter file to ignore duplicates. Remove this parameter after recovery completes so that valid duplicate row errors can be identified. Detailed Recovery Procedures for MultiLoad For step-by-step information on handling failovers when using MultiLoad, see the Replication Services Recovery Procedures Document for Teradata Database at: Under Knowledge, select Asset Repository Sites Search. Under Select Repositories to Search, select Asset Repository. Note: This web site is restricted to Teradata associates only. Customers who need this document should contact their Teradata representative. Bulk SQL Bulk SQL refers to SQL DML statements, such as MERGE or INSERT SELECT, that are often used for data loading, as well as deletes and UPDATE WHERE statements. These statements may generate large amounts of change data. Since SQL statements are always contained within a single transaction, all the change data for the statement are directed to a single, randomly selected RSG. The Memory limit per transaction field prevents such large transactions from monopolizing RSG memory resources to the detriment of other kinds of transactions. The use of only one RSG sets an upper limit on the size of the batch you can process. Note: Since bulk SQL transactions normally use spill files, it is important to ensure that there is adequate disk space on each node. The default spill file directory is system disk that is used for other important files. Calculate your maximum space requirements by multiplying the number of rows in your replication tables by the size of each row. If your Teradata system runs Teradata Replication Services Using Oracle GoldenGate 49

50 Chapter 4: System Set-up and Operations Replication Recovery Procedures Overview out of spill file space, it forces a disconnect from the replication server to free up spill file space. Replication Recovery Procedures Overview Switchover Procedure The subscriber (secondary) system may assume the role of the source (primary) system in either of two scenarios: Switchover: A planned action. Failover: An unplanned outage of the source system. Note: The following instructions include the assumptions that all replication groups are defined identically on both systems, and that the Extract and Replicat processes are set up to perform replication in either direction. Note: This procedure refers to the Extract processes that extract changes on the source system as primary extract groups. Extract groups that extract changes on the subscriber system are secondary extract groups. A primary replicat group is one that receives change data from a primary extract group. In either case, the procedure is: 1 Wait until all the trail files are applied to the subscriber system. 2 If any of the replicated tables have identity columns, reset the sequence generators using the Procedure To Reset Identity Column Sequence Generators on page Start all the secondary Extract groups to begin capturing changes to the replicated tables on the subscriber system. 4 Redirect updates and load applications to the subscriber system. While the source system is down, Oracle GoldenGate collects the redirected updates and loads in trail files on the replication server. When the source system is back online, the subscriber Replicat processes apply the collected updates to catch up the source. The procedure for switchover is similar to the procedure for failover. The difference is that switchover is planned, so you have time to quiesce the update and load activity on the source before taking it offline. To ensure that the replication system does not miss any updates, do not terminate any replication groups. Subscriber System Outage Considerations If the subscriber system becomes unavailable or if a primary replicat group is stopped, change data continues to accumulate in the trail files as long as there is enough disk space, and no changes are lost. 50 Teradata Replication Services Using Oracle GoldenGate

51 Chapter 4: System Set-up and Operations Replication Recovery Procedures Overview Down Node Handling If an RSG is unavailable for any reason, such as a node failure, the DBS restarts and replication continues to function via the remaining RSGs. Procedure To Reset Identity Column Sequence Generators Do the following to make sure that the sequence generators do not generate any values that are already used: 1 Submit this query to identify all the replicated tables that have identity columns: select d.databasename, t.tvmid, t.tvmname, tf.fieldname from dbc.tvm t, dbc.tvfields tf, dbc.repgrouptables rt, dbc.idcol i, dbc.dbase d where rt.basetblid = t.tvmid and i.tableid = t.tvmid and d.databaseid = t.databaseid and tf.tableid = t.tvmid and tf.idcoltype is not null; 2 For each table identified by the preceding query: a Construct and execute a statement to get the current maximum value of the identity column: declare curmax decimal(18,0); select max(<<column name>>) from <<table name>> into curmax; b Construct and execute a statement to set the next available sequence number for a table: update DBC.IdCols set AvailValue = curmax + Increment where TableId = <<table id>>; Note: Step 2a assumes that identity column increments are positive. For negative increments, select min(<<column name>>). Step 2b requires bypassing privileges. Replication Server Failure RSGs on the source system must detect and respond to a disconnection from the replication server. RSGs detect a direct disconnect immediately, which allows them to gracefully clean up their connections. An example of a direct disconnect is termination of the Extract process. However, if the replication server drops off the network, no error condition is reported. If the connection to Oracle GoldenGate is idle, the disconnection is not detected immediately. When an RSG tries to send change data to the replication server, TCP detects a disconnection and signals the RSGs to take appropriate action. As a workaround, if the replication server fails, either: Restart Teradata Database to force a complete recovery Generate replication activity, which causes the RSGs to immediately detect the failure and drop their connections Teradata Replication Services Using Oracle GoldenGate 51

52 Chapter 4: System Set-up and Operations Character Sets and Replication Replicat Checkpoint Table Replicat maintains checkpoints that provide a position in the trail file from which to start after a failure. To improve data recovery and integrity, Teradata recommends that you create a Replicat checkpoint table on the subscriber database. Use this optional table in addition to the checkpoint file that Oracle GoldenGate maintains by default in the GoldenGate directory. For the procedure to create a checkpoint table, see Oracle GoldenGate for Windows and UNIX Reference Guide. Detailed Replication Recovery Procedures For detailed recovery procedures for many different situations, including use of MultiLoad, see Replication Services Recovery Procedures for Teradata Database at: Under Knowledge, select Asset Repository Sites Search. Under Select Repositories to Search, select Asset Repository. Note: This web site is restricted to Teradata associates only. Customers who need this document should contact their Teradata representative. Character Sets and Replication Oracle GoldenGate supports replication of the following character sets between Teradata platforms: LATIN (single byte character set) UNICODE (double-byte character set) KANJISJIS (multi-byte character set) Oracle GoldenGate also supports replication of the following character sets between different system types: LATIN UNICODE Wherever UNICODE and KANJISJIS are used, the following limitations exist: Source and subscriber character sets must be the same type. Data must be sent in PASSTHRU mode. No filtering, transformations, or changing of character sets is allowed. Oracle GoldenGate supports only ASCII-based table and column names. UNICODE and KANJISJIS table names and column names are not supported. Oracle GoldenGate does not support DDL replication for the UTF-16 character encoding for UNICODE. 52 Teradata Replication Services Using Oracle GoldenGate

53 Chapter 4: System Set-up and Operations Disk Space Considerations Disk Space Considerations When estimating disk space for replication, plan for occasions when the subscriber system is down and unapplied data accumulates. The amount of disk space determines how long your replication system can support an outage. When disk space is exhausted, you must stop Replication Services. To determine your disk space requirements in these situations, consider the: Longest expected downtime Average rate of inserts, updates, and deletes for each table being replicated Row size per table for each insert, update, and delete stored in the Oracle GoldenGate trail file Caution: Avoid allowing replication to proceed for an extended period with Extract rates exceeding Replicat rates. To ensure Oracle GoldenGate frees disk space no longer needed after extracts are complete, set the PURGEOLDEXTRACTS parameter in the Manager parameter file. If you do not set this parameter, you are keeping old trail files, which may cause you to exceed available disk space. For more information about this option, see Oracle GoldenGate Reference Guide for Windows and UNIX. For best performance, the trail files should be distributed across as many disks as are available. In addition, the trail files for different replication groups should be distributed across as many disks as are available. For a highly active group, use multiple trail files and place them on as many different disk drives as possible. Oracle GoldenGate also requires space for temporary storage for Extract sorts. Teradata recommends that different disks be dedicated to different replication groups, Extract trail files, sorted trail files, and Replicats. Replication and the Archive/Recovery Utility The Archive/Recovery utility does not back up or restore replication information. Replicated tables may be backed up without restriction, but the replication state of the table is not preserved in the archive. Replication group definitions are not preserved in the archive, even an archive of the DBC database. Archive/Recovery cannot restore: A table that is a member of a replication group A database that contains any tables that are members of a replication group After a restore of database DBC, no replication groups exist in the restored system. Teradata Replication Services Using Oracle GoldenGate 53

54 Chapter 4: System Set-up and Operations Table Keys and Uniqueness Constraints Table Keys and Uniqueness Constraints For correct results, all rows must have a unique key because Oracle GoldenGate applies changes on the subscriber system as single-row operations. Oracle GoldenGate gets key information and other table metadata from the source system. Teradata Database determines the unique key to be (in order of precedence): The declared primary key, if any The unique primary index, if any The first unique secondary index defined on the table, if any The entire set of columns (in which case, the table cannot be a multiset table) The unique key also determines how the parallel Replicat streams are partitioned with column conversion function. function divides the rows of a table across two or more Oracle GoldenGate processes. Rows with the same key value are always sent to the same trail file and processed in the correct order, but rows with different key values are not necessarily processed in order. Preventing Uniqueness Violations Either: Use the Replicat MAP parameter with the KEYCOLS option to choose a unique key that is never updated. Do not use function with tables that have multiple uniqueness constraints. For more information on the Replicat MAP parameter and column conversion function, see Oracle GoldenGate for Windows and UNIX Reference Guide, version Teradata Replication Services Using Oracle GoldenGate

55 Chapter 4: System Set-up and Operations Replication Limits Replication Limits Note the following Teradata or GoldenGate software limits when implementing replication: Parameter Value Maximum number of replication groups per system. 100 Maximum number of tables per replication group. 500 Maximum number of replicated tables allowed in the system. 10,000 Maximum VARCHAR column size for a replicated table. Maximum row size for a replicated table. Maximum number of columns that can be defined per replicated table. Maximum number of tables that can be copied simultaneously with a table copy operation. Combined maximum number of replication groups, tables that are members of a replication group, and replication group-to-rsg connections per system. 64,000 bytes 64,000 bytes 2, ,300 Replication-Related Restrictions The following restrictions apply to replication: If the replication source table has UNICODE data and a subscriber column is not defined as a UNICODE data type, data will not be properly replicated. Multiple Replicat streams with aggregate join indexes or hash indexes may cause deadlocks on the subscriber. Teradata Replication Services requires at least two active nodes at all times. You cannot have a configuration with one active node and one hot standby node. RSGs cannot migrate to hot standby nodes. When a node fails, the RSGs on that node are unavailable. When you initiate or terminate replication, Teradata Database obtains an exclusive lock on all tables in the replication group. Therefore, stop and start replication only when those tables are not being queried. Teradata Replication Services Using Oracle GoldenGate 55

56 Chapter 4: System Set-up and Operations Replication-Related Restrictions 56 Teradata Replication Services Using Oracle GoldenGate

57 CHAPTER 5 TAM Initialization Parameters TAM initialization parameters control: The connection between TAM and the Teradata system Tracing for TAM debugging The behavior and properties of TAM There must be a TAM parameter file (an initialization file) for each replication group. This chapter lists those parameters and discusses how to use them. Using the TAM Parameters TAM parameters properly initiate a replication group, so you should set the values for these parameters when you create a replication group. The settings remain until you reload the TAM libraries and restart the Extracts. Creating the TAM Initialization File 1 Use a text editor to create a text file. 2 Add the parameters to the file. See TAM Initialization Parameters on page Save the file with an.ini extension. For easy identification, the name of the initialization file can be the group name or any other name, for example, E1.ini. Specify the initialization file name with the TAM parameter in the Extract parameter file. After initial set-up, you can edit the file any time, for example, to turn on encryption, get before images, or set up tracing for debugging. To change the settings: 1 Quiesce the replication group. 2 Terminate the replication group. 3 Stop the Extract process. 4 Change the TAM.ini parameters. 5 Restart Extract. After TAM connects to the RSG, do not change the following TAM parameters, which specify RSG connection options: CharacterSet DataRSG[1...n] Teradata Replication Services Using Oracle GoldenGate 57

58 Chapter 5: TAM Initialization Parameters Using the TAM Parameters Encryption UpdateBeforeImages Issue a terminate command before you change any of these parameters. Otherwise, on reconnection, the RSG returns this error: The reconnect message does not match the connect message. Example The following is a sample initialization file. The sample does not necessarily illustrate recommended settings. Mode=Replication DictOdbcConnString=DSN=myDSN;uid=myUser;pwd=myPass MgmtOdbcConnString=DSN=myDSN GroupId=1234 SecurityToken=A8CCC932A6F5A0DA CreateGroupStmtFile=CreateMyGroup.sql CharacterSet=ASCII ControlRSG= :5298 ; (This is SMP005-4) vproc 9215 DataRSG1= :5298 ; (This is SMP005-4) vproc 9215 DataRSG2= :5298 ; (This is SMP005-5) vproc 9214 DataRSG3= :5298 ; (This is SMP005-6) vproc 9213 DataRSG4= :5298 ; (This is SMP005-7) vproc 9211 Encryption=None MaxCopyQueueSize=100 CopyThreadDataWaitSleep=0.5 Recovery If an Extract fails because of an improper TAM.ini parameter when capturing data (for example, UpdateBeforeImages was set to FALSE when it should have been TRUE), do the following: 1 Quiesce the replication group. 2 Restart the Extract with the same parameter setting. 3 Terminate the replication group. 4 Stop the Extract process. 5 Change the parameter to the correct setting. 6 Restart the Extract. 58 Teradata Replication Services Using Oracle GoldenGate

59 Chapter 5: TAM Initialization Parameters Using the TAM Parameters Enabling TAM Tracing You can run TAM tracing by issuing the following command from the GGSCI: ggsci> send extractname, vammessage"tam_trace:option" where: extractname is the name of the Extract option is one of the following: Option debug Purpose Turns on tracing of the entire replication process for use in debugging performance Reports the row processing rate for every 5,000 rows Reports the timestamp for BEGIN and END TRANSACTION, commit response, and transaction complete messages pollrsg all None Provides the following status for the polled RSGs: Whether the RSGs are idle or presenting data How many RSGs are presenting data RepCSN messages (merge cues) sent and replies received Combines the debug, performance, and pollrsg functions Turns off tracing Note: The tam_trace command performs the same functions as the TAM Tracing parameter and can be used instead of the Tracing parameter. However, tam_trace lets you turn off tracing while Extract is running, and the Tracing parameter does not. Teradata Replication Services Using Oracle GoldenGate 59

60 Chapter 5: TAM Initialization Parameters TAM Initialization Parameters TAM Initialization Parameters Parameter Value Description AltControlRSG Bidirectional server IP or name <address>[:<portnumber>] TRUE or FALSE Default = FALSE Optional, but highly recommended. The alternate control RSG takes over as the control RSG when the control RSG is down. It must be the address of the node that has the next highest RSG number in the system. If you do not specify AltControlRSG, TAM cannot connect to an alternate control RSG if the regular control RSG is down. Optional. Before images are used for ROLLBACK recovery. When a before image is created, a snapshot of an existing row is stored before any data is modified. This parameter specifies whether before images are sent from RSG to TAM. It must be set to TRUE if: Before images for updates are required No primary key has been defined for the table (no unique indexes and no KEYCOLS) The Extract parameter GETUPDATEBEFORES is specified. Setting this parameter to FALSE creates only after images for updates and has better performance. Caution: This parameter is now deprecated. It still functions but is being replaced the equivalent parameter UpdateBeforeImages. New users should use UpdateBeforeImages. CharacterSet ASCII or UTF16 Required. The character set for the replication group. If you set this parameter to UTF16, you must set the ODBC DSN to be UTF16 also. DDL replication is not supported for UTF16. For information on creating the ODBC DSN, see ODBC Driver for Teradata User Guide. ControlRSG server IP or name <address>[:<portnumber>] Example: node1:5298 Required. This parameter specifies the node address of the Control RSG, which is always RSG Optionally, you can specify the port number To determine the values for ControlRSG, see Determining the Values for the ControlRSG Parameter on page Teradata Replication Services Using Oracle GoldenGate

61 Chapter 5: TAM Initialization Parameters TAM Initialization Parameters Parameter Value Description CopyThreadData WaitSleep CreateGroupStmt File DataRSG[1..n] DictOdbcConn String Default = 0.5 (sec) Create Group statement file name Windows example: C:\ggs\dirsql\CreateGrou pstmtfile= CreateMyGroup.sql Linux example: /ggs/dirsql/ CreateGroupStmtFile=Crea temygroup.sql server IP or name <address>[:<portnumber>] Logon string Example: DictOdbcConnString=DSN=m ydsn;uid =myuser;pwd=mypass Optional. The timeout in number of seconds for a data thread waiting for data or for a queue block to be available. This parameter can be expressed as a whole number or with decimals. The name of this parameter is legacy code and is no longer accurate. This parameter applies to more than copies. Optional. The name of the file that contains the CREATE REPLICATION GROUP statement for a new group. Specify this file if the group does not exist when replication starts. There are two alternatives for creating a replication group: 1. Specify this parameter the first time you use TAM. The GroupID and SecurityToken values for the new replication group are automatically inserted in the TAM parameter file. 2. Use SQL to create the replication group and then manually insert the SecurityToken and GroupID TAM parameter values. Required. The RSG node address. Optionally, you can specify the port number Each of the Data RSGs is involved in replication. Teradata strongly recommends that you: Specify at least two RSGs Add a comment after each IP address, mapping it to the corresponding node name and RSG vproc ID, for example: DATARSG1= :5298 ; (This is SMP007-1) vproc 9211 Required. The logon string of a user with privileges to the dictionary tables. Encryption None Control Data All Required. The types of messages to encrypt. There is little difference in overhead between encrypting just data messages and encrypting both data and control messages. The values are: All = specify encryption None = no encryption Teradata Replication Services Using Oracle GoldenGate 61

62 Chapter 5: TAM Initialization Parameters TAM Initialization Parameters Parameter Value Description GroupId MaxCopyQueue Size MaxProtTrans CompleteThresh MgmtOdbcConn String Group ID generated by the CREATE REPLICATION GROUP statement Default = ,024 Default = 4 Logon string Example: MgmtOdbcConnString=DSN=m ydsn;uid= myuser;pwd=mypass Optional. There are two alternatives for creating a replication group: Specify the CreateGroupStmtFile parameter the first time you use TAM. The GroupID and SecurityToken values for the new replication group are automatically inserted in the TAM parameter file. Use SQL to create the replication group and then manually set the SecurityToken and GroupID TAM parameter values. Optional. Internal queue size to hold transactions. Refers to the maximum number of data blocks that the data threads can store in the queue. The name of this parameter is legacy code and is no longer accurate. This parameter applies to more than copies. Optional. Specifies the maximum number of outstanding transactions that can be held before checkpointing is requested. Used in maximum protection mode only. The value used can significantly affect performance. If there are many sessions applying transactions at a high rate, you can set the parameter to a relatively high value, such as 10. If the number of sessions is small or the Replicat rate lower, set this number to a small, single-digit value, such as 1-4. Required The logon string of a user with rights to execute management functions, such as CREATE REPLICATION GROUP. This logon requires the REPLCONTROL privilege. For more information on that privilege, see GRANT REPLCONTROL on page 93. Mode Replication Required. The type of operation to be performed. Replication specifies ongoing change in data extract. 62 Teradata Replication Services Using Oracle GoldenGate

63 Chapter 5: TAM Initialization Parameters TAM Initialization Parameters Parameter Value Description rsgtimeoutmsec rsgtimeoutsec SecurityToken 0-60,000,000 microsec Default = 10 Recommendation: Use the default value for any replication group that uses multiple RSG connections sec Default = 0 Recommendation: Use the default value for any replication group that uses multiple RSG connections. Hexadecimal string generated by the CREATE REPLICATION GROUP statement Optional. Specifies the fractional seconds of the RSG polling timeout interval. The RSG polling timeout interval is important when you have multiple RSG data connections. The RSG polling timeout interval determines how long TAM waits on an idle connection before asking the RSG to generate a dummy transaction to keep itself busy. If one RSG is idle, the merge processing of multiple transaction streams stalls. Use RsgTimeoutMSec with rsgtimeoutsec, which specifies whole seconds. For example, to specify an interval of seconds (50 millisec), set rsgtimeoutsec to 0 and rsgtimeoutmsec to 50,000. Optional. Timeout in seconds when polling the RSG for data. Optional. The security token for the replication group (if the group already exists). There are two alternatives for creating a replication group: Specify the CreateGroupStmtFile parameter the first time you use TAM. The GroupID and SecurityToken values for the new replication group are automatically inserted in the TAM parameter file. Use SQL to create the replication group and then manually set the SecurityToken and GroupID TAM parameter values. Tracing Debug Performance PollRSG All None Default = None Optional. Turns on TAM tracing for debugging. The TAM trace is stored in the Oracle GoldenGate directory in the <inifile>.log file. The log files roll over to.log1, log2.log5. For an explanation of the options, which are the same as for the tam_trace command, see Enabling TAM Tracing on page 59. Teradata Replication Services Using Oracle GoldenGate 63

64 Chapter 5: TAM Initialization Parameters TAM Initialization Parameters Parameter Value Description UpdateBeforeImages TRUE or FALSE Default = FALSE Optional. Before images are used for ROLLBACK recovery. Once a before image is created, a snapshot of an existing row is stored before any data is modified. This parameter specifies whether before images are sent from RSG to TAM. It must be set to TRUE if: Before images for updates are required No primary key has been defined for the table (no unique indexes and no KEYCOLS) The Extract parameter GETUPDATEBEFORES is specified. Setting this parameter to FALSE creates only after images for updates and has better performance. Other values that control replication include some DBS Control utility fields. For more information, see DBS Control Utility Fields Affecting Replication on page 39. Determining the Values for the ControlRSG Parameter To determine the values for ControlRSG: 1 At the Teradata command line, enter vprocmanager to start the vprocmanager utility. 2 Enter status to see all the vprocs, including the RSGs, and identify the host node for each vproc. 3 In the first column, find vproc 9215, which is always the Control RSG. Record the node number on which it appears. In the following example, vproc 9215 is on node Under PDE Physical Configuration, find the node with the Control RSG. Find the BYNET node name in the last column. In this example, the BYNET node name of vproc 3-07 is bambam1_bynet. 5 Enter quit to exit vprocmanager. 6 At the command line, issue the following command on any node of the Teradata system to get the network host name: pcl -shell hostname 7 Find the external network name, which appears after the BYNET node name. 64 Teradata Replication Services Using Oracle GoldenGate

65 Chapter 5: TAM Initialization Parameters TAM Initialization Parameters Example bambam1:~ # tdatcmd PDE running version is bambam1:~ # vprocmanager / / \ --- / / / / \ \ \ \ \ Release Version b VprocManager Utility (Sep 98) Enter a command, HELP or QUIT: status SYSTEM NAME: localhost 09/07/30 12:42:41 DBS LOGICAL CONFIGURATION Vproc Rel. Node Crash Vproc Config Config Cluster/ RcvJrnl/ Number Vproc# ID Movable Count State Status Type Host No. Host Type * Yes 0 ONLINE Online AMP 0 On Yes 0 ONLINE Online AMP 1 On Yes 0 ONLINE Online AMP 2 On Yes 0 ONLINE Online AMP 3 On Yes 0 ONLINE Online AMP 4 On Yes 0 ONLINE Online AMP 5 On Yes 0 ONLINE Online AMP 6 On Yes 0 ONLINE Online AMP 7 On Yes 0 ONLINE Online AMP 8 On Yes 0 ONLINE Online AMP 9 On Yes 0 ONLINE Online AMP 10 On Yes 0 ONLINE Online AMP 11 On Yes 0 ONLINE Online AMP 12 On Yes 0 ONLINE Online AMP 13 On Yes 0 ONLINE Online AMP 0 On Yes 0 ONLINE Online AMP 1 On Yes 0 ONLINE Online AMP 2 On Yes 0 ONLINE Online AMP 3 On Yes 0 ONLINE Online AMP 4 On Yes 0 ONLINE Online AMP 5 On Yes 0 ONLINE Online AMP 6 On Yes 0 ONLINE Online AMP 7 On Yes 0 ONLINE Online AMP 8 On Yes 0 ONLINE Online AMP 9 On Yes 0 ONLINE Online AMP 10 On Yes 0 ONLINE Online AMP 11 On Yes 0 ONLINE Online AMP 12 On Teradata Replication Services Using Oracle GoldenGate 65

66 Chapter 5: TAM Initialization Parameters TAM Initialization Parameters Yes 0 ONLINE Online AMP 13 On No 0 ONLINE N/A RSG 0 N/A No 0 ONLINE N/A RSG 0 N/A No 0 OFFLINE N/A RSG 0 N/A No 0 ONLINE N/A RSG 0 N/A No 0 ONLINE N/A GTW 1 COP No 0 ONLINE N/A GTW 1 COP No 0 ONLINE N/A GTW 1 COP No 0 ONLINE N/A GTW 1 COP Yes 0 ONLINE Online PE 1 COP Yes 0 ONLINE Online PE 1 COP Yes 0 ONLINE Online PE 1 COP Yes 0 ONLINE Online PE 1 COP Yes 0 ONLINE Online PE 1 COP Yes 0 ONLINE Online PE 1 COP Yes 0 ONLINE Online PE 1 COP Yes 0 ONLINE Online PE 1 COP * DBS Control AMP DBS State: Logons are enabled - The system is quiescent DBS RestartKind: COLD PDE PHYSICAL CONFIGURATION Node Node Clique Memory ID State Number CPUs (MB) CHANs LANs AMPs Node Name ONLINE bambam1_bynet 3-08 ONLINE bambam2_bynet 3-09 ONLINE bambam3_bynet 3-10 ONLINE bambam4_bynet PDE State: RUN/STARTED Enter a command, HELP or QUIT: quit Exiting VprocManager... bambam1:~ # pcl -shell hostname All 4 node(s) have connected < bambam3_bynet > bambam3 < bambam4_bynet > bambam4 66 Teradata Replication Services Using Oracle GoldenGate

67 Chapter 5: TAM Initialization Parameters TAM Initialization Parameters < bambam2_bynet > bambam2 < bambam1_bynet > bambam1 bambam1:~ # Teradata Replication Services Using Oracle GoldenGate 67

68 Chapter 5: TAM Initialization Parameters TAM Initialization Parameters 68 Teradata Replication Services Using Oracle GoldenGate

69 CHAPTER 6 Teradata SQL This chapter provides information on the Teradata SQL statements used to implement replication, showing only those statements (or statement options) specific to replication. The statements GRANT, REVOKE, SHOW, and COMMENT have many more options, which are not related to replication. To see the complete statement and more information on... GRANT REVOKE SHOW COMMENT (comment retrieving form) COMMENT (comment placing form) See... SQL Data Control Language. SQL Data Control Language. SQL Data Definition Language Syntax and Examples. SQL Data Manipulation Language. SQL Data Definition Language Syntax and Examples. Teradata Replication Services Using GoldenGate 69

70 Chapter 6: Teradata SQL ALTER REPLICATION GROUP ALTER REPLICATION GROUP Purpose Changes the definition of an existing replication group by adding tables to, or dropping tables from, the specified group. Syntax ALTER REPLICATION GROUP replication_group_name A A, ; ADD DROP database_name. database_name., table_name table_name,, ADD table_name, DROP table_name database_name. database_name. 1101B239 where: Syntax element replication_group_name ADD database_name Specifies the name of the replication group whose definition is to be changed. This name must be unique on the system. The specified replication group must already be defined. If it is not, the system aborts the request and returns an error to the requestor. that the set of table names that follows this keyword is to be added to the specified replication group definition. Any table you specify must observe the following rules: It must be a base table that is already defined in the system. It cannot belong to another replication group. If you specify both ADD and DROP clauses in the same ALTER REPLICATION GROUP statement, you must specify all the ADD clauses before you specify any of the DROP clauses. the name of the database that contains replication_group_name. This specification is optional if replication_group_name is contained within the current database. 70 Teradata Replication Services Using GoldenGate

71 Chapter 6: Teradata SQL ALTER REPLICATION GROUP Syntax element table_name DROP Specifies the name of a table to be added to, or dropped from, the replication group definition. that the set of table names that follows this keyword is to be dropped from the specified replication group definition. Any table you specify must be an existing member of the replication group. If you specify both ADD and DROP clauses in the same ALTER REPLICATION GROUP statement, you must specify all the ADD clauses before you specify any of the DROP clauses. ANSI Compliance Required Privileges ALTER REPLICATION GROUP is a Teradata extension to the ANSI SQL-2008 standard. REPLCONTROL Rules for Using ALTER REPLICATION GROUP If you do not specify either an ADD clause set or a DROP clause set, submitting an ALTER REPLICATION GROUP statement to the system changes the security token for the group. If you specify either an ADD clause set, a DROP clause set, or both, submitting an ALTER REPLICATION GROUP statement to the system does not change the security token for the group. If you specify both a set of ADD clauses and a set of DROP clauses, you must specify all the ADD clauses before you specify any of the DROP clauses. You cannot mix ADD and DROP clauses. If a change data capture or apply operation has been initiated for the named replication group, and a table is to be added to the group, the system sets the state of the table to the same state as the other tables in the replication group (see Viewing Detailed Information on a Replication Group on page 47 for descriptions of the various table states). The table set to be dropped from the set must be defined currently as members of the group. Otherwise, the system aborts the request. Any tables added to the replication group should be defined with one of the following unique constraints in which all columns have also been specified NOT NULL: Unique primary index Primary key Unique secondary index The uniqueness constraint facilitates the ability of the change data apply function to determine the correct target row for an update or delete operation. Teradata Replication Services Using GoldenGate 71

72 Chapter 6: Teradata SQL ALTER REPLICATION GROUP If a table of the replication group is not defined with a unique constraint, the change data apply function does not change the data row identifier that was assigned by the platform on which the change data row was generated. The platform on which the change row was created and the platform to which it is to be applied must use the same hashing algorithm. The platform on which the change row was created and the platform to which it is to be applied must have the same platform character set. The source and target tables must have the same column set defined as their primary index. Because ALTER REPLICATION GROUP is a DDL statement, it follows the general Teradata Database rule that it must be either the only statement in a transaction or, if there are other, non-ddl statements defined within the transaction, ALTER REPLICATION GROUP must be the last statement of the transaction. Example 1: Adding Tables To and Dropping Tables From a Replication Group The following example alters a replication group named receivables_group by adding tables named payables.invoices and payables.customer and dropping tables named payables.purchorder and payables.vendor: ALTER REPLICATION GROUP receivables_group ADD payables.invoices, payables,customer DROP payables.purchorder, payables.vendor; The security token for receivables_group is not changed as the result of this request. Example 2: Changing the Security Token for a Replication Group The following example changes the security token for a replication group named receivables_group: ALTER REPLICATION GROUP receivables_group; 72 Teradata Replication Services Using GoldenGate

73 Chapter 6: Teradata SQL COMMENT (Comment Placing Form) COMMENT (Comment Placing Form) Purpose Creates a user-defined description of a replication group in the data dictionary. Syntax COMMENT GROUP replication_group_name ON AS IS 'comment' ; 1152A039 where: Syntax Element... Specifies... GROUP replication_group_name AS IS comment the object type. the name of the replication group for which a comment is to be placed. an optional keyword that introduces a clause defining a comment string. the commentary on or description of the object name. Maximum string length is 255 characters from any supported client character sets. An existing string can be changed by specifying a new string. If no string is specified, any string previously stored is returned. ANSI Compliance COMMENT is a Teradata extension to the ANSI SQL:2008 standard. Required Privileges REPLCONTROL Example The following request places a comment on the replication group definition named receivables_group: COMMENT ON GROUP receivables_group AS 'This is the group for receivables'; Teradata Replication Services Using GoldenGate 73

74 Chapter 6: Teradata SQL COMMENT (Comment Placing Form) Related Topics See COMMENT (Comment Retrieving Form) on page 75 for information about the comment returning form of the COMMENT statement. 74 Teradata Replication Services Using GoldenGate

75 Chapter 6: Teradata SQL COMMENT (Comment Retrieving Form) COMMENT (Comment Retrieving Form) Purpose Retrieves a previously placed comment on a replication group. Syntax COMMENT GROUP replication_group_name ON ; 1152A038 where: Syntax Element... Specifies... GROUP replication_group_name the object type. the name of the replication group for which a comment is to be retrieved. ANSI Compliance COMMENT is a Teradata extension to the ANSI SQL:2008 standard. Required Privileges None Rules for Using COMMENT (Comment Retrieving Form) COMMENT (Retrieving Form) is treated as a DML statement for transaction processing, so it can be used in two-phase commit session mode (see Introduction to Teradata for a brief description of the two-phase commit protocol). You can specify a COMMENT (Retrieving Form) request at any point within the boundaries of an explicit transaction in Teradata session mode. To retrieve a comment, do not specify a comment string following the specification of the replication group name. Teradata Replication Services Using GoldenGate 75

76 Chapter 6: Teradata SQL COMMENT (Comment Retrieving Form) The following table explains this behavior in more detail: IF you... THEN the system... specify a comment string do not specify a comment string determines whether the specified replication group has an existing comment. If: It does: The system places the specified comment string for the replication group in the data dictionary. It does not: The system replaces the existing replication group in the data dictionary with the newly specified comment string. determines whether the specified replication group has an existing comment. If: It does: The system returns the text of that comment as it is stored in the data dictionary. It does not: The system returns a null. Example: Retrieving a Comment Suppose you placed the following comment describing the invoice column in the payables table: COMMENT ON GROUP payables.invoices IS 'Vendor name, followed by invoice date'; The following request retrieves this comment: COMMENT ON GROUP payables.invoices; Related Topics See COMMENT (Comment Placing Form) on page 73 for information about the comment placing form of this SQL statement. 76 Teradata Replication Services Using GoldenGate

77 Chapter 6: Teradata SQL CREATE REPLICATION GROUP CREATE REPLICATION GROUP Purpose Creates a replication group definition. Syntax CREATE REPLICATION GROUP replication_group_name A A where:, ( table_name ) database_name. user_name. ; 1101B236 Syntax element group_name database_name user_name Specifies a name for the defined replication group. See SQL Fundamentals for the rules for naming database objects. A replication group name must be unique among the complete set of replication group names on a Teradata platform. It cannot be qualified. the optional qualifying name of the database or user that contains table_name. See SQL Fundamentals for the rules for naming database objects. Notice that database_name or user_name is required if table_name is not contained within the current database. Teradata Replication Services Using GoldenGate 77

78 Chapter 6: Teradata SQL CREATE REPLICATION GROUP Syntax element table_name Specifies the optional name of a base table to be included in the defined replication group. See SQL Fundamentals for the rules for naming database objects. The following restrictions apply to any table included in the table list for this replication group: It must be a base table. It cannot be defined as a member of any other replication group. Its definition must already exist before you attempt to create the replication group (see CREATE TABLE in SQL Data Definition Language Syntax and Examples). If you create a group without specifying a table_name set, the group is called an empty group because it has no members. In this case, you must define a set of user-defined DDL capture rules using either the CREATE REPLICATION RULESET statement (see CREATE REPLICATION RULESET/ REPLACE REPLICATION RULESET on page 81) or the ALTER REPLICATION GROUP ADD statement (see ALTER REPLICATION GROUP on page 70). ANSI Compliance CREATE REPLICATION GROUP is a Teradata extension to the ANSI SQL:2008 standard. Required Privileges REPLCONTROL Replication Table States See Viewing Detailed Information on a Replication Group on page 47 for a list of table states and their definitions. Restrictions on Tables Defined To Be Replication Group Members All tables specified for inclusion in a replication group must be base data tables. The following cannot be members of a replication group: Dictionary tables Global temporary tables Global temporary trace tables Hash indexes Join indexes Recursive views Secondary index subtables Views Volatile tables You can replicate a primary platform table to a subscriber platform table having a different table definition if the subscriber table definition is a subset of the primary platform table definition. 78 Teradata Replication Services Using GoldenGate

79 Chapter 6: Teradata SQL CREATE REPLICATION GROUP For example, you can replicate a table that has 4 columns on the primary platform to a table that has 3 columns on the subscriber platform if the latter column set is a proper subset of the columns defined for the primary version of the table. You cannot replicate to a different table definition that defines more columns than the primary platform table definition. This operation is controlled by commands issued from the Oracle GoldenGate process, not by SQL requests issued from the primary Teradata platform. A table can belong to only one replication group. The definition for any table specified for inclusion in a replication group must already exist before you submit the CREATE REPLICATION GROUP request. You can add a table defined with an identity column to a replication group, but the identity column must be defined as GENERATED BY DEFAULT on the subscriber side. If you intend to replicate in both directions, the ranges of the values defined for the two systems must be disjoint. For example, the identity column values for one system might all be odd numbers, while those for the other system might all be even. If a replication group contains a multiset table, you might have to take the special action described in this bullet if you want duplicate rows in the table. When duplicate rows are updated or deleted, replication processes one operation for each of the duplicate rows. On the subscriber system, the first of those operations updates or deletes all of the duplicate rows. Any subsequent operations on those rows return a mapping error - record not found message to the requestor and, by default, the replication operation terminates. To avoid this problem, you can just log the error and then ignore it if you add the following lines in the Replicat parameter file: REPERROR DEFAULT, ABEND REPERROR 100, DISCARD This action permits the update and delete operations of the duplicate rows to replicate properly. However, it also has the side effect of logging the messages and continuing to replicate normally for other occurrences of the record not found error, which might be legitimate errors. Because CREATE REPLICATION GROUP is a DDL statement, it follows the general Teradata Database rule that it must be either the only statement in a transaction or, if there are other, non-ddl statements defined within the transaction, CREATE REPLICATION GROUP must be the last statement of the transaction. Multiple Change Data Apply streams containing aggregate join indexes or hash indexes can cause deadlock on the subscriber system. Any ODBC connections you define for use by the TAM or Oracle GoldenGate software should have a timeout setting of at least 3,600 seconds (1 hour). Teradata Replication Services Using GoldenGate 79

80 Chapter 6: Teradata SQL CREATE REPLICATION GROUP Rule for SQL Update Operations Against a Replication Group Member Table You can issue an SQL DML update statement (DELETE, INSERT, MERGE, or UPDATE) to a replication group member subscriber table while a change data apply operation is active. Example The following example creates a replication group named payables_group that includes the following three base tables, all of which are contained within the payables database on the primary platform: Invoices Purchorders Transactions CREATE REPLICATION GROUP payables_group ( payables.invoices, payables.purchorders, payables.transactions); 80 Teradata Replication Services Using GoldenGate

81 Chapter 6: Teradata SQL CREATE REPLICATION RULESET/ REPLACE REPLICATION RULESET CREATE REPLICATION RULESET/ REPLACE REPLICATION RULESET Purpose Creates a set of replication rules and associates them with the specified replication group and rule set name. Syntax CREATE REPLICATION RULESET rule_set_name FOR replication_group_name REPLACE, DEFAULT A A B AS object_kind LIKE string_literal C ESCAPE character_literal B C ; AND NOT LIKE string_literal ESCAPE character_literal 1101A553 where: Syntax element rule_set_name DEFAULT FOR replication_group_name Specifies the name of the newly created rule set or the name of the rule set to be replaced by a new definition. If you do not specify the optional clauses beginning with AS object_kind LIKE, Teradata Database creates an empty rule set, which enables automatic DDL replication. See SQL Fundamentals for the rules for naming database objects. that all the rules in the rule set are default rules. Teradata Database applies a default rule only if no other rule matches the replication object. Nondefault rules must not match the same object as a nondefault rule associated with another replication group. A default rule must not match the same object as a default rule associated with another replication group. the name of the replication group to which this rule set is assigned. Teradata Replication Services Using GoldenGate 81

82 Chapter 6: Teradata SQL CREATE REPLICATION RULESET/ REPLACE REPLICATION RULESET Syntax element AS object_kind Specifies one or more database objects to add to this replication rule set. The valid object kinds are specified using the keywords: INDEX MACRO TABLE TEMPORARY TABLE TRIGGER VIEW If you do not specify a rule specification clause, the defined rule set is empty. LIKE string_literal ESCAPE character_literal AND NOT LIKE string_literal pattern strings to match against the fully qualified names of the objects of certain SQL statements. The string literals can contain wildcard characters. Pattern string matching is not case-specific. Only the optimizer forms of COLLECT STATISTICS and DROP STATISTICS are subject to rule matching. Only the comment-placing form of the COMMENT statement is subject to rule matching. For details, see SQL Data Definition Language Detailed Topics. an escape character. The string literal specified with the [NOT] LIKE operator and the optional ESCAPE character are used together in the same way as the LIKE predicate operator. See SQL Functions, Operators, Expressions, and Predicates. pattern strings not to be matched against the fully qualified names of the objects of certain SQL statements. The string literals can contain wildcard characters. Pattern string matching is not case-specific. For details, see SQL Data Definition Language Detailed Topics. ANSI Compliance CREATE REPLICATION RULESET is a Teradata extension to the ANSI SQL:2008 standard. Required Privileges REPLCONTROL. Privileges Granted Automatically None. 82 Teradata Replication Services Using GoldenGate

83 Chapter 6: Teradata SQL CREATE REPLICATION RULESET/ REPLACE REPLICATION RULESET About CREATE REPLICATION RULESET The CREATE REPLICATION RULESET statement creates a set of one or more rules and associates them with a specified replication group and rule set name. Replication rules are used to accomplish the following: Make new tables automatically become members of a replication group. Replicate operations on objects that are not tables (for example, views, macros, triggers, and join indexes). IF you specify this form of the statement CREATE REPLACE AND a rule set with the same name already exists for the specified replication group, THEN the request fails. existing rule set is replaced by the new rule set. CREATE REPLICATION RULESET or REPLACE REPLICATION RULESET must be the only DDL statement in a transaction. If a transaction also contains non-ddl statements, then the CREATE REPLICATION RULESET or REPLACE REPLICATION RULESET request must be the last statement in the transaction. LIKE and NOT LIKE Matching Patterns for Hash and Join Indexes If the object_kind of a rule is INDEX, then the system matches the LIKE and NOT LIKE patterns to index_name in the following statement types: COLLECT STATISTICS ON index_name COMMENT ON index_name CREATE HASH INDEX index_name CREATE JOIN INDEX index_name DROP HASH INDEX index_name DROP JOIN INDEX index_name DROP STATISTICS ON index_name LIKE and NOT LIKE Matching Patterns for Macros If the object_kind of the rule is MACRO, then the system matches the LIKE and NOT LIKE patterns to macro_name in the following statement types: COMMENT ON MACRO macro_name CREATE MACRO macro_name DROP MACRO macro_name GRANT ON macro_name RENAME MACRO macro_name TO REPLACE MACRO macro_name REVOKE ON macro_name Teradata Replication Services Using GoldenGate 83

84 Chapter 6: Teradata SQL CREATE REPLICATION RULESET/ REPLACE REPLICATION RULESET LIKE and NOT LIKE Matching Patterns for Tables If the object_kind of a rule is TABLE, then the system matches the LIKE and NOT LIKE patterns to table_name for CREATE TABLE table_name request types. Other DDL operations on tables that are members of a replication group are automatically captured (see Automatic Replication of DDL Affecting Group Members on page 85). On a source system, if table_name matches a TABLE rule defined for a replication group, the table automatically becomes a member of the replication group. On a subscriber system, the table created by the captured CREATE TABLE statement is acquired as a member of a replication group (with the same name as on the source system). LIKE and NOT LIKE Matching Patterns for Global Temporary Tables A global temporary table cannot be a member of a replication group. A global temporary table can be replicated as a dictionary definition only, not in its materialized form. DDL statements that refer to the temporary materialized state of the table cannot be replicated. DDL statements that affect the global state of the object can be replicated. If the object_kind of a rule is TEMPORARY TABLE, then the system matches the LIKE and NOT LIKE patterns to table_name in the following statement types: COLLECT STATISTICS ON table_name COMMENT ON COLUMN table_name.column_name COMMENT ON TABLE table_name CREATE GLOBAL TEMPORARY TABLE table_name DROP STATISTICS ON table_name DROP TABLE table_name GRANT ON table_name RENAME TABLE table_name TO REVOKE ON table_name Note: Only the optimizer forms of COLLECT STATISTICS and DROP STATISTICS are subject to rule matching. Note: Only the comment-placing DDL form of the COMMENT statement is subject to rule matching and capture for replication. This applies to COMMENT statements for all supported DDL capture objects. Collecting or dropping statistics on a materialized global temporary table using the following statements is not subject to rule matching: COLLECT STATISTICS ON TEMPORARY table_name DROP STATISTICS ON TEMPORARY table_name 84 Teradata Replication Services Using GoldenGate

85 Chapter 6: Teradata SQL CREATE REPLICATION RULESET/ REPLACE REPLICATION RULESET LIKE and NOT LIKE Matching Patterns for Triggers If the object_kind of a rule is TRIGGER, then the system matches the LIKE and NOT LIKE patterns to trigger_name in the following statement types: ALTER TRIGGER trigger_name COMMENT ON TRIGGER trigger_name CREATE TRIGGER trigger_name DROP TRIGGER trigger_name RENAME TRIGGER trigger_name TO REPLACE TRIGGER trigger_name LIKE and NOT LIKE Matching Patterns for Views If the object_kind of a rule is VIEW, then the system matches the LIKE and NOT LIKE patterns to view_name in the following statement types: COMMENT ON COLUMN view_name.column_name COMMENT ON VIEW view_name CREATE [RECURSIVE] VIEW view_name DROP VIEW view_name GRANT ON view_name RENAME VIEW view_name TO REPLACE [RECURSIVE] VIEW view_name REVOKE ON view_name Automatic Replication of DDL Affecting Group Members If table_name is a member of a replication group, the following DDL statements are captured for replication on a subscriber system: ALTER TABLE table_name ALTER TRIGGER table_name COLLECT STATISTICS ON table_name COMMENT ON COLUMN table_name.column_name COMMENT ON TABLE table_name CREATE [UNIQUE] INDEX ON table_name DROP INDEX ON table_name DROP STATISTICS ON table_name DROP TABLE table_name a GRANT ON table_name RENAME TABLE table_name TO REVOKE ON table_name a. In the case of DROP TABLE, the affected table is automatically removed from the replication group. Teradata Replication Services Using GoldenGate 85

86 Chapter 6: Teradata SQL CREATE REPLICATION RULESET/ REPLACE REPLICATION RULESET The two forms of the COMMENT statement are handled as follows: This form of COMMENT comment-placing comment-retrieving IS captured. not captured. The two forms of the COLLECT STATISTICS and DROP STATISTICS statements are handled as follows: This form of COLLECT STATISTICS and DROP STATISTICS QCD optimizer IS not captured. captured. Automatic Replication of Replication Group Properties The following DDL statements that change the properties of replication groups are replicated automatically: ALTER REPLICATION GROUP (with ADD clauses, DROP clauses, or both) COMMENT ON GROUP (Comment Placing Form) CREATE REPLICATION RULESET REPLACE REPLICATION RULESET DROP REPLICATION RULESET An ALTER REPLICATION GROUP statement that is used to generate a new security token is not replicated. Example 1 Create a rule set named sales1 for the replication group named myrepgroup to capture any table that is created in the salesdb database and also capture any DDL that affects any view in salesdb where the view name does not have the suffix _s. CREATE REPLICATION RULESET sales1 FOR myrepgroup AS TABLE LIKE 'SalesDB.%', VIEW LIKE 'SalesDB.%' AND NOT LIKE '%z_s' ESCAPE 'z'; Notice the use of an ESCAPE character to override the normal treatment of the UNDERSCORE character (_) as a wildcard. 86 Teradata Replication Services Using GoldenGate

87 Chapter 6: Teradata SQL CREATE REPLICATION RULESET/ REPLACE REPLICATION RULESET Example 2 Create an empty rule set to enable automatic replication. CREATE REPLICATION RULESET dummyruleset FOR myrepgroup; Example 3 Conflicting rules in a rule set are generally not be detected at the time a rule set is created. Instead, they are usually detected when the rules are applied to the specified DDL statement. CREATE REPLICATION RULESET sales1 FOR myrepgroup AS TABLE LIKE 'SalesDB.Sales%' AND NOT LIKE 'SalesDB.%'; The system successfully creates this rule set, however there can never be a match for any DDL request such as the following: CREATE VIEW salesdb.salesv AS SELECT. FROM sales; Example 4 Rules for an object kind from different rule sets defined for a replication group are ORed together when the system is attempting to match with an object name. For example, the TABLE rules from rule sets sales1 and sales2 are ORed together to form the following TABLE rule: (('SalesDB.SalesNW_1' LIKE 'SalesDB.SalesNW%') OR ( 'SalesDB.SalesNW_1' LIKE 'SalesDB.SalesSE%')) The table salesdb.salesnw_1 satisfies the TABLE rule from rule set sales1. CREATE REPLICATION RULESET Sales1 FOR MyRepGroup AS TABLE LIKE 'SalesDB.SalesNW%'; CREATE REPLICATION RULESET Sales2 FOR MyRepGroup AS TABLE LIKE 'SalesDB.SalesSE%; CREATE TABLE SalesDB.SalesNW_1 ( Trans_Id Integer, Trans_Date TimeStamp, Trans_Qty Integer); In the following example, the TABLE rule condition for the replication group myrepgroup is the following: ((('SalesDB.SalesNW_1' LIKE 'SalesDB.SalesNW%') AND ('SalesDB.SalesNW_1' NOT LIKE 'SalesDB.SalesSE%')) OR (('SalesDB.SalesNW_1' LIKE 'SalesDB.SalesSE%') AND ('SalesDB.SalesNW_1' NOT LIKE 'SalesDB.SalesNW%'))) Teradata Replication Services Using GoldenGate 87

88 Chapter 6: Teradata SQL CREATE REPLICATION RULESET/ REPLACE REPLICATION RULESET The table salesdb.salesnw_1 satisfies the TABLE rule from rule set sales1. CREATE REPLICATION RULESET sales1 FOR myrepgroup AS TABLE LIKE 'SalesDB.SalesNW%' AND NOT LIKE 'SalesDB.SalesSE%'; CREATE REPLICATION RULESET sales2 FOR myrepgroup AS TABLE LIKE 'SalesDB.SalesSE%' AND NOT LIKE 'SalesDB.SalesNW%'; CREATE TABLE salesdb.salesnw_1 ( trans_id INTEGER, trans_date TIMESTAMP, trans_qty INTEGER); Example 5 Rule matching is not case-sensitive. In the following example, the table salesdb.salesnw_1 matches the TABLE rule defined by rule set sales1. Related Topics See: CREATE REPLICATION RULESET Sales1 FOR myrepgroup AS TABLE LIKE 'SalesDB.SalesNW%'; CREATE TABLE salesdb.salesnw_1 ( trans_id INTEGER, trans_date TIMESTAMP, trans_qty INTEGER); ALTER REPLICATION GROUP on page 70 CREATE REPLICATION GROUP on page 77 DROP REPLICATION GROUP on page 89 HELP REPLICATION GROUP on page 95 SHOW REPLICATION GROUP on page Teradata Replication Services Using GoldenGate

89 Chapter 6: Teradata SQL DROP REPLICATION GROUP DROP REPLICATION GROUP Purpose Drops the definition for the specified replication group and all rule sets associated with it. Syntax DROP REPLICATION GROUP replication_group_name ; 1101A240 where: Syntax element replication_group_name Specifies the name of the replication whose definition is to be dropped. See SQL Fundamentals for the rules for naming database objects. ANSI Compliance Required Privileges DROP REPLICATION GROUP is a Teradata extension to the ANSI SQL:2008 standard. REPLCONTROL Rules for Using DROP REPLICATION GROUP The name you stipulate for the replication group must specify an existing replication group on the server. The specified replication group cannot be participating in any change data capture functions at the time you submit the request. All tables defined as members of the replication group must be in one of the following states before you can drop the group definition: Defined Terminated Teradata Replication Services Using GoldenGate 89

90 Chapter 6: Teradata SQL DROP REPLICATION GROUP Because DROP REPLICATION GROUP is a DDL statement, it follows the general Teradata Database rule that it must be either the only statement in a transaction or, if there are other, non-ddl statements defined within the transaction, DROP REPLICATION GROUP must be the last statement of the transaction. Example The following example causes the definition for the existing replication group named inventory_group to be dropped from the Teradata platform. Tables that are members of the group cannot participate in change data capture functions after the DROP REPLICATION GROUP statement has been performed successfully. DROP REPLICATION GROUP inventory_group; 90 Teradata Replication Services Using GoldenGate

91 Chapter 6: Teradata SQL DROP REPLICATION RULESET DROP REPLICATION RULESET Purpose Removes a rule set from a replication group. If you drop a replication group, this is done automatically. Syntax DROP REPLICATION RULESET rule_set_name FOR replication_group_name ; 1101A554 where: Syntax element rule_set_name FOR replication_group_name Specifies the name of the replication rule set definition to be dropped. See SQL Fundamentals for the rules for naming database objects. name of the replication group for which the replication rule set is defined. See SQL Fundamentals for the rules for naming database objects. ANSI Compliance Required Privileges DROP REPLICATION RULESET is a Teradata extension to the ANSI SQL-2008 standard. REPLCONTROL. Privileges Granted Automatically None. DROP REPLICATION RULESET and Transactions Because it is a DDL statement, DROP REPLICATION RULESET must be the only DDL statement in a transaction. If the transaction also contains non-ddl statements, DROP REPLICATION RULESET must be the last statement of the transaction. Teradata Replication Services Using GoldenGate 91

92 Chapter 6: Teradata SQL DROP REPLICATION RULESET Example The following example drops the replication rule set sales1 from replication group myrepgroup: DROP REPLICATION RULESET sales1 FOR myrepgroup; Related Topics See: CREATE REPLICATION GROUP on page 77 CREATE REPLICATION RULESET/ REPLACE REPLICATION RULESET on page 81 DROP REPLICATION GROUP on page Teradata Replication Services Using GoldenGate

93 Chapter 6: Teradata SQL GRANT REPLCONTROL GRANT REPLCONTROL Purpose Assigns administrative replication privileges to a user. Syntax GRANT REPLCONTROL TO, user_name WITH GRANT OPTION ; 1152A041 where: Syntax Element... Specifies... REPLCONTROL user_name WITH GRANT OPTION two separate functions: The ability to define and manage replication groups. The ability to run SQL statements that change columnar data values for a table when that table is in a state that would not otherwise allow changes to be made. the recipient of the GRANT statement action, which can be one or more users. that the person granted REPLCONTROL can grant the privilege to others. ANSI Compliance GRANT REPLCONTROL is a Teradata extension to the ANSI SQL:2008 standard. Required Privileges You must be one of the following to grant the REPLCONTROL privilege: User DBC A user possessing the REPLCONTROL privilege Rules and Considerations REPLCONTROL is a total system privilege and is not granted to or revoked from specific tables or databases. Use extreme caution when granting REPLCONTROL. Teradata Replication Services Using GoldenGate 93

94 Chapter 6: Teradata SQL GRANT REPLCONTROL The username must be a unique identifier that is assigned to an existing system user. It cannot be the name of a role defined in the system. Any privilege granted can be revoked using the REVOKE statement. See REVOKE REPLCONTROL on page 100. GRANT takes effect immediately. You do not need to log out to receive a privilege that was just granted to you. Example: Granting the REPLCONTROL Privilege Related Topics The following example grants user BJ the privilege to create, alter, and drop replication groups. GRANT REPLCONTROL TO BJ; See REVOKE REPLCONTROL on page Teradata Replication Services Using GoldenGate

95 Chapter 6: Teradata SQL HELP REPLICATION GROUP HELP REPLICATION GROUP Purpose Reports detailed information about a replication group and its member tables. Syntax HELP REPLICATION GROUP replication_group_name ; 1101A237 where: Syntax element replication_group_name Specifies the name of the replication group for which an attribute report is desired. The specified replication group must be defined on the Teradata platform. ANSI Compliance Required Privileges HELP REPLICATION GROUP is a Teradata extension to the ANSI SQL:2008 standard. You must have the REPLCONTROL privilege to request a report of replication group attributes. Use the SHOW privilege to enable a user to perform HELP or SHOW requests only against a specified replication group. Teradata Replication Services Using GoldenGate 95

96 Chapter 6: Teradata SQL HELP REPLICATION GROUP Replication Group Details Submit a HELP REPLICATION GROUP request to see the group name, group identifier, table state, and transaction commit mode for a specific replication group. Attribute Data Type Description Group Name CHARACTER(30) The name assigned to the replication group at the time it was created. On a standard language support system, the data type for GROUP NAME is CHARACTER(30) CHARACTER SET LATIN. On a Japanese language support system, the data type for GROUP NAME is CHARACTER(30) CHARACTER SET UNICODE if a multibyte site-defined session character set such as UTF-8, UTF-16, Chinese, or Korean is used. For any other language support system, the data type for GROUP NAME is CHARACTER(30) CHARACTER SET KANJI1. Group ID INTEGER The system-assigned identifier for the replication group. Operation CHARACTER(1) Whether an Apply operation or a Capture operation is active. Set to null when the replication group is initially defined. The definition of the codes is as follows: A: An apply operation is active. C: A capture operation is active. NULL: No operation is active. Protection Mode CHARACTER The protection mode in effect during a Capture operation. Set to null when the replication group is initially defined. The definition of the codes is: Y: Maximum protection mode. N: Maximum performance mode. NULL: No capture operation is active. Status CHARACTER Indicates which SQL statements are permitted on the tables in that group. The table and the group status should be identical except when a user command suspends individual tables. Set to null when the replication group is initially defined. The definition of the codes appears in Replication Table Status on page Teradata Replication Services Using GoldenGate

97 Chapter 6: Teradata SQL HELP REPLICATION GROUP Replication Table Status Table Status Status Name Description C Connected Oracle GoldenGate connected to the server to start Extract. SQL SELECT statements are accepted on the table. DML statements are no longer accepted on the table. All SQL DDL is accepted except: ALTER TABLE on the replicated table DROP TABLE on the replicated table DROP DATABASE on the database that contains the replicated table D Defined The table is defined as a member of a replication group. The corresponding group state is NULL. Any type of SQL statement is accepted for the table. F Failed Oracle GoldenGate initiated replication but no longer responds to any TCP/IP communications from the server. SQL DML requests are processed depending upon how the replication group was connected: In maximum performance mode, DML requests are accepted. In maximum protection mode, the system aborts transactions in progress containing DML requests. The server holds new DML requests until Oracle GoldenGate reconnects. All SQL DDL is accepted except: ALTER TABLE on the replicated table DROP TABLE on the replicated table DROP DATABASE on the database that contains the replicated table I Initiated Oracle GoldenGate sent a control command to the server to initiate data capture. DML statements are accepted. All SQL DDL is accepted except: ALTER TABLE on the replicated table DROP TABLE on the replicated table DROP DATABASE on the database that contains the replicated table Teradata Replication Services Using GoldenGate 97

98 Chapter 6: Teradata SQL HELP REPLICATION GROUP Table Status Status Name Description S Suspended Oracle GoldenGate sent a suspend command to the server for the table. No DML statements that update data are accepted for the table. SQL SELECT statements are accepted. All SQL DDL is accepted except: ALTER TABLE on the replicated table DROP TABLE on the replicated table DROP DATABASE on the database that contains the replicated table T Terminated Oracle GoldenGate issued a terminate command for an Extract operation for the replication group. Any type of SQL DML statement is accepted for the table. All SQL DDL is accepted for except: ALTER TABLE on the replicated table DROP TABLE on the replicated table DROP DATABASE on the database that contains the replicated table ALTER TABLE requests that do not add, drop, or modify columns of a replicated table are acceptable when the table state is any of the following: Connected Failed Initiated Suspended You can add tables to a replication group in any state. You cannot restore from archive tables that are members of a replication group. To restore them, you must first drop them from the replication group. 98 Teradata Replication Services Using GoldenGate

99 Chapter 6: Teradata SQL HELP REPLICATION GROUP Example The following example requests information about the replication group named receivables_group: HELP REPLICATION GROUP receivables_group; The response is: HELP REPLICATION GROUP receivables_group; *** Help information returned. One row. *** Total elapsed time was 1 second. GroupName Identifier Operation MaxProtect receivables_group 1176 C Y I Status ***Help information returned. 2 rows. DatabaseName TableName Identifier Operation payables invoices C I payables transactions C I Status Teradata Replication Services Using GoldenGate 99

100 Chapter 6: Teradata SQL REVOKE REPLCONTROL REVOKE REPLCONTROL Purpose Revokes administrative replication privileges from a user. Syntax REVOKE GRANT OPTION FOR REPLCONTROL TO FROM, user_name ; 1152A042 where: Syntax Element... Specifies... GRANT OPTION FOR REPLCONTROL TO FROM user_name the ability to grant REPLCONTROL to others. REVOKE GRANT OPTION FOR revokes only the ability to grant the privilege to others but does not revoke the REPLCONTROL privilege itself. two separate functions: The ability to define and manage replication groups. The ability to run SQL statements that change columnar data values for a table when that table is in a state that would not otherwise allow changes to be made. the ANSI SQL-compatible choice: FROM. the non-ansi-compatible choice: TO. the recipient of the REVOKE statement action, which can be one or more users. ANSI Compliance REVOKE REPLCONTROL is a Teradata extension to the ANSI SQL:2008 standard. Required Privileges You must be one of the following to revoke the REPLCONTROL privilege: User DBC. A user possessing the REPLCONTROL privilege, WITH GRANT OPTION. 100 Teradata Replication Services Using GoldenGate

101 Chapter 6: Teradata SQL REVOKE REPLCONTROL Rules and Considerations REPLCONTROL is a total system privilege and is not granted to or revoked from specific tables or databases. The username must be a unique identifier that is assigned to an existing system user. It cannot be the name of a role defined in the system. REVOKE takes effect immediately. No logout is required. The system does not automatically revoke privileges previously granted by a user after that user is dropped from the system. Example: Revoking the REPLCONTROL Privilege The following example revokes from user Max only the privilege to grant REPLCONTROL: REVOKE GRANT OPTION FOR REPLCONTROL FROM Max; User Max still has the REPLCONTROL privilege himself. The following example revokes REPLCONTROL from user Max: REVOKE REPLCONTROL FROM Max; Related Topics See GRANT REPLCONTROL on page 93 for information about granting SQL privileges. Teradata Replication Services Using GoldenGate 101

102 Chapter 6: Teradata SQL SET SESSION OVERRIDE REPLICATION SET SESSION OVERRIDE REPLICATION Purpose Overrides the normal replication controls for the current session or reestablishes them after they have been overridden. Syntax SET SESSION OVERRIDE REPLICATION ON OFF ; 1101A238 where: Syntax element ON OFF Specifies that the normal replication controls are overridden for the current session or until you submit a SET SESSION OVERRIDE REPLICATION OFF statement. override of normal replication controls is turned off for the current session. ANSI Compliance SET SESSION OVERRIDE REPLICATION is a Teradata extension to the ANSI SQL:2008 standard. Required Privileges REPLCONTROL. Overriding the Normal Replication Controls for a Session SET SESSION OVERRIDE REPLICATION specifies that SQL statements that change data and are executed during the session override the normal controls specified for Teradata Replication Services. Setting replication override ON permits SQL statements such as DELETE, INSERT, MERGE, and UPDATE to be executed during the session against any table regardless of its current state. For more information on the states of tables in a replication group, see Viewing Detailed Information on a Replication Group on page 47. The override is in effect until the session is logged off or until you submit another SET SESSION request with a parameter of OVERRIDE REPLICATION OFF. 102 Teradata Replication Services Using GoldenGate

103 Chapter 6: Teradata SQL SET SESSION OVERRIDE REPLICATION SQL updates to a table are not output to a concurrently executing change data capture activity that involves that table. SQL updates can be made to a table under the following conditions: While replicated data is concurrently being applied to that table While it is in a Teradata Replication Services suspended state SET SESSION OVERRIDE is also useful when: You are loading a table (via MultiLoad, TPump, or BTEQ), but you do not want the loaded rows to be replicated. You want to switch a load job from the source to the subscriber in a failover situation. For more information, see Load Exact Copies of Tables onto the Subscriber System on page 36. Example 1: Setting Override On for the Current Session The following example sets override on for the current session: SET SESSION OVERRIDE REPLICATION ON; Example 2: Setting Override Off for the Current Session The following example sets override off for the current session: SET SESSION OVERRIDE REPLICATION OFF; Teradata Replication Services Using GoldenGate 103

104 Chapter 6: Teradata SQL SET SESSION SUBSCRIBER SET SESSION SUBSCRIBER Purpose Overrides the normal behavior of several SQL actions in the current session for replication purposes. Syntax SET SESSION SUBSCRIBER ON OFF ; 1101A555 where: Syntax element OFF ON Specifies to disable the suppression of the normal SQL actions activated by a SET SESSION SUBSCRIBER ON request. to suppress the normal behavior of the following SQL actions: Triggered actions invoked by SQL requests in the current session. Automatic generation of values for identity columns created with the GENERATED ALWAYS attribute. This permits the values for all identity columns to be overridden with user-supplied values. ANSI Compliance SET SESSION SUBSCRIBER is a Teradata extension to the ANSI SQL:2008 standard. Required Privileges REPLCONTROL. Privileges Granted Automatically None. How SET SESSION SUBSCRIBER Works When you specify SET SESSION SUBSCRIBER ON, Teradata Database overrides the normal behavior of certain SQL request actions: Teradata Database suppresses triggered actions against the table that would otherwise occur as the result of DML requests in the current session. 104 Teradata Replication Services Using GoldenGate

105 Chapter 6: Teradata SQL SET SESSION SUBSCRIBER Teradata Database enables the automatic generation of values for an identity column to be overridden by user-supplied values even if the column was defined with the GENERATED ALWAYS attribute when the replicated table was created. See Identity Columns and Triggers on page 22. In this case, the system treats all identity columns as if they had been defined with the GENERATED BY DEFAULT attribute. A SET SESSION SUBSCRIBER ON override stays in effect either until the session is logged off or until you submit a SET SESSION SUBSCRIBER OFF request. SET SESSION SUBSCRIBER and Request Cache Matching Teradata Database uses the SUBSCRIBER attribute as an additional condition for matching a cached request. A request run with the SUBSCRIBER attribute does not find a match with a cached request that was run without the SUBSCRIBER attribute. Example 1 The following request sets SUBSCRIBER overrides on for the session. SET SESSION SUBSCRIBER ON; Example 2 The following request disables SUBSCRIBER overrides that had previously been set for the session. SET SESSION SUBSCRIBER OFF; Teradata Replication Services Using GoldenGate 105

106 Chapter 6: Teradata SQL SHOW REPLICATION GROUP SHOW REPLICATION GROUP Purpose Displays the SQL text most recently used to create, replace, or modify the specified replication group. Syntax SHOW REPLICATION GROUP replication_group_name ; 1152A040 where: Syntax Element... Specifies... replication_group_name the name of the replication group whose most recent SQL create text is to be reported. ANSI Compliance Required Privileges The SHOW REPLICATION GROUP statement is a Teradata extension to the ANSI SQL:2008 standard. REPLCONTROL Example: SHOW REPLICATION GROUP This example reports the current DDL for the replication group named Payables_Group. SHOW REPLICATION GROUP Payables_Group; The system responds by reporting the following SQL text: CREATE REPLICATION GROUP Payables_Group ( Payables.Invoices, Payables.Transactions); 106 Teradata Replication Services Using GoldenGate

107 APPENDIX A Notation Conventions This appendix describes the notation conventions used in this book. Two conventions describe the SQL syntax and code: Syntax diagrams, used to describe SQL syntax form, including options. See Syntax Diagram Conventions on page 107. Square braces in the text, used to represent options. The indicated parentheses are required when you specify options. For example: DECIMAL [(n[,m])] means the decimal data type can be defined optionally: without specifying the precision value n or scale value m specifying precision (n) only specifying both values (n,m) you cannot specify scale without first defining precision. CHARACTER [(n)] means that use of (n) is optional. The values for n and m are integers in all cases Syntax Diagram Conventions Notation Conventions Item Definition / Comments Letter An uppercase or lowercase alphabetic character ranging from A through Z. Number A digit ranging from 0 through 9. Do not use commas when typing a number with more than 3 digits. Teradata Replication Services Using Oracle GoldenGate 107

108 Appendix A: Notation Conventions Syntax Diagram Conventions Item Word Spaces Punctuation Definition / Comments Keywords and variables. UPPERCASE LETTERS represent a keyword. Syntax diagrams show all keywords in uppercase, unless operating system restrictions require them to be in lowercase. lowercase letters represent a keyword that you must type in lowercase, such as a Linux command. lowercase italic letters represent a variable such as a column or table name. Substitute the variable with a proper value. lowercase bold letters represent an excerpt from the diagram. The excerpt is defined immediately following the diagram that contains it. UNDERLINED LETTERS represent the default value. This applies to both uppercase and lowercase words. Use one space between items such as keywords or variables. Type all punctuation exactly as it appears in the diagram. Paths The main path along the syntax diagram begins at the left with a keyword, and proceeds, left to right, to the vertical bar, which marks the end of the diagram. Paths that do not have an arrow or a vertical bar only show portions of the syntax. The only part of a path that reads from right to left is a loop. Continuation Links Paths that are too long for one line use continuation links. Continuation links are circled letters indicating the beginning and end of a link: A A FE0CA002 When you see a circled letter in a syntax diagram, go to the corresponding circled letter and continue reading. 108 Teradata Replication Services Using Oracle GoldenGate

109 Appendix A: Notation Conventions Syntax Diagram Conventions Required Entries Required entries appear on the main path: SHOW FE0CA003 If you can choose from more than one entry, the choices appear vertically, in a stack. The first entry appears on the main path: SHOW CONTROLS VERSIONS FE0CA005 Optional Entries You may choose to include or disregard optional entries. Optional entries appear below the main path: SHOW CONTROLS FE0CA004 If you can optionally choose from more than one entry, all the choices appear below the main path: READ SHARE ACCESS JC01A010 Some commands and statements treat one of the optional choices as a default value. This value is UNDERLINED. It is presumed to be selected if you type the command or statement without specifying one of the options. Strings String literals appear in apostrophes: 'msgtext ' JC01A004 Teradata Replication Services Using Oracle GoldenGate 109

110 Appendix A: Notation Conventions Syntax Diagram Conventions Abbreviations If a keyword or a reserved word has a valid abbreviation, the unabbreviated form always appears on the main path. The shortest valid abbreviation appears beneath. SHOW CONTROLS CONTROL FE0CA042 In the above syntax, the following formats are valid: SHOW CONTROLS SHOW CONTROL Loops A loop is an entry or a group of entries that you can repeat one or more times. Syntax diagrams show loops as a return path above the main path, over the item or items that you can repeat: (, 3, 4 cname ) JC01B012 Read loops from right to left. The following conventions apply to loops: IF... there is a maximum number of entries allowed there is a minimum number of entries required a separator character is required between entries THEN... the number appears in a circle on the return path. In the example, you may type cname a maximum of 4 times. the number appears in a square on the return path. In the example, you must type at least three groups of column names. the character appears on the return path. If the diagram does not show a separator character, use one blank space. In the example, the separator character is a comma. 110 Teradata Replication Services Using Oracle GoldenGate

111 Appendix A: Notation Conventions Syntax Diagram Conventions IF... a delimiter character is required around entries THEN... the beginning and end characters appear outside the return path. Generally, a space is not needed between delimiter characters and entries. In the example, the delimiter characters are the left and right parentheses. Excerpts Sometimes a piece of a syntax phrase is too large to fit into the diagram. Such a phrase is indicated by a break in the path, marked by ( ) terminators on each side of the break. The name for the excerpted piece appears between the terminators in boldface type. The boldface excerpt name and the excerpted phrase appears immediately after the main diagram. The excerpted phrase starts and ends with a plain horizontal line: LOCKING excerpt A A HAVING con where_cond excerpt, cname, col_pos JC01A014 Multiple Legitimate Phrases In a syntax diagram, it is possible for any number of phrases to be legitimate: DATABASE TABLE VIEW dbname tname vname JC01A016 In this example, any of the following phrases are legitimate: dbname DATABASE dbname tname Teradata Replication Services Using Oracle GoldenGate 111

112 Appendix A: Notation Conventions Syntax Diagram Conventions TABLE tname vname VIEW vname Sample Syntax Diagram, CREATE VIEW viewname AS A CV cname LOCKING LOCK A dbname ACCESS B DATABASE FOR SHARE MODE tname IN READ TABLE WRITE vname EXCLUSIVE VIEW EXCL,, B SEL expr FROM tname qual_cond C.aname C HAVING cond ; qual_cond WHERE cond, GROUP BY cname, col_pos JC01A018 Diagram Identifier The alphanumeric string that appears in the lower right corner of every diagram is an internal identifier used to catalog the diagram. The text never refers to this string. 112 Teradata Replication Services Using Oracle GoldenGate

113 APPENDIX B Configuration and Setup Verification Examples This appendix provides two simple examples of configuring a small Teradata-to-Teradata replication system and checking the operation of the hardware components. About These Examples Directory Path Separators The first example is a simple setup for change data capture. In the example, you create one replication group, add one table to it, and verify that changes to the table are replicated properly. The second example is a simple setup for DDL replication. A complete installation would have replication set up in both directions in case of failover. To reverse replication direction in case of failover, you must create the same replication group on both systems with the same tables and the same privileges. Neither example describes clustering. Once you confirm that the basic setup is operational, you can customize the configuration for greater functionality and performance. Detailed installation and set up for each component (Teradata Database, the ODBC Driver for Teradata, TAM, and Oracle GoldenGate) is covered under specific documentation available from Teradata or Oracle GoldenGate. Directory path separators are different on Windows than Linux. Specifically: / is for Linux \ is for Windows This appendix shows Linux examples. For Windows, change the path separators. Using path separators not supported on your operating system causes replication failure. Prerequisite Checklist Completed ( ) Action You created the /ggs directory on the replication server, for example, C:/ggs. You copied the Oracle GoldenGate software into the /ggs directory, unzipped the package, and obtained a valid license key file from Oracle. Teradata Replication Services Using Oracle GoldenGate 113

114 Appendix B: Configuration and Setup Verification Examples Prerequisite Checklist Completed ( ) Action You ran ggsci from the /ggs directory and issued the command CREATE SUBDIRS: ggsci>create subdirs. If the replication server is running Windows, you ran the following in the \ggs directory at the command prompt: INSTALL ADDEVENTS INSTALL ADDSERVICE These commands tell Windows to run all processes in one window and not open a new window for each process. You created the directory /tamini in the /ggs directory. You copied the TAM library (libtam.so or Tam.dll) into the /ggs directory. You created the ggs/obey directory under the /ggs directory. You specified the default checkpoint table in the GLOBALS file. To do this: 1 Edit the file with an ASCII text editor and enter the GLOBALS parameters, one per line. 2 Save the file as GLOBALS (uppercase, no extension) in the Oracle GoldenGate installation directory. Do not move this file. You did the following with the 32-bit Teradata ODBC Driver: 1 Installed it on the replication server (ODBC depends on tdicu and TeraGSS) 2 Configured it, including creating the data source name (DSN) Choose the 64-bit ODBC Driver if your replication server is running Linux. Otherwise, choose 32-bit. To configure the ODBC Driver on a Linux client, see Sample ODBC Initialization Files for Linux on page 135. You configured the RSG vprocs on the source Teradata system (this requires the Teradata PUT utility) and they are in the ONLINE state in vprocmanager. You obtained the IP address of the RSG control node and all RSG data nodes. For more information, see Determining the Values for the ControlRSG Parameter on page 64. You verified your setup (Teradata Database, TTU, TAM, Oracle GoldenGate, and the operating system) using the component compatibility matrix available via the Teradata Replication Services Using Oracle GoldenGate Ordering and Configuration Information document, available from your Teradata representative. You have the REPLCONTROL privilege, which allows you to define and manage replication groups. You have at least two drives, one for the Oracle GoldenGate software and one for the trail files. Using the same drive for Oracle GoldenGate software and trail files can lead to failure of the replication server. Use the Extract parameter file to set up this two-drive configuration. 114 Teradata Replication Services Using Oracle GoldenGate

115 Appendix B: Configuration and Setup Verification Examples Prerequisite Checklist Completed ( ) Action You checked server connectivity by starting Extract and Replicat and sending some SQL requests that change rows. To send the SQL, you can use either: Windows: Teradata SQL Assistant or Teradata Administrator. Linux: adhoc program (see ODBC Driver for Teradata User Guide). To find further sources of information on Teradata Replication Services Using Oracle GoldenGate, see Oracle GoldenGate Documentation and Training on page 14 and Teradata Replication Documentation by Task on page 15. Teradata Replication Services Using Oracle GoldenGate 115

116 Appendix B: Configuration and Setup Verification Examples High-Level Architecture High-Level Architecture The following figure depicts the architecture used in these examples. There are separate servers for Extract and Replicat (a data pump architecture). The transaction commit mode is maximum protection. Figure 7: Data Pump Architecture. Teradata Database SOURCE GG1 (Extract) 153.xx.xx xx.xx.1 Node xx.xx.2 Node xx.xx.3 RSG RSG Control Connection Data Connections TCP/IP TAM Tam.ini Unsorted Trail File Sort Extract Initial Extract EXTRACT Server (Capture) Node xx.xx.4 Node 4 RSG RSG Pump Extract Sorted Trail File Teradata Database TARGET 153.xx.xx.7 sandbox Node xx.xx.8 Remote Trail File Node 2 ODBC 153.xx.xx.9 Replicat Process Node 3 REPLICAT Server (Delivery) 153.xx.xx.10 Node 4 GG2 ( Replicat) 153.xx.xx.6 sandbox2 1152A024 Using Data Pumps Teradata recommends using a secondary Extract (data pump) to write to the remote trail files. In data pump architecture: 1 The primary Extract writes to a local trail file. 2 The data pump reads that trail file. 3 The data pump writes to a remote trail file. 116 Teradata Replication Services Using Oracle GoldenGate

117 Appendix B: Configuration and Setup Verification Examples Process Overview: Change Data Capture Example The advantages of using a data pump are: High availability. Extract can write and checkpoint a local trail more quickly, minimizing the delay to commit transactions on the source. When the source and subscriber systems are connected by a wide area network, each system has a local replication server, which is recommended by Oracle. Process Overview: Change Data Capture Example To configure and verify your replication installation: 1 Create Teradata users, databases, tables, and replication groups. 2 Create the Oracle GoldenGate parameter (.prm) and TAM initialization (.ini) files on the Extract server: a b c d e Manager parameter file Extract parameter file Sort parameter file Pump parameter file Teradata Access Module initialization file 3 Create the Oracle GoldenGate parameter (.prm) files on the Replicat server: a b Manager parameter file Replicat parameter file 4 Start GGSCI and Manager (Extract and Replicat servers). 5 Configure Oracle GoldenGate Extract processes: a b c d e Configure Extract Configure unsorted trail files Configure sort (Extract) Configure sorted trail files Configure pump (Extract) f Configure remote trail files 6 Configure Oracle GoldenGate Replicat. 7 Start Extracts and Replicats. 8 Use a simple insert to check for proper operation. 9 Clean up. Teradata Replication Services Using Oracle GoldenGate 117

118 Appendix B: Configuration and Setup Verification Examples Task 1: Create Teradata Objects and Replication Group Notice the following about the setup example in this appendix: The parameter file names and Teradata object names are variables. You can name extracts, sorts, replicats, parameter files, initialization files, and Teradata objects differently, as long as they conform to the naming conventions of each product. The parameter files are minimally configured for testing replication setup. Additional parameters or options are probably required. Consult Teradata and Oracle documentation for advanced configuration information. Task 1: Create Teradata Objects and Replication Group The following two examples create user gguser1 on both the source and subscriber systems. Note: In these examples, the TAM.ini file does not have the CreateGroupStmtFile set. Therefore, you have to manually create the replication groups, retrieve the group ID and the security token, and place them in the TAM.ini file. Create User 1: Source Teradata System (Sandbox) CREATE USER gguser1 as PERM=1E7, PASSWORD=gguser1; CREATE SET TABLE gguser1.t1,no FALLBACK, NO BEFORE JOURNAL, NO AFTER JOURNAL, CHECKSUM = DEFAULT (c1 INTEGER, c2 CHAR(10) CHARACTER SET LATIN NOT CASESPECIFIC) PRIMARY INDEX (c1); Create User 1: Subscriber Teradata System (Sandbox2) CREATE USER gguser1 as PERM=1E7, PASSWORD=gguser1; CREATE SET TABLE gguser1.t1,no FALLBACK, NO BEFORE JOURNAL, NO AFTER JOURNAL, CHECKSUM = DEFAULT (c1 INTEGER, c2 CHAR(10) CHARACTER SET LATIN NOT CASESPECIFIC) PRIMARY INDEX (c1); Grant Privileges The following example grants privileges to user gguser1. User gguser1 is granted REPLCONTROL, which allows you to define and manage replication groups. GRANT SELECT ON dbc TO gguser1; GRANT ALL on gguser1 TO gguser1; GRANT REPLCONTROL TO gguser1; 118 Teradata Replication Services Using Oracle GoldenGate

119 Appendix B: Configuration and Setup Verification Examples Task 1: Create Teradata Objects and Replication Group Create a Table and a Replication Group (Source Teradata System) In the following example, you create a table and a replication group on the source system. In this example, only one table (t1) is included in the replication group (testgrp). CREATE TABLE gguser1.t1 (c1 int, c2 char (10)); CREATE REPLICATION GROUP testgrp(gguser1.t1); Teradata responds with: Group Identifier Security Token C9E5AB02F47632AD <---will be unique per RG Note: When you create your replication group, be sure to record the group identifier and the security token. You need to set the values for these parameters later in the TAM initialization file. Note: Use the following SQL requests to obtain information about replication groups: SQL Request HELP REPLICATION GROUP testgrp SELECT * FROM dbc.repgroup Purpose Reports on the attributes of a specified replication group. Displays all replication groups defined on the server. Create Identical Tables on the Subscriber Create the same table on the subscriber system that you created on the source system: CREATE TABLE gguser1.t1 (c1 int, c2 char (10)); Teradata Replication Services Using Oracle GoldenGate 119

120 Appendix B: Configuration and Setup Verification Examples Task 2: Create Oracle GoldenGate Parameter (.prm) and TAM Initialization (.ini) Files on the Extract Server Task 2: Create Oracle GoldenGate Parameter (.prm) and TAM Initialization (.ini) Files on the Extract Server Note: The examples reflect sample file names and the recommended directories in which to place the parameter files. Use these comment indicators in the parameter files: -- (dash dash) for Oracle GoldenGate ; (semicolon) or -- (dash dash) for the Teradata tam.ini Step 1: Create a Manager Parameter File (/ggs/dirprm/mgr.prm) 1 From the Oracle GoldenGate directory, run the ggsci program to open the Oracle GoldenGate Software Command Interface (GGSCI). 2 In GGSCI, issue the following command to edit the Manager parameter file: EDIT PARAMS MGR 3 Add the following parameter to specify the default Manager port number: PORT Save and close the file. Step 2: Create an Extract Parameter File (/ggs/dirprm/ext.prm) 1 In GGSCI, issue the following command to create the Extract parameter file: EDIT PARAMS <group name> where <group name> is the name of the Extract process for which the file is being created. 2 Enter the Oracle GoldenGate parameters, starting a new line for each parameter statement: extract ext sourcedb sandbox wildcardresolve dynamic exttrail /ggs/dirdat/aa DSOPTIONS createtranlog, restartappend VAM /ggs/tam.so, PARAMS( inifile, /ggs/tamini/tam.ini, callbacklib, extract.exe ) TABLE gguser1.t1; 3 Save and close the file. 120 Teradata Replication Services Using Oracle GoldenGate

121 Appendix B: Configuration and Setup Verification Examples Task 2: Create Oracle GoldenGate Parameter (.prm) and TAM Initialization (.ini) Files on the Extract Server Step 3: Create a Sort Parameter File (/ggs/dirprm/sort.prm) 1 In GGSCI, issue the following command to create the sort parameter file: EDIT PARAMS <group name> where <group name> is the name of the sort process for which the file is being created. 2 Enter the Oracle GoldenGate parameters, starting a new line for each parameter statement: extract sort passthru sourcedb sandbox DSOPTIONS SORTTRANLOG WILDCARDRESOLVE DYNAMIC EXTTRAIL /ggs/dirdat/qq table gguser1.t1; Note: Specify PASSTHRU to prevent conflicting versions of metadata that cause replication failure. 3 Save and close the file. Step 4: Create a Pump Parameter File (/ggs/drprm/pump) 1 In GGSCI, issue the following command to create the pump parameter file: EDIT PARAMS <group name> where <group name> is the name of the pump process for which the file is being created. 2 Enter the Oracle GoldenGate parameters, starting a new line for each parameter statement: extract pump passthru rmthost 153.xx.xx.6, mgrport 7809 rmttrail /ggs/dirdat/zz table gguser1.t1; 3 Save and close the file. Note: Specify PASSTHRU to prevent conflicting versions of metadata that cause replication failure. Step 5: Create a TAM Initialization File (/ggs/tamini/tam.ini) 1 In a text editor, enter the parameter file, for example: Mode=Replication DictOdbcConnString=DSN=sandbox;uid=gguser1;pwd=gguser1 MgmtOdbcConnString=DSN=sandbox;uid=gguser1;pwd=gguser1 CharacterSet=ASCII ControlRSG=153.xx.xx.36:5298 ; (This is SMP007-4) vproc 9215 AltControlRSG=153.xx.37.2 ; (This is SMP007-5) vproc 9214 DataRSG1=153.xx.xx.36:5298 ; (This is SMP007-4) vproc 9215 DataRSG2=153.xx.xx.37:5298 ; (This is SMP007-5) vproc 9214 DataRSG3=153.xx.xx.38:5298 ; (This is SMP007-6) vproc 9213 DataRSG4=153.xx.xx.39:5298 ; (This is SMP007-7) vproc 9212 ENCRYPTION=None SecurityToken= A5535D28 ;note: Replace the SecurityToken parameter with yours Teradata Replication Services Using Oracle GoldenGate 121

122 Appendix B: Configuration and Setup Verification Examples Task 3: Create Oracle GoldenGate Parameter Files on the Replicat Server MaxProtTransCompleteThresh=1 MaxCopyQueueSize=1024 CopyThreadDataWaitSleep=0.001 GroupID=2197 ;note: GroupID parameter used beginning with TD12 ;note: Replace the GROUPID number with yours ;ReplicationGroupName=testgrp [V2R6.2 only] UPDATEBEFOREIMAGES=true Note: Set UPDATEBEFOREIMAGES to true. If you do not, updates fail to tables that do not have a unique index. 2 Save the file as an ASCII file named tam.ini in the /ggs/tamini directory. Task 3: Create Oracle GoldenGate Parameter Files on the Replicat Server Step 1: Create the Manager Parameter File (/ggs/dirprm/mgr.prm) 1 In GGSCI, issue the following command to edit the Manager parameter file: EDIT PARAMS MGR 2 Add the following parameter to specify the default Manager port number: PORT Save and close the file. Step 2: Create the Replicat Parameter File (/ggs/dirprm/rep.prm) 1 In GGSCI, issue the following command to create the Replicat parameter file: EDIT PARAMS <group name> where <group name> is the name of the Replicat process for which the file is being created. 2 Enter the Oracle GoldenGate parameters, starting a new line for each parameter statement: replicat rep targetdb SANDBOX2 assumetargetdefs map gguser1.t1 target gguser1.t1 DISCARDFILE /ggs/dirrpt/rep.dsc, PURGE WILDCARDRESOLVE DYNAMIC Note: The discard file is important in checking Replicat errors. 3 Save and close the file. 122 Teradata Replication Services Using Oracle GoldenGate

123 Appendix B: Configuration and Setup Verification Examples Task 4: Start GGSCI and Manager (Extract and Replicat Servers) Task 4: Start GGSCI and Manager (Extract and Replicat Servers) Start GGSCI if you have not done so already, and start the Manager process: GG1 EXTRACT Server GG1:/ # cd /ggs GG1:/ggs # ggsci GGSCI (GG1) 1> start mgr Manager started. GG2 REPLICAT Server GG2:/ # cd /ggs GG2:/ggs #./ggsci GGSCI (GG2) 1> start mgr Manager started. Task 5: Add the Extract Processes Step 1: Configure Extract Perform these steps from the GGSCI interface to set up the GG1 EXTRACT server: GGSCI (GG1) 2> add extract ext, vam EXTRACT added. Step 2: Configure Unsorted Trail Files GGSCI (GG1) 3> add exttrail /ggs/dirdat/aa, extract ext EXTTRAIL added. Step 3: Configure Sort (Extract) GGSCI (GG1) 4> add extract sort, vamtrailsource /ggs/dirdat/aa EXTRACT added. Step 4: Configure Sorted Trail Files GGSCI (GG1) 5> add exttrail /ggs/dirdat/qq, extract sort EXTTRAIL added. Step 5: Configure Pump (Extract) GGSCI (GG1) 5> add extract pump, exttrailsource /ggs/dirdat/qq EXTTRAIL added. Teradata Replication Services Using Oracle GoldenGate 123

124 Appendix B: Configuration and Setup Verification Examples Task 6: Add the Replicat Processes Step 6: Configure Remote Trail Files Step 7: Check Status GGSCI (GG1) 7> add rmttrail /ggs/dirdat/zz, extract pump RMTTRAIL added. GGSCI (GG1) 8> info all Program Status Group Lag Tm Since Chkpt MANAGER RUNNING EXTRACT STOPPED EXT 00:00:00 00:05:31 EXTRACT STOPPED PUMP 00:00:00 00:00:42 EXTRACT STOPPED SORT 00:00:00 00:02:55 Task 6: Add the Replicat Processes Step 1: Set up the Extract Server Perform these steps to set up the GG2 EXTRACT server: GG2 EXTRACT Server GGSCI (GG2) 1> add replicat rep, exttrail /ggs/dirdat/zz, checkpointtable REPLICAT added. Step 2: Check Status GGSCI (GG2) 2> info all Program Status Group Lag Tm Since Chkpt MANAGER RUNNING REPLICAT STOPPED REP 00:00:00 00:00: Teradata Replication Services Using Oracle GoldenGate

125 Appendix B: Configuration and Setup Verification Examples Task 7: Start the Extract and Replicat Servers Task 7: Start the Extract and Replicat Servers GG1 EXTRACT Server GGSCI (GG1) 1> start * Sending START request to MANAGER... EXTRACT EXT starting Sending START request to MANAGER... EXTRACT PUMP starting Sending START request to MANAGER... EXTRACT SORT starting GGSCI (GG1) 2> info all Program Status Group Lag Tm Since Chkpt MANAGER RUNNING EXTRACT RUNNING EXT 00:00:00 00:00:03 EXTRACT RUNNING PUMP 00:00:00 01:44:09 EXTRACT RUNNING SORT 00:00:00 00:00:03 GG2 REPLICAT Server GGSCI (GG2) 1> start replicat rep Sending START request to MANAGER... REPLICAT REP starting GGSCI (GG2) 2> info all Program Status Group Lag Tm Since Chkpt MANAGER RUNNING REPLICAT RUNNING REP 00:00:00 00:00:03 Use VIEW REPORT to help identify problems with processes starting. For example: GGSCI (GG1) 30> view report, ext Teradata Replication Services Using Oracle GoldenGate 125

126 Appendix B: Configuration and Setup Verification Examples Task 8: Use a Simple Insert To Check for Proper Operation Task 8: Use a Simple Insert To Check for Proper Operation Step 1: Check the Stats Before the SQL INSERT GGSCI (GG1) 21> stats * Sending STATS request to EXTRACT EXT... No active extraction maps. ERROR: EXTRACT PUMP not currently running. Sending STATS request to EXTRACT SORT... No active extraction maps. Step 2: Issue SQL INSERT to Teradata Source System insert into gguser1.t1 values (100,'elmo') Step 3: Check That the Row Is Applied on the Replicat Server On the GGS command line, type: GGSCI (IRIS3) 20>stats REP The result should show you that one row is applied to the Replicat server. You can use this command in the future to diagnose problems and tune the performance of the Oracle GoldenGate processes. This command tells you how many rows the replication system has processed. Sending STATS request to REPLICAT REP... Start of Statistics at :41:12. Replicating from GGUSER1.T1 to GGUSER1.T1: *** Total statistics since :41:12 *** Total inserts 1.00 Total updates 0.00 Total deletes 0.00 Total discards 0.00 Total operations 1.00 *** Daily statistics since :41:12 *** Total inserts 1.00 Total updates 0.00 Total deletes 0.00 Total discards 0.00 Total operations 1.00 *** Hourly statistics since :41:12 *** Total inserts 1.00 Total updates 0.00 Total deletes 0.00 Total discards Teradata Replication Services Using Oracle GoldenGate

127 Appendix B: Configuration and Setup Verification Examples Task 9: Clean Up Total operations 1.00 *** Latest statistics since :41:12 *** Total inserts 1.00 Total updates 0.00 Total deletes 0.00 Total discards 0.00 Total operations 1.00 End of Statistics. Step 4: Check That the Row Is Applied on the Subscriber System In a BTEQ session, log on to the subscriber system and verify that the table has one replicated row. sel * from gguser.t1; *** Query completed. One row found. 2 columns returned. *** Total elapsed time was 1 second. c1 c elmo Task 9: Clean Up Cleanup should include dropping the replication group and removing the trail files and the result files. 1 Check the replication group status by using SQL Assistant or BTEQ: a Get the replication group name: sel * from dbc.repgroup; b Check the replication group status: help replication group testgrp; c Make sure Extracts are still running so that the replication group is in the proper running state (status=i). Note: It is important to follow the next three steps in order. You cannot drop the replication group unless it is in terminated state (status=t) and it cannot be terminated while it is failed. 2 From GGSCI terminate the replication group: Send extract ExtractName, vammessage control:terminate Teradata Replication Services Using Oracle GoldenGate 127

128 Appendix B: Configuration and Setup Verification Examples Task 9: Clean Up 3 Check the replication group status again to make sure it is T for terminated. On the source system, use BTEQ: help replication group testgrp; *** Help information returned. One row. *** Total elapsed time was 1 second. GroupName Identifier Operation MaxProtect Status testgrp 1014 C Y T *** Help information returned. One row. DatabaseName TableName Identifier gguser1 t B Drop the replication group using SQL Assistant or BTEQ: DROP REPLICATION GROUP testgrp;; 5 Stop and delete the Extract and Replicat processes in GGSCI. Stop extract <group name> Delete extract <group name> Stop replicat <group name> Delete replicat <group name> 6 Stop Manager in GGSCI (only if no one else is using the system and it is completely idle). Stop mgr 7 Exit GGSCI. EXIT 8 Delete and drop the checkpoint table (if one was created). 9 Remove the trail files in /ggs/dirdat/. 128 Teradata Replication Services Using Oracle GoldenGate

129 Appendix B: Configuration and Setup Verification Examples DDL Replication Setup Example DDL Replication Setup Example The following example describes a simple setup for DDL replication. Task 1: Create a Replication Group, Rule Set, and Tables on the Source System 1 Create the tables for replication: create table gguser.t1(i int, c char (10)); 2 Create the replication group: create replication group testgrp(t1); *** Replication Group has been created. *** Total elapsed time was 1 second. Group Identifier Security Token B015999C59221EC8 3 Create a replication rule set: create replication ruleset testrs1 for testgrp as table like 'gguser.t%', view like 'gguser.v%'; Task 2: Create a Replication Group, Rule Set, and Tables on the Subscriber System Create the identical replication group, rule set, and tables on the subscriber system. Task 3: Create the TAM Initialization File on the Replication Server: tamini\ext1.ini Mode=Replication DictOdbcConnString=DSN=salsa MgmtOdbcConnString=DSN=salsa CharacterSet=ASCII ControlRSG=153.xx.xx.36:5298 ; (This is salsa1) vproc 9215 AltControlRSG=153.xx ; (This is salsa2) vproc 9214 DataRSG1=153.xx.xx.36:5298 ; (This is salsa1) vproc 9215 DataRSG2=153.xx.xx.37:5298 ; (This is salsa2) vproc 9214 Encryption=None MaxCopyQueueSize=1024 Teradata Replication Services Using Oracle GoldenGate 129

130 Appendix B: Configuration and Setup Verification Examples Task 4: Create the Extract Parameter File on the Replication Server: dirprm\ext1.prm CopyThreadDataWaitSleep=0.5 GroupID=1024 SecurityToken= B015999C59221EC8 UpdateBeforeImages = TRUE Task 4: Create the Extract Parameter File on the Replication Server: dirprm\ext1.prm EXTRACT ext1 SOURCEDB salsa EXTTRAIL dirdat\ext1\aa DDL WILDCARDRESOLVE DYNAMIC DSOPTIONS createtranlog, restartappend VAM Tam.dll, PARAMS( inifile, tamini\ext1.ini, callbacklib, extract.exe ) TABLE gguser.*; Task 5: Create the Sort Extract Parameter File on the Replication Server: dirprm\ext2.prm EXTRACT ext2 SOURCEDB salsa PASSTHRU RMTHOST localhost, MGRPORT 7809 RMTTRAIL dirdat\ext\bb WILDCARDRESOLVE DYNAMIC DSOPTIONS SORTTRANLOG TABLE gguser.*; Task 6: Create the Replicat Parameter File on the Replication Server: dirprm\rep1.prm REPLICAT rep2 SOURCEDB iris1 SQLEXEC "SET SESSION SUBSCRIBER ON;" SQLEXEC "COMMIT;" ASSUMETARGETDEFS DDLOPTIONS REPORT DISCARDFILE dirdef\rep2.dsc, PURGE WILDCARDRESOLVE DYNAMIC MAP gguser.*, TARGET gguser.*; 130 Teradata Replication Services Using Oracle GoldenGate

131 Appendix B: Configuration and Setup Verification Examples Task 7: Add the Extracts, Replicat, and Trail File Task 7: Add the Extracts, Replicat, and Trail File ggsci> ADD EXTRACT EXT1, VAM ggsci> ADD EXTTRAIL DIRDAT\EXT\AA, EXTRACT EXT1 ggsci> ADD EXTRACT EXT2, VAMTRAILSOURCE DIRDAT\EXT\AA ggsci> ADD EXTTRAIL DIRDAT\EXT\BB, EXTRACT EXT2 ggsci> ADD REPLICAT REP1, EXTTRAIL DIRDAT\EXT\BB, NODBCHECKPOINT Task 8: Create the dirdat Directory for Pext1 and Pext2 Trails mkdir dirdat\ext Task 9: Add the ODBC DSNs for the Source and Subscriber Systems For more information, see ODBC Data Sources for Windows on page 133 or Sample ODBC Initialization Files for Linux on page 135. Task 10: Start the Extract and Replicat in GGSCI ggsci> START ext1 ggsci> START ext2 ggsci> START rep1 Task 11: Check the Status ggsci> STATUS ext1 ggsci> STATUS ext2 ggsci> STATUS rep1 Teradata Replication Services Using Oracle GoldenGate 131

132 Appendix B: Configuration and Setup Verification Examples Task 12: Issue DDLs Task 12: Issue DDLs The following table is captured and added to the replication group: CREATE TABLE T2(I int, j int); help replication group testgrp; help database gguser; The following ALTER TABLE is captured: ALTER TABLE gguser.t1 ADD C1 char(10); Show table t1; The following DDL is not captured because it does not match a rule: Create table mytab(i int, j int); Help Replication group testgrp; The CREATE VIEW DDL is captured: Create view v1 as sel * from t1; Help database gguser; The following DDL is captured and the table is dropped from the replication group: Drop table t2; Help replication group testgrp; The following DDL is captured: Create replication ruleset testrs2 for testgrp as macro like gguser.m% ; The following DDL is captured: Create macro gguser.m1 as (sel * from dbc.dbase;); Help database gguser; Task 13: Check Statistics and the Report File ggsci>stats ext1 ggsci>stats ext2 ggsci>stats rep1 ggsci> view report rep1 This should display captured DDLs. Task 14: Terminate and Stop the Extract and Replicat ggsci>send ext1, vammessage control:terminate ggsci> stop ext1 ggsci> stop ext2 ggsci> stop rep1 132 Teradata Replication Services Using Oracle GoldenGate

133 Appendix B: Configuration and Setup Verification Examples ODBC Data Sources for Windows ODBC Data Sources for Windows The ODBC Driver for Teradata allows the Extract server to communicate with the Teradata source system and the Replicat server to communicate with the Teradata subscriber system. Configure ODBC on both the Extract and Replicat servers. Note: You must first install the Teradata ODBC Driver on both the Extract and Replicat servers. The Teradata ODBC Driver is located on Teradata Utility Pack for Windows CD. Complete installation procedures for all Teradata Tools and Utilities software are contained in Teradata Tools and Utilities Installation Guide for Microsoft Windows (B A) available from After installation, select Start>Control Panel>Administrative Tools>Data Sources (ODBC) and configure the data source for the Extract server as in the following example: Teradata Replication Services Using Oracle GoldenGate 133

134 Appendix B: Configuration and Setup Verification Examples ODBC Data Sources for Windows Note: In the Name(s) or IP address(es) box, be sure to enter either the name(s) or IP address(es) of each LAN-connected node in your system, one per line. Omitting nodes from this list reduces the number of available connections to the database and can decrease system performance significantly. Note: You must also add all node identifiers entered here to either Domain Name Services (DNS) or the local hosts file. The hosts file is located in the system32\drivers\etc subdirectory of the directory in which Windows is installed. Next, click on Options to bring up the following screen and check Run in Quiet Mode. Then click OK. Click OK once more to exit the setup dialog box. Repeat this procedure for the Replicat server. 134 Teradata Replication Services Using Oracle GoldenGate