oracle golden gate 11g_new features (1)

Oracle GoldenGate 11gR1 New Features Overview

Oracle GoldenGate 11gR1 New Features Overview 1 - 2


Oracle GoldenGate 11gR1

Oracle GoldenGate 11gR1 enables the exchange and manipulation of data at the transaction

level among multiple, heterogeneous platforms across the enterprise. Its modular

architecture gives you the flexibility to extract and replicate selected data records,

transactional changes, and changes to DDL (data definition language) across a variety of

topologies.


Key Capabilities and Technology Differentiators

Oracle GoldenGate works in heterogeneous environments, across different databases and

hardware types. Its modular architecture gives the user the flexibility to extract and replicate

selected data records, transactional changes, and changes to DDL (data definition language)

across a variety of topologies. Oracle GoldenGate further differentiates itself from other

technologies with:

• Performance – moving large volumes of data very efficiently while maintaining very low

lag times/latency.

• Extensibility and Flexibility – meeting a wide range of customer solutions and integration

needs with an open, modular architecture.

• Reliability – overall architecture is extremely resilient against potential interruptions and

easy to recover.

Oracle GoldenGate 11gR1 New Features

The new features introduced in Oracle GoldenGate 11gR1 are broken-up into four separate

categories: platforms and infrastructure, performance, manageability, and flexibility. The

subsequent lessons cover these features in further detail.

Oracle GoldenGate11gR1 New Features Overview 1 - 5


Oracle Database 11.2.0.2

Oracle GoldenGate 11gR1 provides support for the latest version of the Oracle database

providing the same heterogeneous capabilities as with previous versions of the Oracle

database.

Oracle Exadata Storage Server

Oracle Exadata Storage Servers combine Oracle's smart storage software and Oracle's

industry-standard Sun hardware to deliver the highest industry's highest database storage

performance. To overcome the limitations of conventional storage, Oracle Exadata Storage

Servers use a massively parallel architecture to dramatically increase data bandwidth

between the database server and storage.


MySQL

Oracle GoldenGate 11gR1 now offers extended support for MySQL. In this version, log-

based Capture from MySQL 5.1.15 or later is supported (Delivery does not have this

restriction) and is achieved by natively reading and parsing the MySQL transaction logs.


SQL Server 2008

Oracle GoldenGate 11gR1 now offers extended support for Microsoft database versions by

adding log-based Capture to the current Delivery support of SQL Server 2008. This is

achieved by scraping the logs to capture the changed data, similar to the functionality for SQL

Server 2000 and 2005. However, there is one new requirement for the installation for 2008 -when the user that issues the INSTALL ADDSERVICE ADDEVENTS command from the dos

prompt, they must be logged in as the Admin user.

Finally, there is no need to setup Microsoft SQL Server replication components such as distributer database and publisher. The standard TRANDATA is sufficient.



Bounded Recovery

A new Bounded Recovery feature has been added that guarantees an efficient recovery after

the Extract stops for any reason, planned or unplanned, no matter how many open

(uncommitted) transactions there were at the time that Extract stopped, nor how old they

were. Bounded Recovery sets an upper boundary for the maximum amount of time that it

would take for Extract to recover to the point where it stopped and then resume normal

processing.

NOTE: Before modifying this parameter from its default settings, it is highly recommended to

contact Oracle support for guidance.

Reduce LOB Fetching

LOB capture differs between earlier and later versions of the Oracle database. In Oracle Database

versions earlier than 10g, all in-row LOBs are captured from the redo log but out-of-row LOBs are

fetched from the database. For Oracle Databases 10g and later, all LOBs are captured from the redo

log, whether they are stored in-row or out-of-row (some exceptions may apply).


Microsoft OLE DB

OLE DB is an API designed by Microsoft for accessing different types of data stored in a

uniform manner. New in Oracle GoldenGate 11g, the default connection from Replicat uses

OLE DB to connect to the target database (instead of ODBC).


Emulating a Replication User

OLE DB can be configured to use the replication user by using the DBOPTIONS parameter

with the USEREPLICATIONUSER option. When the replication user is used, the following

concerns must be addressed for their effect on data integrity:

• IDENTITY seeds on the target are not updated. A partitioning scheme is needed to

avoid primary key violations unless the target is read-only.

• Foreign key constraints are not enforced.

• ON UPDATE CASCADE, ON DELETE CASCADE and triggers are disabled. This is

beneficial to Replicat, since it prevents duplicate operations, but may not be appropriate

for the target applications and might require modification to the code of the constraint or

trigger to ensure data integrity.

• CHECK constraints are not enforced, so data integrity cannot be certain on the target.


Dynamic SQL

Dynamic SQL is a programming technique that enables a user to build SQL statements dynamically at runtime. In Oracle GoldenGate, the DYNSQL and NODYNSQL parameters are

used to control the way that SQL statements are formed. With NODYNSQL, Replicat uses

literal SQL statements with the bind variables resolved. With DYNSQL (default value), Replicat

uses dynamic SQL to compile a statement once and then execute it many times with different

bind variables.

In most environments, using DYNSQL offers the best efficiency and most throughput.

However, there may be some circumstances where NODYNSQL proves to be faster and more

efficient.



Long-Running Transactions

The TRANSACTIONTIMEOUT parameter prevents an uncommitted Replicat target transaction

from holding locks on the target database and consuming its resources unnecessarily. The

value of this parameter can be changed so that Replicat can work within existing application

timeouts and other database requirements on the target database.

To verify if Replicat is currently backing out a timed-out transaction, you can use the following

command:

GGSCI> SEND REPLICAT group, STATUS

Performing transaction timeout recovery

Waiting for data at logical EOF after transaction timeout

recovery


TRANSACTIONTIMEOUT Parameter

During normal operations, Replicat remembers the position in the trail of the beginning of the

first sources transaction in the current transaction, in case the transaction must be abended or retried. When TRANSACTIONTIMEOUT is enabled, Replicat also saves the position of the first

record of the current source transaction and will use that position as the logical end-of-file

(EOF) if it is triggered.


Activity Logging

The Activity Logging subsystem is a set of software components that record application

activity in a variety of formats, in a flexible, lightweight and robust manner. Information

captured by the Activity Logging API is used to diagnose normal application processing and

new program logic under development. It can also provide additional details when application

operation fails unexpectedly.

Schema Modifications

If the DDL has changed in a heterogenous replication environment, then the target side

sourcedefs files must be modified to continue .


DDL Enhancements: Mapping Schemas

The MAPSESSIONSCHEMA parameter enables a source session schema to be mapped to a

different session schema on the target. The example above shows how MAPSESSIONSCHEMA works to allow the mapping of a source session schema to another

schema on the target. The following DDL capture and mapping configurations are for Extract

and Replicat.


DDL Enhancements: Active-active Bi-Directional Configuration

Oracle GoldenGate 11gR1 offers support for DDL in an active-active bi-directional configuration. A new UPDATEMETADATA option of the DDLOPTIONS parameter notifies

Replicat on the system where DDL originated that this DDL was propagated to the other

system, and that Replicat should now update its object metadata cache to match the new

metadata. This keeps Replicat's metadata cache synchronized with the current metadata of

the local database. This is for the Oracle platform only.


Suppressing Triggers and Cascading Deletes

The SUPPRESSTRIGGERS parameter prevents triggers from firing on target objects that are

configured for replication with Oracle GoldenGate. This alleviates the need to manually

disable triggers and constraints. To use this option, the Replicat user must be an Oracle

Streams administrator which can be granted by invoking dbms_goldengate_auth.grant_admin_privilege.


New Oracle GoldenGate 11gR1 GGSCI: Trandata Commands

For Sybase, the LOBs argument controls how the database propagates LOB data for the specified table. LOBSALWAYSNOINDEX sets LOB replication to ALWAYS_REPLICATE (which

always replicates the LOB data whether or not it has changed in a transaction). LOBSALWAYSNOINDEX does not mark the table to use an index on replication which provides

the following benefit of no lock being held while ADD TRANDATA is being executed. Note that

all of the correct options are set by default.


New Oracle GoldenGate 11gR1 GGSCI: Miscellaneous Commands

A new ALLOWNESTED command enables the use of nested OBEY files. A nested OBEY file is

one that contains another OBEY file. An attempt to run a nested OBEY file in the default mode

of NOALLOWNESTED will cause an error.


New Oracle GoldenGate 11gR1 GLOBALS Parameters

SYSLOG filters the types of Oracle GoldenGate messages that are written to the system logs.

This parameter is available to both the GLOBALS parameter file and/or Manager parameter file.

With SYSLOG, you can:

• include all Oracle GoldenGate messages

• suppress all Oracle GoldenGate messages

• filter to include information, warning, or error messages, or any combination of those

types

When you use SYSLOG in the GLOBALS parameter file, it controls message filtering for all of the

Oracle GoldenGate processes on the system. When it appears in a Manager parameter file, it controls messages filtering only for the Manager process. If used in both the GLOBALS and

Manager parameter files, the Manager setting overrides the GLOBALS setting for the Manager

process. This enables you to use separate settings for Manager and all of the other Oracle

GoldenGate processes.


New Oracle GoldenGate 11gR1 Extract: Tuning Parameters

Bounded Recovery is a component of the general Extract checkpointing facility. It guarantees

an efficient recovery after Extract stops for any reason, planned or unplanned, no matter how

many open (uncommitted) transactions there were at the time that Extract stopped, nor how

old they were.

NOTE: Before modifying this parameter from its default settings, it is highly recommended to

contact Oracle support for guidance.

See Lesson 3: Performance Enhancements for additional information.


New Oracle GoldenGate 11gR1 General Parameter Syntax Updates

Use the COMPRESSUPDATES and NOCOMPRESSUPDATES parameters for Extract to control the

way columns are written to the trail record fro update operations. COMPRESSUPDATES, the

default, causes Extract to write only the primary key and the changes columns of a row to the

trail for update operations. This provides enough information to update the correct target record, while restricting the amount of data that must be processed. NOCOMPRESSUPDATES

sends all of the columns to the trail. This becomes the default when a table definition does not include a primary key or unique index. COMPRESSUPDATES and NOCOMPRESSUPDATES

apply globally for all TABLE statements in a parameter field.

DBOPTIONS

• CONNECTIONPORT <port>: Valid for Replicat for multi-daemon MySQL. Specifies the

TCP/IP port.


New Oracle GoldenGate 11gR1 General Parameter Syntax Updates (cont).

• DEFERREFCONST: Valid for Replicat for Oracle. Delays referential integrity constraint

checking and enforcement by the database until the Replicat transaction is committed.

You can use this parameter instead of disabling the constraints on the target tables if the

database is Oracle version 9.2.0.7 and later. If used with an Oracle version that does not support this functionality, DEFERREFCONST will be ignored without returning a

notification to the GoldenGate log.

• LOBBUFSIZE <bytes>: Valid for Extract for Oracle. This argument determines the

memory buffer size to allocate for each embedded LOB attribute that is in an Oracle

object type.

• CONNECTIONPORT <port>: Valid for Replicat for multi-daemon MySQL. Specifies the

TCP/IP port.

• LOBWRITESIZE <bytes>: Valid for Replicat for Oracle. Specifies a fragment size for

each LOB that Replicat writes to the target database. The LOB data is stored in a buffer

until this size is reached. Because LOBs must be written to the database in fragments,

writing in larger blocks prevents excessive I/O. The higher the value, the fewer I/O calls

that are made by Replicat to the database server to write the whole LOB to the

database. This argument determines the memory buffer size to allocate for each

embedded LOB attribute that is in an Oracle object type.

• SUPPRESSTRIGGERS | NOSUPPRESSTRIGGERS: Valid for Replicat for Oracle. Prevents

triggers from firing on target objects that are configured for replication with Oracle

GoldenGate. You can use this parameter for Oracle 10.2.0.5 and later patches, and for

Oracle 11.2.0.2 and later, instead of manually disabling the triggers. To use this option,

the Replicat user must be an Oracle Streams administrator, which can be granted by

invoking dbms_goldengate_auth.grant_admin_privilege. The default is NOSUPPRESSTRIGGERS.

• USEODBC: (Valid for Replicat for SQL Server) Configures Replicat to use ODBC to

perform DML operations. The default is to use OLE DB. Not valid if USEREPLICATIONUSER is enabled; will cause Replicat to abend. Note: Replicat always

uses ODBC to connect to the database catalog to obtain metadata.

• USEREPLICATIONUSER: (Valid for Replicat for SQL Server) Configures Replicat to

perform target DML operations as the SQL Server replication user. The replication user

is not a SQL Server user or account, but is a property of the database connection. USEREPLICATIONUSER enables the SQL Server NOT FOR REPLICATION flag. See

Lesson 3: Performance Enhancements for additional details.



DDLOPTIONS

• ADDTRANDATA [ABEND | RETRYOP <RETRYDELAY <seconds> MAXRETRIES

<retries>]: Valid for Extract (Oracle and Teradata). Use ADDTRANDATA to:

- enable Oracle’s supplemental logging automatically for new tables created with a CREATE TABLE.

- to update supplemental logging for tables affected by an ALTER TABLE to add or

drop columns.

- update supplemental logging for tables that are renamed.

- update supplemental logging for tables where unique or primary keys are added or

dropped.

For a more detailed look into the other arguments, consult the Oracle GoldenGate

Windows and UNIX Reference Guide version 11gR1 (11.1.1).



• MAPSESSIONSCHEMA <source_schema> TARGET <target_schema>: Valid for

Replicat (Oracle only). Enables a source session schema to be mapped to (transformed

to) a different session schema on the target.

- <source_schema> is the session schema that is set with ALTER SESSION set

CURRENT_SCHEMA on the source.

- <target_schema> is the session schema that is set with ALTER SESSION set

CURRENT_SCHEMA on the target.

Wildcards are not supported. You can use multiple MAPSESSIONSCHEMA parameters to

map different schemas.

MAPSESSIONSCHEMA overrides any mapping of schema names that is based on master

or derived object names.

• PASSWORD ENCRYPTKEY [ DEFAULT | ENCRYPTKEY <keyname>]: Valid for Extract for

Oracle. Directs Extract to encrypt all passwords in source DDL before writing the DDL to

the trail.

- DEFAULT specifies that the passwords were encrypted by using a random key

generated by Oracle GoldenGate. On the target, the password is decrypted automatically without requiring an ENCKEYS file.

- ENCRYPTKEY <keyname> specifies that passwords were encrypted with a user-

defined method and specifies a lookup key in an ENCKEYS file on the target system.

To use the encryption options, you must first generate the encrypted password with the ENCRYPT PASSWORD command in GGSCI. For more information about Oracle

GoldenGate encryption options, see the Oracle GoldenGate Windows and UNIX

Administrator’s Guide.

• PASSWORD ENCRYPTKEY [ DEFAULT | ENCRYPTKEY <keyname>]: Valid for Replicat

(Oracle only). Use in an active-active bidirectional configuration. This parameter notifies

Replicat on the system where DDL originated that this DDL was propagated to the other

system, and that Replicat should now update its object metadata cache to match the

new metadata. This keeps Replicat’s metadata cache synchronized with the current

metadata of the local database.

• USEOWNERFORSESSION: Valid for Replicat (Oracle only). Forces the schema of an

unqualified object in the Replicat DDL statement to be that of the Replicat session schema, instead of the schema in an ALTER SESSION SET CURRENT_SCHEMA

statement, which is the default behavior.



TRANLOGOPTIONS

• COMPLETEARCHIVEDLOGONLY: (Oracle) Overrides the default Extract processing of

archived logs.

- Default in regular mode: Extract starts processing an archived log immediately

when it becomes available, without waiting for it to be written to disk.

- Override in regular mode: Use COMPLETEARCHIVEDLOGONLY to force Extract to wait

until an archived log is completely written to disk before beginning to read it.

- Default in archived log only (ALO) mode: Forces Extract to wait for the complete

archived log to be written to disk.

- Override in ALO mode: Use NOCOMMPLETEARCHIVEDLOGONLY to force Extract to

start processing an archived log immediately when it becomes available.



• This parameter applies when copying production (source) archive logs to a secondary

database where they will serve as the data source. Some Oracle programs do not build

the archive log from the first byte to the last byte in sequential order, but instead may

copy the first 500MB, then the last 500MB, and finally the middle 1000MB, for example.

If Extract begins reading at the first byte, it will abend when it reaches the break in the

byte sequencing. Waiting for the whole file to be written prevents this problem.

• DBLOGREADER: (Oracle) Causes Extract to use a newer API that is available as of

Oracle 10.2.0.5. This API uses the database server to access the redo and archive logs,

so that they do not have to reside in ASM. The database must contain the libraries that contain the API modules and must be running. When used, DBLOGREADER enables

Extract to use a read buffer size of up to 4 MB in size. The maximum buffer size when

using the default OCI buffer is 1024000 bytes. A larger buffer may improve the performance of Extract when redo rate is high. You can use the DBLOGREADERBUFSIZE

option to specify a buffer size.

• DBLOGREADERBUFSIZE <buffer size>: (Oracle) Specifies the size of the read buffer

that Extract uses when capturing from an Oracle ASM instance when DBLOGREADER is

being used. Specify a buffer of up to 4MB. The default is 1024000 bytes. When using a buffer size that is larger than 1024000, you must change the BUFSIZE parameter to a

value that is equal to, or larger, than what you specify for DBLOGREADERBUFSIZE.

• NODDLCHANGEWARNING: (SQL Server) Forces Extract not to log a warning when a DDL

operation is made to a source object for which Extract is capturing data. The default is to

report a warning, so that the problem can be corrected. Oracle GoldenGate does not

support DDL capture and replication for SQL Server, so it expects source and target

metadata to remain constant. Some DDL changes do not cause Extract to abend, but the warning still will be logged whenever such changes occur. NODDLCHANGEWARNING

will prevent those messages from accumulating in the Oracle GoldenGate log.

• SKIPDIRLOADINSERT: (Oracle) Causes Extract to skip all Oracle direct-load INSERTs.

The default behavior (without this parameter) is to capture Oracle direct-load INSERTs.

This option applies to Oracle logs with log compatibility of Oracle 10g or later.


Upgrading to Oracle GoldenGate 11gR1 from Oracle GoldenGate 10.4

Perform the following steps to upgrade an Oracle GoldenGate 10.4 instance to Oracle

GoldenGate 11gR11.1.1:

1. Install v11.1.1 of Oracle GoldenGate into a new directory by following the directions for a

new installation for your database and platform. You do not need to create the sub-

directories. You only need to complete the steps to the point where the programs have

been expanded. See the installation instructions for your supported database.

2. (Oracle source database if using DDL replication) There are numerous changes to the

DDL triggers and objects that need to be rebuilt. This procedure creates a new DDL

environment, but removes DDL history. To preserve the continuity of source and target

structures, stop DDL activity on the source database and allow Replicat to apply the

changes that are in the trail to the target. To determine when Replicat is finished, issue the

following command until you see a message that there is no more data to process:

INFO REPLICAT <group>


Upgrading to Oracle GoldenGate 11gR1 from Oracle GoldenGate 10.4 (cont).

3. Stop all of the Oracle GoldenGate processes, starting with Extract and

Replicat processes, and then the Manager process.

GGSCI> STOP EXTRACT <group>

GGSCI> STOP REPLICAT <GROUP>

GGSCI> STOP MANAGER

4. Move the files and programs that you expanded from your new directory into

your existing Oracle GoldenGate directory.

5. (Oracle source database if using DDL replication) Follow the instructions in

“Rebuilding the DDL environment” on slide 10 and then return to the follow

steps.

6. Start all of the Oracle GoldenGate processes, starting with Manager, and then

Extract and Replicat.

GGSCI> START MANAGER

GGSCI> START EXTRACT <group>

GGSCI> START REPLICAT <GROUP>


Upgrading to Oracle GoldenGate 11gR1 from Version(s) Prior to Oracle

GoldenGate 10.4

Perform the following steps to upgrade the target database only from an Oracle GoldenGate

v10.x prior to 10.4 and to Oracle GoldenGate v9.5 and earlier (for upgrading specifically on

z/OS, there are some additional steps that may be required. Reference Upgrading to Oracle

GoldenGate v11g Release 1 (11.1.1)):





2. Stop Replicat and then Manager:


GGSCI> STOP MANAGER

3. Remove the CACHESTATEMENTS option of BATCHSQL if being used in the Replicat

parameter file.


Upgrading to Oracle GoldenGate 11gR1 from Version(s) Prior to Oracle

GoldenGate 10.4 (cont).

4. Move the files and programs that you expanded from your new directory

into your existing Oracle GoldenGate directory.

5. Start Manager and then Replicat:


GGSCI> START REPLICAT <GROUP>


Upgrading to Oracle GoldenGate 11gR1 from Oracle GoldenGate 10.4

Perform the following steps to upgrade an Oracle GoldenGate 10.4 instance to Oracle

GoldenGate 11gR11.1.1:





2. (Oracle source database if using DDL replication) There are numerous changes to the

DDL triggers and objects that need to be rebuilt. This procedure creates a new DDL

environment, but removes DDL history. To preserve the continuity of source and target

structures, stop DDL activity on the source database and allow Replicat to apply the

changes that are in the trail to the target. To determine when Replicat is finished, issue the

following command until you see a message that there is no more data to process:

INFO REPLICAT <group>


Upgrading to Oracle GoldenGate 11gR1 from Oracle GoldenGate 10.4 (cont).

3. Stop all of the Oracle GoldenGate processes, starting with Extract and

Replicat processes, and then the Manager process.

GGSCI> STOP EXTRACT <group>


GGSCI> STOP MANAGER

4. Move the files and programs that you expanded from your new directory into

your existing Oracle GoldenGate directory.

5. (Oracle source database if using DDL replication) Follow the instructions in

“Rebuilding the DDL environment” on slide 10 and then return to the follow

steps.

6. Remove the TRANSMEMORY parameter from any Extract parameter file.

This applies to all platforms except NonStop, OSS, and z/OS.

7. Remove the CACHESTATEMENTS option of BATCHSQL if being used in the

Replicat parameter file.

8. Start only the Manager process.


9. If not upgrading the target to v11.1.1, modify the Extract that is sending data

to the target (usually a data pump but could be the primary Extract) to include the FORMAT RELEASE option in the RMTTRAIL parameter. This includes the

online Extracts and initial-load Extracts. This ensures that the trails that

the new version of Oracle GoldenGate writes are backwards compatible with

the downstream Oracle GoldenGate environments and that the downstream

Replicats can process the data.

RMTTRAIL <trail> FORMAT RELEASE {9.0 | 9.5 | 10.4}

10. A new Oracle GoldenGate trail header was added in v10. In order to switch

to this new format successfully, you must roll over each trail with the

following command to all of the appropriate Extract and data-pump groups:

ALTER EXTRACT <group>, ETROLLOVER

11. Start all of the Extract and data-pump groups:

GGSCI> START EXTRACT <group>


Rebuilding the DDL Environment to a Clean State

For Oracle databases, to completely remove, and then reinstall, the Oracle

GoldenGate DDL object in preparation for an upgrade to Oracle GoldenGate v11.1.1,

perform the following steps:

1. After stopping the source Oracle GoldenGate processes, change directories to the

Oracle GoldenGate installation directory.

2. Run SQL*Plus and log in as a user that has SYSDBA privileges.

3. Disable all sessions that ever issued DDL. Otherwise the database might

generate an ORA-04021 error.

4. Run the ddl_disable script to disable the DDL trigger.

5. Run the ddl_remove script to remove the Oracle GoldenGate DDL trigger, the

DDL history and marker tables, and other associated objects. This script produces a ddl_remove_spool.txt file that logs the script output and a

ddl_remove_set.txt file that logs current user environment settings in case they

are needed for debugging.


Rebuilding the DDL Environment to a Clean State (cont).

6. Run the marker_remove script to remove the Oracle GoldenGate marker

support system. This script produces a marker_remove_spool.txt file that

logs the script output and a marker_remove_set.txt file in case they are

needed for debugging.

7. Run the marker_setup script to reinstall the Oracle GoldenGate marker

support system. You will be prompted for the name of the Oracle

GoldenGate schema.

8. Run the ddl_setup script. You will be prompted for:

- The name of the Oracle GoldenGate DDL schema.

- The installation mode. Use the INITIALSETUP mode. This mode drops

and recreates existing DDL objects before creating new objects.

9. Run the role_setup script to recreate the Oracle GoldenGate DDL role.

10. Grant the role you just created to all Oracle GoldenGate users under which

the following Oracle GoldenGate processes run: Extract, Replicat, GGSCI,

and Manager. You might need to make multiple grants if the processes have

different user names.

11. Run the ddl_enable.sql script to enable the DDL trigger.

12. Return to the upgrade procedure that you were following.


Property Templates to Use with Flat File

A new flat file writer property, {writer}.template, has been added for the implementation

of property templates. This property specifies the name of the template of typical properties

that is to be used for that flat file writer.


Property Templates

The property templates presets certain properties based on common usage. The template

settings can be overridden by setting the property in the properties file. For each property in

the template, the system first checks to see if that property is set in the properties file itself. If

the user hasn't specified it, the template setting is used.


Siebel Remote Support

When Oracle GoldenGate is used with Siebel applications, remote users do not see changes

made to Siebel by Oracle GoldenGate. Only changes made through the Siebel application

server are written to the remote log. Oracle GoldenGate writes directly to the underlying

database tables without creating the log entries. Oracle GoldenGate for Flat File 11gR1 writes

transactions to a set of rolling files in a specific format understood by the Siebel DMUTL tool.


Siebel Remote Support

• goldengate.userexit.datetime.removecolon - A general property added for

Siebel remote integration that controls whether or not a colon is written between the date

and time. When set to false, the date and time column values are written to the output

files in the default format of the Oracle GoldenGate trail, YYYY-

MMDD:HH:MI:SS.FFFF.

• files.data.bom.code - A flat file writer output format added for Siebel remote

integration that specifies a hexadecimal value as the byte order marker (BOM) to be

written to the beginning of the file.

• groupcols - A flat file writer output format property added for Siebel remote

integration that controls whether or not the column names, before values and after values

are grouped together.

• afterfirst - A flat file writer data content property added for Siebel remote

integration that controls whether or not the after image is written before the before image

when includebefores is set to true.


Siebel Remote Support (cont).

• begintx.metacols, endtx.metacols - Two flat file writer metadata column

properties added for Siebel remote integration that specify the metadata columns to use

to mark the beginning and end of a transaction. These marker records are written (with

end of line delimiters) to the output files before and after the operation records that make

up the transaction.

• goldengate.userexit.buffertxs=true - A general property added for Siebel

remote integration that specifies that the transactions are to be buffered in memory. This

is required when accumulating the number of operations in a transaction.

The following metadata columns have also been added:

• %COLNAME – The value in the named column.

• “<value>” –Any literal. The quote policy will be applied.

• numops – The number of operations in the current transaction.

• numcols – The number of columns to be output.


Flexible File Rollover

There are three different rollover settings that can be used:

• Rollover based on commit timestamp - Files may be rolled over based on the Julian

commit timestamp. This is enabled using the new files.data.rollover.timetype

parameter.

• Synchronized rollover of multiple files - All currently open files may be rolled over at

the same time. This is enabled using the new files.data.rollover.multiple

parameter.

• Rollover at a specified time - The rollover may be based on a specific time. This is

enabled using the new files.data.rollover.attime parameter.


Quote Policy Enhancements

Two new properties allow the user to specify certain criteria on data types that are placed in

quotes:

• dsv.quotes.policy – Controls the policy for applying quotes by allowing the user to

select from the options:

- default – Only dates and chars are quoted

- never – No metadata column or column values are quoted

- always –All metadata columns and column values are quoted

- datatypes – Only specific data types are quoted

• dsv.quotes.policy.datatypes – Controls whether integer, character, float, or

datetime data types are to be quoted when dsv.quotes.policy is set to datatypes.


Source and Target Definitions

Oracle GoldenGate for Java includes a Gendef utility that generates an Oracle GoldenGate

source definitions file from the properties defined in a properties file. It creates a normalized

definition of tables based on the property settings and other parser-specific data definition

values.


oracle golden gate 11g_new features (1)

Documents