Oracle Golden Gate Introduction

Oracle Golden Gate is a log based database synchronize software.

Oracle Golden Gate 简述

Oracle 在2009年收购了Golden Gate,之后Oracle 把Stream 的一些优点引入到了Golden Gate。 所以以后在数据复制这块,Oracle 肯定也是大力发展Golden Gate。


Golden Gate复制原理是通过挖掘Oracle的日志(redo和归档),然后生成自己的队列文件,通过队列文件传输到目标端,目标端通过读取相应的队列文件在目标数据库中重演事务。

Golden Gate 可以跨不同的数据库进行复制,如Oracle、IBM DB2、MS SQL Server等。Quest 公司也有一个复制软件:SharePlex,不过它只支持Oracle到Oracle的复制。用过Toad 的人应该都知道Quest 公司。

在联机文档上找了点这块的资料,粘贴如下,有空在研究下Golden Gate.

Oracle Database High Availability Solutions for Unplanned Downtime

3.7 Oracle GoldenGate and Oracle Streams
Oracle GoldenGate is Oracle's strategic product for data distribution and data integration. It is a high-performance software application that uses log-based bidirectional data replication for real-time capture, transformation, routing, and delivery of database transactions across heterogeneous systems.(GG 说明)Oracle GoldenGate helps you achieve continuous availability and real-time integration for your mission-critical data. It is described in more detail in Section 3.7.1.
Oracle Streams is also a very flexible and powerful database replication feature that Oracle will continue to support but will not make major enhancements in future releases.(Oracle 在Stream 上不会在投入太多了) You can continue to use an existing Oracle Streams deployment to maximize your return on investment. However, you should consider Oracle GoldenGate as the long-term replication strategy for your organization. See the Oracle Database 2 Day + Data Replication and Integration Guide, Oracle Streams Concepts and Administration, and the Oracle Streams Replication Administrator's Guide for more information about Oracle Streams data replication and integration.
Oracle GoldenGate will be enhanced with many of the best capabilities of Oracle Streams to create a best-of-both worlds information distribution solution.

3.7.1 About Oracle GoldenGate
Oracle GoldenGate is an asynchronous, log-based, real-time data replication product that moves high volumes of transactional data in real-time across heterogeneous database, hardware, and operating system environments with minimal impact.
A typical environment includes a capture, pump and delivery process. Each of these processes can run on most of the popular operating systems and databases, including Oracle Database and non-Oracle databases. All or a portion of the data may be replicated, and the data within any of these processes may be manipulated for not only heterogeneous environments but also different database schemas. Oracle GoldenGate supports multimaster replication, hub-and-spoke deployment, and data transformation. Thus, Oracle GoldenGate enables you to ensure that your critical systems are operational 24/7, and the associated data is distributed across the enterprise to optimize decision making.
Oracle GoldenGate is also an excellent method to minimize downtime during planned maintenance, including application and database upgrades, in addition to platform migrations.

Benefits of Oracle GoldenGate
Oracle GoldenGate optimizes real-time information access and availability because it:
(1)Supports replication involving a heterogeneous mix of Oracle Database and non-Oracle databases
(2)Maintains continuous availability to mission-critical systems:
1)Disaster recovery and data protection
Creates and maintains an immediate failover site with up-to-the-minute data to minimize recovery time for mission-critical systems.
2)Zero downtime operations
Enables uninterrupted business operations during system upgrades, migration, and maintenance activities.
3)Data distribution
Synchronizes data for distributed applications in real time for improved availability and scalability.
4)Query offloading
Ensures high performance for production systems while still supporting necessary read-only activities by replicating data between heterogeneous sources and targets.
(3)Enables real-time data integration across the enterprise:
1)Real-time data warehousing
Provides continuous, real-time capture and delivery of the most recent change data between OLTP systems and the data warehouse.
2)Operational reporting
Off loads reporting activity from the production database to lower-cost secondary systems that have current data for real-time reporting.
3)Operational data integration
Integrates operational data between OLTP systems in real time.

3.7.2 Using Oracle GoldenGate with Oracle Active Data Guard
Oracle Golden Gate and Oracle Active Data GuardFoot 2 are strategic capabilities within Oracle's software portfolio and are complementary to each other. When used together, Oracle GoldenGate and Oracle Active Data Guard offer a unique data protection and information distribution solution not offered by any other product.
While these features generally fall into the category of replication technologies, each has a very different area of focus:

(1)Oracle Active Data Guard is Oracle's strategic product for data protection and disaster recovery for Oracle Database.
Oracle Active Data Guard is a superset of standard Data Guard functionality included in Oracle Database Enterprise Edition, thus Active Data Guard also inherits all Data Guard functionality:
1) Transparent operation across all data types, storage attributes, DML and DDL
2) Management simplicity; simple one-way replication of the entire database
3) Superior corruption protection
4) Choice of asynchronous or synchronous (zero data loss) protection
5) High availability during unplanned events via automatic database and client failover
6) Minimized downtime by implementing database upgrades, system and site maintenance, or technology refresh, in rolling fashion across primary and standby databases

Oracle Active Data Guard requires a separate license and can only be used with Oracle Database Enterprise Edition. It can be purchased as the Active Data Guard Option for Oracle Database Enterprise Edition. It is also included with Oracle GoldenGate. Basic Data Guard functionality does not require a separate license, and it is included with Oracle Enterprise Edition. Oracle Active Data Guard is described in Section 3.6.2.

(2)Oracle GoldenGate is Oracle's strategic product for data distribution and data integration.
Oracle GoldenGate supplements Active Data Guard with its heterogeneous and bidirectional replication capabilities to enable enterprise-wide information distribution, zero-downtime upgrades and migrations, query offloading to heterogeneous systems, and multimaster database solutions.

Depending on the business situation:
1)Choose Oracle Active Data Guard for a simple, high-performance, drop-in solution for disaster recovery, data protection, and high availability for the entire Oracle database.
2)Choose Oracle GoldenGate to set up a data distribution and data synchronization solution through this Oracle-Oracle replication configuration, or a more flexible multimaster HA solution.

Figure 3-1 shows a configuration in which an Oracle Data Guard physical standby database provides optimal data protection and offloads read-only workload from the primary database. It also provides for heterogeneous replication of various subsets of the production database to multiple target databases. Rather than host Oracle GoldenGate replication on the production database, the Oracle GoldenGate capture process is offloaded to the physical standby database where changes are captured from archived redo logs and replicated, without necessitating overhead for Oracle GoldenGate processing on the production system.

Figure 3-1 Oracle GoldenGate and Oracle Data Guard for Unplanned Outages

Description of "Figure 3-1 Oracle GoldenGate and Oracle Data Guard for Unplanned Outages"

Oracle GoldenGate is also an excellent method to minimize downtime during planned maintenance, including application and database upgrades and platform migrations.

Oracle Golden Gate 系列一 — GG 架构 说明

一. GoldenGate 下载地址



二. GoldenGate 架构说明
学一个工具,最块的方法是先掌握其原理,当然也是因系统而已,GG 的原理比Oracle 的就简单很多,直接从Administrator’s Guide 上摘取GG 的架构部分。

2.1 Oracle GoldenGate supported processing methods anddatabases
Oracle Golden Gate enables the exchange and manipulation of data at the transactionlevel among multiple, heterogeneous platforms across the enterprise. Itsmodular architecture gives you the flexibility to extract and replicateselected data records, transactional changes, and changes to DDL (datadefinition language) across a variety of topologies.

With thisflexibility, and the filtering, transformation, and custom processing featuresof Oracle GoldenGate, you can support numerous business requirements:
1) Business continuance and highavailability.
2) Initial load and databasemigration.
3) Data integration.
4) Decision support and datawarehousing.

Figure 1 Oracle GoldenGate supportedtopologies

Table 1 Supported processing methods1

*Supported only as a target database.Cannot be a source database for Oracle GoldenGate extraction.
** Uses a capture module that communicateswith the Oracle GoldenGate API to send change data to Oracle GoldenGate.
*** Only like-to-like configuration issupported. Data manipulation, filtering, column mapping not supported.

2.2. Overview of the Oracle GoldenGate architecture
Oracle Golden Gate is composed of thefollowing components:
(1) Extract
(2) Data pump
(3) Replicat
(4) Trails or extract files
(5) Checkpoints
(6) Manager
(7) Collector

Figure 2 illustrates the logical architecture of Oracle Golden Gate for initial dataloads and for the replication of ongoing database changes. This is the basicconfiguration. Variations of this model are recommended depending on businessneeds.

Figure 2 Oracle GoldenGate logicalarchitecture

2.2.1 Overview of Extract
The Extract process runs on the source system and is the extraction (capture) mechanism ofOracle Golden Gate. You can configure Extract in one of the following ways:
(1)Initialloads: For initial data loads, Extract extracts a current set of data directlyfrom their source objects.
(2)Change synchronization: To keep source data synchronized with another set of data, Extractcaptures changes made to data (typically transactional inserts, updates, and deletes)after the initial synchronization has taken place. DDL changes and sequences arealso extracted, if supported for the type of database that is being used.

When processing data changes, Extract obtains the data from a data source that can be one ofthe following.
(1)The database recovery logs or transaction logs (such as the Oracle redo logs or SQL/MX audittrails). The actual method of obtaining the data from the logs varies dependingon the database type.
(2)A third-partycapture module. This method provides a communication layer that passes datachanges and metadata from an external API to the Extract API. The databasevendor or a third-party vendor provides the components that extract the data changesand pass it to Extract.

Extract captures all of the changes that are made to objects that you configure for synchronization.Extract stores the changes until it receives commit records or rollbacks forthe transactions that contain them. When a rollback is received, Extractdiscards the data for that transaction. When a commit is received, Extractsends the data for that transaction to the trail for propagation to the targetsystem. All of the log records for a transaction are written to the trail as asequentially organized transaction unit. This design ensures both speed anddata integrity.

Extract ignores operations on objects that are not in the Extract configuration, even thoughthe same transaction may also include operations on objects that are in the Extractconfiguration.

Multiple Extract processes can operate on different objects at the same time. For example, oneprocess could continuously extract transactional data changes and stream themto a decision-support database, while another process performs batch extractsfor periodic reporting. Or, two Extract processes could extract and transmit inparallel to two Replicat processes (with two trails) to minimize target latencywhen the databases are large. To differentiate among different processes, youassign each one a group name (see “Overviewof groups” on page 18).

2.2.2 Overview of datapumps
A data pump is asecondary Extract group within the source Oracle GoldenGate configuration. If adata pump is not used, Extract must send data to a remote trail on the target.In a typical configuration that includes a data pump, however, the primary Extract group writes to a trail on the source system. The data pump reads this trail and sends the data over the network to a remote trail on the target. The data pump adds storage flexibility and also serves to isolate the primaryExtract process from TCP/IP activity.

Like a primary Extract group, a data pump can be configured for either online or batch processing.It can perform data filtering, mapping, and conversion, or it can be configuredin pass-through mode, where data is passively transferred as-is, withoutmanipulation. Pass-through mode increases the throughput of the data pump,because all of the functionality that looks up object definitions is bypassed.

In most businesscases, you should use a data pump. Some reasons for using a data pump includethe following:
(1)Protection against network and target failures: In a basic Oracle GoldenGate configuration,with only a trail on the target system, there is nowhere on the source systemto store data that Extract continuously extracts into memory. If the network orthe target system becomes unavailable, that Extract could run out of memory andabend. However, with a trail and data pump on the source system, captured datacan be moved to disk, preventing the abend of the primary Extract. Whenconnectivity is restored, the data pump captures the data from the source trailand sends it to the target system(s).
(2)You are implementing several phases of data filtering or transformation. When using complexfiltering or data transformation configurations, you can configure a data pump toperform the first transformation either on the source system or on the targetsystem, or even on an intermediary system, and then use another data pump orthe Replicat group to perform the second transformation.
(3) Consolidating data from many sources to a central target. When synchronizing multiple sourcedatabases with a central target database, you can store extracted data on each sourcesystem and use data pumps on each of those systems to send the data to a trail onthe target system. Dividing the storage load between the source and targetsystems reduces the need for massive amounts of space on the target system toaccommodate data arriving from multiple sources.
(4) Synchronizingone source with multiple targets. When sending data to multiple target systems,you can configure data pumps on the source system for each target. If network connectivityto any of the targets fails, data can still be sent to the other targets.

If your requirements preclude the use of a data pump, you can still configure Oracle GoldenGatewithout one. Oracle GoldenGate supports many different configurations. See theconfiguration chapters in this guide to find the one that is best suited toyour environment.

2.2.3 Overview of Replicat
The Replicat process runs on the target system. Replicat reads extracted data changes and DDLchanges (if supported) that are specified in the Replicat configuration, and then it replicates them to the target database. You can configure Replicat inone of the following ways:
(1) Initial loads: For initial data loads, Replicat can apply data to target objects orroute them to a high-speed bulk-load utility.
(2)Change synchronization: To maintain synchronization, Replicat applies extracted data changesto target objects using a native database interface or ODBC, depending on the databasetype. Replicated DDL and sequences are also applied, if supported for the typeof database that is being used. To preserve data integrity, Replica applies thereplicated changes in the same order as they were committed to the sourcedatabase.

You can use multiple Replica processes with multiple Extract processes in parallel to increase throughput. Each set of processes handles different objects. To differentiate among processes, you assign each one a group name .
You can delay Replica so that it waits a specific amount of time before applying data to thetarget database. A delay may be desirable, for example, to prevent thepropagation of errant SQL, to control data arrival across different time zones,or to allow time for other planned events to occur. The length of the delay iscontrolled by the DEFER APPLY INTERVAL parameter.

2.2.4 Overview of trails
To support the continuous extraction and replication of database changes, Oracle GoldenGate stores the captured changes temporarily on disk in a series of files called a trail. A trail can exist on the source or target system, or on an intermediary system,depending on how you configure Oracle GoldenGate. On the local system it is known as an extract trail (or local trail). On a remote system it is known as aremote trail.

By using a trailfor storage, Oracle GoldenGate supports data accuracy and fault tolerance. The use of a trail also allows extraction and replication activities to occur independently of each other.With these processes separated, you have more choices for how data isdelivered. For example, instead of extracting and replicating changescontinuously, you could extract changes continuously but store them in thetrail for replication to the target later, whenever the target applicationneeds them. Processes that write to, and read, a trail
The primary Extract process writes to a trail. Only one Extract process can write to atrail.

Processes that read the trail are:
(1) Data-pump Extract: Extracts data from a local trail for further processing, if needed, andtransfers it to the target system or to the next Oracle GoldenGate process
downstream in the Oracle GoldenGateconfiguration.
(2) Replicat: Reads a trail to apply change data to the target database. Trail maintenance
Trail files are created as needed during processing, and they are aged automatically to allow processing to continue without interruption for file maintenance. By default,trails are stored in the dirdat sub-directory of the Oracle GoldenGatedirectory.

By default, each file in a trail is 10 MB in size. All file names in a trail begin with the same two characters, which you assign when you create the trail. As files arecreated, each name is appended with a unique, six-digit serial (sequence)number from 000000 through 999999, for example c:\ggs\dirdat\tr000001. When thetrail sequence number reaches 999999, the numbering starts over at 000000.

You can create more than one trail to separate the data from different objects or applications. You link the objects that arespecified in a TABLE or SEQUENCE parameter to a trail that is specified with an EXTTRAIL or RMTTRAIL parameter in the Extract parameter file. Aged trail filescan be purged by using the Manager parameter PURGEOLDEXTRACTS. How processes write to a trail
To maximize throughput, and to minimize I/O load on the system, extracted data is sent into and out of a trail in large blocks. Transactional order is preserved. By default, Oracle GoldenGate writes data to the trail in canonical format, aproprietary format which allows it to be exchanged rapidly and accurately amongheterogeneous databases. However, data can be written in other formats that arecompatible with different applications.
By default,Extract operates in append mode, where if there is a process failure, arecovery marker is written to the trail and Extract appends recovery data tothe file so that a history of all prior data is retained for recovery purposes.
In append mode, the Extract initialization determines theidentity of the last complete transaction that was written to the trail atstartup time. With that information, Extract endsrecovery when the commit record for that transaction is encountered in the datasource; then it begins new data capture with the next committed transactionthat qualifies for extraction and begins appending the new data to the trail. Adata pump or Replicat starts reading again from that recovery point.
Overwrite mode is another version of Extract recovery thatwas used in versions of Oracle GoldenGate prior to version 10.0. In these versions, Extract overwrites the existing transaction datain the trail after the last write-checkpoint position, instead of appending thenew data. The first transaction that is written is the first one that qualifiesfor extraction after the last read checkpoint position in the data source.
If the versionof Oracle GoldenGate on the target is older than version 10, Extract will automaticallyrevert to overwrite mode to support backward compatibility. This behavior canbe controlled manually with the RECOVERYOPTIONS parameter. Trail format
As of Oracle GoldenGate version 10.0, each file of a trail contains a file header record thatis stored at the beginning of the file. The file header contains information about the trail file itself. Previous versions of Oracle GoldenGate do not contain this header.
Each data record in a trail file also contains a header area, as well as a data area. The recordheader contains information about the transaction environment, and the dataarea contains the actual data values that were extracted. For more informationabout the trail record format, see Appendix 1. File versioning
Because all of the Oracle GoldenGate processes are decoupled and thus can be of different OracleGoldenGate versions, each trail file or extract file has a version that is stored in the file header. By default, the version of a trail is the current version of the process that created the file. To set the version of a trail, use the FORMAT option of the EXTTRAIL, EXTFILE,RMTTRAIL,or RMTFILE parameter.
To ensure forward and backward compatibility of files among different Oracle GoldenGate processversions, the file header fields are written in a standardized token format.New tokens that are created by new versions of a process can be ignored byolder versions, so that backward compatibility is maintained. Likewise, newerOracle GoldenGate versions support older tokens. Additionally, if a token isdeprecated by a new process version, a default value is assigned to the tokenso that older versions can still function properly. The token that specifiesthe file version is COMPATIBILITY and can be viewed in the Logdump utility andalso by retrieving it with the GGFILEHEADER option of the @GETENV function.
A trail orextract file must have a version that is equal to, or lower than, that of theprocess that reads it. Otherwise the process will abend. Additionally,OracleGoldenGate forces the output trail or file of a data pump to be the sameversion as that of its input trail or file.
Upon restart,Extract rolls a trail to a new file to ensure that each file is of only oneversion (unless the file is empty).

2.2.5 Overview of extract files
When processing a one-time run, such as an initial load or a batch run that synchronizes transactional changes, Oracle GoldenGate stores the extracted changes in an extractfile instead of a trail. The extract file typically is a single file but can beconfigured to roll over into multiple files in anticipation of limitations onfile size that are imposed by the operating system. Inthis sense, it is similar to a trail, except that checkpoints are not recorded.The file or files are created automatically during the run. The sameversioning features that apply to trails also apply to extract files.

2.2.6 Overview of checkpoints
Checkpoints store the current read and write positions of a process to disk for recovery purposes.These checkpoints ensure that data changes that are marked for synchronizationactually are extracted by Extract and replicated by Replicat, and they preventredundant processing. They provide fault tolerance by preventing the loss ofdata should the system, the network, or an Oracle GoldenGate process need to berestarted. For complex synchronization configurations, checkpoints enablemultiple Extract or Replicat processes to read from the same set of trails.
Checkpoints work with inter-process acknowledgments to prevent messages from being lost in thenetwork. Oracle GoldenGate has a proprietary guaranteed-message delivery technology.
Extract creates checkpoints for its positions in the datasource and in the trail. Replicat creates checkpoints for its position in thetrail.

A checkpoint system is used by Extract and Replicat processesthat operate continuously, but it is not required by Extract and Replicat processes that run in batch mode . A batchprocess can be re-run from its start point, whereas continuous processing requiresthe support for planned or unplanned interruptions that is provided by checkpoints.
Replicat stores its checkpoints in a checkpoint table in the target database to couple the commitof its transaction with its position in the trail file. This ensures that atransaction will only be applied once, even if there is a failure of theReplicat process or the database process. For reporting purposes, Replicat alsohas a checkpoint file on disk in the dirchk subdirectory of the OracleGoldenGate directory. You can optionally configure Replicat to use this file asits sole checkpoint store, and not use a checkpoint table at all. In this mode,however, there can be cases where the checkpoint in the file is not consistentwith what was applied after a database recovery, if the failure either rolledback or rolled forward a transaction that was considered applied by Replicat.The checkpoint table guarantees consistency after recovery.

2.2.7 Overview of Manager
Manager is the control process of Oracle GoldenGate. Manager must be running on each system inthe Oracle GoldenGate configuration before Extract or Replicat can be started, and Manager must remain running while those processes are running so that resource managementfunctions are performed. Manager performs the following functions:
(1) Monitor and restart OracleGoldenGate processes.
(2)Issue threshold reports, forexample when throughput slows down or when synchronization latency increases.
(3)Maintain trail files and logs.
(4)Allocate data storage space.
(5)Report errors and events.
(6)Receive and route requests from theuser interface.

One Manager process can control many Extract or Replicat processes. On Windows systems,Manager can run as a service. For more information about the Manager process, see Chapter 2.

2.2.8 Overview of Collector
Collector is aprocess that runs in the background on the target system. Collector receives extracted database changes that are sent across the TCP/IP network, and it writes them toa trail or extract file. Typically, Manager starts Collector automatically whena network connection is required. When Manager starts Collector, the process isknown as a dynamic Collector, and Oracle GoldenGate users generally do notinteract with it. However, you can run Collector manually. This is known as a staticCollector. Not all Oracle GoldenGate configurations use a Collector process.
When a dynamicCollector is used, it can receive information from only one Extract process, sothere must be a dynamic Collector for each Extract that you use. When a staticCollector is used, several Extract processes can share one Collector. However,a one-to-one ratio is optimal. The Collector process terminates when theassociated Extract process terminates.
By default, Extract initiates TCP/IP connections from the source system to Collector on thetarget, but Oracle GoldenGate can be configured so that Collector initiatesconnections from the target. Initiating connections from the target might berequired if, for example, the target is in a trusted network zone, but thesource is in a less trusted zone.

2.3 Overview of processing methods
Oracle GoldenGate can be configured for thefollowing purposes:
(1) A static extraction of selecteddata records from one database and the loading of those records to anotherdatabase.
(2) Online or batch extraction andreplication of selected transactional data changes and DDL changes (forsupported databases) to keep source and target data consistent.
(3) Extraction from a database andreplication to a file outside the database.For these purposes, OracleGoldenGate supports the following processing modes.
(4) An online process runs untilstopped by a user. Online processes maintain recovery checkpoints in the trailso that processing can resume after interruptions. You can use online processesto continuously extract and replicate transactional changes and DDL changes(where supported).
(5) A batch run, or special run,process extracts or replicates database changes that were generated withinknown begin and end points. For special runs, Oracle GoldenGate does notmaintain checkpoints. Should a process fail, the job can be started over, usingthe same begin and end points. You can use a special run to process a batch ofdatabase changes (such as to synchronize source and target objects once a dayrather than continuously) or for an initial data load.
(6) A task is a special type of batchrun process and is used for certain initial load methods.
A task is aconfiguration in which Extract communicates directly with Replicat over TCP/IP.Neither a Collector process nor temporary disk storage in a trail or file isused.

2.4 Overview of groups
To differentiateamong multiple Extract or Replicat processes on a system, you define processinggroups. For example, to replicate different sets of data in parallel, you wouldcreate two Replicat groups.
A processinggroup consists of a process (either Extract or Replicat), its parameter file,its checkpoint file, and any other files associated with the process. ForReplicat, a group also includes the associated checkpoint table.
You definegroups by using the ADD EXTRACT and ADD REPLICAT commands in the Oracle GoldenGatecommand interface, GGSCI. A group name can be as follows:

All files andcheckpoints relating to a group share the name that is assigned to the group itself.Any time that you issue a command to control or view processing, you supply agroup name or multiple group names by means of a wildcard.

2.5 Overview of the Commit Sequence Number (CSN)
When workingwith Oracle GoldenGate, you might need to refer to a Commit Sequence Number, o rCSN. The CSN can be required to position Extract in the transaction log, to repositionReplicat in the trail, or for other purposes. It is returned by some conversionfunctions and is included in reports and certain GGSCI output.
A CSN is anidentifier that Oracle GoldenGate constructs to identify a transaction for the purposeof maintaining transactional consistency and data integrity. It uniquelyidentifies a particular point in time in which a transaction commits to thedatabase.
Each kind ofdatabase management system generates some kind of unique serial number of itsown at the completion of each transaction, which uniquely identifies thattransaction.
A CSN capturesthis same identifying information and represents it internally as a series ofbytes, but the CSN is processed in a platform-independent manner. A comparisonof any two CSN numbers, each of which is bound to a transaction-commit recordin the same log stream, reliably indicates the order in which the twotransactions completed.
The CSN value isstored as a token in any trail record that identifies the beginning of a transaction.This value can be retrieved with the @GETENV column conversion function and viewedwith the Logdump utility.

Extract writes anormalized form of the CSN to external storage such as the trail files and thecheckpoint file. There, the CSN is represented as a hex string of bytes. Innormalized form, the first two bytes represent the database platform, and theremainder of the string represents the actual unique identifier.
The CSN is alsoincluded in report output, error messages, and command input and output (asappropriate) in human-readable, display form that uses native characterencoding. In this form, the database type is not included, but it can besupplied separately from the identifier.

Table 3 Oracle GoldenGate CSN values perdatabase1 (continued)

All databaseplatforms except Oracle, DB2 LUW, and DB2 z/OS have fixed-length CSNs, whichare padded with leading zeroes as required to fill the fixed length. CSNs thatcontain multiple fields can be padded within each field, such as the SybaseCSN.

Oracle Golden Gate 系列二 — GG 的系统需求

一. Memory requirements
The amount ofmemory that is required for Oracle GoldenGate depends on the number of concurrentprocesses that will be running. At minimum on thesource system, there is a primary Extract process that captures sourcedata and a secondary Extract data-pump process that transfers data across thenetwork. At minimum on the target system is at leastone Replicat process that applies the replicated data to the target database.In some cases, these processes might all operate on the same system, dependingon the required configuration.
—并发进程的数据量决定GG内存的大小,在source system端,最少需要一个Extract 进程和一个data-pump进程,在target system 端, 至少需要一个replicat 进程。

(1)The OracleGoldenGate GGSCI command interface fully supports up to 300 concurrent Extractand Replicat processes per instance of Oracle GoldenGate. An instance of OracleGoldenGate equates to one Manager process, which is the main controller process.
— 在每个GG instance 上,GGSCI 命令结构最多支持300个Extract和 replicat 并发进程,每个GG instance 需要一个Manager 进程。
(2)Each Extractand Replicat process needs approximately 25-55 MB of memory, or more dependingon the size of the transactions and the number of concurrent transactions.
—每个Extract 和 Replicat 进程大概需要25-55M的内存,根据的要根据事务的数量和事务的并发量决定。

The actual amount of physical memory that is used by any Oracle GoldenGate process is controlledby the operating system, not the Oracle GoldenGate program. The Oracle GoldenGatecache manager takes advantage of the memory management functions of the operatingsystem to ensure that Oracle GoldenGate processes work in a sustained and efficientmanner.
—GG 实际使用的物理内存量是由操作系统控制的,GG的cache manager 利用操作系统的memory managementfunctions 来保证GG 以持续和有效的方式来运行。

Within its cache, it makes use of modernvirtual memory techniques by:
—GG 的cachemanager 利用virtual memory 技术:
(1)Allocatingand managing active buffers efficiently.
(2)Recycling oldbuffers instead of paging to disk, when possible.
(3)Pagingless-used information to disk, when necessary.

The cachemanager keeps an Oracle GoldenGate process working within the soft limit of itsglobal cache size, only allocating virtual memory (not physical memory) on demand.System calls to increase the cache size are made only as a last resort and,when used, are always followed by the release of virtual memory back to thesystem.
—Cache manager 保持GG 进程在global cache 的大小内工作,在需要时仅分配virtualmemory,操作完会,会释放virtual memory。 只有在不得已的情况下,才会增加cache size。

The system musthave sufficient swap space for each Oracle GoldenGate Extract and Replicat processthat will be running.
—系统必须要有足够的swap space 来支撑GG Extract 和Replicat 进程的运行。

To determine the required swap space:
—通过一下的方法来确定需要swap space 的大小:
(1) Start up oneExtract or Replicat.
(2) Run GGSCI.
(3) View thereport file and find the line PROCESS VM AVAIL FROM OS (min).
(4) Round up thevalue to the next full gigabyte if needed. For example, round up 1.76GB to 2GB.
(5) Multiplythat value by the number of Extract and Replicat processes that will be running.The result is the maximum amount of swap space that could be required. To determinethe number of processes you will need, consult the configuration chapters in theOracle GoldenGate Windows and UNIX Administrator’s Guide.

二.Disk requirements
Assign the following free disk space:
(1) 50-150 MB,depending on the database and platform. This includes space for the compresseddownload file and space for the uncompressed files. You can delete the downloadfile after the installation is complete.
GG 软件需要的空间大小
(2)40 MB for theworking directories and binaries for each instance of Oracle GoldenGate thatyou are installing on the system. For example, to install two builds of Oracle GoldenGateinto two separate directories, allocate 80 MB of space.
每个GG instance 的working directories 和binaries 是40M。
(3)To installOracle GoldenGate into a cluster environment, install the Oracle GoldenGatebinaries and files on a shared file system that is available to all cluster nodes.
如果是集群环境上部署GG,GG binaries 和 files 需要放在共享文件系统上。
(4)An additional1 GB of disk space on any system that hosts Oracle GoldenGate trails, which arefiles that contain the working data. You may need more or less than this amount,because the space that is consumed by the trails depends on the volume of datathat will be processed. Start with 1 GB and adjust as needed. See also the followingguidelines.
至少1G的空间来存放trails 文件

三.Storagefor Oracle GoldenGate trails
To prevent trailactivity from interfering with business applications, assign a separate disk orfile system to contain the trail files. These files are created duringprocessing to store all of the data that is captured by Oracle GoldenGate. The default size is 10 megabytes, but can be changed duringthe configuration process. Trail files accumulate but can be purged accordingto rules set with the PURGEOLDEXTRACTS parameter.
—为了避免trail 被其他的应用干扰,最好分配独立的disk 或者 filesystem 来存放trail 文件。 Trail file 里保存的是GG capture 的data。 Trail file 默认大小是10M,该大小可以进行配置,trail files 是类型型的,其保留策略可以通过PURGEOLDEXTRACTS 参数控制。

Trail files canreside on drives that are local to the Oracle GoldenGate installation, or they canreside on NAS or SAN devices. You will specify the location of the trails whenyou configure Oracle GoldenGate.
—trail files 可以保留在本地磁盘或者NAS/SAN 设备上,具体在安装GG时可以配置。

For trails that are stored at the source location, there should be enough space to handle data accumulation should thenetwork connection fail. In a typical configuration, a secondary Extractprocess (known as a data pump) sends data from a local trail over the network,and it will fail when the network does.
However, theprimary Extract that reads the transaction logs and writes to the local trailwill continue to do so. This Extract should not be stopped during a failure;otherwise, transaction data might be missed if the transaction logs recycle orget removed from the system before the data is completely captured. There mustbe enough disk space to hold the data accumulation.
—在一个典型的GG 配置,source 会有Extract 和data-pump进程,如果trails 存储在source 本地,当网络出现故障,data-pump 进程会失败,但extract 进程还会继续工作,这样trails 文件会越来越大, 必须要有足够的空间来存放trails。

For trails atthe target location, provide enough disk space to handle data accumulation accordingto the purge rules set with the PURGEOLDEXTRACTS parameter. Even with PURGEOLDEXTRACTSin use, data will always accumulate on the target because it is transferredacross the network faster than it can be applied to the target database.
—如果trails 放在target 端,那么需要根据PURGEOLDEXTRACTS参数来决定所需要的磁盘空间。

To estimate requiredtrail space:
估算trailspace 方法:
1. Estimate thelongest time that the network could be unavailable. Plan to store enough datato withstand the longest possible outage, because otherwise you will need to resynchronizethe source and target data if the outage outlasts disk capacity.
2. Estimate howmuch transaction log volume your business applications generate in one hour.
3. Use thefollowing formula to calculate the required disk space.
trail disk space=[logvolume in one hour] x [number of hours downtime] x 0.4

This equationuses a multiplier of 40 percent because only about 40 percent of the data in atransaction log is needed by Oracle GoldenGate.
—注意这里乘以了40%,因为GG 只需要大概40%的事务log。

This formula isa conservative estimate, and you should run tests once you have configuredOracle GoldenGate to determine exactly how much space you need.

四.Temporarydisk requirements
By default,Oracle GoldenGate maintains data that it swaps to disk in the dirtmp subdirectoryof the Oracle GoldenGate installation directory. The cache manager assumes thatall of the free space on the file system is available. You can assign adirectory by using the CACHEDIRECTORY option of the CACHEMGR parameter.
—默认情况下,GG 的maintains data 会放在GG 安装目录的dirtmp子目录下,可以使用CACHEMGR的CACHEDIRECTORY来进行修改。

五.OracleRAC requirements
To installOracle GoldenGate in an Oracle Real Application Cluster (RAC) environment, installOracle GoldenGate on the shared drive(s) that are accessed by the RAC nodes.This allows you to start the Oracle GoldenGate processes from any of the nodes.If the node where the processes are running fails, you can start them onanother node without modifying parameter files, because the processingcheckpoints are preserved in the installation directory.
—对于RAC 集群,GG 需要安装在共享设备里,这样可以从任何一个节点启动,而且当在一个节点上运行失败时,可以从其他的节点启动,并不需要修改配置。

六. Network
1. Configure the system to use TCP/IPservices, including DNS.
2. Configure the network with the hostnames or IP addresses of all systems that will be hosting Oracle GoldenGateprocesses and to which Oracle GoldenGate will be connecting. Host names areeasier to use.
3. Oracle GoldenGate requires the followingunreserved and unrestricted TCP/IP ports:
(1) One port forcommunication between the Manager process and other Oracle GoldenGateprocesses.
(2)A range ofports for local Oracle GoldenGate communications: can be the default rangestarting at port 7840 or a customized range of up to 256 other ports.
—GG 的端口,默认从7840开始
4. Keep a record of the ports that youassigned to Oracle GoldenGate. You will specify them with parameters whenconfiguring the Manager process.
5. Configure your firewalls to acceptconnections through the Oracle GoldenGate ports.

七. Operating system privileges
1. To install onWindows, the person who installs Oracle GoldenGate must log in as Administrator.
2. To install onUNIX, the person who installs Oracle GoldenGate must have read and writeprivileges on the Oracle GoldenGate installation directory.
3. The OracleGoldenGate Extract, Replicat, and Manager processes must operate as an operatingsystem user that has privileges to read, write, and delete files and subdirectoriesin the Oracle GoldenGate directory. In addition, the Manager process requiresprivileges to control the other Oracle GoldenGate processes.
4. The Extractprocess must operate as an operating system user that has read access to thetransaction log files, both online and archived. On UNIX systems, that usermust be a member of the group that owns the Oracle instance. If you install theManager process as a Windows service during the installation steps in thisdocumentation, you must install as Administrator for the correct permissions tobe assigned. If you cannot install Manager as a service, assign read access tothe Extract process manually, and then always run Manager and Extract asAdministrator.
5. Dedicate theExtract, Replicat, and Manager operating system users to Oracle GoldenGate.Sensitive information might be available to anyone who runs an Oracle GoldenGateprocess, depending on how database authentication is configured.

八.Itanium requirements
To installOracle GoldenGate on a Microsoft Itanium system, the vcredist_IA64.exe runtime librarypackage must be installed. You can download this package from the Microsoft website.This package includes VisualStudio DLLs necessary for Oracle GoldenGate to operateon the Itanium platform. If these libraries are not installed, OracleGoldenGate generates the following error.
“The application failed to initializeproperly (0xc0150002). Click on Ok to terminate the application.
—在安腾的windows的系统上运行GG,必须要先安装vcredist_IA64.exe包。如果没有安装,会报错。 不过Oracle 12c 已经不在支持Itanium CPU,所以这块了解一下就ok了。

九.Other programs
1. Beforeinstalling Oracle GoldenGate on a Windows system, install and configure the MicrosoftVisual C ++ 2005 SP1 Redistributable Package. Make certain it is the SP1 versionof this package, and make certain to get the correct bit version for yourserver. This package installs runtime components of Visual C++ Libraries. For moreinformation, and to download this package, go to
—在Windows 上安装GG,需要先安装MicrosoftVisual C ++ 2005 SP1包。

2. Oracle GoldenGate fully supports virtual machine environmentscreated with any virtualization software on any platform. When installingOracle GoldenGate into a virtual machine environment, select a build thatmatches the database and the operating system of the virtual machine, not thehost system. For example, on a Windows system with a RHAS 4.0 virtual machinerunning Oracle11g, you would install the RHAS 4.0 build for Oracle 11g, just asyou would on an actual Linux machine.
—GG 支持虚拟机环境。

十. Database configuration
1. To run OracleGoldenGate for multiple Oracle instances on a Windows system, you must installan instance of Oracle GoldenGate for each one
2. On 64-bit SunSolaris, HP Tru64 (OSF/1), and LINUX machines with 32-bit Oracle databases,Oracle GoldenGate requires LD_LIBRARY_PATH to include the 32-bit Oracle libraries.You will be instructed to set LD_LIBRARY_PATH in the installation instructions inthis manual.
在Linux 32bit等系统上运行GG,需要指定LD_LIBRARY_PATH,其要包含32bit的oraclelibraries。
3. If thedatabase is Oracle 10g or later and configured to use a Bequeath connection,the sqlnet.ora file must contain the bequeath_detach=true setting.
如果是Oracle 10g以后的版本,必须要在sqlnet.ora 中设置bequeath_detach=true,以使用Bequeath connection
4. To supportthe default RMAN log retention feature on Oracle RAC, you must download andinstall the database patch that is provided in BUGFIX 11879974 before you add theExtract groups.
5. Additionaldatabase configuration requirements are explained elsewhere in this manual.

十一. Database client
The full Oracle client must be used with Oracle GoldenGate so that the Oracle GoldenGate programshave access to the Oracle XDK libraries. Do not use Oracle Instant Client,which lacks those libraries. You can download the full client from the Oraclewebsite.

十二. Database user for Oracle GoldenGateprocesses
1. Create adatabase user that is dedicated to Oracle GoldenGate. It can be the same user forall of the Oracle GoldenGate processes that must connect to a database:
(1) Extract (source database)
(2) Replicat (target database)
(3) Manager (source database, if usingDDL support)
(4) DEFGEN (source or target database)

2 To preservethe security of your data, and to monitor Oracle GoldenGate processing accurately,do not permit other users, applications, or processes to log on as, or operate as,the Oracle GoldenGate database user.
Keep a record of the database users. They must be specified in the Oracle GoldenGate parameterfiles with the USERID parameter. Use the USERID parameter for the database user,and use the TRANLOGOPTIONS parameter with the ASMUSER and ASMPASSWORD optionsfor the ASM user.

十三. Database privileges
Certainprivileges are required for a regular Oracle instance, plus additionalprivileges for an ASM instance and additional privileges for Oracle EnterpriseEdition 10.2 or later.

1. Regular Oracle database instance
To assign the correct privileges to theOracle GoldenGate database user, see Table 1.

2.Oracle ASM instance
If Oracle 10g AutomaticStorage Management (ASM) is in use, Oracle GoldenGate requires a user for theExtract process to access the ASM instance. Oracle GoldenGate does not supportusing operating-system authentication for the ASM user. You can use SYS user orany user with SYSDBA privileges in the ASM instance. See Table 2.
—如果使用ASM,GG 需要能够访问ASM instance。

3. Oracle Enterprise Edition 10.2 or later instance
In OracleEnterprise Edition 10.2 or later, the additional privileges in Table 3 arerequired for the Extract database user. In these Enterprise Edition versions,Oracle Recovery Manager (RMAN) works with Extract to retain the archive logsthat Extract needs for recovery. The special privileges are required forinteraction with an underlying Oracle Streams Capture and with RMAN.

Oracle Gloden Gate 系列三 — GG 支持与不支持的对象类型与操作 说明

2011-11-16 15:21:40 我来说两句 收藏 我要投稿 [字体:小 大]

一.Supported Oracle data types
1.1 Numeric data types
(1) NUMBER up to the maximum sizepermitted by Oracle

Limitations of support
The support of rangeand precision for floating-point numbers depends on the host machine. Ingeneral, the precision is accurate to 16 significant digits, but you shouldreview the database documentation to determine the expected approximations.Oracle GoldenGate rounds or truncates values that exceed the supportedprecision.

1.2 Character data types

1.3 Multi-byte character types
(1) NCHAR and NVARCHAR2 multi-bytecharacter data types
(2) Multi-byte data stored in CHAR andVARCHAR2 columns

Limitations of support
(1) For OracleGoldenGate to support multi-byte character data, the source and target databasesmust be identical. Transformation, filtering, and other manipulation are not supported.
(2) Multi-bytecharacters can be used with limitations in MAP and TABLE parameter statementssuch as string-based conversion functions and WHERE clauses. The code point fora multi-byte character must be represented within an escape sequence, for example“\u20ac.”
(3) Multi-bytedata is supported whether the length semantics are in bytes or characters. Ifthe semantics setting of the source database is BYTE and the setting of thetarget is CHAR, use the Replicat parameter SOURCEDEFS in your configuration,and place a DEFGEN generated definitions file on the target. These steps arerequired to support the difference in semantics, whether or not the source andtarget data definitions are identical. Replicat refers to the definitions fileto determine the upper size limit for fixed-size character columns.
(4) If thedatabase has an NLS_NCHAR_CHARACTERSET value other than AL16UTF16, use the VARWIDTHNCHARparameter to force NCHAR data to be written to the trail with 2-byte lengthinformation.

1.4 Binary data types
(1) RAW

1.5 Date and timestamp data types
(1) DATE
(2) TIMESTAMP (see Limitations ofsupport)

Limitations of support
(1) By default,only TIMESTAMP WITH TIME ZONE specified as a UTC offset is supported. To supportTIMESTAMP WITH TIME ZONE specified as TZR (Region ID), you must use the Extractparameter TRANLOGOPTIONS with either the INCLUDEREGIONID or INCLUDEREGIONIDWITHOFFSEToption. Without TRANLOGOPTIONS, Extract abends on this data type.
(2) TIMESTAMPWITH TIME ZONE as TZR is not supported by Oracle GoldenGate for initial loads, foruse with the SQLEXEC feature, or for operations where the column must befetched from the database. In these cases, the region ID is converted to a timeoffset by the Oracle database engine when the column is selected. Replicat willreplicate the column data as date and time data with a time offset value.
(3)Because ofthe way that the Oracle database normalizes TIMESTAMP WITH LOCAL TIME ZONE tothe local time zone of the database, the timestamps do not transfer correctlybetween databases that are in different time zones. Timestamps will transfercorrectly between databases in the same time zone if you set the time zone ofthe Replicat session to the timezone of the database. Include the followingparameter statement in the Replicat parameter file, placing it after the USERIDparameter, but before the first MAP statement:
SQLEXEC"ALTER SESSION SET TIME_ZONE = <value of dbtimezone>"
(4) OracleGoldenGate does not support negative dates.

1.6 Large object data types
(1) CLOB
(3) BLOB

Limitations of support
(1) SECUREFILE and BASICFILE are bothsupported.
(2) Store large objects out of row ifpossible.
(3) LOB capturediffers between earlier and later versions of Oracle:
Oracle versions earlierthan 10g:
In-row LOBs are captured from the redo log, but outof-rowLOBs are fetched from the database. If a value getsdeleted before a fetch occurs, Extract writes a null to the trail. If a valuegets updated before the fetch occurs, Extract writes the updated value. Toprevent these inaccuracies, try to keep Extract latency low. The OracleGoldenGate documentation provides guidelines for tuning process performance.
In-rows的情况从redo log captured,out of-row从lobsegments里进行fetch。
这里in-row 和 outof-row的区别,可以参考我的blog:
Oracle LOB 详解

Oracle 10g and later,BASICFILE LOBs:
All BASICFILELOBs are captured from the redo log, whether stored in-row or out-of row. However,Extract will continue to fetch LOBs under the following conditions, for whichit will issue a warning:
—对于BASICFILE LOBs,不管是in-row 还是out-ofrow都是从redo log 里进行captured,但是在一下情况下会从LOBs里进行fetch:
1) Extract determines that a LOB instanceis invalid.
2) The LOB data is missing from the redolog. This can occur if the BASICFILE LOB is created with the no_logging option.
3) The LOB is created with the CACHEattribute.
4) A LOB is only partially updated. Oracle GoldenGate does not support partial column data.Extract assumes LOB data to be incomplete if the LOB data does not start with aLOB reset record or does not start at the first byte and does not end at thelast byte, according to the new LOB length. Partial updates can be generated bythe following OCI calls: OCILOBWrite(), OCILobAppend(), OCiLobCopy(), OCILobLoadFromFile(),OCILobTrim(), and by updated made through procedures in the dbms_lob package.
5) Extract detects an anomaly in the LOBdata, such as a missing page number, missing END MARKER, or a mismatch betweenthe size that was captured and the expected size.

Oracle 10g and later,SECUREFILE LOBs:
Oracleintroduced SECUREFILE LOBs in 11g Release 1. SECUREFILE LOBs are captured fromthe redo logs only when the update is complete and the LOB is not transformed(the column is not compressed or encrypted or deduplicated) and storedout-of-row.
—SECUREFILE LOBs是11gR1里推出来的,当update完成,并且这个LOB 没有进行compress 或者encrypted 或者deduplicated,且数据存在lobsegment里。满足这种情况才从redo log里进行captured。

Extract will fetchSECUREFILE LOBs under the following circumstances:
1) The LOB is stored in-row.
注意这里,in-row 的情况下是进行fetch操作。
2) The LOB is transformed either with compression or encryption.
3) The LOB is created with the CACHE attribute.
4) Extract determines that a LOB instance is invalid.
5)LOB data is missing from the redo log. This can occur if the LOB is created with any of following options:deduplicate, no_logging, filesystem_like_logging.
redo log里LOB data 丢失的情况下也会进行fetch。
6) The LOB is updated using OCILOBWrite(), OCILobAppend(),OCiLobCopy(), OCILobLoadFromFile(), OCILobTrim(), or through procedures in thedbms_lob package.
7) Any other anomalies as detected by Extract in terms of a missingpage number, a missing END MARKER, or a mismatch between the size that wascaptured and the expected size.

(4) When changing a SECUREFILE LOBfrom one storage to another (such as from ENCRYPT to DECRYPT), Oracle updatesthe whole table, and Extract captures those updates from the log. Therefore, itwill appear as though Oracle updated all of the data blocks that are associatedwith the table. This also can happen when an ALTER TABLE command sets a DEFAULTvalue to a column that has null values.
(5) If CLOB columns can store binarydata, set the NLS_LANG system environment variable and the NLS_LANGUAGEdatabase parameter to the same value.
(6) When the size of a large objectexceeds 4K, Oracle GoldenGate stores the data in segments within the OracleGoldenGate trail. The first 4K is stored in the base segment, and the rest isstored in a series of 2K segments. Oracle GoldenGate does not support thefiltering, column mapping, or manipulation of large objects of this size. Full OracleGoldenGate functionality can be used for objects that are 4K or smaller.

1.7 XML data types
XMLType issupported.

Limitations of support
(1)The source and target objects thatcontain the XML must be identical. Filtering and manipulation are notsupported. However, you can map the XML representation of an object to acharacter column by means of a COLMAP clause in a TABLE or MAP statement.
(2) Oracle GoldenGate treats XMLTypedata as a LOB. There is no size limitation, but see “Large object data types”on page 10 for additional support and limitations.
(3) A table that contains XMLTypecolumns must have one of the following: a primary key, column(s) with a uniqueconstraint, or a unique index.

1.8 User defined types
OracleGoldenGate supports user defined types (UDT) when the source and target objectshave the same structure. The schema names can be different.
—GG 支持用户自定义类型

1.8.1 General limitationsof support
(1) Extract mustfetch UDTs (except for object tables) from the database, so you should configureand use a snapshot for data consistency. Because a UDT must be fetched, a tablethat contains one must have one of the following: a primary key, column(s) witha unique constraint, or a unique index.
UDT 必须从database 进行fetch
(2) OracleGoldenGate does not support UDTs with the following embedded scalar types: CLOB,CFILE, BFILE, or INTERVAL_YM, INTERVAL_DS, and OPAQUE (with the exception ofXMLType, which is supported).
UDT 不支持的类型
(3) Object or relational tables wherethe key contains a UDT, or where a UDT is the only column, are not supported.
(4) The RMTTASK parameter does notsupport user-defined types (UDT).
(5) CHAR and VARCHAR attributes thatcontain binary or unprintable characters are not supported.
(6) UDTs, including values insideobject columns or rows, cannot be used within filtering criteria in TABLE orMAP statements, or as input or output for the Oracle GoldenGate column-conversionfunctions, SQLEXEC, or other built-in data-manipulation tools. Support is onlyprovided for like-to-like Oracle source and targets.
(7) Oracle GoldenGate does not supportREF types.

1.8.2 Limitations forcollection types
(1) When data ina nested table is updated, the row that contains the nested table must be updatedat the same time.
(2) When VARRAYSand nested tables are fetched, the entire contents of the column are fetchedeach time, not just the changes.

1.8.3 Limitations forobject tables
(1) OracleGoldenGate supports object tables in uni-directional and active-active configurationsfor Oracle 10g and later. Object tables are captured from the redo log,butcertain data types that are fetched from the database when in regularrelational tables, such as LOBs and collection types, will also be fetched whenin object tables. Similarly, current limitations that apply to collection typeswhen in regular tables also apply to these types when in object tables.
(2) An Oracle objecttable can be mapped to a non-Oracle object table in a supported target database.
(3) A primarykey must be defined on the root-level object attributes of the object table,andcannot include leaf-level attributes. If no key is defined, Oracle GoldenGatewill use all viable columns as a pseudo-key.
(4)OracleGoldenGate does not support the replication of DDL operations for an object table.This limitation includes the database object versioning that is associated withALTERs of object tables.
(5) Synonyms arenot supported for object tables or relational tables that contain object tables.

1.8.4 Limitations forspatial types
OracleGoldenGate supports SDO_GEOMETRY, SDO_TOPO_GEOMETRY, and SDO_GEORASTER (rastertables) for Oracle 10g and later.

1.9 Other supported data types
(3) INTERVAL DAY and INTERVAL YEAR ifthe size of the target column is equal to, or greater than, that of the source.

二. Non-supported Oracle data types

三. Supported objects and operations forOracle DML
3.1 Tables, views, and materialized views
Oracle GoldenGate supports the following DML operations made to regular tables, index organizedtables (created with the ORGANIZATION INDEX clause of CREATE TABLE), clustered tables,and materialized views.
(4) Associated transaction controloperations

3.1.1 Limitations of support for regular tables
(1) Oracle GoldenGate supports tablesthat contain any number of rows up to 2 MB in length. Each character LOB/LONGcolumn contributes up to 4 KB to this limit, and each binary LOB columncontributes up to 8 KB. This row-size limitation mostly affects updateoperations on columns that are being used as a row identifier. This identifier canbe a primary or unique key, a key defined within the Oracle GoldenGateparameter file, or all of the columns if no key is defined. If a row identifieris updated, the 2 MB length must include not only the after image, but also thefull before image, which is required to find the correct key on the target forthe update.
(2) LOB columns are supported in theirfull size.
(3) Oracle GoldenGate supports themaximum number of columns per table that is
supported by the database.
(4) Oracle GoldenGate supports themaximum column size that is supported by the
database. OracleGoldenGate supports tables that contain only one column, except when the columncontains one of the following data types:
—GG 支持只有一列的表,但是该列不能为以下类型
1) LOB
3) Nested table
4) User defineddata type
6) XML
(5) Oracle GoldenGate supports tableswith unused columns, but the support is disabled by default, and Extract abendson them. You can use the DBOPTIONS parameter with the ALLOWUNUSEDCOLUMN optionto force Extract to generate a warning and continue processing. When usingALLOWUNUSEDCOLUMN, either the same unused column must exist in the targettable, or a source definitions file must be created for Replicat with theDEFGEN utility. You can include the appropriate ALTER TABLE…SET UNUSEDstatements in a DDL replication configuration.
—GG 支持unused 列,但是该功能默认是禁用的。可以通过DBOPTIONS参数的ALLOWUNUSEDCOLUMN 选项来强制extract 生成warning.
(6) Oracle GoldenGate supports tableswith interval partitioning. Make certain that the WILDCARDRESOLVE parameterremains at its default of DYNAMIC.
—GG 支持interval partitioning。
(7) Oracle GoldenGate supports tableswith virtual columns, but does not capture change data for these columns,because the database does not write it to the transaction log. You can use theFETCHCOLS option of the TABLE parameter to fetch the value of a virtual column.Replicat does not apply DML to a virtual column, even if the data for that columnis in the trail, because the database does not permit DML on that type of column.Data from a source virtual column when fetched can be applied to a target columnthat is not a virtual column.
—GG 支持virtual columns,但是不会capture virtual columns上的数据变化,因为数据库不会将virtual columns上的的信息写入log。 我们可以使用FETCHCOLS 选项来fetch 到virtualcolumn上的信息,但是Replicat 进程不会应用这些信息到virtual columns上,即使这些信息存在trail里,但是可以将这些fetch 的信息target database上的非virtualcolumn上。
(8) In an initial load, all of thedata is selected directly from the source tables, not the transaction log.Therefore, in an initial load, data values for all columns, including virtualcolumns, gets written to the trail or sent to the target, depending on themethod that is being used. As when applying change data, however, Replicat doesnot apply initial load data to virtual columns, because the database does notpermit DML on that type of column.
—在初始化装载的时候,所有数据是直接从source table上获取,而不是从事务日志里。 因此在initialload 时,所有列的值,包含virtual columns,都会写入trail 文件或者发送到target。 但在target端apply时,Replicat 不会应用data 到virtualcolumns,因为数据库进制virtual column上的DML 操作。
(9) Oracle GoldenGate does not permita virtual column to be used in a KEYCOLS clause in a TABLE or MAP statement.
(10) If a unique key includes a virtualcolumn, and Oracle GoldenGate must use that key, the virtual column will beignored. This might affect data integrity if the remaining columns do notenforce uniqueness. Fetching only provides an after value, and Oracle GoldenGaterequires before and after values of keys.
(11) If a unique index is defined onany virtual columns, it will not be used.
(12) If a unique key or index containsa virtual column and is the only unique identifier on a table, OracleGoldenGate must use all of the columns as an identifier to find target rows.Because a virtual column cannot be used in this identifier, it is possible thatReplicat could apply operations containing this identifier to the wrong targetrows.
(13) Tables created as EXTERNAL are notsupported.
(14) A key cannot contain a column thatis part of an invisible index.
(15) Tables created with tablecompression or OLTP table compression are not supported. Oracle GoldenGatesupports delivery to Oracle Exadata with EHCC compression enabled for insertoperations. In order for Replicat to apply data so that it is compressed withEHCC, you must use the INSERTAPPEND parameter for Replicat, which causesReplicat to use an APPEND hint for inserts.
(16) OracleGoldenGate supports Transparent Data Encryption (TDE) applied at the column andtablespace level. Column-level encryption is supportedfor all versions of Oracle, 11.1, and 11.2. Tablespace-levelencryption is supported for all versions of Oracle and
(17) Oracle GoldenGate supports thesynchronization of TRUNCATE statements as part of the full DDL synchronizationfeature or as standalone functionality that is independent of full DDLsynchronization. The standalone TRUNCATE feature supports the replication of TRUNCATETABLE, but no other TRUNCATE options. The full DDL feature supports TRUNCATE TABLE,ALTER TABLE TRUNCATE PARTITION, and other DDL. To avoid errors from duplicate operations,only one of these features can be active at the same time. The GETTRUNCATES parametercontrols the standalone TRUNCATE feature.
(18) Oracle GoldenGate supports thecapture of direct-load INSERTs for Oracle versions 9iR2, 10gR1, and 10gR2 andlater. Supplemental logging must be enabled, and the database must be inarchive log mode. The affected tables cannot contain LOBs if the database is9iR2 or 10gR1, but LOBs are supported for later versions. The followingdirect-load methods are supported.
1) /*+ APPEND */ hint
2)/*+ PARALLEL */ hint (Non-RAC only)

3.1.2 Limitations of support for views
(1) Oracle GoldenGate can replicate toa view as long as it is inherently updatable.
(2) Oracle GoldenGate supports capturefrom a table in the source database to an inherently updatable view in thetarget database.
(3) The structures of the table andthe view must be identical.
(4) A key must be defined on theunique columns in the view. This is done by means of a KEYCOLS clause in theMAP statements.

3.1.3 Limitations of support for materialized views
(1) Materialized views created WITHROWID are not supported.
(2) The materialized view log can becreated WITH ROWID.
(3) The source table must have aprimary key.
(4) Truncates of materialized viewsare not supported. You can use a DELETE FROM statement.
(5) Some Oracle GoldenGateinitial-load methods do not support LOBs in a materialized view.
(6) For Replicat, the materializedview must be updateable.
(7) DML (but not DDL) from a fullrefresh of a materialized view is supported for Oracle 10g and later. If DDLsupport for this feature is required, open an Oracle GoldenGate support case.

3.1.4 Limitations of support for index-organized tables
(1) IOTs are supported for Oracleversions 10.2 and later.
(2) Oracle GoldenGate supports IOTsthat are created with the MAPPING TABLE option, but it only captures changesmade to the base IOT, not changes made to the mapping table. However, Oraclewill maintain the mapping table on the target, if one is being used.
(3) IOTs that are stored in acompressed format are not supported (for example, in a
compressed tablespace).
A compressed IOTis different from an IOT that has key compression defined with the COMPRESSoption. IOTs with key compression are supported.
(4) Because an IOT does not have arowid, Oracle GoldenGate must fetch certain data types in an IOT from thedatabase. The fetch uses the key value as the row identifier, which increasesthe potential for “row not found” errors. Oracle GoldenGate provides theFETCHOPTIONS parameter to handle these errors. Data types that are fetched are:
4) XMLType
5) UDT
6) Nested table
(5) (Oracle 10g and later) TRUNCATESof an IOT where one partition is empty will not be captured.

3.1.5 Limitations of support for clustered tables
(1) Indexed and hash clusters are bothsupported.
(2) Encrypted and compressed clusteredtables are not supported.

3.2 Sequences
OracleGoldenGate supports the replication of sequence values by means of the SEQUENCEparameter. Oracle GoldenGate ensures that the target sequence values willalways be higher than those of the source (or equal to them, if the cache is0).

DDL support forsequences (CREATE, ALTER, DROP, RENAME) is compatible with, but not requiredfor, replicating sequence values. To replicate just sequence values, you do notneed to install the Oracle GoldenGate DDL support environment. You can just usethe SEQUENCE parameter.

Limitations of support for sequences
(1) The cache size and the incrementinterval of the source and target sequences must be identical.
(2) The cache can be any size,including 0 (NOCACHE).
(3) The sequence can be set to cycleor not cycle, but the source and target databases must be set the same way.
(4) To add SEQUENCE to a configurationin which DDL support is enabled, you must reinstall the Oracle GoldenGate DDLobjects in INITIALSETUP mode.

四. Non-supported objects and operations for Oracle DML
(1) REF
(2) Tablespaces and tables created oraltered with COMPRESS
(3) Synonyms
(4) Database Replay
(5) Distributed transactions
(6) XA distributed transactions
(7) Transparent Application Failover

五. Supported objects and operations forOracle DDL
All Oracle GoldenGatetopology configurations are supported for Oracle DDL replication. Active-active(bi-directional) replication of Oracle DDL is supported between two (and only two)databases that contain identical metadata.
Oracle GoldenGate supports DDL operations of up to 2 MB in size on the following objects:

The 2 MB size limitation includes packages,procedures, and functions.

The actual sizelimit of the DDL support is approximate, because the size will not only includethe statement text but also Oracle GoldenGate maintenance overhead that dependson the length of the object name, the DDL type, and other characteristics ofkeeping a DDL record internally.

六.Non-supported objects and operations forOracle DDL
6.1 Oracle-reserved schemas
The following schema names are considered Oracle-reserved and must be excluded from the OracleGoldenGate DDL configuration. Oracle GoldenGate will ignore these schemas.

6.2 Oracle recycle bin
Because of aknown issue in Oracle 10g, the Oracle recycle bin must be turned off to supportOracle GoldenGate DDL replication. If the recycle bin is enabled, the Oracle GoldenGateDDL trigger session receives implicit recycle bin DDL operations that cause thetrigger to fail.

To turn off the recyclebin:
(1) Oracle 10g Release 2 and later:Set the RECYCLEBIN initialization parameter to OFF.
(2) Oracle 10g Release 1: Set the_RECYCLEBIN initialization parameter to FALSE. Consult the Oracle 10g databasedocumentation for the correct syntax.

6.3 Other non-supported DDL
Oracle GoldenGate does not support thefollowing:
(2) DDL on nested tables.
(3) DDL that involves password-basedcolumn encryption, such as:
1) CREATE TABLE t1 ( a number, bvarchar2(32) ENCRYPT IDENTIFIED BY my_password);
2) ALTER TABLE t1 ADD COLUMN cvarchar2(64) ENCRYPT IDENTIFIED BY my_password;
(4) ALTER DATABASE and ALTER SYSTEM(these are not considered to be DDL)

七. Supported and non-supported object namesand case
The followingwill help you verify whether the name of a supported object qualifies or disqualifiesit for inclusion in an Oracle GoldenGate configuration.

Object names and owners
Source andtarget object names must be fully qualified in Oracle GoldenGate parameter files,as in fin.emp. Oracle GoldenGate supports character case as follows.

7.1 Case sensitivity
The followingare general guidelines for the case-sensitivity of object names as it relatesto Oracle GoldenGate. These guidelines may or may not apply to your databases,depending on whether the database or the underlying operating system supportscase-sensitivity.

Keep in mindthat case-sensitivity (or lack thereof) may apply to the source database but notthe target, or to the target but not the source.
(1) If thesystem or database is case-sensitive, Oracle GoldenGate supports the case sensitivityof database names, owner and schema names, object names, column names, and usernames.
(2) If thesystem or database is case-insensitive (or is configured forcase-insensitivity), Oracle GoldenGate converts all names to upper case. Theexception is Oracle 11g, where case-sensitive passwords are supported in OracleGoldenGate input that requires passwords.

To preservecase-sensitivity in an Oracle GoldenGate configuration:
In OracleGoldenGate parameter files, specify case-sensitive names exactly as they appearin the database. In TABLE and MAP parameters, enclose case-sensitive names indouble quotes if the other database (the source or target of the case-sensitiveobjects) is not casesensitive.
If replicatingfrom a case-insensitive source to a case-sensitive target, enter the source namesin upper case in the Replicat MAP statements, to reflect the fact that Extractwrites them to the trail as uppercase.
For example:

7.2 Supported characters
Oracle GoldenGate supports alphanumeric characters in object names and in the names ofkey columns and non-key columns. Oracle GoldenGate also supports the following nonalphanumericcharacters in columns that are not being used by Oracle GoldenGate as a key.

Oracle Golden Gate 系列四 — GG 安装 与 卸载 理论知识

2011-11-16 15:25:28 我来说两句 收藏 我要投稿 [字体:小 大]

在前面的几篇里讲了GG的系统需求及支持的对象类型, 在这里看下GG的安装与卸载的理论知识,这里只介绍Linux 平台的说明,其他平台的自己参看官方文档。

一.GG 安装说明

To install Oracle GoldenGate , the following steps arerequired:
(1) Downloading Oracle GoldenGate
(3) Setting library paths fordynamic builds
(4) Installing the OracleGoldenGate software
(5) Installing support for Oraclesequences
(6) (Optional) Installing OracleGoldenGate DDL support

1.1 Downloading Oracle GoldenGate
可以直接从 上下载GG.

Make certain that the ORACLE_HOME and ORACLE_SID system environment variables are set to thecorrect Oracle instance. The Oracle GoldenGate processes refer to them when connectingto the database.

To specify Oraclevariables on UNIX-based systems
(1) If there is one instance of Oracleon the system, set ORACLE_HOME and ORACLE_SID at the system level. If youcannot set them that way, use the following SETENV statements in the parameterfile of every Extract and Replicat group that will be connecting to the instance.
—如果只是一个instance,那么在系统级别设置ORACLE_HOME和ORACLE_SID,如果不能设置,可以设置GG Extract 和Replicat 组的SETENV 参数。
SETENV (ORACLE_HOME = “<path to Oraclehome location>”)

The SETENV parametersoverride the system settings and allow the Oracle GoldenGate process to set thevariables at the session level when it connects to the database.
—SETENV 参数会覆盖系统级别的设置。

(2) If there are multiple Oracleinstances on the system with Extract and Replicat processes connecting to them,you will need to use a SETENV statement in the parameter file of each processgroup and point it to the correct instance. For example, the following showsparameter files for two Extract groups, each capturing from a different Oracleinstance.
—如果有多个instance,那么就需要对每个Extract 和 Replicat进程组设置SETENV 参数。

Group 1:
SETENV (ORACLE_HOME =“/home/oracle/ora9/product”)
RMTTRAIL /home/ggs/dirdat/rt
TABLE hr.emp;
TABLE hr.salary;

Group 2:
SETENV (ORACLE_HOME =“/home/oracle/ora9/product”)
RMTTRAIL /home/ggs/dirdat/st
TABLE fin.sales;
TABLE fin.cust;

1.3 Setting library paths for dynamic builds on UNIX
Oracle GoldenGate uses shared libraries. When you install Oracle GoldenGate on a UNIX system,the following must be true before you run GGSCI or any other Oracle GoldenGate process.
—GG 需要使用shared libraries,所以在使用GG 之前,要先确保如下选项

1.3.1. When OracleGoldenGate connects to the database locally, all of the following must have thesame bit type, either all 32-bit, all 64-bit, or all IA64:
1) OracleGoldenGate version
2) Oracle library versions
3) Database versions
—如果GG 连接到本地的database,要学到以上的几种软件版本要一致。

1.3.2. When OracleGoldenGate connects through SQL*Net, the Oracle client library and the OracleGoldenGate build must match. This means that the Oracleversion, the bit type (32-bit, 64-bit, IA64) and the operating system versionall must match. If you are using the TRANLOGOPTIONS parameter with the LOGSOURCEoption and Oracle GoldenGate connects to transaction logs from a different operatingsystem, the Oracle versions must also be the same.

1.3.3. Make certain thatthe database libraries are added to the shared-library environment variables ofthe system. This procedure is usually performed atdatabase installation time. Consult your Database Administrator if you have anyquestions.
—确保数据库的library 添加到了系统的变量里。

1.3.4. If you will be running an OracleGoldenGate program from outside the Oracle GoldenGate installation directory ona UNIX system:
(1) (Optional) Add the OracleGoldenGate installation directory to the PATH environment variable.
(2)(Required) Add the OracleGoldenGate installation directory to the sharedlibraries environment variable.

For example,given an Oracle GoldenGate installation directory of /users/ogg, the second commandin the following example requires these variables to be set:
Command RequiresGG libraries in environment variable?
$ users/ogg > ./ggsci No
$ users > ./ogg/ggsci Yes

To set the variables in Korn shell
PATH=<installation directory>:$PATH
export PATH
<shared librariesvariable>=<absolute path of installation directory>:$<sharedlibraries variable>
export <shared libraries variable>

To set the variables in Bourne shell
export PATH=<installation directory>:$PATH
export <shared librariesvariable>=<absolute path of installation directory>:$<sharedlibraries variable>

To set the variables in C shell
setenv PATH <installation directory>:$PATH
setenv <shared libraries variable><absolute path of installation directory>:$<shared librariesvariable>

Where: <sharedlibraries variable> is one of the following:


To view thelibraries that are required by an Oracle GoldenGate process, use the ldd<process> shell command before starting the process. This command also showsan error message for any that are missing.

1.4 Installing Oracle GoldenGate on Linux and UNIX
1.4.1 Installing Oracle GoldenGate into a Linux or UNIX cluster
Follow these guidelines if installing intoa cluster configuration:
(1) Install the Oracle GoldenGatebinaries and files on a file system that is available to all cluster nodes,according to the directions that follow.
(2) After installing OracleGoldenGate, configure the Manager process within the cluster application, asdirected by the cluster documentation, so that Oracle GoldenGate will fail overproperly with the other applications.

1.4.2 Installing the Oracle GoldenGate files
1. Extract the Oracle GoldenGate mediapack.zipfile to the system and directory where you want Oracle GoldenGate to beinstalled.
2. Run the command shell.
3. Change directories to the new OracleGoldenGate directory.
4. From the Oracle GoldenGate directory,run the GGSCI program.
5. In GGSCI, issue the following command tocreate the Oracle GoldenGate working directories.
6. Issue the following command to exitGGSCI.

1.5 Installing support for Oracle sequences
To support Oracle sequences, you must install some database procedures. These proceduressupport the Oracle GoldenGate FLUSH SEQUENCE command, which you issue immediatelyafter you start the Oracle GoldenGate processes for the first time (typically whenyou perform the initial data synchronization procedure).

To install Oracle sequence objects
Follow these instructions on the source andtarget systems.
1. On the source and target Oracle systems,connect to SQL*Plus as SYSDBA.
2. If you already assigned a database userto support the Oracle GoldenGate DDL replication feature, you can skip thisstep. Otherwise, on both systems create a database user that can also be theDDL user.
3. From the Oracle GoldenGate installationdirectory, run GGSCI.
4. In GGSCI, issue the following command.
5. In the file, enter the GGSCHEMA parameterand specify the schema of the DDL user that you created earlier in thisprocedure.
GGSCHEMA <schema>
6. Save and close the file.
7. On both systems, run the sequence.sql scriptfrom the root of the Oracle GoldenGate installation directory. This scriptcreates some procedures for use by Oracle GoldenGate processes. (Do not runthem yourself.) You are prompted for the user information that you created inthe first step.
SQL> @sequence.sql
—在所有系统饿GG根目录下执行sequence.sql 脚本,该脚本会为GG 进程创建一些过程。
8. On the source system, grant EXECUTE privilegeon the updateSequence procedure to a database user that can be used to issuethe DBLOGIN command. Remember or record this user. You use DBLOGIN to log intothe database prior to issuing the FLUSH SEQUENCE command, which calls theprocedure.
SQL> GRANT EXECUTE on DDLuser.updateSequenceTO DBLOGINuser;
—在source 端,赋权限
9. On the target system, grant EXECUTE privilegeon the replicateSequence procedure to the Replicat database user.
SQL> GRANT EXECUTE on DDLuser.replicateSequenceTO Replicatuser;
—在target 端赋权。

1.6 Configuring Manager and other processes
To configureOracle GoldenGate to support your business requirements, It containsinstructions to:
(1) Configure the Manager processwith a TCP/IP port and other optional parameters that control dynamic portassignments, trail file maintenance, automatic startup, and other properties.
(2) Configure Extract and Replicatprocesses to support reporting, high availability, disaster recovery, and othertopologies.
(3) Configure security to controluser access, file security, and data encryption.
(4) Configure integration,manipulation, and conversion features that enable you to customize OracleGoldenGate and support the delivery of data across heterogeneous environments.
(5) Configure utilities and othertools that support Oracle GoldenGate.

二.启用GG 对DDL 操作的支持
DDL support forsequences (CREATE, ALTER, DROP, RENAME) is compatible with, but not requiredfor, replicating the sequence values themselves. To replicate just sequencevalues, you do not need to install the Oracle GoldenGate DDL support environment. You can just use the SEQUENCE parameter.

2.1 Overview of the DDL objects
To install theOracle GoldenGate DDL environment, you will be installing the database objectsshown in Table 7.
—启用DDL 需要安装以下的对象。

2.2 Oracle GoldenGate DDL objects in an Oracle standby configuration
In a physical orlogical Oracle standby configuration, the Oracle GoldenGate DDL objects arepropagated by the Oracle system (along with the other changes) from the primaryserver to the standby server. The Oracle GoldenGate DDL trigger will performits function on either the primary server or the logical standby server, butnot on a physical standby server, and only if the mode of operation on theserver is READ WRITE. On a physical standby, Oracle GoldenGate DDL objects arenot active.
If DDLreplication by Oracle GoldenGate will not be used on a logical standby server,you can disable the DDL trigger there after it has been installed and enabledon the primary server. If the logical standby server will be used as a sourceof DDL replication, however, the trigger must be enabled.

2.3 Installing the DDL objects
1. Choose an Oracle GoldenGate schema oranother schema for the DDL objects.

2. Grant the following permission on theOracle GoldenGate schema.
GRANT EXECUTE ONutl_file TO <schema>;

3. Choose a tablespace for the DDL objectsthat can accommodate the growth of the GGS_DDL_HIST and GGS_MARKER tables. The GGS_DDL_HISTtable, in particular, will grow in proportion to overall DDL activity. If thetablespace that contains these objects fills up, no DDL operations can beissued on the database, and the business applications will pause.
—选择一个存放DDL 表的tablespace。

4. Open the GLOBALS file in the homedirectory of this instance of Oracle GoldenGate. If a GLOBALS file does notexist, create one. For information on creating or editing a GLOBALS file, seethe Oracle GoldenGate Windows and UNIX Administrator’s Guide.

5. Specify the name of the DDL schema byadding the following parameter to the GLOBALS file.
GGSCHEMA <schema_name>
—指定DDL 的用户

6. (Optional) To change the names of otherobjects listed in Table 7, the changes must be made now, before proceeding withthe rest of the installation. Otherwise, you will need to stop OracleGoldenGate DDL processing and reinstall the DDL objects. It is recommended thatyou accept the default names of the database objects. To change any name inTable 7 (except the schema), do one or both of the following:
—在table 7里列了DDL 需要的对象名称,如果需要修改这些对象的默认名称,按以下方式来操作:
(1) Record all name changes in the params.sqlscript. Edit this script and change the appropriate parameters. Do not run thisscript.
(2) List the names shown in Table 8 inthe GLOBALS file. The correct parameters to use are listed in the Parameter columnof the table.

7. Change directories to the OracleGoldenGate installation directory.

8. Exit all Oracle sessions, includingthose of SQL*Plus, those of business applications, those of the OracleGoldenGate processes, and those of any other software that uses Oracle. Preventthe start of any new sessions.

9. Run SQL*Plus and log in as a user thathas SYSDBA privilege. This privilege is required to install the DDL trigger inthe SYS schema, which is required by Oracle. All other DDL objects areinstalled in the schema that you created in step 1.

10. Run the marker_setup.sql script.
(1) Supply the name of the OracleGoldenGate schema when prompted, and then press Enter to execute the script.
(2) This script installs support forthe Oracle GoldenGate DDL marker system.

11. Run the ddl_setup.sql script.

You are prompted to:
(1) Disable the Oracle recycle bin ifthe database is Oracle 10g.
(2) Stop current Oracle GoldenGate DDLreplication.
(3) Specify the name of the DDL schemafrom step 1.
(4) Specify the installation mode: Toinstall DDL objects the first time, use the INITIALSETUP mode.

INITIALSETUPmode assumes that no Oracle GoldenGate DDL objects exist and drops them if theydo. If the DDL objects exist and you want to reinstall them, but
preserve any DDL history, use the procedurein “Restoring an existing DDL environment to a clean state” on page 68.

12. Run the role_setup.sql script.
(1) At the prompt, supply the DDLschema name.
(2) The script drops and creates therole that is needed for DDL synchronization, and it grants DML permissions onthe Oracle GoldenGate DDL objects.

13. Grant the role that was created(default name is GGS_GGSUSER_ROLE to all Oracle GoldenGate Extract users. Youmay need to make multiple grants if the processes have different user names.
GRANT<role> TO <user>;

14. Run the ddl_enable.sql script to enablethe DDL trigger.

To install and use the optional performance tool
To improve theperformance of the DDL trigger, make the ddl_pin script part of the database startup.It must be invoked with the Oracle GoldenGate DDL user name, as in:
@ddl_pin <DDL_user>
This script pinsthe PL/SQL package that is used by the trigger into memory. If executing thisscript from SQL*Plus, connect as SYSDBA from the Oracle GoldenGate installationdirectory. This script relies on the Oracle dmbs_shared_pool system package, soinstall that package before using ddl_pin.


Uninstalling Oracle GoldenGate from Linux or UNIX
1. Run the command shell.
2. (Suggested) Log on as the systemadministrator, or as a user with permission to issue Oracle GoldenGatecommands, and to delete files and directories from the operating system.
3. Change directories to the OracleGoldenGate installation directory.
4. Run GGSCI.
5. Stop all Oracle GoldenGate processes.
6. Stop the Manager process.
7. Exit GGSCI.
8. Remove the Oracle GoldenGate files byremoving the installation directory.
9. Drop any Oracle GoldenGate-relatedobjects from the database as needed.

Oracle Golden Gate 系列五 — GG 使用配置 说明

2011-11-16 15:26:59 我来说两句 收藏 我要投稿 [字体:小 大]

一. Preparing the database for Oracle GoldenGate
1.1 Preparing constraints for Oracle GoldenGate
The followingtable attributes must be addressed in an Oracle GoldenGate environment.

1.1.1 Disabling triggers and cascade constraints
You will need to make some changes to the triggers, cascade update, and cascade delete constraintson the target tables. Oracle GoldenGate replicates DML that results from a triggeror a cascade constraint. If the same trigger or constraint gets activated onthe target table, it becomes redundant because of the replicated version, andthe database returns an error.
—在target table上,需要禁用triggers或者cascadeconstraints,因为source 上会将这些改变同步过去,如果在target 端在做一次就会报错,下面的示例使整个流程:
Consider the following example, where the source tables are “emp_src” and “salary_src” and the target tables are “emp_targ” and “salary_targ.”
1. A delete is issued for emp_src.
2. It cascades a delete to salary_src.
3. Oracle GoldenGate sends both deletes tothe target.
4. The parent delete arrives first and isapplied to emp_targ.
5. The parent delete cascades a delete tosalary_targ.
6. The cascaded delete from salary_src isapplied to salary_targ.
7. The row cannot be located because it wasalready deleted in step 5.

Oracle GoldenGate provides some options to handle triggers or cascade constraints automatically,depending on the Oracle version:
—GG 提供了选选项自动处理triggers 或者 cascade constraints,不同的版本,方法也不一样。
(1) For Oracle10.2.0.5 and later patches to, and for Oracle and later 11gR2 versions, you can use the Replicat parameter DBOPTIONS with the SUPPRESSTRIGGERS option to cause Replicat to disable the triggers during its session.
(2) For Oracle9.2.0.7 and later, you can use the Replicat parameter DBOPTIONS with the DEFERREFCONSToption to delay the checking and enforcement of cascade update and cascadedelete constraints until the Replicat transaction commits.
(3) For earlier Oracle versions, you must disable triggers and integrity constraints or alter themmanually to ignore the Replicat database user.

1.1.2 Deferring constraint checking
If constraintsare DEFERRABLE on the source, the constraints on the target must also be DEFERRABLE.You can use one of the following parameter statements to defer constraint checkinguntil a Replicat transaction commits:
—如果source 端的约束是deferrable(延时)的,那么target端也必须是deferrable的。
(1) Use SQLEXEC at the root level ofthe Replicat parameter file to defer the constraints for an entire Replicatsession.
—使用SQLEXEC设置这个Replicat session的defer 属性
SQLEXEC (“altersession set constraint deferred”)
(2) For Oracle and later, youcan use the Replicat parameter DBOPTIONS with the DEFERREFCONST option to delayconstraint checking for each Replicat transaction.
— 之后可以通过DBOPTIONS参数的DEFERREFCONST选项来设置delay constraint checking。

Replicat mightneed to set constraints to DEFERRED if it is possible that an update transactioncould affect the primary keys of multiple rows. Called a transient primary key updatein Oracle GoldenGate terminology, this kind of operation typically uses an x+n formulaor other form of manipulation that shifts the values and causes a new value tobe the same as an old one.
The followingillustrates a sequence of value changes that can cause this condition if constraintsare not deferred. The example assumes the primary key column is “CODE” and thecurrent key values (before the updates) are 1, 2, and 3.
update item set code = 2 where code = 1;
update item set code = 3 where code = 2;
update item set code = 4 where code = 3;

In this example,when Replicat applies the first update to the target, there is an error becausethe key value of 2 already exists in the table. The Replicat transactionreturns constraint violation errors. By default,Replicat does not handle these violations and abends.
—上面的示例演示了deferred 的影响,如果不设置,Replicat 事务会报错,而且在默认情况下Replicat 不会处理这种异常。

To enable Replicat tomanage these updates:
—启用Replicat管理以上的update 情况:
(1) Use the Replicat parameter HANDLETPKUPDATE to enable Replicat to handle the transient primary key updates.
(2) Create the constraints as DEFERRABLE INITIALLY IMMEDIATE on the target tables. The constraints arechecked when Replicat commits the transaction. You can:
1) Use SQLEXEC at the root level of the Replicat parameter file todefer the constraints for an entire Replicat session.
SQLEXEC (“alter session set constraintdeferred”)
2) For Oracle and later, you can use the Replicat parameterDBOPTIONS with the DEFERREFCONST option to delay constraint checking for eachReplicat transaction. If constraints are not DEFERRABLE, Replicat handles theerrors according to rules that are specified with the HANDLECOLLISIONS andREPERROR parameters, if they exist, or else it abends.

1.1.3 Assigning row identifiers
Oracle GoldenGate requires some form of unique row identifier on the source and targettables to locate the correct target rows for replicated updates and deletes. How Oracle GoldenGate determines the kind of row identifier to use
Unless a KEYCOLS clause is used in the TABLE or MAP statement, Oracle GoldenGate automatically selectsa row identifier to use in the following order of priority:
1. Primary key
2. First uniquekey alphanumerically with no virtual columns, no UDTs, no functionbased columns,and no nullable columns
3. First uniquekey alphanumerically with no virtual columns, no UDTs, and no functionbased columns,but can include nullable columns
4. If none of the preceding key types exist (even though there might be other types of keys definedon the table) Oracle GoldenGate constructs a pseudo key of all columns that thedatabase allows to be used in a unique key, excluding virtual columns, UDTs, function-basedcolumns, and any columns that are explicitly excluded from the Oracle GoldenGateconfiguration.

Depending on whether schema-level or table-level logging was activated, there might be just one key or multiple keys logged to the redo log.

If there are other, non-usable keys on a table or if there are no keys at all on the table,Oracle GoldenGate logs an appropriate message to the report file. Constructinga key from all of the columns impedes the performance of Oracle GoldenGate onthe source system. On the target, this key causes Replicat to use a larger,less efficient WHERE clause. Using KEYCOLS tospecify a custom key
If a table does not have an appropriate key, or if you prefer the existing key(s) not to be used,you can define a substitute key if the table has columns that always containunique values. You define this substitute key by including a KEYCOLS clausewithin the Extract TABLE parameter and the Replicat MAP parameter. The specified key will override any existing primary or unique key that OracleGoldenGate finds.

1.1.4 Configuring the database to log key values
GGSCI provides commands to configure the source database to log the appropriate key values whenever it logs a row change, so that they are available to Oracle GoldenGate in the redo record. By default, the database only logs column values that arechanged. The appropriate command must be issued before you start OracleGoldenGate processing.
—GGSCI 可以配置source database 上写入log的内容,在默认情况下只log 变化的列值,在启动GG 进程之前需要发布合适的命令来控制log内容。 ADD TRANDATA
The ADD TRANDATA command enables table-level logging and is generally appropriate if you willnot be using the Oracle GoldenGate DDL replication feature, or if you want to use that feature and your data meets certain requirements documented for this command in the Windows and UNIX Reference Guide. ADD SCHEMATRANDATA
The ADD SCHEMATRANDATA command enables schema-level logging. It logs more key values to the redo log than ADD TRANDATA does, and it affects all of the current and future tables of a given schema. Because ADD SCHEMATRANDATA logs key values atomically when each DDL operation occurs, it is the preferred logging method to use if you will be using the Oracle GoldenGate DDL replication feature. (If thedatabase system can tolerate the extra redo data, you can also use ADDSCHEMATRANDATA without using the DDL replication feature.)

To initiate the logging of key values
1. On the source system, run GGSCI from theOracle GoldenGate directory.
2. In GGSCI, issue the following command tolog on to the database.
Where:<user> is a database user who has the privilege to enable table-level orschemalevel supplemental logging, depending on the logging command that youwill be choosing from Table 9, and <password> is that user’s password.

4. Log in to SQL*Plus as a user with ALTERSYSTEM privilege, and then issue the following command to enable minimalsupplemental logging at the database level. This logging is required to processupdates to primary keys and chained rows.
5. To start the supplemental logging,switch the log files.
6. Verify that supplemental logging isenabled at the database level with this command:
(1) For Oracle 9i, the output must beYES.
(2) For Oracle 10g, the output must beYES or IMPLICIT.

7. If using ADD TRANDATA with the COLSoption, create a unique index for those columns on the target to optimize rowretrieval. If you are logging those columns as a substitute key for a KEYCOLSclause, make a note to add the KEYCOLS clause to the TABLE and MAP statementswhen you configure the Oracle GoldenGate processes.

1.1.5 Limiting row changes in tables that do not have a key
If a target table does not have a primary key or a unique key, duplicate rows can exist. In this case, Oracle GoldenGate could update or delete too many target rows,causing the source and target data to go out of synchronization without error messages to alert you.
To limit the number of rows that are updated, use the DBOPTIONS parameter with the LIMITROWS option in the Replicat parameter file. LIMITROWS can increase the performance of Oracle GoldenGate on the target system because only one row is processed.

1.2 Configuring character sets
To ensure accurate character representation from one database to another, the following mustbe true:
(1) The character set of the targetdatabase must be a superset of the character set of the source database.
(2) If your client applications usedifferent character sets, the database character set must be a superset of thecharacter sets of the client applications. In this configuration, every characteris represented when converting from a client character set to the database characterset.

1.2.1 To view globalization settings
To determine the globalization settings of the database and whether it is using byte or character semantics, use the following commands in SQL*Plus:

1.2.2 To view globalization settings from GGSCI
The VIEW REPORT<group> command in GGSCI shows the current database language and charactersettings and indicates whether or not NLS_LANG is set.

1.2.3 To set NLS_LANG
1. Set the NLS_LANG parameter according to the documentation for your database version and operating system. On UNIX systems, you can set NLS_LANG through the operating system or by using a SETENV parameter in the Extract and Replicat parameter files. For best results, set NLS_LANG from the parameter file, where it is less likely to be changed than at the system level.
NLS_LANG must beset in the format of:

This is an example in UNIX, using the SETENV parameter in the Oracle GoldenGate parameterfile:

2. Stop and thenstart the Oracle GoldenGate Manager process so that the processes recognize thenew variable.
OracleGoldenGate reports Oracle error messages in U.S. English (AMERICAN_AMERICA),regardless of the actual character set of the reporting database. OracleGoldenGate performs any necessary language conversion internally withoutchanging the language configuration of the database.

1.3 Adjusting cursors
The Extract process maintains cursors for queries that fetch data and also for SQLEXEC operations.Without enough cursors, Extract must age more statements. Extract maintains as many cursors as permitted by the Extract MAXFETCHSTATEMENTS parameter. You can increase the value of this parameter as needed. Make an appropriate adjustment to the maximum number of open cursors that are permitted by the database.

1.4 Setting fetch options
To process certain update records from the redo log, Oracle GoldenGate fetches additional rowdata from the source database. Oracle GoldenGate fetches data for the following:
(1) Operations that contain LOBs.(Fetching of LOBs does not apply to Oracle 10g and later databases, becauseLOBs are captured from the redo log of those versions.)
(2) User-defined types
(3) Nested tables
(4) XMLType objects

By default,Oracle GoldenGate uses Flashback Query to fetch the values from the undo (rollback) tablespaces. That way, Oracle GoldenGate can reconstruct a read-consistent row imageas of a specific time or SCN to match the redo record.
—默认情况下,GG 使用Flashback query 从undo 里fetch values。

To configure the database for best fetch results
For best fetch results, configure thesource database as follows:
—为了更好的进行fetch,在source database 进行如下配置:
1. Set a sufficient amount of redoretention by setting the Oracle initialization parameters UNDO_MANAGEMENT andUNDO_RETENTION as follows (in seconds).
UNDO_RETENTION can be adjusted upward in high-volume environments.

2. Calculate the space that is required inthe undo tablespace by using the following formula.
<undospace> = <UNDO_RETENTION> * <UPS> + <overhead>
(1) <undo space> is the numberof undo blocks.
(2) <UNDO_RETENTION> is thevalue of the UNDO_RETENTION parameter (in seconds).
(3) <UPS> is the number of undoblocks for each second.
(4) <overhead> is the minimaloverhead for metadata (transaction tables, etc.).

Use the system view V$UNDOSTAT to estimate<UPS> and <overhead>.

3. For tables that contain LOBs, do one of the following:
(1) Set the LOB storage clause toRETENTION. This is the default for tables that are created when UNDO_MANAGEMENTis set to AUTO.
—lob 存储设置为retention,那么UNDO_MANAGEMENT 设置为auto。
(2) If usingPCTVERSION instead of RETENTION, set PCTVERSION to an initial value of 25. You can adjust it based on the fetch statistics that are reportedwith the STATS EXTRACT command (see Table 10). If the value of theSTAT_OPER_ROWFETCH CURRENTBYROWID or STAT_OPER_ROWFETCH_CURRENTBYKEY field inthese statistics is high, increase PCTVERSION in increments of 10 until thestatistics show low values.
—如果使用PCTVERSION,那么该值设为25. LOB中PCTVERSION 和RETENTION的区别,参考我的blog:
Oracle LOB 详解

4. Grant the following privileges to theOracle GoldenGate Extract user:
Or …
GRANT FLASHBACKON <owner.table> TO <db_user>

Oracle GoldenGate provides the following parameters to manage fetching.

1.5 Replicating TDE-encrypted data
Oracle GoldenGate supports the Transparent Data Encryption (TDE) at the column and tablespace level.
(1) Column-level encryption issupported for all versions of, 11.1, and 11.2.
(2) Tablespace-level encryption issupported for all versions of and

1.5.1 Required database patches
To support TDE,one of the following Oracle patches must be applied to the database,dependingon the version.
(1) Patch 10628966 for10.
(2) Patch 10628963 for11.
(3) Patch 10628961 for

1.5.2 Overview of TDE support
TDE support involves two kinds of keys:
(1) The encrypted key can be a tablekey (column-level encryption), an encrypted redo log key (tablespace-levelencryption), or both. A key is shared between the Oracle server and Extract.
(2) The decryption key is a passwordknown as the shared secret that is stored securely in both domains. Only aparty that has possession of the shared secret can decrypt the table and redolog keys.

The encrypted keys are delivered to the Extract process by means of built-in PL/SQL code. Extract uses the shared secret to decrypt the data. Extract never handles the walletMaster Key itself, nor is it aware of the Master Key password. Those remainwithin the Oracle server security framework.
Extract neverwrites the decrypted data to any file other than a trail file, not even adiscard file (specified with the DISCARDFILE parameter). The word “ENCRYPTED”will be written to any discard file that is in use.
The impact of this feature on Oracle GoldenGate performance should mirror that of the impactof decryption on database performance. Other than a slight increase in Extract startuptime, there should be a minimal affect on performance from replicating TDEdata.

1.5.3 Requirements for replicating TDE
(1) If DDL will ever be performed onan encrypted table, or if table keys will ever be rekeyed, you must eitherquiesce the table while the DDL is performed or enable Oracle GoldenGate DDLsupport. It is more practical to have the DDL environment active so that it isready, because a re-key usually is a response to a security violation and must beperformed immediately. To install the Oracle GoldenGate DDL environment, see theinstructions in this guide.
(2) To maintain high securitystandards, the Oracle GoldenGate Extract process should run as part of theOracle User (the user that runs the Oracle Server). That way, the keys areprotected in memory by the same privileges as the Oracle User.
(3) The Extract process must run onthe same machine as the database installation.

1.5.4 Recommendations for replicating TDE
Extract decryptsthe TDE data and writes it to the trail as clear text. To maintain data securitythroughout the path to the target tables, it is recommended that you alsodeploy Oracle GoldenGate security features to:
(1) encrypt the data in the trails
(2) encrypt the data in transitacross TCP/IP

1.5.5 Configuring TDE support
The followingoutlines the steps that the Oracle Security Officer and the Oracle GoldenGateAdministrator take to establish communication between the Oracle server and theExtract process. Oracle SecurityOfficer and Oracle GoldenGate Administrator
Agree on ashared secret (password) that meets or exceeds Oracle password standards. Thispassword must not be known by anyone else. Oracle Security Officer
1. Issue thefollowing MKSTORE command to create an “ORACLEGG” entry in the Oracle wallet.ORACLEGG must be the name of the key. Do not supply the shared secret on the commandline; instead, supply it when prompted.
Enter <secret>
2. (Oracle RAC10gR2 and 11gR1) Copy the wallet that contains the shared secret to each node,and then reopen the wallets.

With Oracle11gR2, there is one wallet in a shared location, with synchronized access among all nodes. Oracle GoldenGate Administrator
1. Compile thedbms_internal_cklm.plb package that is installed in the Oracle GoldenGate installationdirectory.
2. Grant EXECprivilege on the dbms_internal_cklm.get_key procedure to the Extract database user.This procedure facilitates sharing of the encrypted keys between the Oracle Serverand Extract.
3. Run GGSCI andissue the ENCRYPT PASSWORD command to encrypt the shared secret so that it isobfuscated within the Extract parameter file. This is a security requirement.
ENCRYPT PASSWORDtakes the clear-text string as input and provides options for encrypting itwith an Oracle GoldenGate-generated default key or a user-defined key that isstored in a secure local ENCKEYS file. For instructions, see the securitychapter of the Oracle GoldenGate Windows and UNIX Administrator’s Guide.
4. In theExtract parameter file, use the DBOPTIONS parameter with the DECRYPTPASSWORD option.As input, supply the encrypted shared secret and the Oracle GoldenGategeneratedor user-defined decryption key. For syntax options, see the Oracle GoldenGateWindows and UNIX Reference Guide.
5. Close, andthen open, the Oracle wallet before you start Extract. This step works aroundissues with caching that can cause an ORA-28360 (security module) error.
Close and thenopen the wallet whenever a shared secret is created or changed.

1.5.6 Changing the Oracle shared secret
Use this procedure to change the shared secret that supports Oracle Transparent Data Encryption.You can change the shared secret when needed, but “ORACLEGG” must remain thename of the key.
1. Stop the Extract process.

2. Issue the following MKSTORE command tomodify the "ORACLEGG" entry in the Oracle wallet. Do not supply thenew shared secret on the command line; instead, supply it when prompted.
Enter <secret>
To change the shared secret, the parameter 'modifyEntry' is used instead of “createEntry,”because you are modifying an existing wallet entry.

3. Use the ENCRYPT PASSWORD command inGGSCI to encrypt the new shared secret. For instructions, see the securitychapter of the Oracle GoldenGate Windows and UNIX Administrator’s Guide.

4. Replace the old encrypted shared secretand decryption key with the new ones in the Extract parameter file by modifyingthe DECRYPTPASSWORD option of DBOPTIONS. For syntax options, see the OracleGoldenGate Windows and UNIX Reference Guide.

5. Close, and then open, the Oracle walletbefore you start Extract. This process works around issues with caching thatcan cause an ORA-28360 error.

6. Start Extract.

1.6 Ensuring correct handling of Oracle Spatial objects
To replicate georaster tables (tables that contain one or more columns of SDO_GEORASTER objecttype), follow these instructions to configure Oracle GoldenGate to process themcorrectly.

1.6.1 Mapping the georaster tables
You must createa TABLE statement and a MAP statement for the georaster tables and also for therelated raster data tables.

1.6.2 Sizing the XML memory buffer
Evaluate yourspatial data before starting Oracle GoldenGate processes. If the METADATA attributeof the SDO_GEORASTER data type in any of the values exceeds 1 MB, you must increasethe size of the memory buffer that stores the embedded SYS.XMLTYPE attribute ofthe SDO_GEORASTER data type. If the data exceeds the buffer size, Extractabends. The size of the XML buffer is controlled by the DBOPTIONS parameterwith the XMLBUFSIZE option.

1.6.3 Handling triggers on the georaster tables
Every georastertable has a trigger that affects the raster data table. To ensure the integrityof the target georaster tables, do the following:
(1) Keep the trigger enabled on bothsource and target to ensure consistency of the spatial data.
(2) Use the REPERROR option of the MAPparameter to handle “ORA-01403 No data found” errors.

The error iscaused by redundant deletes on the target. When a row in the source georaster tableis deleted, the trigger cascades the delete to the raster data table. Bothdeletes are replicated. The replicated parent delete triggers the cascaded(child) delete on the target.
When thereplicated child delete arrives, it is redundant and generates the error.

To handle redundant deletes with REPERROR
1. Use a REPERROR statement in each MAPstatement that contains a raster data table.
2. Use Oracle error 1403 as the SQL error.
3. Use any of the response options as theerror handling.
See the following examples for ways you canconfigure the error handling.

A sufficient way to handle the errors is simply to use REPERROR with DISCARD to discard the cascadeddelete that triggers them. The trigger on the target georaster table performsthe delete to the raster data table, so the replicated one is not needed.
MAP geo.st_rdt,TARGET geo.st_rdt, REPERROR (-1403, DISCARD) ;

If you need tokeep an audit trail of the error handling, use REPERROR with EXCEPTION to invokeexceptions handling. For this, you create an exceptions table and map thesource raster data table twice:
(1) once to the actual targetraster data table (with REPERROR handling the 1403 errors).
(2) again to the exceptions table,which captures the 1403 error and other relevant information by means of aCOLMAP clause.

When usingexceptions handling like this, you must use the ALLOWDUPTARGETMAP parameter tokeep Replicat from abending on the dual source mapping.
This example provides a Replicat parameter file that contains the required parameters, andit provides a sample script that creates an exceptions table. Note that a macrois used in the parameter file to populate the TARGET and COLMAP portions of theexceptions MAP statements. The required INSERTALLRECORDS and EXCEPTIONSONLYparameters are also included in the macro. The macro eliminates the need totype the same information over again for each of the MAP statements.

Replicat parameter file
DISCARDFILE./dirrpt/rgeoras.dsc, purge
— Thisstarts the macro
, TARGETgeo.exceptions
, COLMAP( rep_id = "1"
,table_name = @GETENV ("GGHEADER", "TABLENAME")
,dberrmsg = @GETENV ("LASTERR", "DBERRMSG")
, optype= @GETENV ("LASTERR", "OPTYPE")
,errtype = @GETENV ("LASTERR", "ERRTYPE")
, logrba= @GETENV ("GGHEADER", "LOGRBA")
,logposition = @GETENV ("GGHEADER", "LOGPOSITION")
,committimestamp = @GETENV ("GGHEADER", "COMMITTIMESTAMP")
— Thisends the macro
Mapping of regular and georaster tables. Requires no exception handling.
Replicat abends on errors, which is its default error handling.
MAPgeo.blob_table, TARGET geo.blob_table ;
MAPgeo.georaster_table, TARGET geo.georaster_table ;

MAPgeo.georaster_table2, TARGET geo.georaster_table2 ;
MAPgeo.georaster_tab1, TARGET geo.georaster_tab1 ;
MAPgeo.georaster_tab2, TARGET geo.georaster_tab2 ;
MAPgeo.mv_georaster_table1, TARGET geo.mv_georaster_table1 ;
— Mapping of rasterdata tables. Requires exception handling for 1403 errors.
MAPgeo.st_rdt_3_table, TARGET geo.st_rdt_3_table, REPERROR (-1403, EXCEPTION)
MAPgeo.st_rdt_3_table #exception_handling()
MAP geo.rdt_1_table,TARGET geo.rdt_1_table, REPERROR (-1403, EXCEPTION) ;
MAP geo.rdt_1_table#exception_handling()
MAP geo.rdt_2_table,TARGET geo.rdt_2_table, REPERROR (-1403, EXCEPTION) ;
MAP geo.rdt_2_table#exception_handling()
MAPgeo.mv_rdt_1_table, TARGET geo.mv_rdt_1_table, REPERROR (-1403, EXCEPTION)
MAPgeo.mv_rdt_1_table #exception_handling()

Sample script that creates an exceptions table
drop tableexceptions
create tableexceptions
( rep_id number
, table_namevarchar2(61)
, errno number
, dberrmsgvarchar2(4000)
, optypevarchar2(20)
, errtypevarchar2(20)
, logrba number
, logposition number
, committimestamptimestamp
When using anexceptions table for numerous tables, someone should monitor its growth.

1.7 Replicating TIMESTAMP with TIME ZONE
Oracle GoldenGate supports the capture and replication of TIMESTAMP WITH TIME ZONE asa UTC offset (TIMESTAMP '2011-01-01 8:00:00 -8:00') but abends on TIMESTAMPWITH TIME ZONE as TZR (TIMESTAMP '2011-01-01 8:00:00 US/Pacific') by default.
To support TIMESTAMP WITH TIME ZONE as TZR, use the Extract parameter TRANLOGOPTIONS with oneof the following:
(1) INCLUDEREGIONID to replicateTIMESTAMP WITH TIME ZONE as TZR from an Oracle source to anOracle target of thesame version or later.
(2) INCLUDEREGIONIDWITHOFFSET toreplicate TIMESTAMP WITH TIMEZONE as TZR from an Oraclesource that is at leastv10g to an earlier Oracle target, or to a non-Oracle target.

These options allow replication to Oracle versions that do not support TIMESTAMP WITH TIME ZONEas TZR and to database systems that only support time zone as a UTC offset.

Oracle GoldenGate does not support TIMESTAMP WITH TIME ZONE as TZR for initial loads,situations where the column must be fetched from the database, or for theSQLEXEC feature. In these cases, the region ID is converted to a time offset bythe Oracle database when the column is selected. Replicat replicates the columndata as date and time data with a time offset value.

1.8 Controlling Replicat COMMIT options on an Oracle target
When an onlineReplicat group is configured to use a checkpoint table (recommended), it takes advantageof the asynchronous COMMIT feature that was introduced in Oracle 10gR2.
When applying atransaction to the Oracle target, Replicat includes the NOWAIT option in theCOMMIT statement. This improves performance by allowing Replicat to continue processingimmediately after applying the COMMIT, while the database engine logs the transactionin the background.
The checkpointtable supports data consistency with asynchronous COMMITs because it makes theReplicat checkpoint part of the Replicat transaction itself. The checkpointeither succeeds with, or fails with, that transaction. Asynchronous COMMIT isalso the default for initial loads and batch processing.
You can disablethe default asynchronous COMMIT behavior by using the DBOPTIONS parameter with theDISABLECOMMITNOWAIT option in the Replicat parameter file. If a checkpoint table is not used for a Replicat group, the checkpoints are maintained in a fileon disk, and Replicat uses the synchronous COMMIT option by default (COMMIT with WAIT), which forces Replicat to wait until the transaction is loggedbefore it can continue processing. This prevents inconsistencies that canresult after a database failure, where the state of the transaction that is recorded in the checkpoint file might be different than its state after therecovery.

1.9 Supporting delivery to Oracle Exadata with EHCC compressed data
OracleGoldenGate supports delivery to Oracle Exadata with Hybrid Columnar Compression(EHCC) enabled for insert operations. To ensure that this data is applied
correctly, use the INSERTAPPEND parameterin the Replicat parameter file. INSERTAPPEND causes Replicat to use an APPENDhint for inserts. Without this hint, the record will be inserted uncompressed.

Capture from Exadata is not supported at this time.

1.10 Managing LOB caching on a target Oracle database
Replicat writesLOB data to the target database in fragments. To minimize the effect of thisI/O on the system, Replicat enables Oracle’s LOB caching mechanism, caches the fragmentsin a buffer, and performs a write only when the buffer is full. For example, ifthe buffer is 25,000 bytes in size, Replicat only performs I/O four times givena LOB of 100,000 bytes.
(1) To optimize the buffer size tothe size of your LOB data, use the DBOPTIONS parameter with the LOBWRITESIZE<size> option. The higher the value, the fewer the I/O calls made byReplicat to write one LOB.
(2) To disable Oracle’s LOBcaching, use the DBOPTIONS parameter with the DISABLELOBCACHING option. WhenLOB caching is disabled, whatever is sent by Replicat to Oracle in one I/O callis written directly to the database media.

1.11 Additional requirements for Oracle RAC
This topiccovers additional configuration requirements that apply when Oracle GoldenGatewill be operating in an Oracle Real Application Clusters (RAC) environment.

1.11.1 General requirements
(1) All nodes in the RAC cluster musthave synchronized system clocks. The clocks must be synchronized with the clockon the system where Extract is executed. Oracle GoldenGate compares the time ofthe local system to the commit timestamps to make critical decisions. Forinformation about synchronizing system clocks, consult or yoursystems administrator.
(2) All nodes in the cluster must havethe same COMPATIBLE parameter setting.
The following table shows some OracleGoldenGate parameters that are of specific benefitin Oracle RAC.

1.11.2 Special procedures on RAC
(1) If the primary database instanceagainst which Oracle GoldenGate is running stops or fails for any reason,Extract abends. To resume processing, you can restart the instance or mount theOracle GoldenGate binaries to another node where the database is running andthen restart the Oracle GoldenGate processes. Stop the Manager process on theoriginal node before starting Oracle GoldenGate processes from another node.
(2) Whenever the number of redothreads changes, the Extract group must be dropped and re-created.
(3) To write SQL operations to thetrail, Extract must verify that there are no other operations from other RACnodes that precede the ones in the redo log that it is reading. For example, ifa log contains operations that were performed from 1:00 a.m. to 2:00 a.m., andthe log from Node 2 contains operations that were performed from 1:30 a.m. to2:30 a.m., then only the operations up to, and including, the 2:00 a.m. one canbe moved to the server where the main Extract is coordinating the redo data. Extractmust ensure that there are no more operations between 2:00 a.m. and 2:30a.m.that need to be captured.
(4) In active-passive environments,the preceding requirement means that you might need to perform some operationsand archive log switching on the passive node to ensure that operations fromthe active node are passed to the passive node. This eliminates any issues thatcould arise from a slow archiver process, failed network links, and other latencyissues caused by moving archive logs from the Oracle nodes to the server where themain Extract is coordinating the redo data.
(5) To process the last transaction ina RAC cluster before shutting down Extract, insert a dummy record into a sourcetable that Oracle GoldenGate is replicating, and then switch log files on allnodes. This updates the Extract checkpoint and confirms that all availablearchive logs can be read. It also confirms that all transactions in those archivelogs are captured and written to the trail in the correct order.

1.12 Additional requirements for ASM
This topiccovers additional configuration requirements that apply when Oracle GoldenGateoperates in an Oracle Automatic Storage Management (ASM) instance.

1.12.1 Ensuring ASM connectivity
To ensure thatthe Oracle GoldenGate Extract process can connect to an ASM instance, do thefollowing.
(1) List the ASM instance in thetnsnames.ora file. The recommended method for connecting to an ASM instancewhen Oracle GoldenGate is running on the database host machine is to use abequeath (BEQ) protocol.
A BEQ connectiondoes not work when using a remote Extract configuration. In that case,configure TNSNAMES with the TCP/IP protocol.

(2) If using the TCP/IP protocol,verify that the Oracle listener is listening for new connections to the ASMinstance. The listener.ora file must contain an entry similar to the following.
(ORACLE_HOME= /u01/app/grid)
TheBEQ protocol does not require a listener.

1.12.2 Optimizing the ASM connection
Use theTRANLOGOPTIONS parameter with the DBLOGREADER option in the Extract parameter fileif the ASM instance is one of the following versions:
(1) Oracle or later 10g R2versions
(2) Oracle or later 11g R2versions

A newer ASM APIis available in those releases (but not in Oracle 11g R1 versions) that usesthe database server to access the redo and archive logs. When used, this APIenables Extract to use a read buffer size of up to 4 MB in size. A largerbuffer may improve the performance of Extract when redo rate is high. You canuse the DBLOGREADERBUFSIZE option of TRANLOGOPTIONS to specify a buffer size.

二.Preparing DBFS for active-activepropagation with Oracle GoldenGate
2.1 Supported operations and prerequisites
Oracle GoldenGate for DBFS supports the following:
(1) Supported DDL (like TRUNCATE or ALTER) on DBFS objects except for CREATE statements on the DBFS objects. CREATE onDBFS must be excluded from the configuration, as must any schemas that willhold the created DBFS objects. The reason to exclude CREATES is that themetadata for DBFS must be properly populated in the SYS dictionary tables (whichitself is excluded from Oracle GoldenGate capture by default).
(2) Capture and replication of DML onthe tables that underlie the DBFS filesystem.

The procedures that follow assume that Oracle GoldenGate is configured properly to support active-activeconfiguration. This means that it must be:
(1) Installed according to theinstructions in this guide.
(2) Configured according to theinstructions in the Oracle GoldenGate Windows and UNIX Administrator’s Guide.

2.2 Applying the required patch
Apply the OracleDBFS patch for bug-9651229 on both databases. To determine if the patch isinstalled, run the following query:
connect / as sysdba
select procedure_name from dba_procedures
where object_name = 'DBMS_DBFS_SFS_ADMIN'
and procedure_name = 'PARTITION_SEQUENCE';

The query should return a single row. Anything else indicates that the proper patched version ofDBFS is not available on your database.

2.3 Examples used in these procedures
The followingprocedures assume two systems and configure the environment so that DBFS userson both systems see the same DBFS files, directories, and contents that are keptin synchronization with Oracle GoldenGate. It is possible to extend theseconcepts to support three or more peer systems.

2.4 Partitioning the DBFS sequence numbers
DBFS uses aninternal sequence-number generator to construct unique names and unique IDs.These steps partition the sequences into distinct ranges to ensure that thereare no conflicts across the databases. After this is done, further DBFSoperations (both creation of new fileystems and subsequent filesystemoperations) can be performed without conflicts of names, primary keys, or IDsduring DML propagation.

1. Connect to each database as sysdba.
2. Issue the following query on eachdatabase.
select last_number
from dba_sequences
where sequence_owner = 'SYS'
and sequence_name = 'DBFS_SFS_$FSSEQ'

3. From this query, choose the maximumvalue of LAST_NUMBER across both systems, or pick a high value that issignificantly larger than the current value of the sequence on either system.

4. Substitute this value (“maxval” is usedhere as a placeholder) in both of the following procedures. These procedureslogically index each system as myid=0 and myid=1.

dbms_dbfs_sfs_admin.partition_sequence(nodes=> 2, myid => 0,
newstart=> :maxval);
Node 2
dbms_dbfs_sfs_admin.partition_sequence(nodes => 2, myid => 1,
newstart=> :maxval);

Notice thedifference in the value specified for the myid parameter. These are the different index values.

For a multi-way configuration among threeor more databases, you could make the following alterations:
(1) Adjust the maximum value that isset for “maxval” upward appropriately, and use that value on all nodes.
(2) Vary the value of “myid” in theprocedure from 0 for the first node, 1 for the second node, 2 for the thirdone, and so on.

5. (Recommended) After (and only after) theDBFS sequence generator is partitioned, create a new DBFS filesystem on eachsystem, and use only these filesystems for DML propagation with OracleGoldenGate. See “Configuring the DBFS filesystem”。

DBFS filesystemsthat were created before the patch for bug-9651229 was applied or before theDBFS sequence number was adjusted can be configured for propagation, but thatrequires additional steps not described in this document. If you must retainold filesystems, open a service request with Oracle Support.

2.5 Configuring the DBFS filesystem
To replicate DBFS filesystem operations, use a configuration that is similar to the standardbi-directional configuration for DML.

(1) Use matched pairs of identicallystructured tables.
(2) Allow each database to have writeprivileges to opposite tables in a set, and set the other one in the set toread-only. For example:
1)Node1 writes to local table "t1" and these changesare replicated to t1 on Node2.
2)Node2 writes to local table “t2” and these changes arereplicated to t2 on Node1.
3)On Node1, t2 is read-only. On Node2, t1 is read-only.

DBFS filesystems make this kind of table pairing simple because:
(1) The tables that underlie the DBFSfilesystems have the same structure.
(2) These tables are modified bysimple, conventional DML during higher-level filesystem operations.
(3) The DBFS Content API provides away of unifying the namespace of the individual DBFS stores by means of mountpoints that can be qualified as read-write or read-only.

The following steps create two DBFS filesystems (in this case named FS1 and FS2) and set the mto be read-write or read, as appropriate.

1. Run the following procedure to createthe two filesystems. (Substitute your store names for “FS1” and “FS2.”)
Example declare
'posix', 'DBMS_DBFS_SFS');
'posix', 'DBMS_DBFS_SFS');

2. Run the following procedure to give eachfilesystem the appropriate access rights.
(Substitute your store names for “FS1” and“FS2.”)
Example Node 1
dbms_dbfs_content.mountStore('FS1', 'local');
dbms_dbfs_content.mountStore('FS2', 'remote',read_only => true);
Example Node 2
dbms_dbfs_content.mountStore('FS1', 'remote',read_only => true);
dbms_dbfs_content.mountStore('FS2', 'local');

In this example,note that on Node 1, store "FS1" is read-write and store"FS2" is read-only, while on Node 2 the converse is true: store"FS1" is read-only and store "FS2" is read-write.
Note also thatthe read-write store is mounted as "local" and the read-only store ismounted as "remote". This provides users on each system with anidentical namespace and identical semantics for read and write operations.Local path names can be modified, but remote path names cannot.

2.6 Mapping local and remote peers correctly
The names of thetables that underlie the DBFS filesystems are generated internally and dynamically.Continuing with the preceding example, there are:
(1) Two nodes (Node 1 and Node 2 inthe example).
(2) Four stores: two on each node(FS1 and FS2 in the example).
(3) Eight underlying tables: twofor each store (a table and a ptable). These tables must be identified,specified in Extract TABLE statements, and mapped in Replicat MAP statements.

1. To identify the table namesthat back each filesystem, issue the following query.(Substitute your storenames for “FS1” and “FS2.”)

Example select fs.store_name, tb.table_name,tb.ptable_name
fromtable(dbms_dbfs_sfs.listTables) tb,
wherefs.schema_name = tb.schema_name
andfs.table_name = tb.table_name
andfs.store_name in ('FS1', 'FS2')

The output looks like the followingexamples.

2. Identify the tables that are locallyread-write to Extract by creating the following TABLE statements in the Extractparameter files. (Substitute your owner and table names.)

Example: Node 1
TABLE owner.SFS$_FST_100;
TABLE owner.SFS$_FSTP_100;
Example: Node 2
TABLE owner. SFS$_FST_119;
TABLE owner.SFS$_FSTP_119;

3. Link changes on each remotefilesystem to the corresponding local filesystem by creating the following MAP statementsin the Replicat parameter files. (Substitute your owner and table names.)

Example: Node 1
MAP owner.SFS$_FST_119,
TARGET owner.SFS$_FST_118;
MAP owner.SFS$_FSTP_119,
TARGET owner.SFS$_FSTP_118;
Example: Node 2
MAP owner.SFS$_FST_100,
TARGET owner.SFS$_FST_101;
MAP owner.SFS$_FSTP_100,
TARGET owner.SFS$_FSTP_101;

This mapping captures and replicates local read-write “source” tables to remote readonly peertables:
(1) Filesystem changes made to FS1 onNode 1 propagate to FS1 on Node 2.
(2) Filesystem changes made to FS2 onNode 2 propagate to FS2 on Node1.

Changes to thefilesystems can be made through the DBFS ContentAPI (package DBMS_DBFS_CONTENT)of the database or through dbfs_client mounts and conventional filesystemstools.

All changes are propagated in both directions.
(1) A user at the virtual root of theDBFS namespace on each system sees identical content.
(2) For mutable operations, users usethe "/local" sub-directory on each system.
(3) For read operations, users can useeither of the "/local" or "/remote" sub-directories, dependingon whether they want to see local or remote content.

三.Configuring the Oracle redo logs
3.1 Ensuring data availability
When operatingin its normal mode, Oracle GoldenGate reads the online logs by default, butwill read the archived logs if an online log is not available. Therefore, forbest results, enable archive logging. The archives provide a secondary datasource should the online logs recycle before Extract is finished with them. Thearchive logs for open transactions must be retained on the system in caseExtract needs to recapture data from them to perform a recovery.
默认情况下,GG 读取onlinelog 来获取capture 数据,如果online redo 不可用的时候就会去读归档日志。 所以尽可能的启用归档,并将归档日志保留一定的时间,以防Extract 进程从归档日志recapture data。

If you cannotenable archive logging, configure the online logs according to the following guidelinesto retain enough data for Extract to capture what it needs before the logs recycle.Allow for Extract backlogs caused by network outages and other externalfactors, as well as long-running transactions.
如果没有启用归档,那么就需要按照以下方法来配置onlinelog,以保证在log recycle 之前,Extrace 能从onlinelog里capture 足够的数据。
In a RACconfiguration, Extract must have access to the online and archived logs for allnodes in the cluster, including the one where Oracle GoldenGate is installed.
—RAC 环境下,Extract 必须能够访问所有节点的online 和archivedlog。 即RAC 环境下GG需要安装在共享文件系统上,这点在安装GG那部分有说明。

3.1.1 Log retention requirements per Extract recovery mode
The followingsummarizes the different recovery modes that Extract might use and their log-retentionrequirements:
(1) By default, the Bounded Recoverymode is in effect, and Extract requires access to the logs only as far back astwice the Bounded Recovery interval that is set with the BR parameter. Thisinterval is an integral multiple of the standard Extract checkpoint interval,as controlled by the CHECKPOINTSECS parameter. These two parameters control theOracle GoldenGate Bounded Recovery feature, which ensures that Extract can recoverin-memory captured data after a failure, no matter how old the oldest open transactionwas at the time of failure.
(2) In the unlikely event that theBounded Recovery mechanism fails when Extract attempts a recovery, Extractreverts to normal recovery mode and must have access to the archived log thatcontains the beginning of the oldest open transaction in memory at the time offailure and all logs thereafter.

3.1.2 Log retention options
Depending on theversion of Oracle, there are different options for ensuring that the requiredlogs are retained on the system.

(1)Oracle Enterprise Edition 10.2 and later
For these versions, Extract works with Oracle Recovery Manager (RMAN) to retain the logsthat Extract needs for recovery. This feature is enabled by default when youadd or register an Extract group in GGSCI with ADD EXTRACT (TRANLOG option) or REGISTEREXTRACT.
By default,Extract retains enough logs to perform a Bounded Recovery, but you can configureExtract to retain enough logs through RMAN for a normal recovery by using the TRANLOGOPTIONSparameter with the LOGRETENTION option set to SR. There also is an option to disablethe use of RMAN log retention. Review the options of LOGRETENTION in the OracleGoldenGate Windows and UNIX Reference Guide before you configure Extract. Ifyou set LOGRETENTION to DISABLED, see “Determining how much data to retain”.

To support RMANlog retention on Oracle RAC, you must download and install the database patchthat is provided in BUGFIX 11879974 before you add the Extract

The RMAN logretention feature creates an underlying (but non-functioning) Oracle StreamsCapture process for each Extract group. The name of the Capture is based on thename of the associated Extract group. The log retention feature can operateconcurrently with other local Oracle Streams installations. When you create anExtract group, the logs are retained from the current database SCN.

If the OracleFlashback storage area is full, RMAN purges the archive logs even when neededby Extract. This limitation exists so that the requirements of Extract (andother Oracle replication components) do not interfere with the availability of redoto the database.

(2)All other Oracle versions
For versions ofOracle other than Enterprise Edition 10.2 and later, you must manage the logretention process yourself with your preferred administrative tools. Follow thedirections in “Determining how much data to retain”.

3.1.3 Determining how much data to retain
When managinglog retention, try to ensure rapid access to the logs that Extract would requireto perform a normal recovery (not a Bounded Recovery). See “Log retention requirementsper Extract recovery mode”. If you must move the archives off the database system,the TRANLOGOPTIONS parameter provides a way to specify an alternate location.See “Specifying the archive location”.

The recommendedretention period is at least 24 hours worth of transaction data, including bothonline and archived logs. To determine the oldest log that Extract might needat any given point, issue the SEND EXTRACT command with the SHOWTRANS option.You might need to do some testing to determine the best retention time givenyour data volume and business requirements.

If data that Extract needs during processing was not retained, either in online or archived logs,one of the following corrective actions might be required:
(1) Alter Extract to capture from alater point in time for which log data is available (and accept possible dataloss on the target).
(2) Resynchronize the source and targetdata, and then start the Oracle GoldenGate environment over again.

3.1.4 Purging log archives
Make certain notto use backup or archive options that cause old archive files to be overwrittenby new backups. Ideally, new backups should be separate files with different namesfrom older ones. This ensures that if Extract looks for a particular log, itwill still exist, and it also ensures that the data is available in case it isneeded for a support case.

3.2 Specifying the archive location
If the archivedlogs reside somewhere other than the Oracle default directory, specify that directorywith the ALTARCHIVELOGDEST option of the TRANLOGOPTIONS parameter in theExtract parameter file.
You might alsoneed to use the ALTARCHIVEDLOGFORMAT option of TRANLOGOPTIONS if the format thatis specified with the Oracle parameter LOG_ARCHIVE_FORMAT containssub-directories.
ALTARCHIVEDLOGFORMATspecifies an alternate format that removes the sub-directory from the path. Forexample, %T/log_%t_%s_%r.arc would be changed to log_%t_%s_%r.arc. As an alternativeto using ALTARCHIVEDLOGFORMAT, you can create the sub-directory manually, and thenmove the log files to it.

3.3 Mounting logs that are stored on other platforms
If the onlineand archived redo logs are stored on a different platform from the one that Extractis built for, do the following:
(1) NFS-mount the archive files.
(2) Map the file structure to thestructure of the source system by using the LOGSOURCE and PATHMAP options ofthe Extract parameter TRANLOGOPTIONS.

3.4 Configuring Oracle GoldenGate to read only the archivedlogs
You can configure Extract to read exclusively from the archived logs. This is known as ArchivedLog Only (ALO) mode. In this mode, Extract reads exclusively from archived logsthat are stored in a specified location. ALO mode enables Extract to useproduction logs that are shipped to a secondary database (such as a standby) asthe data source. The online logs are not used at all. Oracle GoldenGateconnects to the secondary database to get metadata and other required data asneeded. As an alternative, ALO mode is supported on the production system.

3.4.1 Limitations and requirements of ALO mode
(1) Log resets (RESETLOG) cannot bedone on the source database after the standby databaseis created.
(2) ALO cannot be used on a standbydatabase if the production system is Oracle RAC and the standby database isnon-RAC. In addition to both systems being Oracle RAC, the number of nodes oneach system must be identical.
(3) ALO on Oracle RAC requires adedicated connection to the source server. If that connection is lost, OracleGoldenGate processing will stop.
(4) On Oracle RAC, the directoriesthat contain the archive logs must have unique names across all nodes;otherwise, Extract may return “out of order SCN” errors.
(5) ALO mode does not supportarchive log files in ASM mode. The archive log files must be outside the ASMenvironment for Extract to read them.

3.4.2 Configuring Extract for ALO mode
1. Enable supplemental logging at the tablelevel and the database level for the tables in the source database.

2. When Oracle GoldenGate is running on adifferent server from the source database, make certain that SQL*Net isconfigured properly to connect to a remote server, such as providing thecorrect entries in a TNSNAMES file. Extract must have permission to maintain aSQL*Net connection to the source database.

3. Use a SQL*Net connect string in:
(1) The USERID parameter in theparameter file of every Oracle GoldenGate process that connects to thatdatabase.
(2) The DBLOGIN command in GGSCI.
Example USERID statement:
USERID ggext@ora10g01, PASSWORD ggs123

If you have astandby server that is local to the server that Oracle GoldenGate is runningon, you do not need to use a connect string in USERID. You can just supply theuser login name.

4. Use the Extract parameter TRANLOGOPTIONSwith the ARCHIVEDLOGONLY option. This option forces Extract to operate in ALOmode against a primary or logical standby database, as determined by a value ofPRIMARY or LOGICAL STANDBY in the db_role column of the v$database view. Thedefault is to read the online logs. TRANLOGOPTIONS with ARCHIVEDLOGONLY is notneeded if using ALO mode against a physical standby database, as determined bya value of PHYSICAL STANDBY in the db_role column of v$database. Extract automatically operates in ALO mode if it detectsthat the database is a physical standby.

5. Other TRANLOGOPTIONS options might berequired for your environment. For example, depending on the copy program thatyou use, you might need to use the COMPLETEARCHIVEDLOGONLY option to preventExtract errors.

6. Use the MAP parameter for Extract to mapthe table names to the source object IDs.

7. Add the Extract group by issuing the ADDEXTRACT command with a timestamp as the BEGIN option, or by using ADD EXTRACT withthe SEQNO and RBA options. It is best to give Extract a known start point atwhich to begin extracting data, rather than by using the NOW argument. Thestart time of “NOW” corresponds to the time of the current online redo log, butan ALO Extract cannot read the online logs, so it must wait for that log to bearchived when Oracle switches logs. The timing of the switch depends on thesize of the redo logs and the volume of database activity, so there might be alag between when you start Extract and when data starts being captured. Thiscan happen in both regular and RAC database configurations.

If Extractappears to stall while operating in ALO mode。

3.5 Setting redo parallelism for Oracle 9i sources
If using OracleGoldenGate for an Oracle 9i source database, set the _LOG_PARALLELISM parameterto 1. Oracle GoldenGate does not support values higher than 1.

3.6 Avoiding log-read bottlenecks
When OracleGoldenGate captures data from the redo logs, I/O bottlenecks can occur becauseExtract is reading the same files that are being written by the databaselogging mechanism. Performance degradation increases with the number of Extractprocesses that read the same logs. You can:
(1) Try using faster drives and afaster controller. Both Extract and the database logging mechanism will befaster on a faster I/O system.
(2) Store the logs on RAID 0+1.Avoid RAID 5, which performs checksums on every block written and is not a goodchoice for high levels of continuous I/O. For more information, see the Oracledocumentation or search related web sites.

四.Managing the Oracle DDL replication environment
4.1 Enabling and disabling the DDL trigger
You can enableand disable the trigger that captures DDL operations without making any configurationchanges within Oracle GoldenGate. The following scripts control the DDL trigger.
(1) ddl_disable: Disables thetrigger. No further DDL operations are captured or replicated after you disablethe trigger.
(2) ddl_enable: Enables thetrigger. When you enable the trigger, Oracle GoldenGate starts capturingcurrent DDL changes, but does not capture DDL that was generated while thetrigger was disabled.

Before running these scripts, disable all sessions that ever issued DDL, including those of theOracle GoldenGate processes, SQL*Plus, business applications, and any othersoftware that uses Oracle. Otherwise the database might generate an ORA-04021error. Do not use these scripts if you intend to maintain consistent DDL on thesource and target systems.

4.2 Maintaining the DDL marker table
You can purge rows from the marker table at any time. It does not keep DDL history. To purgethe marker table, use the Manager parameter PURGEMARKERHISTORY. Manager getsthe name of the marker table from one of the following:
1. The namegiven with the MARKERTABLE <table> parameter in the GLOBALS file, if specified.
2. The defaultname of GGS_MARKER.

PURGEMARKERHISTORY provides options to specify maximum and minimum lengths of time to keep a row,based on the last modification date.

4.3 Deleting the DDL marker table
Do not delete the DDL marker table unless you want to discontinue synchronizing DDL.
The marker tableand the DDL trigger are interdependent. An attempt to drop the marker tablefails if the DDL trigger is enabled. This is a safety measure to prevent thetrigger from becoming invalid and missing DDL operations. If you remove themarker table, the following error is generated:
"ORA-04098:trigger 'SYS.GGS_DDL_TRIGGER_BEFORE' is invalid and failed re-validation"

The proper wayto remove an Oracle GoldenGate DDL object depends on your plans for the rest ofthe DDL environment. To choose the correct procedure, see one of the following:
(1) “Changing DDL object namesafter installation” on page 66
(2) “Restoring an existing DDLenvironment to a clean state” on page 68
(3) “Removing the DDL objects from thesystem” on page 69

4.4 Maintaining the DDL history table
You can purgethe DDL history table to control its size, but do so carefully. The DDL historytable maintains the integrity of the DDL synchronization environment. Purges tothis table cannot be recovered through the Oracle GoldenGate interface.

To maintain the DDL history table
1. To prevent any possibility of DDLhistory loss, make regular full backups of the history table.
2. To ensure the recoverability of purgedDDL, enable Oracle Flashback for the history table. Set the flashback retentiontime well past the point where it could be needed. For example, if your fullbackups are at most one week old, retain two weeks of flashback. OracleGoldenGate can be positioned backward into the flashback for reprocessing.
3. If possible, purge the DDL history tablemanually to ensure that essential rows are not purged accidentally. If yourequire an automated purging mechanism, use the PURGEDDLHISTORY parameter inthe Manager parameter file. You can specify maximum and minimum lengths of timeto keep a row.

Temporary tablescreated by Oracle GoldenGate to increase performance might be purged at the sametime as the DDL history table, according to the same rules. The names of thesetables are derived from the name of the history table, and their purging isreported in the Manager report file. This is normal behavior.

4.5 Deleting the DDL history table
Do not deletethe DDL history table unless you want to discontinue synchronizing DDL. Thehistory table contains a record of DDL operations that were issued.
The historytable and the DDL trigger are interdependent. An attempt to drop the history tablefails if the DDL trigger is enabled. This is a safety measure to prevent thetrigger from becoming invalid and missing DDL operations. If you remove thehistory table, the following error is generated:
"ORA-04098:trigger 'SYS.GGS_DDL_TRIGGER_BEFORE' is invalid and failed re-validation"

The proper wayto remove an Oracle GoldenGate DDL object depends on your plans for the rest ofthe DDL environment. To choose the correct procedure, see one of the following:
(1) “Changing DDL object namesafter installation” on page 66
(2) “Restoring an existing DDLenvironment to a clean state” on page 68
(3) “Removing the DDL objects fromthe system” on page 69

4.6 Purging the DDL trace file
To prevent theDDL trace file from consuming excessive disk space, run the ddl_cleartrace scripton a regular basis. This script deletes the trace file, but Oracle GoldenGatewill create it again.
The default nameof the DDL trace file is ggs_ddl_trace.log. It is in the USER_DUMP_DEST directoryof Oracle. The ddl_cleartrace script is in the Oracle GoldenGate directory.

4.7 Applying database patches and upgrades when DDL supportis enabled
Database patchesand upgrades usually invalidate the Oracle GoldenGate DDL trigger and otherOracle GoldenGate DDL objects. Before applying a database patch, do the following.
1. Disable the Oracle GoldenGate DDLtrigger by running the following script.
2. Apply the patch.
3. Enable the DDL trigger by running thefollowing script.

Databaseupgrades and patches generally operate on Oracle objects. Because OracleGoldenGate filters out those objects automatically, DDL from those proceduresis not replicated when replication starts again.

To avoidrecompile errors after the patch or upgrade, which are caused if the trigger isnot disabled before the procedure, consider adding calls to @ddl_disable and @ddl_enableat the appropriate locations within your scripts.

4.8 Applying Oracle GoldenGate patches and upgrades when DDLsupport is enabled
If there are instructionslike these in the release notes or upgrade instructions that accompany arelease, follow those instead of these. Do not use this procedure for anupgrade from an Oracle GoldenGate version that does not support DDL statementsthat are larger than 30K (pre-version 10.4).

Follow these steps to apply a patch or upgrade to the DDL objects. This procedure may or maynot preserve the current DDL synchronization configuration, depending onwhether the new build requires a clean installation.

1. Run GGSCI. Keep the session open for theduration of this procedure.
2. Stop Extract to stop DDL capture.
3. Stop Replicat to stop DDL replication.
4. Download or extract the patch or upgradefiles according to the instructions provided by Oracle GoldenGate.
5. Change directories to the OracleGoldenGate installation directory.
6. Run SQL*Plus and log in as a user thathas SYSDBA privileges.
7. Disconnect all sessions that ever issuedDDL, including those of Oracle GoldenGate processes, SQL*Plus, businessapplications, and any other software that uses Oracle. Otherwise the databasemight generate an ORA-04021 error.
8. Run the ddl_disable script to disablethe DDL trigger.
9. Run the ddl_setup script. You areprompted for:
(1) The name of the Oracle GoldenGateDDL schema. If you changed the schema name, use the new one.
(2) The installation mode: Selecteither NORMAL or INITIALSETUP mode, depending on what the installation orupgrade instructions require. NORMAL mode recompiles the DDL environmentwithout removing DDL history. INITIALSETUP removes the DDL history.
10. Run the ddl_enable.sql script to enablethe DDL trigger.
11. In GGSCI, start Extract to resume DDLcapture.
12. Start Replicat to start DDLreplication.

4.9 Changing DDL object names after installation
Follow these steps to change the names of the Oracle GoldenGate DDL schema or other DDLobjects after they are installed. This procedure preserves the continuity ofsource and target DDL operations.

1. Run GGSCI. Keep the session open for theduration of this procedure.
2. Stop Extract to stop DDL capture.
3. Stop Replicat to stop DDL replication.
4. Change directories to the OracleGoldenGate installation directory.
5. Run SQL*Plus and log in as a user thathas SYSDBA privileges.
6. Disconnect all sessions that ever issuedDDL, including those of Oracle GoldenGate processes, SQL*Plus, businessapplications, and any other software that uses Oracle. Otherwise the databasemight generate an ORA-04021 error.
7. Run the ddl_disable script to disablethe DDL trigger.
8. To change the DDL schema name, specifythe new name in the local GLOBALS file.
9. To change the names of any otherobjects, do the following:
(1) Specify the new names in the params.sqlscript. Do not run this script.
(2) If changing objects in Table 12,specify the new names in the local GLOBALS file. The correct parameters to useare listed in the Parameter column of this table.

10. If using a new schema for the DDLsynchronization objects, create it now.
11. Change directories to the OracleGoldenGate installation directory.
12. Run SQL*Plus and log in as a user thathas SYSDBA privileges.
13. Run the ddl_setup script. You areprompted for:
(1) The name of the Oracle GoldenGateDDL schema. If you changed the schema name, use the new one.
(2) The installation mode: Select the NORMALmode to recompile the DDL environment without removing the DDL history table.
14. Run the ddl_enable.sql script to enablethe DDL trigger.
15. In GGSCI, start Extract to resume DDLcapture.
16. Start Replicat to start DDLreplication.

4.10 Restoring an existing DDL environment to a clean state
Follow these steps to completely remove, and then reinstall, the Oracle GoldenGate DDL objects.This procedure creates a new DDL environment, but removes DDL history.

Due to objectinterdependencies, all objects must be removed and reinstalled in this procedure.

1. If you are performing thisprocedure in conjunction with the installation of a new Oracle GoldenGateversion, download and install the Oracle GoldenGate files, and create or updateprocess groups and parameter files as necessary.

2. (Optional) To preserve the continuity ofsource and target structures, stop DDL activities and then make certain thatReplicat finished processing all of the DDL and DML data in the trail. Todetermine when Replicat is finished, issue the following command until you seea message that there is no more data to process.
Instead of usingINFO Replicat, you can use the EVENTACTIONS option of TABLE and MAP to stop theExtract and Replicat processes after the DDL and DML has been processed.

3. Run GGSCI.
4. Stop Extract to stop DDL capture.
5. Stop Replicat to stop DDL replication.
6. Change directories to the OracleGoldenGate installation directory.
7. Run SQL*Plus and log in as a user thathas SYSDBA privileges.
8. Disconnect all sessions that ever issuedDDL, including those of Oracle GoldenGate processes, SQL*Plus, businessapplications, and any other software that uses Oracle. Otherwise the databasemight generate an ORA-04021 error.
9. Run the ddl_disable script to disablethe DDL trigger.
10. Run the ddl_remove script to remove theOracle GoldenGate DDL trigger, the DDL history and marker tables, and otherassociated objects. This script produces a ddl_remove_spool.txt file that logsthe script output and a ddl_remove_set.txt file that logs environment settingsin case they are needed for debugging.
11. Run the marker_remove script to removethe Oracle GoldenGate marker support system. This script produces a marker_remove_spool.txtfile that logs the script output and a marker_remove_set.txt file that logsenvironment settings in case they are needed for debugging.
12. Run the marker_setup script toreinstall the Oracle GoldenGate marker support system. You are prompted for thename of the Oracle GoldenGate schema.
13. Run the ddl_setup script. You areprompted for:
(1) The name of the Oracle GoldenGateDDL schema.
(2) The installation mode. Toreinstall DDL objects, use the INITIALSETUP mode. This mode drops and recreatesexisting DDL objects before creating new objects.
14. Run the role_setup script to recreatethe Oracle GoldenGate DDL role.
15. Grant the role to all Oracle GoldenGateusers under which the following Oracle
GoldenGate processes run: Extract,Replicat, GGSCI, and Manager. You might need to make multiple grants if theprocesses have different user names.
16. Run the ddl_enable.sql script to enablethe DDL trigger.

4.11 Removing the DDL objects from the system
This procedure removes the DDL environment and removes the history that maintains continuitybetween source and target DDL operations.

Due to objectinterdependencies, all objects must be removed.

1. Run GGSCI.
2. Stop Extract to stop DDL capture.
3. Stop Replicat to stop DDL replication.
4. Change directories to the OracleGoldenGate installation directory.
5. Run SQL*Plus and log in as a user thathas SYSDBA privileges.
6. Disconnect all sessions that ever issuedDDL, including those of Oracle GoldenGate processes, SQL*Plus, businessapplications, and any other software that uses Oracle. Otherwise the databasemight generate an ORA-04021 error.
7. Run the ddl_disable script to disablethe DDL trigger.
8. Run the ddl_remove script to remove theOracle GoldenGate DDL trigger, the DDL history and marker tables, and theassociated objects. This script produces a ddl_remove_spool.txt file that logsthe script output and a ddl_remove_set.txt file that logs current userenvironment settings in case they are needed for debugging.
9. Run the marker_remove script to removethe Oracle GoldenGate marker support system. This script produces a marker_remove_spool.txtfile that logs the script output and a marker_remove_set.txt file that logsenvironment settings in case they are needed for debugging.

7.3 Non-supported characters
Oracle GoldenGate does not support the following characters in object or column names.