Oracle GoldenGate Best Practices - Configuring Oracle GoldenGate For Teradata Databases V5a ID1323119.1-1

An Oracle White Paper
Updated March 2014
Oracle GoldenGate Best Practices: Configuring

Oracle GoldenGate for Teradata Databases
Oracle GoldenGate for Teradata
Executive Overview.............................................................................. 1
Introduction.......................................................................................... 1
Prerequisites........................................................................................ 4
Hardware.......................................................................................... 4
Intermediary Server.......................................................................... 4
Install and Configure Oracle GoldenGate Software......................... 4
Setup the Database User................................................................. 4
Teradata Database.......................................................................... 5
Configure ODBC.............................................................................. 6
Database Activity............................................................................. 6
Oracle GoldenGate Manager Process................................................. 9
Max Protection Capture..................................................................... 11
TAM Configuration......................................................................... 11
Change Data Capture.................................................................... 13
Configure VAM Sort Extract........................................................... 16
Configure Extract Data Pump........................................................ 16
Configure Replicat.............................................................................. 19
Teradata to Teradata Configuration............................................... 19
Other Databases to Teradata Configuration.................................. 19
Turbo Apply for Teradata............................................................... 20
Using KEYCOLS in Replicat.......................................................... 21
Oracle GoldenGate Macros............................................................... 22
DDL Replication................................................................................. 24
Enable DDL Capture in Teradata................................................... 24
Enable DDL Capture in VAM Extract............................................. 25
Enable DDL Passthru in Sort Extract............................................. 25
Enable DDL Passthru in Data Pump.............................................. 25
Enable DDL Apply in Replicat........................................................ 25
Maintenance Tasks........................................................................ 25
Staging Tables................................................................................... 27
Teradata to Teradata..................................................................... 27
Other Databases to Teradata........................................................ 29
Staging Table Processing With Oracle GoldenGate...................... 30
Synchronizing Data............................................................................ 31
Maintenance....................................................................................... 32
Delete Oracle GoldenGate Extract................................................ 32
Add a Table to an Existing Extract................................................. 32
Move a Table to a New Extract...................................................... 32
Modify Table Columns................................................................... 33
Things to Know.................................................................................. 34
In Doubt Transactions.................................................................... 34
Character Sets and Replication..................................................... 34
Avoiding ODBC Login Timeouts.................................................... 34
Teradata ODBC Driver Limitations................................................ 35
Improving Oracle GoldenGate Throughput with @RANGE........... 35
Primary Indexes vs. Primary Keys ................................................ 35
Executing Stored Procedures from Oracle GoldenGate................ 37
Teradata Queries You Need To Know........................................... 38
References......................................................................................... 40
Executive Overview
This paper presents configuration considerations for implementing Oracle GoldenGate version 12c
into an environment running the Teradata database.
Oracle GoldenGate supports data capture for the Teradata Database up to version 14.10. As of
Teradata Database version 15.00, Oracle GoldenGate only supports delivery delivery.
Introduction
Oracle GoldenGate for Teradata allows users to capture changes made to a specific set of tables in
one database and deliver those changes to corresponding tables in another database in near real
time. Replication can serve several purposes in database information management:
• Replication can provide a backup of specified table data in the event of problems with the
primary database.
• If the site is dual active, and one system becomes unavailable, the remaining system can
automatically take over database operations. The data on the systems will have been
automatically synchronized via replication.
• When implemented between Teradata and databases from other vendors, data can be
migrated from one system to the other, making data accessible across the different
environments.
The typical configuration includes:
• A source database
• A target database
• A source and target server running Oracle GoldenGate for Teradata. Oracle GoldenGate
for Teradata provides transport for data captured from Teradata Database and applies it to
the target database.
• The ODBC driver for Teradata installed on the both Oracle GoldenGate servers; this
supports data transfer between the Oracle GoldenGate software and the database systems.
• Teradata Access Module installed on the source Oracle GoldenGate server; this supports
data transfer between a Teradata Database and Oracle GoldenGate.
Figure 1 illustrates the major components for replicating Teradata databases.
1
Figure 1. Major Components Required For Teradata Data Replication
In our simplified view, the major components associated with Teradata data replication are:
1. Teradata Database Server

a. Parsing Engine (PE)
i. A Parsing Engine (PE) is a vproc that manages the dialogue between a
client application and the Teradata Database, once a valid session has been
established.
b. Access Module Processor (AMP)
i. The AMP is a vproc that controls its portion of the data on the system.
AMPs do the physical work associated with generating an answer set
(output) including sorting, aggregating, formatting, and converting. The
AMPs perform all database management functions on the required rows in
the system. The AMPs work in parallel, each AMP managing the data rows
stored on its single vdisk. AMPs are involved in data distribution and data
access in different ways.
c. Relay Services Gateway vprocs (RSG) are the Teradata server functions whereby an
intermediary can capture the changes made to a specified set of tables and then
deliver those changes to another server. A replication group defines the set of tables
for which changes are to be captured or applied. For data replication, one RSG
should be configured per Teradata Node.
2. Source Oracle GoldenGate Server

a. Teradata Access Module (TAM)
i. TAM is a shared object that is linked to the Oracle GoldenGate Extract at
process start time. TAM provides a TCP/IP link between Extract and RSG
for receiving change data records.
ii. A TAM process consists of 3 threads:
1. Management Thread
1) The Management Thread exchanges information with
Oracle GoldenGate. It receives notifications from Oracle
GoldenGate to start/stop VAM Extracts. It also provides
status and statistical information to Oracle GoldenGate when
requested. The Management Thread also handles extended
SQL creation and execution through ODBC to the Teradata
primary server.
2. Control Thread
2
1) The Control Thread establishes the connection to the RSG

and handles communication for purposes of initiating data
movement.
3. Data Thread
1) The Data Thread establishes the connection to the RSG
and moves data transmitted from the RSG to Oracle
GoldenGate, performing any necessary data transformation
along the way. It also handles receipt of the acknowledgement
from Oracle GoldenGate once the data has been committed to
the VAM Trail.
b. VAM Extract
i. Oracle GoldenGate Extract receives change data records from TAM and
writes these records to a disk file (VAM Trail).
c. VAM Trail
i. The VAM Trail contains records transmitted to TAM from the Teradata
RSG. The records in this trail are “unsorted”, meaning they may not be in
correct transaction sequence order.
ii. A database transaction exists for all records being written to the VAM Trail,
and the original database transaction is not committed until the data being
written into the VAM Trail is committed (two-phased commit).
d. Sort Extract
i. The Sort Extract reads the records from the VAM Trail, sorts them into
correct transaction sequence order and writes the data to the local Golden
Gate Trail.
e. Data Pump
i. The Extract Data Pump reads the records from the local Oracle GoldenGate
Trail and transmits the data over TCP/IP to the target Oracle GoldenGate
Intermediary Server.
ii. Transmitted data may be compressed and encrypted by the Data Pump.
Data encryption is required when (1) transmission occurs over a public
network, or (2) when the data is considered “sensitive”; i.e., it contains
credit or bank account information, or other personal information.
f. ODBC
i. The Teradata ODBC driver is used to establish a database connection
between the Teradata Database Server and the Oracle GoldenGate VAM,
VAM Sort, and Data Pump processes.
3. Target Oracle GoldenGate Server

a. Server Collector
i. Server Collector receives the information transmitted by the Data Pump,
decompresses and decrypts the data, and then writes the information into
the remote Oracle GoldenGate Trail.
b. Replicat
i. Oracle GoldenGate Replicat reads the data written to disk by Server
Collector, builds Teradata specific SQL DML statements and passes these
statements to the target Teradata Server Parsing Engine via an ODBC
connection.
c. ODBC
i. The Teradata ODBC driver is used to establish a database
connection between the Teradata Database Server and the
Oracle GoldenGate Replicat process
3
Prerequisites
Before implementing Oracle GoldenGate Extract and Replicat, several modifications must be made
to the server environment. In this section we shall discuss these prerequisites.
Hardware
Although not required, it is best to install the Oracle GoldenGate application on a multi-node cluster
server. Doing so will minimize the impact of a Oracle GoldenGate outage due to a server failure.
Two intermediary servers will be required; one for change data capture and one for change data
apply, connected via TCP/IP.
The Oracle GoldenGate application does have specific hardware requirements; however, the
minimum configuration recommended is:
1. Two dual core processors

2. Sufficient RAM to ensure page swapping does not occur.
a. The amount of RAM required depends upon the number of Extract and Replicat
processes configured.
3. Sufficient disk to hold 7 days of Oracle GoldenGate Trails at peak processing workloads.
a. This will ensure there is sufficient disk space to store captured data in the event of a
target intermediary server or target database server extended outage.
Intermediary Server
The intermediary server, where Oracle GoldenGate is to be installed, may run any supported
version of the Linux or Windows Operating System.
If the intermediary server uses the Windows operating system, tune the Windows Desktop Heap to
allow more than 50 Oracle GoldenGate groups to run simultaneously by changing the following
operating system values:
Windows Option Set To Value

SessionViewSpace 48Mb
SharedSection Third value to 4096
Install and Configure Oracle GoldenGate Software

1. Download the appropriate Oracle GoldenGate release and install as per the Oracle
GoldenGate Installation documentation.
2. Configure and start the Oracle GoldenGate Manager process.
Setup the Database User

Access the Teradata server and create the user assigned for Oracle GoldenGate Extract. This user
requires access to several tables owned by the dbc user. As the dbc user, execute the following
grants:
1. Grant select on dbc.repgroup to <userid>;

2. Grant select on dbc.tvm to <userid>;
3. Grant select on dbc.dbase to <userid>;
4. Grant select on dbc.errormsgs to <userid>;
5. Grant select on dbc.tvfields to <userid>;
6. Grant select on dbc.indexes to <userid>;
7. Grant select on dbc.indoubtreslog to <userid>;
8. Grant replcontrol to <userid>;
On the target Teradata server, Oracle GoldenGate Replicat will require the following grants:
1. Grant select on dbc.tvm to <userid>;

2. Grant select on dbc.dbase to <userid>;
3. Grant select on dbc.errormsgs to <userid>;
4. Grant select on dbc.tvfields to <userid>;
5. Grant select on dbc.indexes to <userid>;
6. Grant select, insert, update, delete on <database>.<table> to <userid>;
Teradata Database
1. Create the RSG Spill File Directory
a. This directory is used by the RSG to store transaction data if a large transaction occurs,
or Oracle GoldenGate Extract does not receive change data as quickly as it is
generated.
2. Define RSG vprocs
a. The process of capturing change data relies on RSG vprocs. RSGs must be added to
every Teradata node.
DBSControl Settings
There are four DBSControl Utility Fields whose settings affect Replication. These fields are:
1. Memory limit per transaction

a. The maximum amount of in-memory storage that the RSG can use to store the records
for one transaction. If a transaction exceeds this, 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.
b. Default: 2 pages
c. Valid Values: 0 – 127 pages
d. Recommended Setting: 10 pages
2. Client reset timeout

a. How long the RSG should wait for Oracle GoldenGate to reconnect after a
communication failure or reset before spilling transactions to disk.
b. Default: 300 seconds
c. Valid Values: 0 – 65,535 seconds
d. Recommended Setting: Default
3. Temp Storage Page Size

a. 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.
b. Default: 4 Kb
c. Valid Values: 1 – 1024 Kb
d. Recommended Setting: 80 Kb
4. Spill File Path

a. A directory that is used by the RSG for spill files.
b. Default: MP-RAS: /var/tdrsg
Linux: /var/opt/teradata/tdtemp/tdrsg
Windows: C:\Program Files\Teradata\TDAT\tdTemp\tdrsg
For more information on these database requirements refer to the Teradata Replication Solutions
Overview in the Teradata Database Documentation.
Configure ODBC
Oracle GoldenGate utilizes ODBC to communicate with the Teradata server. Setup an ODBC Data
Source for the Teradata server, specifying:
1. The username and password assigned for Oracle GoldenGate Extract.
2. The ODBC connection must be set for

a. Session Mode: ANSI
b. DateTime Format: AAA
c. Use Column Names
d. Disable Parsing
e. Use Regional Setting for Decimal Support
f. Run in Quite Mode
g. Use Native Large Object Support
3. By default ODBC is configured with LoginTimeout of 20 seconds.

a. This option defines a value corresponding to the number of seconds to wait when
establishing a virtual circuit with Teradata for login.
b. This option may be adjusted up or down if Oracle GoldenGate process startup issues
are encountered.
For Oracle GoldenGate running on a Linux server, in the Oracle GoldenGate user’s .cshrc file
include an environment variable to define the location of the odbc.ini file:
setenv ODBCINI /<folder>/.odbc.ini
For more information about ODBC configuration for Oracle GoldenGate, refer to the Oracle
GoldenGate Administration Manual or the ODBC Driver for Teradata User Guide.
Database Activity
To properly configure the Oracle GoldenGate application for maximum performance, gather the size
and activity rates for all tables being considered for data replication. Business rules must be
established that specify the acceptable delay, or lag, for data to be captured from the source database
and applied to the target database. These rules are needed to determine the number of Oracle
GoldenGate Extract and Replicat processes.
Multiple Teradata Replication Groups

In a high volume environment, change data capture (CDC) may be configured using multiple
Teradata Replication Groups; however, care must be taken to ensure that transactions are wholly
contained within the same Teradata Replication Group.
Figure 2. Single vs. Multiple Teradata Replication Groups
Teradata
Extract
T
A
Node 1 M Extract for Teradata
Replication Group
RGOLDEN,
Node 2 containing tables
used by Sales, HR,
and Payroll
applications.
Node n
Teradata
Extract
T Extract for Teradata Replication Group
A RSALES, containing tables used by Sales
Node 1 application
M
Node 2
Extract
T Extract for Teradata Replication Group RHR,
A containing tables used by HR application
M
Node n
Extract
T Extract for Teradata Replication Group
A RPAYROLL, containing tables used by
Payroll application
M
Guidelines to consider when setting up Replication Groups
1. If there are multiple applications, each with a unique set of tables, it is appropriate to isolate
each set of tables in a separate replication group.
2. If a replicated table is maintained exclusively by bulk-loading methods, it is best to dedicate

one replication group to that table. If that is not feasible, put tables with similar load
methods and batch volumes in the same group.
3. Tables that may be loaded concurrently should be in separate replication groups to

minimize competition for the same resources.
4. TPump generates many concurrent transactions, so the replication workload is distributed

across all the RSGs that are assigned to the replication group.
a. 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 DBSControl fields as follows:
i. The RSG page size (TempStoragePageSize) should be larger than the change row
size.
ii. Memory limit per transaction should be large enough to accommodate all the
change data for most transactions.
5. MultiLoad generates the changed data for each data block as a separate pseudo-transaction,
which is transmitted to a randomly selected RSG. The replication workload is distributed
across all the RSGs assigned to the replication group.
a. For the best performance with MultiLoad, set the DBSControl field
TempStoragePageSize to be large enough to accommodate a complete set of changed
row images for one data block.
6. 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 will be 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.
Since bulk SQL transactions normally use spill files, it is important to ensure that there is adequate
disk space on each node. Note that the default spill file directory is system disk that is used for other
important files.
Oracle GoldenGate Manager Process
Manager is the Oracle GoldenGate parent process and is responsible for the management of Oracle
GoldenGate processes, resources, user interface, and the reporting of thresholds and errors.
A sample Manager parameter file is provided in Table 1.
Table 1. Sample Manager Parameter File

port 15000
dynamicportlist 15001-15050
purgeoldextracts ./dirdat/*, usecheckpoints
PORT
The default Manager listener port is 7809. Because this is a well documented and publicized port
number, it may not be the best setting in a customer environment; especially if the server is on a non-
secure network. The customer’s network administrator should assign Oracle GoldenGate Manager a
non-default port number.
DYNAMICPORTLIST
When Manager receives a connect request from Capture, Apply, or GGSCI; the default functionality
is to utilize any available free port for data exchange. In a production environment this may not be
desired functionality; therefore, the customer’s network administrator should assign a series, or
range of ports for exclusive use by Oracle GoldenGate processes.
DYNAMICPORTLIST may be configured as:
1. A series of ports
a. DYNAMICPORTLIST 15301, 15302, 15303, 15380, 15420
2. A range of ports
a. DYNAMICPORTLIST 12010-12250
3. A range of ports plus individual ports
a. DYNAMICPORTLIST 12010-12020, 15420, 15303
A maximum of 256 ports may be specified.
PURGEOLDEXTRACTS
Use PURGEOLDEXTRACTS in the Manager parameter file to purge trail files when oldenGate has
finished processing them. As a Manager parameter, PURGEOLDEXTRACTS provides trail
management in a centralized fashion and takes into account multiple processes.
To control the purging, follow these rules:
1. Specify USECHECKPOINTS to purge when all processes are finished with a file as indicated
by checkpoints. Basing the purge on checkpoints ensures that no file is deleted until all
processes are finished with it. USECHECKPOINTS considers the checkpoints of both Extract
and Replicat before purging.
2. Use the MINKEEP rules to set a minimum amount of time to keep an unmodified file:
a. Use MINKEEPHOURS or MINKEEPDAYS to keep a file for <n> hours or days.
b. Use MINKEEPFILES to keep at least <n> files including the active file. The default is
1.
3. Use only one of the MINKEEP options. If more than one is used, Oracle GoldenGate selects
one of them based on the following:
a. If both MINKEEPHOURS and MINKEEPDAYS are specified, only the last one is
accepted, and the other will be ignored.
b. If either MINKEEPHOURS or MINKEEPDAYS is used with MINKEEPFILES, then
MINKEEPHOURS or MINKEEPDAYS is accepted, and MINKEEPFILES is ignored.
Set MINKEEPDAYS on the source server to keep <n> number of local extract trails on disk to
facilitate disaster recovery of the source database. The number of days is determined by the
customer.
AUTOSTART
AUTOSTART is used to start Oracle GoldenGate Capture or Apply processes as soon as Manager’s
startup process completes.
LAGREPORT
LAGREPORT denotes the interval at which Manager checks Capture and Apply processes for lag.
This setting is customer dependent; however, a setting of “LAGREPORTHOURS 1” should be
sufficient in most environments.
LAGCRITICAL
LAGCRITICAL denotes the threshold at which lag becomes unacceptable. Manager writes a
message to the Oracle GoldenGate Error Log. This setting is customer dependent; however, the
recommended settings below will suffice for most installations:
Environment Setting
Disaster Recovery LAGCRITICALMINUTES 5
Decision Support LAGCRITICALMINUTES 5
Reporting LAGCRITICALHOURS 1
Windows Cluster Considerations

Ensure that Oracle GoldenGate Manager is installed as a Service on each node in the cluster. The
Oracle GoldenGate Manager resource in the SQL Server Cluster Group must be moved to each node
and Oracle GoldenGate Manager installed as a service. To do so without moving all the resources in
the SQL Server Cluster Group, do the following:
1. Create a new, temporary cluster group.

2. Ensure that the GGS Manager resource is NOT checked to “Affect the Group” on failover.
3. Ensure that the disk resource W, for Oracle GoldenGate is NOT checked to “Affect the Group”
on failover if Oracle GoldenGate is the only resource using this disk resource.
4. Stop all Extracts and Pumps from GGSCI with STOP ER *
5. Take GGS Manager Offline from Cluster Administrator.
6. Delete any dependencies for the GG Manager resource.
7. Move the GGS Manager resource from the SQL Server Cluster Group to the newly created
cluster group.
8. Move this drive resource to the newly created cluster group.
9. Move the newly created group to the new node.
10. Login to the new node and browse to the GG install directory.
11. Start GGSCI.EXE and type:
a. SHELL INSTALL ADDSERVICE ADDEVENTS
12. Open the Windows Services applet and set the Log On account for the GGSMGR service that
was just created if using other than the default, Local System Account.
13. Ensure that the Log On account for the GGSMGR service is a member of the new node’s local
Administrators Group.
14. Ensure that system DSN’s have been created on the new node exactly as they have been created
on the primary node.
15. Bring GGS Manager Resource online through Cluster Administrator.
16. Verify in GGSCI that All Extracts and Pumps have started. They should start automatically
when GGS Manager Resource comes online, but may take a few seconds and may require a
manual start with: START ER *
17. Stop Extracts and Pumps in GGSCI with: STOP ER *
18. Move the new cluster group with the GGS Manager and disk resource back to the primary node.
19. Move both resources in the new cluster group back to the SQL Server Cluster Group and reset
the dependencies for the GGS Manager Resource (SQL Server and drive W resource
dependencies).
20. Delete the temporary cluster group created in Step 1.
21. Bring GGS Manager Resource back online, and verify all Extracts and Pumps are running
through GGSCI.
22. BOOTDELAYMINUTES
This WINDOWS parameter and must be the first entry in the Manager parameter file.
BOOTDELAYMINUTES specifies the amount of time Manager is to delay after the server has
booted. This delay is to allow other server components (RAID disks, database, network, etc) to
startup and become active before Manager begins processing
Max Protection Capture

Oracle GoldenGate for Teradata, configured in Maximum Protection Mode offers the highest level
of data protection for replication. Transactions are not committed on the Teradata Database server
until Oracle GoldenGate has acknowledged receipt of all data for the transaction.
TAM Configuration
The Teradata Access Module, or TAM, must be obtained from Teradata and installed into the Oracle
GoldenGate object directory before Extract can be implemented. This module is linked into the
Oracle GoldenGate Extract program at startup time and provides Extract with links into the Teradata
database environment.
TAM requires a configuration file be present that provides specifics about the Teradata environment
and the Teradata Replication Group that will be used to facilitate Oracle GoldenGate Extract.
TAM Initialization File

The TAM configuration file may be created via any text editor, and should be saved with the suffix
“.ini”. It is recommended to store these files within the Oracle GoldenGate installation directory, in a
subdirectory named “dirtam”. Information required in this file is:
1. The mode of operation, Replication or TableCopy

a. For change data capture, enter
i. Mode=REPLICATION
2. The OBDC connection string used to access the Teradata data dictionary
a. This is the ODBC Data Source information previously configured.
b. If you did not specify a username and password in the ODBC configuration, enter
i. DictOdbcConnString=DSN=<ODBC DSN>;uid=<userid>;pwd=<password>
c. If you provided the database username and password in the ODBC configuration, enter
i. DictOdbcConnString=DSN=<ODBC DSN>;
3. The ODBC connection string used to execute management functions on the Teradata database.
a. This is the ODBC Data Source information previously configured.
b. If you did not specify a username and password in the ODBC configuration, enter
i. MgmtOdbcConnString=DSN=<ODBC DSN>;uid=<userid>;pwd=<password>
c. If you provided the database userid and password in the ODBC configuration, enter
i. MgmtOdbcConnString=DSN=<ODBC DSN>;
4. CopyThreadDataWaitSleep=0.001 (1 millisecond)
a. The default is .5 seconds
b. This is the amount of time the TAM will sleep if there is no data queued from the RSG.
5. MaxCopyQueueSize=1024
a. The default is 10, 1024 is the maximum.
b. This is the size of the TAM queue buffer. Each buffer “slot” is 256k.
6. MaxProtTransCompleteThresh=1
a. Number of completed transactions after which GG checkpoint must be requested.
b. The default is 0, which utilizes the Extract setting.
c. The setting of “1” is best for large transactions (over 10k) and when a single Teradata
session is used. The default setting should be used for small, OLTP type transactions.
7. The fully qualified disk file name of the file containing the Teradata commands to create the
above named Teradata Replication Group
a. CreateGroupStmtFile=<disk file>
b. For Teradata 12 and above if this parameter is not used, GroupId and SecurityToken must
be specified
i. GroupId is obtained by querying the database.
ii. SecurityToken is obtained by issuing an “Alter Replication Group” command
within Teradata SQL Assistant.
8. The database character set
a. CharacterSet=ASCII
9. The node name or ipaddress of the Teradata Control Node, Alternate Control Node and Data
RSG Nodes. Specify one Data RSG per configured RSG.
a. ControlRSG=<node>
b. AltControlRSG=<node>
c. DataRSG1=<node>
d. DataRSG2=<node>
e. DataRSG<n>=<node>
10. Which types of messages are encrypted
a. Encryption=All
11. UPDATEBEFOREIMAGES=TRUE
a. Specifies whether before images are sent.
b. Default is false, must be true if GETBEFORES is set in TAM Extract or if Extract is to
capture update operations.
i. The VAM Extract will abend if an update operation is received, this option is not
set to FALSE (the default), and there is no Unique Index on the table.
An example tam.ini file is provided in Table 2.
Table 2. Sample tam.ini file

Mode=Replication
DictOdbcConnString=DSN=GGSTera;uid=gguser;pwd=ggpwd
MgmtOdbcConnString=DSN=GGSTera;uid=gguser;pwd=ggpwd
CreateGroupStmtFile=c:\GGS\Teradata\dirtam\hrtrg1.sql
CharacterSet=ASCII
ControlRSG=terixps
AltControlRSG=terixps
DataRSG1=terixps
DataRSG2=terixps
Encryption=All
MaxCopyQueueSize=1024
CopyThreadDataWaitSleep=0.001
MaxProtTransCompleteThresh=1
UPDATEBEFOREIMAGES=TRUE
When Oracle GoldenGate Extract is started, the information provided will be used by TAM to
establish communication between the database and Extract. The tam.ini file will be updated with the
Teradata Replication Group Security Token. A maximum of 99 Teradata Replication Groups are
permitted.
Create Group Statement File
The Create Group Statement file may be created via any text editor, and should be saved with the
suffix “.sql”. It is recommended to store these files within the Oracle GoldenGate installation
directory, in a subdirectory named “dirtam”. Information required in this file is:
1. The Teradata command “create replication group”

2. The name of the Teradata Replication Group
3. The table list associated with the Teradata Replication Group
a. A database table may only be associated with one Teradata Replication Group
b. Only one Teradata Replication Group is allowed per Oracle GoldenGate Extract
Table 3 shows an example of the create group statement file read by the tam.ini file presented in
Table 2.
Table 3. Sample Create Group Statement File

Create Replication Group HRTRG1 (HR.EMPLOYEE,
HR.EMP_INFO,
HR.EMP_DEPT,
HR.EMP_REVIEWS);
When the Replication Group is created, Teradata assigns the group to an available RSG. The
assignments are made “round-robin” among the configured RSG vprocs. Once the RSG connection
is made, all data for tables associated with the Replication Group will be processed through the
assigned RSG. There is no supported functionality to allow RSG reassignment or tuning within
Teradata.
Change Data Capture

In this section we will discuss the specific configuration requirements, and items that must be taken
into consideration when setting up Oracle GoldenGate Capture in Max Protection mode.
Considerations
Maximum Protection mode offers the highest level of data protection for replication. Transactions
are not committed on the Teradata Database server until Oracle GoldenGate has acknowledged
receipt of all data for the transaction.
Under this mode of operation, if Oracle GoldenGate Extract disconnects from the database,
processing of transactions continues; however, they are not committed back to the client application.
If Oracle GoldenGate does not reestablish connectivity within the timeframe denoted by the
Teradata DBSControl field “Client Reset Timeout”; the database aborts all transactions not
acknowledged by Oracle GoldenGate.
Maximum Protection mode employs a two-phase commit protocol between the database server and
Oracle GoldenGate to ensure that no transactions are lost or sent more than once in the event of
failure of either of the Teradata servers, Oracle GoldenGate, or communication links.
VAM Extract Configuration
Parameters required to configure Extract for Max Protection are:
1. DSOPTIONS CREATETRANLOG, RESTARTAPPEND, VAMCOMPATIBILITY 1

a. These data source options specify the Extract access mode.
i. CREATETRANLOG
1. Places Extract in Max Protection mode. Teradata transaction
data is persisted to disk. The TAM sends transaction data
changes to Extract, which then writes the data to a VAM Trail.
ii. RESTARTAPPEND
1. Directs Extract to append data to the end of the Oracle
GoldenGate trail upon restart, rather than rewriting data that was
written in a previous run.
iii. VAMCOMPATIBILITY 1
1. A value of 1 means the original VAM API metadata structure is
being used. This structure was originally created for Teradata,
which is a separate implementation from the other databases,
and Teradata still uses this level.
By default, when Extract encounters an end of file condition, it goes to sleep for 60 seconds. Since
Teradata RSG sends data to TAM in batches, Extract goes to sleep between RSG data batches. To
improve performance it is recommended that the parameter “EOFDELAY 0” be set in the VAM
Extract. Setting this parameter will prevent Extract from going to sleep when the TAM is queried for
data and there is nothing to retrieve (an EOF condition exists). The drawback of setting this
parameter is increased CPU utilization due to the increased calls to TAM during slow database
periods.
If CPU utilization rates are a concern, setting EOFDELAYCSECS (this specifies time in 1/100 th of a
second intervals) to a value greater than 0 and less than 100 will ensure Extract sleeps less than 60
seconds when an end of file condition is encountered. A setting of “EOFDELAYCSECS 10” will
cause Extract to delay one-tenth of a second before querying TAM for more data.
The TAM setting CopyThreadDataWaitSleep may be used to override this Extract option. The
recommended setting for CopyThreadDataWaitSleep from Teradata is 0.001 (one one-thousands of a
second).
A sample Extract parameter file is provided in Table 4.
Table 4. Sample Extract Parameter File

extract ehremp
sourcedb vm050_td13, userid lpenton, password lpenton
dsoptions createtranlog, restartappend, vamcompatibility 1
wildcardresolve dynamic
vam ./tam.dll params(inifile ./dirtam/hrtrg1.ini, callbacklib
extract.exe)
eofdelaycsecs 10
reportcount every 60 minutes, rate
statoptions resetreportstats
report at 00:01
reportrollover at 00:01
exttrail ./dirdat/hr
table hr.*;
Generating Extract Performance Statistics
In our sample Extract parameter file we can generate information related to the performance of
Extract and workload per table by setting the following options:
1. REPORTCOUNT EVERY 60 MINUTES, RATE

a. This option will cause Extract to write a line in its current report file hourly reporting
the number of records processed since startup.
b. The option RATE specifies that Extract is to report the number of operations per
second and the change in rate since the last count report. These items are displayed in
the report file as:
i. The “rate” statistic is the total number of records divided by the total time
elapsed since the process started.
ii. The “delta” statistic is the number of records since the last report divided by
the time since the last report.
iii. This information may be used to track peak hour workload for trend analysis
as an aid in tuning Extract.
2. STATOPTIONS RESETREPORTSTATS
a. This option will cause Extract to reset its statistics whenever a new report file is
generated.
3. REPORT AT 00:01
a. This option will cause Extract to report total operations processed per table, by
operation type daily at 1 minute after midnight.
b. This information may be used to track daily workload per table for trend analysis as an
aid in tuning Extract.
4. REPORT ROLLOVER AT 00:01
a. This option will cause Extract to close its current report file and create a new report file
daily at 1 minute after midnight.
b. Doing so will result in Extract resetting its internal statistical counters.
Create the Extract Checkpoint

Create the Extract checkpoint using the keyword “VAM” on the GGSCI “add extract” command
line. VAM indicates that a Vendor Access Module (tam.dll or tam.so) will be used to capture data
from the database..
Bi-Directional Extract Considerations

When setting up Extract for a multi site active-active environment, we must ensure that data applied
to one site via the Oracle GoldenGate Replicat process is not captured and sent back to its source
database. To eliminate this continuous data loop, two additional parameters are required for Extract:
1. SQLEXEC "SET SESSION OVERRIDE REPLICATION ON;"

2. SQLEXEC “COMMIT;”
KEYCOLS Usage
In environments in which the source table has no defined keys or indices, listing tables with an
associated KEYCOLS clause of the VAM extract has been shown to improve both Extract and
Replicat performance, as well as reduce or eliminate concrete step errors in associated Replicats.
The columns specified in the KEYCOLS clause in the VAM Extract must be a real part of the
schema and table but do not need to be keys or indices or parts of such.
Configure VAM Sort Extract
VAM Sort Extracts are required when Oracle GoldenGate Extract is in Max Protection mode. The
Oracle GoldenGate Extract writes data in log-style format, which interleaves change records for
different transactions into the VAM Trail. This data must be sorted into correct change sequence
order before it can be applied to the target database.
This sorting is performed by a VAM Sort Extract process.
Table 5 provides a sample configuration file for a VAM Sort Extract associated with a Teradata
Extract.
NOTE: Because of the performance impact, the VAM Sort Extract should write to a local
EXTTRAIL, and never be configured to transmit data over TCP/IP to the target Oracle GoldenGate
Server.
Table 5. Sample VAM Sort Extract Parameter File

extract phremp
exttrail ./dirdat/pe
sourcedb vm050_td13, userid lpenton, password lpenton
dsoptions sorttranlog
table hr.*;
The data source option “SORTTRANLOG” is required and specifies that Extract will sort the
interleaved database transactions into correct prepare/commit/rollback transactional units.
Create the VAM Sort Checkpoint

Create the VAM Sort Extract checkpoint using the keyword “VAMTRAILSOURCE” and a disk
location for writing the VAM Trail on the GGSCI “add extract” command line.
VAMTRAILSOURCE specifies that Extract will write data in log-style format which requires
further processing before it can be sent to Replicat.
Using KEYCOLS
KEYCOLS should not be specified for the VAM Sort Extract.
Configure Extract Data Pump

For Teradata implementations, the Oracle GoldenGate Extract Data Pump is configured in the same
manner as other Oracle GoldenGate installations. As mentioned previously, Extract Data Pumps are
only required if the data is to be transmitted via TCP/IP to a target Oracle GoldenGate installation
where it will be applied to a secondary Teradata database by Oracle GoldenGate Replicat.
Table 6 provides a sample configuration file for a Data Pump associated with a Teradata Extract.
Table 6. Sample Extract Data Pump Parameter File

EXTRACT PHREMP
PASSTHRU
RMTHOST monterey, MGRPORT 15000, COMPRESS
RMTTRAIL ./dirdat/pe
TABLE hr.*;
As with all Extract Data Pumps, the parameter “PASSTHRU” is required to move the data without
accessing the database or interpreting the incoming data. If table mapping, or data transformation is
performed in the Data Pump, ODBC connect information must be provided via the SOURCEDB
parameter.
RMTHOST Options
COMPRESS
COMPRESS should be set anytime data is being transmitted over TCP/P. Compressing outgoing
blocks of records to reduce bandwidth requirements. Oracle GoldenGate decompresses the data
before writing it to the trail.
COMPRESS typically results in compression ratios of at least 4:1 and sometimes better.
Encryption
Data transmitted via public networks should be encrypted. Transactions containing sensitive data
(credit card numbers, social security numbers, healthcare information, etc) must be encrypted before
transmission over unsecure networks.
TCPBUFSIZE
TCPBUFSIZE controls the size of the TCP socket buffer in bytes. By increasing the size of the
buffer larger packets can be sent to the target system. The actual size of the buffer depends on the
TCP stack implementation and the network. The default is 30,000 bytes, but modern network
configurations usually support higher values.
Valid values are from 1000 to 200000000 (two hundred million) bytes.
To compute the proper TCPBUFSIZE setting:
1. Use ping to determine the average round trip time to the target server.
a. PING has several options that may be specified:
i. “-n <count>”
1. The number of echo requests to send. Defaults to 4.
ii. “-l <size>”
1. The size of the ping packet. Defaults to 32 bytes.
b. If you know the average transaction size for data captured, use that value for the
ping; otherwise, use the default.
2. After obtaining the average round trip time, multiply that value by the network
bandwidth.
a. For example, ping returned 64 ms as the average round trip time, and the network
bandwidth is 100 Mb. Multiplying these two numbers will product a result of: .07
* 100 = 7 Mb (.065 rounded up)
3. Network bandwidth is in bits per second, so we need to convert the result from step 2
into bytes per second.
a. Divide the result in step 2 by 8: 7/8 = .875 megabytes per second.
4. TCPBUFSIZE should be set to 875000 in this instance.
On Unix/Linux systems using the ifconfig command to get the TCP Receive Space will also provide
the correct value for the TCPBUFSIZE. On the target system issue the following command:
ifconfig –a
Example output:
eth0 Link encap:Ethernet HWaddr 00:0C:29:89:3A:0A

inet addr:192.168.105.166 Bcast:192.168.105.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST TCP Receive Space:125000 Metric:1
RX packets:23981 errors:0 dropped:0 overruns:0 frame:0
TX packets:5853 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2636515 (2.5 MiB) TX bytes:5215936 (4.9 MiB)
Interrupt:185 Base address:0x2024
Note that the TCP Receive Space is 125000.Therefore for shortest send wait time set the
TCPBUFSIZE also to 125000.
The waittime can be determined by the ggsci command:
send <extract pump>, gettcpstats
Example output:
Sending GETTCPSTATS request to EXTRACT PHREMP ...
RMTTRAIL .\dirdat\pe000000, RBA 717

OK
Session Index 0
Stats started 2008/06/20 16:06:07.149000 0:00:11.234000
Local address 192.168.105.151:23822 Remote address 192.168.105.151:41502
Inbound Msgs 9 Bytes 66, 6 bytes/second
Outbound Msgs 10 Bytes 1197, 108 bytes/second
Recvs 18
Sends 10
Avg bytes per recv 3, per msg 7
Avg bytes per send 119, per msg 119
Recv Wait Time 125000, per msg 13888, per recv 6944
Send Wait Time 0, per msg 0, per send 0
The lower the send Wait time the better performance for the pump over the network.
The customer network administrator can also assist in determining an optimal value.
TCPFLUSHBYTES
TCPFLUSHBYTES controls the size of the buffer, in bytes, that collects data that is ready to be sent
across the network. When this value is reached, the data is flushed to the target.
Set TCPFLUSHBYTES to the same value as TCPBUFSIZE.
Refer to the Oracle GoldenGate Reference Manual for more information on configuring Data
Pumps.
Configure Replicat
For Teradata implementations, Oracle GoldenGate Replicat differs slightly from other Oracle
GoldenGate installations in that ODBC is used to connect to the target database. All other Replicat
functionality remains the same.
Teradata to Teradata Configuration

Table 7 presents an example Replicat parameter file for data captured from another Teradata
database. In this example, the source and target tables are identical and reside in the same table
space; so no column mapping, data mapping, or data transformation is required.
Table 7. Replicat Parameters – Teradata to Teradata

replicat rhremp
targetdb vm050_td13, userid lpenton, password lpenton
assumetargetdefs
discardfile ./dirrpt/rhemp.dsc, append
maxtransops 500
batchsql batchtransops 500, bytesperqueue 1000000
report at 00:01
map hr.employee, target hr.employee;
map hr.emp_info, target hr.emp_info;
map hr.emp_dept, target hr.emp_dept;
map hr.emp_reviews, target hr.emp_reviews;
If the target tables had different column names, columns of different data types, more columns than
the source, or fewer columns than the source, Oracle GoldenGate data transformation functionality
could be used to the source data to the appropriate target columns.
For more information on column mapping and data transformation functions, refer to the Oracle
GoldenGate Reference Guide.
Other Databases to Teradata Configuration

Table 8 presents an example Replicat parameter file for data captured from an Oracle database that is
to be applied to a Teradata database. When performing cross-database replication there are several
items that must be addressed; this example shows how we would configure Replicat to address:
• Differences between the source and target database name.
• Differences in table names.
• Column name differences.
Data transformation is performed via the parameter “SOURCEDEFS”. This parameter specifies a
file name that contains information about the source data; table name, column names, data types,
data length, offset, etc. Replicat uses this information to map and convert the incoming source data
to its Teradata target. The file specified in the SOURCEDEFS parameter is created via the Oracle
GoldenGate DEFGEN utility on the source system and is stored in the “dirdef” subdirectory of the
Teradata Oracle GoldenGate installation directory.
Table 8. Replicat Parameters – Oracle to Teradata
replicat rhremp
targetdb vm050_td13, userid lpenton, password lpenton
sourcedefs ./dirdef/oradefs.def
discardfile ./dirrpt/rhemp.dsc, append
maxtransops 500
batchsql batchtransops 500, bytesperqueue 1000000, opsperbatch 500
report at 00:01
map personnel.emp, target hr.employee,
colmap (usedefaults,
employee_name = emp_name,
employee_number = emp_nbr
);
map personnel.emp_info, target hr.emp_info,
address = emp_add,
apartment_no = emp_add2,
next_of_kin = emp_nok,
hire_date = date_of_hire;
);
map personnel.emp_dept, target hr.emp_dept,
);
map personnel.emp_reviews, target hr.emp_reviews,
);
For more information on column mapping, DEFGEN, and data transformation functions, refer to the
Oracle GoldenGate Reference Guide.
Turbo Apply for Teradata

Turbo Apply must be specified when the target database is Teradata; this allows Oracle GoldenGate
Apply processes to take advantage of the inherent speed of Teradata by submitting data in larger
batches than normal.
To specify Turbo Apply, add the following option to the Replicat parameter file:
BATCHSQL BATCHTRANSOPS 500, BYTESPERQUEUE 1000000, OPSPERBATCH 500
By default Oracle GoldenGate Turbo Apply has a limit of 20Mbytes per write operation. Teradata
ODBC can only handle 1 Mb of data per operation; so Replicat must be set to not exceed the
limitations of Teradata ODBC. This is done by specifying the maximum number of batch operations
per batch (500) and maximum number of bytes per batch queue (1 million) when activating
BATCHSQL.
To prevent Replicat error 3714 “Concrete Step” warnings, the number of operations per batch is set
to 500, instead of the default 1200. This value maybe reduced as needed.
Using KEYCOLS in Replicat
If the Teradata table definition contains non-unique primary indexes, specifying KEYCOLS on the
NUPI column(s) plays a significant role in the reduction of "concrete step" errors in Replicat. The
overhead of the pseudo all-column key when there is no defined UPI takes enough memory to
overrun the Teradata ODBC with even the most conservative sized transaction group.
For example, a NUPI table has 155 columns and we specify KEYCOLS on 4 columns:
For update operations on the NUPI table we would be comparing 155 key columns. For every update
we'll loop through all of the columns to see if any column changed (to determine if it's a key update).
Ultimately, it will be. In this case, we must include all 155 columns for the before image, and those
same 155 columns in the after image for the primary key update record (310 columns in each key
update record).
By specifying the 4 KEYCOLS columns we only have 8 columns (4 * 2) plus the changed columns
in each update record.
The processing and I/O overhead can be significant just based on the number of columns being
processed.
Generating Replicat Performance Statistics

In our sample parameter file we can generate information related to the performance of Replicat and
workload per table by setting the following options:
1. REPORTCOUNT EVERY 60 MINUTES, RATE

a. This option will cause Replicat to write a line in its current report file hourly reporting the
number of records processed since startup.
b. The option RATE specifies that Replicat is to report the number of operations per second
and the change in rate since the last count report. These items are displayed in the report file
as:
i. The “rate” statistic is the total number of records divided by the total time elapsed
since the process started.
ii. The “delta” statistic is the number of records since the last report divided by the
time since the last report.
c. This information may be used to track peak hour workload for trend analysis as an aid in
tuning Replicat.
2. STATOPTIONS RESETREPORTSTATS
a. This option will cause Replicat to reset its statistics whenever a new report file is generated.
3. REPORT AT 00:01
a. This option will cause Replicat to report total operations processed per table, by operation
type daily at 1 minute after midnight.
b. This information may be used to track daily workload per table for trend analysis as an aid
in tuning Replicat.
4. REPORT ROLLOVER AT 00:01
a. This option will cause Replicat to close its current report file and create a new report file
daily at 1 minute after midnight.
b. Doing so will result in Replicat resetting its internal statistical counters.
Oracle GoldenGate Macros
Oracle GoldenGate Macros provide the ability to reuse and share common configuration options
across multiple components in a Oracle GoldenGate instance. For a large Teradata installation
macros may be used:
1. To provide a single location for storing database DSN and user access information.
2. Share common configuration options across all VAM Extract, VAM Sort, and Replicat groups.
In this situation, a Macro Library is the best choice as the shared configuration options may be stored
externally to the Oracle GoldenGate parameter file. Macro Library text files should be stored in a
subdirectory to the Oracle GoldenGate installation named “dirmac”. Table 9 depicts a sample Macro
Library file.
Table 9. Sample Macro Library File

--
-- ODBC Connection Macro
--
MACRO #odbc_connect
BEGIN
sourcedb GGSTera, userid lpenton, password AAAAAAAAAHAUIMASJHFRHJBEHTA,
encryptkey terakey
END;
--
-- MAX Protection VAM Extract
--
MACRO #max_protect
PARAMS (#tam, #tamini)
BEGIN
vam #tam PARAMS(inifile, #tamini, callbacklib, extract.exe)
dsoptions createtranlog, restartappend, vamcompatibility 1
END;
--
-- VAM Sort DSOPTIONS
--
MACRO #vam_sort
BEGIN
dsoptions sorttranlog
END;
--
-- Generate Statistics
--
MACRO #gen_stats
BEGIN
report at 00:01
END;
In our sample macro library file, the password to establish a database connection has been encrypted.
Proper security protocol prohibits the storage of clear passwords within text files, so encrypting the
database access password for Oracle GoldenGate is required.
The GGSCI command “encrypt password” is used to accomplish this task. For more information on
password encryption refer to the Oracle GoldenGate Reference Manual.
Table 10 shows VAM Extract parameter file that utilizes Oracle GoldenGate Macros to share
Table 10. Max Protection Extract Parameter File

nolist
include ./dirmac/mac_lib.mac
list
extract ehremp
#odbc_connect ()
#max_protect(./dirtam/td12//tam.dll, ./dirtam/cust13a.ini)
#gen_stats ()
exttrail ./dirdat/hr
table hr.*;
In our sample parameter file, anything following “NOLIST” will not be written to the report file. In
this case, the contents of the Macro Library file ./dirmac/mac_lib.mac will be read by Extract at
startup; but not written to its report file. Use “LIST” to turn on report file display.
Three Macros are called that utilizes configurations options from the Library:
1. #odbc_connect_ext () retrieves the database connect information.

2. #max_protect(./dirtam/td12//tam.dll, ./dirtam/cust13a.ini) retrieves the configuration options to
set the Extract in Maximum Protection mode, provides the location of the tam.dll shared library
file, and provides the TAM INI file location for VAM as a parameter to the macro.
3. #gen_stats () configures Extract to report statistical information for performance analysis and
tuning.
DDL Replication
Data Dictionary Language replication is supported for Teradata Database version 13 and above,
Teradata Access Module (TAM) 13, and Oracle GoldenGate version 10 or greater installations.
For detailed information on DDL replication, see the Oracle GoldenGate Administrator Guide.
A Teradata DDL statement can be replicated when it satisfies one of the following conditions:
 The DDL statement affects a table that is a member of a replication group.
 The DDL statement matches a user-defined replication rule.
 The DDL statement changes certain properties of a replication group.
Things to consider when enabling DDL Replication:
1. Only unidirectional configurations are supported and like to like configurations are supported.
2. All filtering, mapping, and transformation of data operations must be performed by a primary
Extract process or by Replicat. All of the tables that use DDL support must be configured for
PASSTHRU mode in the Data Pump parameter file.
3. Keep related DDL and DML together in the same process stream to ensure data integrity.
Configure the processes so that:
a. All DDL and DML for any given object are processed by the same Extract group and
by the same Replicat group.
b. All objects that are relational to an object are processed by the same group as the
parent object.
4. If an Extract group writes to multiple trails that are read by different Replicat groups, Extract
sends all of the DDL to all of the trails. Use each Replicat group to filter the DDL by using the
filter options of the DDL parameter.
5. On the source, DDL support is disabled by default.
6. On the target, DDL support is enabled by default, to maintain the integrity of transactional data
that is replicated. By default, Replicat will process all DDL operations that the trail contains.
Replicat may be configured to ignore or filter DDL operations by using parameter settings.
Enable DDL Capture in Teradata

To enable DDL Capture in Teradata
1. Login to SQL Assistant as a user with REPCONTROL authority.

2. Determine which Replication Group will be used in the capture of DDL.
a. If multiple Replication Groups exist, DDL capture should be enabled for those tables
defined in each group.
3. Execute the Teradata command “CREATE REPLICATION RULESET” to specify for which
objects TAM is to pass DDL.
The syntax for CREATE REPLICATION RULESET is:
CREATE REPLICATION RULESET <name> FOR <Replication Group> AS [TABLE | VIEW |

INDEX | TRIGGER | TEMPORARY TABLE | TRIGGER] LIKE ‘<database>. [object name | %]’;
The command:
CREATE REPLICATION RULESET RULE_LP_CUST FOR LP_CUST AS TABLE LIKE

'LPENTON.%';
Creates a replication Ruleset named “RULE_LP_CUST” for the preconfigured Replication Group
“LP_CUST” specifying that TAM is to capture all table DDL operations in the “LPENTON”
database. “%” is a wildcard parameter, so all table alter, create, and drop statements will be passed to
Extract.
If multiple Replication Groups and VAM Captures exist, specify each table already associated with a
Replication Group in a corresponding Ruleset silimar to the following:
CREATE REPLICATION RULESET RULE_LP_CUST FOR LP_CUST AS

TABLE LIKE 'LPENTON.ACCTINFO',
TABLE LIKE 'LPENTON.ACCT_ACTIVITY',
TABLE LIKE 'LPENTON.ACCT_PROFILE';
Enable DDL Capture in VAM Extract

Adding the parameter “DDL INCLUDE ALL” to the VAM Extract will enable DDL capture for all
supported Teradata DDL operations.
Note: There are a multitude of configuration options for the DDL parameter related to scope,
operation types, object types, object names, instruction strings, and instruction words; so be sure to
review the Oracle GoldenGate Administrators Guide to determine which setting is best for a
particular production implementation.
Enable DDL Passthru in Sort Extract

All of the tables that use DDL support must be configured for PASSTHRU mode in the Sort Extract
parameter file.
Enable DDL Passthru in Data Pump

All of the tables that use DDL support must be configured for PASSTHRU mode in the Data Pump
parameter file.
If data filtering or transformation is required for DML operations in the Data Pump, set PASSTHRU
for tables where DDL support is required then set NOPASSTHRU for tables where DML
transformation is required.
Enable DDL Apply in Replicat

By default, DDL INCLUDE ALL is enabled in Replicat, along with DDLOPTIONS
MAPDERIVED. These settings specify that if a MAP statement exists for the derived object, the
name is mapped to the name specified in that TARGET clause; otherwise, the name is mapped to the
name specified in the TARGET clause of the MAP statement that contains the base object.
Maintenance Tasks
Database maintenance is less intrusive when DDL Replication is enabled as the Teradata Replication
Group may remain active when modifying existing table schema or adding new tables for
Replication. Below are some common tasks and steps to perform the maintenance item (the
assumption is that Oracle GoldenGate is configured for DDL Replication).
Modify Table Columns

To add or drop columns from a replicated table:
1. In SQL Assistant, check that the table is part of a Replication Ruleset

a. select * from dbc.repcapturerulesv where likepattern like '<database>.<table>%'
i. Database and table must be in uppercase.
ii. % is a wildcard. All table names containing the designated text will be
returned.
2. If the table is contained within an existing Replication Ruleset, or the Replication Ruleset
LikePattern is wildcarded
a. Execute the table alter in SQL Assistant
3. If a Replication Ruleset does not exist for the table
a. And none exist for the Replication Group assigned to the table
i. Create the new Replication Ruleset
b. But one exists for the Replication Group assigned to the table
i. Replace the existing Replication Ruleset, to include the additional table
1. REPLACE REPLICATION RULESET <name> FOR <replication
group> AS
TABLE LIKE ‘<database>,<table>’,
TABLE LIKE ‘<database>.<table>’;
c. Execute the table alter in SQL Assistant.
Add a New Table to an Existing Extract

1. In SQL Assistant, check that Extract’s Replication Group has a define Replication Ruleset
a. select * from dbc.repcapturerulesv;
2. If a Replication Ruleset exists
a. Execute the table create statement
3. If a Replication Ruleset does not exist for the table
a. Create the new Replication Ruleset.
b. Execute the table create statement.
Note: If the VAM Extract table definition is not wildcarded, the new table must be added to the
Extract table list and the Extract stopped and restarted before the table will be recognized by Oracle
GoldenGate.
Create New Tables and Oracle GoldenGate Components

To create a new set of tables for DML and DDL replication, and the associated Oracle GoldenGate
components:
1. Create a new TAM.INI file that will be used by the VAM Extract.
2. Create the associated CreateGroupStmtFile.
a. Specify an empty Teradata Replication Group.
i. Create Replication Group <name>;
3. Create the Oracle GoldenGate components.
4. Start the VAM Extract.
5. Create the Teradata Replication Ruleset.
6. Create the Teradata tables.
Note: If an empty Teradata Replication Group is created for existing tables, no data will be captured
by the VAM Extract and no warning or error messages will be presented by Oracle GoldenGate.
Staging Tables
Often it is not practical to have Replicat apply data direct to the target Teradata tables. This may be
due to data transformation requirements not provided with the Oracle GoldenGate product, heavy
workloads, or other reasons. In these situations, utilizing Oracle GoldenGate to apply data to a
staging table that is processed via another mechanism may be the only alternative.
In most Teradata environments, these staging tables are processed at regular time intervals via an
Informatica job, Teradata Multiload job, or some other mechanism that loads the target table in a
batch mode. When the load is performed via Informatica, be aware that Informatica performs a table
lock on the staging table which will block Replicat and any other process attempting to gain access
to staging table data. By default, Replicat will recover from these table locks; however, other
applications or utilities (including Informatica) will not.
One of the main issues with processing staging tables is determining proper transaction sequencing
to ensure update and delete operations are processed in proper order. In this section we shall discuss
configuration guidelines for the staging table, Extract, and Replicat to ensure records maybe sorted
in correct transaction sequence by the batch load utility and identify options within Oracle
GoldenGate that maybe used to eliminate the need to use Informatica for batch job processing.
Teradata to Teradata
Staging Table Configuration

When configuring the staging table and the source is Teradata; three additional columns must be
added that will be used to select records from the staging table to process, identify the record
operation, and provide a mechanism for sorting the records in proper transaction sequence.
Column Name Data Type Usage

GG_OPTYPE CHAR(1) Identify the source operation
GG_COMMIT_TS TIMESTAMP(6 Timestamp used for record
) selection in batch processing
GG_LOGPOSITION_LOGRBA DECIMAL(18,0 Sorting in transaction
) sequence
For Teradata, we must used a derived column GG_LOGPOSITION_LOGRBA that identifies the
Oracle GoldenGate Trail sequence number and relative byte address of the record within the trail for
the data row. For other databases, Extract can pass the record sequence number (RSN) of the
transaction in the source database as a token; however, this data does not exist in Teradata.
Extract Configuration
Extract must be configured to pass full data images for insert and delete operations. In the VAM
Extract parameter file this is accomplished by specifying:
1. NOCOMPRESSUPDATES
2. NOCOMPRESSDELETES
Replicat Configuration
In Replicat we must set options to insure all records are inserted into the staging table and then map
the additional data columns with proper data. Add the following to the Replicat parameter file:
1. INSERTALLRECORDS
a. Perform an insert of the record, no matter what the source operation.
2. In the table MAP statement, add the following column maps:
colmap ( usedefaults,
gg_logposition_logrba = @STRCAT (@STRNUM (@GETENV ("RECORD",
"FILESEQNO"), RIGHTZERO, 6), @STRNUM (@GETENV ("RECORD", "FILERBA"),
RIGHTZERO, 10)),
gg_commit_ts = @GETENV ("GGHEADER", "COMMITTIMESTAMP"),
gg_optype = @CASE(@GETENV ("GGHEADER", "OPTYPE"), "INSERT", "I",
"DELETE", "D", "U")
)
In the column mapping, we specify:
gg_logposition_logrba = @STRCAT (@STRNUM (@GETENV ("RECORD", "FILESEQNO"),

RIGHTZERO, 6), @STRNUM (@GETENV ("RECORD", "FILERBA"),
RIGHTZERO, 10))
 Here we derive information used to sort the data records by:

o Getting the file sequence number of the Oracle GoldenGate Trail being read by
Replicat and left pad this number by zero to ensure we always have a six digit number
that represents Oracle GoldenGate Trails 0 through 999999. This becomes the most
significant digit (left set of numerals).
o Getting the relative byte address of the record read within the Oracle GoldenGate Trail.
We left pad this number with zeros to ensure we always have a 10 digit number that
represents rba 0 through 2000000000. This becomes the least significant digit (right set
of numerals).
o Because we are going to concatenate the two sets of numerals together, they must be
converted from numbers to strings (Oracle GoldenGate only supports string
concatenation).
 We get the source record commit timestamp from the Oracle GoldenGate Record Header. This
will be used to determine what records the batch load utility will process.
gg_optype = @CASE(@GETENV ("GGHEADER", "OPTYPE"), "INSERT", "I", "DELETE", "D",

"U")
 We get the source operation type from the header. If the operation was an insert, we write “I”
into the gg_optype column; if a delete, “D”. If neither of these, the operation was an update and
we write “U”.
Other Databases to Teradata
Staging Table Configuration

When configuring the staging table and the source is non-Teradata, and the source Oracle
GoldenGate environment supports the use of @GETENV ("DBTRANSACTION", "RSN"); three
additional columns must be added that will be used to select records from the staging table to
process, identify the record operation, and provide a mechanism for sorting the records in proper
transaction sequence.
Column Name Data Type Usage

GG_OPTYPE CHAR(1) Identify the source operation
GG_COMMIT_TS TIMESTAMP(6) Timestamp used for record selection
in batch processing
TRANS_RSN VARCHAR(50) Sorting in transaction sequence
For Teradata, we must used a derived column GG_LOGPOSITION_LOGRBA that identifies the
Oracle GoldenGate Trail sequence number and relative byte address of the record within the trail for
the data row. For other databases, Extract can pass the record sequence number (RSN) of the
transaction in the source database as a token; however, this data does not exist in Teradata.
Extract Configuration
Extract must be configured to pass full data images for insert and delete operations. In the VAM
Extract parameter file this is accomplished by specifying:
NOCOMPRESSUPDATES
NOCOMPRESSDELETES
Additionally Extract must be configured to pass the transaction record sequence number from the
source database. This is accomplished by setting a token on the TABLE statement:
TOKENS (trans_rsn = @GETENV ("DBTRANSACTION", "RSN"))
Replicat Configuration
In Replicat we must set options to insure all records are inserted into the staging table and then map
the additional data columns with proper data. Add the following to the Replicat parameter file:
1. INSERTALLRECORDS
a. Perform an insert of the record, no matter what the source operation.
2. In the table MAP statement, add the following column maps:
colmap ( usedefaults,
trans_rsn = @TOKEN ("trans_rsn"),
gg_optype = @CASE(@GETENV ("GGHEADER", "OPTYPE"), "INSERT", "I",
"DELETE", "D", "U")
)
In the column mapping, we specify:
trans_rsn = @TOKEN ("trans_rsn")

 Here we get the transaction sequence number from the source database that was passed as a
Token by Extract.

 We get the source record commit timestamp from the Oracle GoldenGate Record Header. This
will be used to determine what records the batch load utility will process.
gg_optype = @CASE(@GETENV ("GGHEADER", "OPTYPE"), "INSERT", "I", "DELETE", "D",
"U")
 We get the source operation type from the header. If the operation was an insert, we write “I”
into the gg_optype column; if a delete, “D”. If neither of these, the operation was an update and
we write “U”.
Staging Table Processing With Oracle GoldenGate

Instead of utilizing Informatica or some other batch scheduling utility, Oracle GoldenGate may be
used to process staging tables.
Process the Table via SQLEXEC

The simplest method is to have Replicat execute a Teradata Stored Procedure that will read data
from the staging table prior to a certain timestamp, apply it to the target table, and then delete the
processed records from the staging table. This may be accomplished with a stand-alone SQLEXEC
that executes at defined intervals, via the Replicat parameter:
SQLEXEC “call <stored procedure>“ EVERY <n> [minutes | hours]
Note: Because of inefficiencies in calling Teradata Stored Procedures, this call should not be
performed too often (See section 11.7 for more information related to these ineffeciencies.)
Process the Table with Event Markers

Oracle GoldenGate Event Markers may be used to execute a shell script that executes Multiload or
some other batch load utility at specified intervals.
Oracle GoldenGate Event Markers are initiated at the source. To setup Event Markers to trigger
batch processing of the staging tables:
On the source side:
1. Create an event marker table that contains one column, such as:
CREATE SET TABLE LPENTON.GG_MARKER ,

NO FALLBACK,
NO BEFORE JOURNAL,
NO AFTER JOURNAL,
CHECKSUM = DEFAULT
( C1 TIMESTAMP(6) DEFAULT CURRENT_TIMESTAMP )
PRIMARY INDEX (C1);
2. Insert a row of data into the GG_MARKER table.

INSERT INTO LPENTON.GG_MARKER (C1) VALUES (CURRENT_TIMESTAMP);
3. In Extract, add the following:

a. A SQLEXEC to update the marker table and designated intervals
i. SQLEXEC “update lpenton.gg_marker set c1 = current_timestamp“ EVERY
<n> [minutes | hours]
b. A table statement to capture the update
i. TABLE lpenton.gg_marker;
On the target side:
1. Add a table statement to the Replicat parameter file to perform the shell call anytime an event
marker is read from the Oracle GoldenGate Trail.
TABLE LPENTON.GG_MARKER, EVENTACTIONS (SHELL <command>)

Synchronizing Data
Data synchronization techniques are discussed in detail in other documentation; however, the
preferred methodology for synchronizing two Teradata databases is to use any of the Teradata data
loader utilities. The recommended utilities are FastLoad and MultiLoad.
The steps to synchronize two Teradata databases are:
1. Create the FastLoad, or MultiLoad scripts.

2. Start the Oracle GoldenGate Extract(s).
3. Start the Oracle GoldenGate Extract Data Pump(s).
4. Modify the Oracle GoldenGate Replicat parameter file(s) to include two options
a. END RUNTIME
i. Directs Replicat to terminate normally when it reads a Oracle GoldenGate
Trail record with the same timestamp, or a timestamp after the time
Replicat was started.
b. HANDLECOLLISIONS
i. Directs Replicat to override certain data issues
1. Duplicate records are overwritten
2. Missing records are ignored
5. Start the FastLoad/MultiLoad
6. When the Teradata load process completes, start the Oracle GoldenGate Replicat
process(es)
7. When the Replicat process(es) stop, remove the HANDLECOLLISIONS and END
RUNTIME parameters. The databases are in sync.
8. Restart the Oracle GoldenGate Replicat process(es).
Refer to the Teradata Zero Downtime Migration Best Practices document for details on how to
perform target instantiation for ZDM installations.
Maintenance
When a table is setup for change data capture, the Teradata Replication Group must be inactive
before table maintenance tasks maybe performed. Below are some common tasks and steps that must
be taken to perform the maintenance item. (Note: DDL capture is supported in Teradata 13.)
Delete Oracle GoldenGate Extract

To delete a Oracle GoldenGate Extract process, it must be “decoupled” from the Teradata
Replication Group.
1. Start the Oracle GoldenGate Software Command Interpreter (GGSCI).

a. With the Extract group in the “running” state, issue the command:
i. send extract <capture name>, vammessage “control:terminate”
b. Issue the command:
i. stop extract <capture name>
c. Issue the command:
i. delete extract <capture name> !
d. Issue the command:
i. send extract <capture name>, vammessage “SQL: DROP
REPLICATION GROUP <repgroup name>;”
1. The Teradata Database command “drop replication group
<repgroup name>” could be executed instead of the
GGSCI command.
Add a Table to an Existing Extract

1. Edit the Extract parameter file.
a. Add the table parameter specification.
2. Edit the Teradata Create Group Statement file.
a. Add the table to the create replication group statement.
3. Within the Teradata Database
a. Suspend activity for all tables linked to the Oracle GoldenGate Extract
4. Start the Golden Gate Software Command Interpreter (GGSCI).
a. With the Extract group in the “running” state, issue the command “info <capture
group>”.
i. Check that Extract has no delay, or lag, receiving change data from the
database.
b. With the Extract group in the “running” state, issue the command
ii. send extract <capture name>, vammessage “control:terminate”
c. Issue the command “stop extract <capture name>”.
5. Within the Teradata Database, issue the command “alter replication group add
<database>.<table>”.
6. Within GGSCI execute the command “start extract <capture name>”.
7. On the target:
a. Modify the Replicat parameter file to map the new source table to a target table.
b. Stop and restart Replicat.
8. Within the Source Teradata Database, activate activity for the tables.
Move a Table to a New Extract

1. Edit the old Extract parameter file.
a. Remove the table parameter specification.
2. Create the new Extract parameter file.
3. Edit the Teradata Create Group Statement file.
a. Remove the table from the create replication group statement.
4. Create the new tam.ini and Teradata Create Group Statement files.
5. Within the Teradata Database
a. Suspend activity for all tables linked to the existing Oracle GoldenGate Extract
group>”.
database.
b. With the Extract group in the “running” state, issue the command
iii. send extract <capture name>, vammessage “control:terminate”
c. Issue the command “stop extract <capture name>”.
7. Within the Teradata Database, issue the command “alter replication group <repgroup
name> drop <database>.<table>”.
8. Within GGSCI
a. Execute the command “start extract <capture name>”.
b. Add the new Extract
c. Start the new Extract
9. Within the Teradata Database, activate activity for the tables.
Modify Table Columns

group>”.
database.
b. Execute the GGSCI command “send <capture>, vammessage
“control:terminate””.
c. Stop the Extract
d. On the target Oracle GoldenGate server, within GGSCI
i. Check that Replicat has no lag Delivering change data to the target
database.
ii. Stop Replicat
2. Perform the table modifications on the source and target databases.
3. Start the Extract and Replicat processes.
Things to Know
In Doubt Transactions
In Maximum Protetction mode, if Oracle GoldenGate does not reconnect before the time period
expires, the system aborts all transactions not acknowledged by Oracle GoldenGate. This may
include some transactions actually sent to Oracle GoldenGate before the disconnection occurred.
The system records each such transaction as a row in the DBC.InDoubtResLog table. When Oracle
GoldenGate reconnects after the time out period, TAM reads the rows in DBC.InDoubtResLog to
find the
in-doubt transactions that were aborted by the server. TAM notifies Oracle GoldenGate to abort
those transactions.
If the database server resets before Oracle GoldenGate reconnects, any outstanding transactions
remain in the in-doubt state, and the timer is started again (regardless of whether Oracle GoldenGate
was connected at the time of the server reset). If the timer subsequently expires before Oracle
GoldenGate reconnects, the outstanding transactions are aborted. When Oracle GoldenGate
reconnects before the time period expires, then Oracle GoldenGate and Teradata coordinate to
determine which in-doubt transactions were received by Oracle GoldenGate; the received
transactions are then committed, while the remaining in-doubt transactions are rolled back .
Character Sets and Replication

Oracle GoldenGate supports replication of the following character sets between Teradata servers:
• LATIN (single byte character set)

• UNICODE (double-byte character set)
• KANJISJIS (multi-byte character set)
Oracle GoldenGate 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 target 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.
• The supported data types are CHAR, VARCHAR, DATE, and NUMERIC (float, integer,
decimal, real). TIME, TIMESTAMP, and INTERVAL data types are not currently
supported.
Avoiding ODBC Login Timeouts

To perform operations during the capture and Replicat processes, Teradata Access Module must
connect to the ODBC driver for Teradata. If login connection time takes longer than the timeout
interval defined in the ODBC for Teradata configuration, Teradata Access Module may not be able
to connect to ODBC, preventing Oracle GoldenGate for Teradata from performing capture or
Replicat operations.
Make sure that the ODBC timeout parameter is set to a value higher than the default (20 seconds) in
order to avoid timeouts. The suggested setting for LoginTimeout is 3600.
Teradata ODBC Driver Limitations
The Teradata ODBC Driver has a limitation of 15 outstanding SQL statements. This affects Replicat
functionality. To address this limitation Oracle GoldenGate Replicat automatically adjusts the
maximum number of active SQL statements when using BATCHSQL so that the database limit of
15 is not exceeded.
Teradata ODBC can only handle 1 Mb of data per operation; so Replicat must be set to not exceed
the limitations of Teradata ODBC.
By default Oracle GoldenGate Turbo Apply performs 20Mbytes per write operation. This is done by
specifying the maximum number of operations per batch (500) and maximum number of bytes per
batch queue (1 million) when activating BATCHSQL:
BATCHSQL BATCHTRANSOPS 500, BYTESPERQUEUE 1000000
Improving Oracle GoldenGate Throughput with @RANGE

The Oracle GoldenGate function @RANGE may be used to increase the throughput of large or
heavily accessed tables. This function computes a hash value of the table Primary Index, or other
column specified in the @RANGE definition to optimize distribution across the number of Oracle
GoldenGate processes specified.
This function may be used at the Data Pump or Replicat process; however, it is more efficient for
use in the Data Pump because calculating ranges on the target side requires Replicat to read through
its entire Oracle GoldenGate Trail to find the data that meets each range specification.
The proper syntax for specifying @RANGE in Teradata is:
1. For the Data Pump

a. TABLE <database>.<table>, FILTER (@RANGE (<col>, <n>, <l>));
b. <col> is the column for performing the data hash
i. <n> is the number of this range process
ii. <l> is the total number of range processes
2. For the Replicat
a. MAP <database>.<table>, TARGET <database>.<table>, FILTER (@RANGE (<col>,
<n>, <l>));
i. <col> is the column for performing the data hash
ii. <n> is the number of this range process
iii. <l> is the total number of range processes
Things to consider when using @RANGE:
 @RANGE cannot be used for Replicat in environments where primary key updates occur. The
PK Update will cause Replicat failures if the update value is not within the data range of the
Replicat process.
 Rows in tables with relational constraints to one another must be grouped together into the same
process or trail to preserve referential integrity.
 When specifying @RANGE at the Data Pump, the Oracle GoldenGate database userid must
have Select authority on the source database.
 Use the column specification to @RANGE instead of KEYCOLS. This is more efficient as the
program logic flow is (1) @RANGE column specification, (2) KEYCOLS specification, then
(3) table Primary Index specification if neither of the above are declared .
Primary Indexes vs. Primary Keys

What is the difference between a primary key and a (unique) primary index?
Primary Indexes
 The primary index for a table controls the distribution of the data for that
table across the AMPs as well as its retrieval. Both distribution and retrieval of the data is
controlled using the Teradata hashing algorithm.
 If the primary index is defined as a partitioned primary index (PPI), the
data is partitioned, based on some set of columns, on each AMP, and ordered by the hash of
the primary index columns within the partition.
 Data accessed based on a primary index is always a one-AMP operation
because a row and its index are stored on the same AMP. This is true whether the primary
index is unique or non-unique, and whether it is partitioned or non-partitioned.
 All Teradata tables require a primary index because the system partitions
tables on their primary indexes. Primary indexes can be:
• Unique or non-unique
• Partitioned or non-partitioned
Primary key
 A primary key is a field (or combination of fields) in a table that is unique
for each row in that table.
 Teradata does not utilize the concept of a “primary key”.
Primary Key Primary Index

• Important component of logical data mode • Not used in logical data model.
• Used to maintain referential integrity. • Used to distribute and retrieve data.
• Must be unique (uniquely identifies each • Can be unique or non-unique.
row). • Values can be changed.
• Values can never be changed. • Can be null.
• Cannot be null. • Defines the most common access path.
• Does not imply access path. • Mandatory for physical table definition.
• Not required for physical table definition.
Oracle GoldenGate and Teradata Indexes

For update operations, Oracle GoldenGate uses the full table image when delivering data to target
database tables with a non-unique primary index.
For the following discussion, the sample table schema below creates a table with a non-unique
primary index. By default, Teradata will set col1 as the Primary Index for data distribution across all
available AMPs.
create set table lpdb.t_table

, no fallback
, no before journal
, no after journal
(
col1 decimal(18,0) not null,
col2 varchar (30),
col3 varchar (200),
col4 char (50)
)
;
We then execute an update statement on the table:
update lpdb.t_table set col4=’Update operation’ where col1 = 123456789
Tables with Unique Primary Indexes
In our test schema, we designate col1 as a Unique Primary Index (UPI). Oracle GoldenGate Replicat
uses this column as it would a primary key. The DML statement built by Replicat is:
UPDATE "LPDB"."T_PK" SET "col2"='This is a test',"col3"='of Terdadta primary key and
indexes',"col4"='Update operation ' WHERE "col1"=123456789
Tables with Primary Indexes
By designating col1 as a Primary Index (NUPI), we see that Oracle GoldenGate treats all columns as
the table key. The values of col1, col2, col3, and the before image of col4 in the target must match
the captured data for the update to be processed:
UPDATE "LPDB"."T_PI" SET "col4"='Update operation '

WHERE "col1"=123456789 AND "col2"='This is a test' AND "col3"='of Terdadta primary
key and indexes' AND "col4"='Insert Operation'
This results in an all AMP operation because the data row hash contained within the database is
based upon the Primary Index, col1, but the DML requires a check of all columns to locate the row.
To override this functionality, setting KEYCOLS (col1), in the Replicat MAP statement results in
the DML statement:
UPDATE "LPDB"."T_PK" SET "col2"='This is a test',"col3"='of Terdadta primary key and

indexes',"col4"='Update operation ' WHERE "col1"=123456789
Executing Stored Procedures from Oracle GoldenGate

SQLEXEC may be used to execute Teradata Stored Procedures; however, this may result in severe
AMP skew. For every invocation of the Stored Procedure, Teradata executes a “HELP
PROCEDURE <stored procedure>”. This command performs a single AMP retrieve from the
DBC.TVFields table, resulting in the skew.
To avoid this performance hit, use Teradata Macros instead of Stored Procedures as Macros execute
the same as normal DML statements (and are cached). As opposed to Stored Procedures, Macros do
not support the use of conditional statements for data selection prior to executing DML. For the
Teradata Macro to function properly, conditional logic must be performed in the Oracle GoldenGate
process.
For example, a Stored Procedure contains the following conditional logic:
CREATE PROCEDURE LPENTON.PREF_VENDOR_TYPE_SP (

IN PRF_TIMESTAMP TIMESTAMP(0),
IN PRF_ACTION VARCHAR(20),
IN VENDOR_TYPE_CD VARCHAR(2),
IN VENDOR_TYPE_DSCR VARCHAR(50),
IN UPDATE_ID VARCHAR(12)
)
ApplyProfiles:
BEGIN
IF PRF_ACTION ='INSERT' OR PRF_ACTION ='SQL COMPUPDATE' THEN
InsProc: BEGIN
UPDATE LPENTON.VENDOR_TYPE
SET VEND_INACTIVE_DTMZ = :PRF_TIMESTAMP
WHERE VENDOR_TYPE_CD = :VENDOR_TYPE_CD
AND VEND_INACTIVE_DTMZ = TIMESTAMP'3001-01-01
00:00:00' ;
INSERT INTO LPENTON.VENDOR_TYPE

(VENDOR_TYPE_CD, VEND_ACTIVE_DTMZ,
VEND_INACTIVE_DTMZ, VENDOR_TYPE_DSCR, UPDATE_ID)
VALUES (:VENDOR_TYPE_CD, :PRF_TIMESTAMP,
TIMESTAMP'3001-01-01 00:00:00', :VENDOR_TYPE_DSCR,
:UPDATE_ID);
END InsProc;
ELSEIF PRF_ACTION = 'DELETE' THEN
DelProc: BEGIN
UPDATE LPENTON.VENDOR_TYPE
SET VEND_INACTIVE_DTMZ = :PRF_TIMESTAMP
WHERE VENDOR_TYPE_CD = :VENDOR_TYPE_CD
AND VEND_INACTIVE_DTMZ = TIMESTAMP'3001-01-01 00:00:00' ;
END DelProc;
ELSE LEAVE ApplyProfiles;
END IF;
END;
Replicat calls this Stored Procedure via the SQLEXEC:
SQLEXEC (SPNAME LPENTON.Pref_Vendor_Type_SP,

PARAMS (PRF_TIMESTAMP = @DATE("YYYY-MM-DD HH:MI:SS", "JTSLCT",
@DATE ("JTSGMT", "YYYY-MM-DD HH:MI:SS",
@GETENV("GGHEADER", "COMMITTIMESTAMP"))),
PRF_ACTION = @GETENV("GGHEADER","OPTYPE"),
VENDOR_TYPE_CD = VendorType,
VENDOR_TYPE_DSCR = Description,
UPDATE_ID = UpdateID),
ERROR RAISE, TRACE ERROR, BEFOREFILTER),
To eliminate the database server performance degradation caused by calling the Stored Procedure,
we convert it to two Teradata Macro that only contains the DML statements; one for the upsert and
one for the delete, and modify the Replicat Group to perform the conditional logic for selecting
records based upon operation type. We’d then call the Macro via a SQLEXEC statement similar to
the following:
SQLEXEC (ID VENDORTYPE, QUERY "EXEC PREF_VENDOR_TYPE(?,?,?,?,?);",

PARAMS ( P1 = @DATE("YYYY-MM-DD HH:MI:SS", "JTSLCT",
@DATE ("JTSGMT", "YYYY-MM-DD HH:MI:SS",
@GETENV("GGHEADER", "COMMITTIMESTAMP"))),
P2 = @GETENV("GGHEADER","OPTYPE"),
P3 = VendorType,
P4 = Description,
P5 = UPDATE_ID),
ERROR RAISE, TRACE ERROR, AFTERFILTER)),
Teradata Queries You Need To Know

1. What Replication Groups exist and which tables are associated with each?
a. SELECT * from DBC.RepTables;
2. What Replication Groups do I own?

a. SELECT * from DBC.RepTablesVX;
3. How do I reset the Replication Group security token?

a. ALTER REPLICATION GROUP <group name>;
4. How do I get the GroupID of a Replication Group?

a. HELP REPLICATION GROUP <group name>;
b. The GroupID is on page 1 of the data returned.
5. What Replication RuleSets exist and what Replication Group and tables are associated with
each?
a. SELECT * from DBC.RepCaptureRulesV;
6. How do I decode a Teradata error message?
a. SELECT ERRORTEXT FROM dbc.errormsgs WHERE errorcode = <error_number>;
References
The following publications were utilized as reference materials for information presented in this
document:
Oracle GoldenGate for Windows and Unix Reference Guide

Oracle GoldenGate for Windows and Unix Administrator Guide
Teradata Replication Solutions Manual
Teradata Warehouse Documentation

Copyright © 2010 Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and
Updated March 2013
the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any
other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of
merchantability or
Oracle Corporation
fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations
World Headquarters
are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by
500 Oracle Parkway
any
Redwood Shores, CA 94065
means, electronic or mechanical, for any purpose, without our prior written permission.
U.S.A.
Worldwide Inquiries: Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective
Phone: +1.650.506.7000 owners.
Fax: +1.650.506.7200
oracle.com 0109

Oracle GoldenGate Best Practices - Configuring Oracle GoldenGate For Teradata Databases V5a ID1323119.1-1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oracle GoldenGate Best Practices - Configuring Oracle GoldenGate For Teradata Databases V5a ID1323119.1-1

Uploaded by

Copyright:

Available Formats

An Oracle White Paper

Updated March 2014

Oracle GoldenGate Best Practices: Configuring

The typical configuration includes:

Figure 1 illustrates the major components for replicating Teradata databases.

Figure 1. Major Components Required For Teradata Data Replication

1. Teradata Database Server

2. Source Oracle GoldenGate Server

1) The Control Thread establishes the connection to the RSG

3. Target Oracle GoldenGate Server

1. Two dual core processors

Windows Option Set To Value

Install and Configure Oracle GoldenGate Software

Setup the Database User

1. Grant select on dbc.repgroup to <userid>;

1. Grant select on dbc.tvm to <userid>;

1. Memory limit per transaction

2. Client reset timeout

3. Temp Storage Page Size

4. Spill File Path

1. The username and password assigned for Oracle GoldenGate Extract.

2. The ODBC connection must be set for

3. By default ODBC is configured with LoginTimeout of 20 seconds.

setenv ODBCINI /<folder>/.odbc.ini

Multiple Teradata Replication Groups

Guidelines to consider when setting up Replication Groups

2. If a replicated table is maintained exclusively by bulk-loading methods, it is best to dedicate

3. Tables that may be loaded concurrently should be in separate replication groups to

4. TPump generates many concurrent transactions, so the replication workload is distributed

A sample Manager parameter file is provided in Table 1.

Table 1. Sample Manager Parameter File

DYNAMICPORTLIST may be configured as:

A maximum of 256 ports may be specified.

To control the purging, follow these rules:

Windows Cluster Considerations

1. Create a new, temporary cluster group.

Max Protection Capture

TAM Initialization File

1. The mode of operation, Replication or TableCopy

An example tam.ini file is provided in Table 2.

Table 2. Sample tam.ini file

1. The Teradata command “create replication group”

Table 3. Sample Create Group Statement File

Change Data Capture

1. DSOPTIONS CREATETRANLOG, RESTARTAPPEND, VAMCOMPATIBILITY 1

A sample Extract parameter file is provided in Table 4.

Table 4. Sample Extract Parameter File

1. REPORTCOUNT EVERY 60 MINUTES, RATE

Create the Extract Checkpoint

Bi-Directional Extract Considerations

1. SQLEXEC "SET SESSION OVERRIDE REPLICATION ON;"

This sorting is performed by a VAM Sort Extract process.

Table 5. Sample VAM Sort Extract Parameter File

Create the VAM Sort Checkpoint

Configure Extract Data Pump

Table 6. Sample Extract Data Pump Parameter File

To compute the proper TCPBUFSIZE setting:

eth0 Link encap:Ethernet HWaddr 00:0C:29:89:3A:0A

The waittime can be determined by the ggsci command:

send <extract pump>, gettcpstats

Sending GETTCPSTATS request to EXTRACT PHREMP ...

RMTTRAIL .\dirdat\pe000000, RBA 717

Set TCPFLUSHBYTES to the same value as TCPBUFSIZE.