Shulou(Shulou.com)06/01 Report--

Oracle GoldenGate download:

Http://www.oracle.com/technetwork/cn/middleware/goldengate/downloads/index.html

Installation documentation on the official website:

Oracle GoldenGate 12c (12.2.0.1):

Http://docs.oracle.com/goldengate/c1221/gg-winux/index.html

Fusion Middleware Installing and Configuring Oracle GoldenGate for Oracle Database:

Https://docs.oracle.com/goldengate/c1221/gg-winux/GIORA/GUID-3108B63B-F2A2-446E-8006-D685C8E9B3A3.htm#GIORA110

Fusion Middleware Oracle GoldenGate Release Notes for Windows and UNIX

Https://docs.oracle.com/goldengate/c1221/gg-winux/GRLWU/index.html

= =

Oracle Fusion Middleware Installing and Configuring Oracle GoldenGate for Oracle Database

Preface

System Requirements and Preinstallation Instructions

Installing Oracle GoldenGate

Preparing the Database for Oracle GoldenGate

Establishing Oracle GoldenGate Credentials

Choosing Capture and Apply Modes

Configuring Oracle GoldenGate in a Multitenant Container Database

Configuring Capture in Integrated Mode

Configuring Capture in Classic Mode

Configuring Oracle GoldenGate Apply

Additional Oracle GoldenGate Configuration Considerations

Additional Configuration Steps for Using Classic Capture

Additional Configuration Steps For Using Nonintegrated Replicat

Configuring DDL Support

Creating Process Groups

Instantiating Oracle GoldenGate Replication

Managing the DDL Replication Environment

Uninstalling Oracle GoldenGate

Optional Parameters for Integrated Modes

Configuring a Downstream Mining Database

Example Downstream Mining Configuration

Installing Trigger-Based DDL Capture

Supporting Changes to XML Schemas

Preparing DBFS for an Active-Active Configuration

Oracle GoldenGate Installed Components

=

1 System Requirements and Preinstallation Instructions

This chapter contains requirements for system and database resources that support Oracle GoldenGate. This chapter includes the following sections

Verifying Certification and System Requirements

Operating System Requirements

Oracle Universal Installer Requirements for Oracle GoldenGate

Database Configuration

Summary of Supported Oracle Data Types and Objects Per Capture Mode

Details of Support for Oracle Data Types

Details of Support for Objects and Operations in Oracle DML

Details of Support for Objects and Operations in Oracle DDL

Supported and Non-supported Object Names

1.1 Verifying Certification and System Requirements

Make sure you install the product on a supported hardware or software configuration. For more information, see the issuing certificate document on the Oracle Fusion Middleware Supported System Configurations (system configuration supported by Oracle Convergence Middleware) page.

1.2 Operating System Requirements operating system check

1.2.1 Memory Requirements

For more information about evaluating Oracle GoldenGate memory requirements, see the CACHEMGR parameter in Reference for Oracle GoldenGate for Windows and UNIX.

For more information about evaluating Oracle GoldenGate memory requirements, see the CACHEMGR parameter in the references for Oracle GoldenGate for Windows and UNIX.

1.2.2 Disk Requirements

1.2.2.1 Disk Requirements for Oracle GoldenGate Installation Files

This section shows the disk requirements for a manual installation and for an installation through OUI.

This section shows the disk requirements for manual installation and OUI installation.

Table 1-1 shows the disk space that is consumed by the files of one Oracle GoldenGate installation in a manual build. A manual build does not use OUI. The person installing Oracle GoldenGate uncompresses the files and creates the working directories.

Table 1-1 shows the disk space consumed by an Oracle GoldenGate installation file in a manual build. Manual builds do not use OUI. The person who installed Oracle GoldenGate unzipped the file and created a working directory.

Disk Requirements for an OUI Build

Platform Oracle Version Compressed Size (MB) Installed Size (MB)

Linux 12c 325 zip file 521

329 OUI installer

1.2.2.2 Other Disk Space Considerations

In addition to the disk space required for files and binaries installed by GoldenGate, you can add an additional 1 GB of disk space on any system that hosts Oracle GoldenGate traces (or sections).

1.2.2.3 Installing in a Cluster

To install Oracle GoldenGate into a clustered environment, install the Oracle GoldenGate binaries and files as Oracle users on a shared file system available to all cluster nodes. For more information, see preparing to install Oracle GoldenGate in a cluster.

1.2.2.4 Temporary Disk Requirements

By default, Oracle GoldenGate writes data to the dirtmp subdirectory of the Oracle GoldenGate installation directory. When the total cache transaction data exceeds the CACHESIZE setting of the CACHEMGR parameter, Extract starts writing the cache data to a temporary file. The cache manager assumes that all available space on the file system is available. If there is a transaction volume of large transaction size, the directory can fill up quickly. To prevent I / O contention and disk-related Extract failures, dedicate the disk to this directory. You can use the CACHEDIRECTORY option of the CACHEMGR parameter to specify a name for this directory.

Swapping disks by the operating system is generally more efficient than writing temporary files using Extract. The default CACHESIZE setting is assumed. Therefore, there should be enough disk space to solve this problem, because write transaction cache data in the file system namespace can be extracted to temporary files only after the value of CACHESIZE is exceeded. If multiple "extract" processes are running on the system, disk requirements may increase. Oracle GoldenGate writes to disk when there is not enough memory to store open transactions. Once the transaction is committed or rolled back, the written data is written to the trace file, the data is released from memory, and Oracle GoldenGate no longer tracks the transaction. There is no minimum disk requirement because transactions are never written to disk when they are committed after each operation.

1.2.3 Network

Record the port you assigned to Oracle GoldenGate. When you configure Manager processes, you will specify them with parameters.

1.2.4 Operating System Privileges

The following are the permissions in the operating system required to install Oracle GoldenGate and run the process:

To install on UNIX, the person who installs Oracle GoldenGate must have read and write access to the Oracle GoldenGate installation directory.

The Oracle GoldenGate Extract,Replicat and Manager processes must be operating system users with permissions to read, write, and delete files and subdirectories in the Oracle GoldenGate directory. In addition, the Manager process requires permissions to control other Oracle GoldenGate processes.

(classic capture mode) in Classic capture mode, the Extract process reads the redo log directly and must operate as an operating system user with read access to online and archived log files. On UNIX systems, the user must be a member of a group that owns an instance of Oracle. If you install the Manager process as a Windows service in the installation steps in this document, you must install it as an administrator to assign the correct permissions. If you cannot install Manager as a service, manually assign read access to the Extract process, and then always run Manager and extract as an administrator.

Dedicate Extract,Replicat and Manager operating system users to Oracle GoldenGate. Sensitive information can be used by anyone running an Oracle GoldenGate process, depending on how database authentication is configured.

1.2.5 Console Character Sets

You can use the following DOS command to set the character set of the Control Station before opening a GGSCI session:

Chcp OS character set

1.3 Oracle Universal Installer Requirements for Oracle GoldenGate

1.4 Database Configuration database configuration

This section contains Oracle GoldenGate requirements specific to Oracle databases. Unless explicitly indicated, both capture modes apply.

If you are using the DBMS_LOB.LOADFROMFILE procedure to update a LOB column only and your supplemental log is on all the columns, Integrated Extract captures the key columns and LOB improving performance. Classic Extract captures the all the columns by default. These behaviors do not effect like to like replications. However, with a replication to data warehouse, you may want all the columns for update. If you are converting from Classic Extract to Integrated Extract, you must use one of the following parameters to ensure that the Extract operates correctly:

If you are using the DBMS_LOB.LOADFROMFILE procedure to update LOB columns and your supplementary log is on all columns, Integrated Extract will capture key columns and LOB to improve performance. Classic Extract captures all columns by default. These behaviors are not like copying. However, by copying to the data warehouse, you may want to update all columns. If you are converting from Classic Extract to Integrated Extract, you must use one of the following parameters to ensure that the extraction is correct:

Use KEYCOLS to add all columns (except LOB).

Use LOGALLSUPCOLS to control the writing of supplementally logged columns.

Database user privileges and configuration requirements are explained in "Establishing Oracle GoldenGate Credentials".

Database user permissions and configuration requirements are described in establishing Oracle GoldenGate credentials.

If the database is configured to use a bequeath connection, the sqlnet.ora file must contain the bequeath_detach=true setting.

If the database is configured to use bequeath connections, the sqlnet.ora file must contain the bequeath_detach = true setting.

To install Oracle GoldenGate in an Oracle Real Application Cluster (RAC) environment, install Oracle GoldenGate on the shared drive (s) that are accessed by the RAC nodes. For more information, see Preparing to Install Oracle GoldenGate Within a Cluster.

To install Oracle GoldenGate in an Oracle Real Application Cluster (RAC) environment, install Oracle GoldenGate on a shared drive accessed by the RAC node. For more information, see preparing to install Oracle GoldenGate in a cluster.

(Integrated capture mode) Integrated Capture mode makes use of a logmining server on the source system or in a downstream Oracle Database. Refer to My Oracle Support article 1557031.1 for all Oracle Database release bundled patches for Oracle GoldenGate.

(integrated capture mode) Integrated capture mode uses a login server in the source system or downstream Oracle database. For all Oracle database version bundle patches for Oracle GoldenGate, see my Oracle support article 1557031.1.

To use integrated capture with an Oracle 11.2.0.3 source database, download and install the 11.2.0.3 database specific bundled patch required for Integrated Extract.

For more information, see Choosing Capture and Apply Modes.

To use the integrated capture with the Oracle 11.2.0.3 source database, download and install the 11.2.0.3 database-specific bundling patch required by Integrated Extract. For more information, see Select capture and apply modes.

Oracle Databases must be in ARCHIVELOG mode so that Extract can process the log files.

The Oracle database must be in ARCHIVELOG mode so that Extract can process log files.

1.5 Summary of Supported Oracle Data Types and Objects Per Capture Mode Summary of Oracle data types and objects supported by each capture mode

Table 1-3 summarizes the way that Oracle GoldenGate supports the Oracle data types according to the capture mode that you choose. For more information about capture modes, see Deciding Which Capture Method to Use.

Tables 1-3 summarize how Oracle GoldenGate supports the Oracle data type based on the capture mode you choose. For more information about capture mode, see determining the capture method to use.

Detailed support information for Oracle data types, objects, and operations starts with Details of Support for Oracle Data Types.

For more information about support for Oracle data types, objects, and operations, see Oracle data type support details.

See: https://docs.oracle.com/goldengate/c1221/gg-winux/GIORA/GUID-B4C2B009-102D-46D2-9AF5-545AE984A16B.htm#GIORA122

1.6 details of Details of Support for Oracle Data Types Oracle data type support

The following outlines details of Oracle data type support by Oracle GoldenGate. Unless otherwise noted, the support applies to both classic and integrated capture mode. For more information about these modes, see Choosing "Capture and Apply Modes".

The following summarizes the details of the Oracle data types supported by Oracle GoldenGate. Unless otherwise noted, support applies to both classic and integrated capture modes. For more information about these modes, see Select capture and apply modes.

1.6.1 ANYDATA Data Types

1.6.1.1 Limitations of Support

Your source database compatibility must be set to 11.2.0.0.0 or higher. Support for named collections and VARRAYs embedded within those data types.

Your source database compatibility must be set to 11.2.0.0.0 or later. Support for named collections and VARRAY embedded in these data types.

1.6.2 Numeric Data Types

1.6.2.1 Limitations of Support

The support of the range and precision for floating-point numbers depends on the host machine. In general, the precision is accurate to 16 significant digits, but you should review the database documentation to determine the expected approximations. Oracle GoldenGate rounds or truncates values that exceed the supported precision.

The range and precision of floating point numbers are supported depending on the host. In general, the accuracy is accurate to 16 significant digits, but you should look at the database documentation to determine the expected approximation. Oracle GoldenGate can round or truncate values that exceed the supported precision.

1.6.3 Character Data Types

1.6.3.1 Limitations of Support

If an extended VARCHAR column is part of unique index or constraint, then direct path inserts to this table may cause Replicat to abend with a warning. Verify that the extended VARCHAR caused the abend by checking all_indexes/all_ind_columns for a unique index or all_cons_columns/all_constraints for a unique constraint. Once you determine that an extended VARCHAR, you can temporarily drop the index or disable the constraint:

If the extended VARCHAR column is part of a unique index or constraint, direct path insertion into this table may cause a Replicat exit warning. Check to see if the extended VARCHAR caused an exception or unique constrained all_indexes / all_constraints by checking the all_indexes / all_constraints of the unique index. Once you have determined the extended VARCHAR, you can temporarily delete the index or disable the constraint:

For Unique Index:

Drop index t2u

For Unique Constraint:

Alter table v32ind modify constraint sys_c0010125 disable

Extended (32K) VARCHAR2 and NVARCHAR2 columns are supported when Extract is in integrated capture mode. All modes of Replicat support 32K VARCHAR2 and NVARCHAR2 columns. The following limitations apply:

Extended (32K) VARCHAR2 and NVARCHAR2 columns are supported when Extract is in integrated capture mode. All modes of Replicat support 32K VARCHAR2 and NVARCHAR2 columns. The following restrictions apply:

Oracle GoldenGate does not support 32K VARCHAR2 and NVARCHAR2 columns as part of a key or unique index, nor as a column in a KEYCOLS clause of the TABLE or MAP parameter. 32K columns cannot be used as row identifiers because they are not supplementally logged even when part of a primary key.

32K columns are not supported as resolution columns in a CDR (conflict resolution and detection) configuration nor as the basis for any other work that requires a column value to be present in the transaction log.

Oracle GoldenGate does not limit the number of 32K columns, but each trail record has a length limit of 4MB for inline records. The number of 32K columns that reaches this limit is approximately 160 columns, but the number of columns also depends on the actual size of the extended VARCHAR2 column.

1.6.4 Multi-byte Character Types multibyte character type

1.6.5 Binary Data Types binary data type

1.6.6 Date and Timestamp Data Types date and timestamp data types

1.6.7 Large Object Data Types

1.6.8 XML Data Types

1.6.9 User Defined or Abstract Types user-defined or abstract type

1.6.10 Oracle data types not supported by Non-Supported Oracle Data Types

1.7 Details of Support for Objects and Operations in Oracle DML: support details for objects and operations in Oracle DML

This section outlines the Oracle objects and operations that Oracle GoldenGate supports for the capture and replication of DML operations.

This section provides an overview of the Oracle objects and operations that Oracle GoldenGate supports capturing and copying DML operations.

1.7.1 Multitenant Container Databases Multi-tenant Container Database

Oracle GoldenGate captures from, and delivers to, a multitenant container database. See Configuring Oracle GoldenGate in a Multitenant Container Database for more information about how Oracle GoldenGate supports multitenant container databases.

Oracle GoldenGate captures from the multi-tenant container database and passes it to the multi-tenant container database. For more information about how Oracle GoldenGate supports multi-tenant container databases, see configuring Oracle GoldenGate in Multi-tenant Container databases.

1.7.2 Tables, Views, and Materialized Views

Oracle GoldenGate supports the following DML operations made to regular tables, index-organized tables, clustered tables, and materialized views.

Oracle GoldenGate supports the following DML operations on regular tables, index organization tables, clustered tables, and materialized views:

INSERT

UPDATE

DELETE

Associated transaction control operations

You can use the DBA_GOLDENGATE_SUPPORT_MODE data dictionary view to display information about the level of support the Oracle GoldenGate capture process has for tables in the database. For more information, see the Oracle Database reference.

1.7.3 Sequences

1.7.4 Non-supported Objects and Operations in Oracle DML

1.8 Details of Support for Objects and Operations in Oracle DDL: details of object and operation support in Oracle DDL

This section outlines the Oracle objects and operation types that Oracle GoldenGate supports for the capture and replication of DDL operations. For more information about DDL support, see the following:

This section provides an overview of the Oracle objects and operation types that Oracle GoldenGate supports capturing and copying DDL operations. For more information about DDL support, see the following:

Configuring DDL Support configuration DDL support

Installing Trigger-Based DDL Capture (Trigger-based capture is required for Oracle releases that are earlier than version 11.2.0.4. If Extract will run in integrated mode against a version 11.2.0.4 or later Oracle Database, the DDL trigger and supporting objects are not required.)

Install trigger-based DDL capture (versions of Oracle earlier than version 11.2.0.4 require trigger-based capture). If Extract will target 11.2.0.4 or higher

1.8.1 objects and operations supported in Supported Objects and Operations in Oracle DDL:Oracle DDL

When the source database is Oracle 11.2.0.4 or later and Extract operates in integrated mode, DDL capture support is integrated into the database logmining server and does not require the use of a DDL trigger. You must set the database parameter compatibility to 11.2.0.4.0. In integrated capture mode, Extract supports DDL that includes password-based column encryption

When the source database is Oracle 11.2.0.4 or later and Extract is running in integrated mode, DDL capture support is integrated into the database login server without the need for DDL triggers. You must set the database parameter compatibility to 11.2.0.4.0. In integrated capture mode, Extract supports DDL with password-based column encryption

Note: Password-based column encryption in DDL is not supported in classic capture mode.

The following additional statements apply to both integrated and classic capture modes with respect to DDL support. The following additional instructions apply to the integration and classic capture modes supported by DDL.

Oracle DDL replication supports all Oracle GoldenGate topology configurations. Active (bidirectional) replication of Oracle DDL is supported between two (and only two) databases that contain the same metadata. Oracle GoldenGate supports DDL on the following objects:

The integrated Extract supports Oracle version-based redefinition (EBR) database replication of Oracle DDL for the following Oracle database objects

Oracle GoldenGate supports DDL operations up to 4 MB. Oracle GoldenGate measures the size of DDL statements in bytes, not characters. This size limit includes packages, procedures, and features. The actual size limit supported by DDL is approximate, because the size includes not only the statement text, but also Oracle GoldenGate maintenance overhead, depending on the length of the object name, the DDL type, and other features that internally retain DDL records.

Oracle GoldenGate supports global temporary table (GTT) DDL operations that are visible to Extract so that they can be replicated. You must set the DDLOPTIONS parameter to enable this operation because it is not set by default.

Oracle GoldenGate supports integrated dictionaries for NOUSERID and TRANLOGOPTIONS GETCTASDML. This means that Extract will get object metadata from LogMiner dictionaries instead of DDL triggers without querying dictionary objects. When the source database compatibility parameter is greater than or equal to 11.2.0.4, Oracle GoldenGate automatically uses an integrated dictionary and uses integrated extraction.

Classic Extract does not support integrated dictionary functionality.

When using the integrated dictionary and trace format in Oracle GoldenGate version 12.2.x, if the Oracle database version is earlier than 12.1.0.2, Integrated Capture needs to apply the Logminer patch to the mining database.

1.8.2 objects and operations not supported in Non-supported Objects and Operations in Oracle DDL:Oracle DDL

These statements apply to integrated and classic capture modes.

1.8.2.1 Excluded Objects

1.8.2.2 Other Non-supported DDL

1.9 object names supported and not supported by Supported and Non-supported Object Names

Oracle object names are case insensitive by default, but can be made case-sensitive with the use of double quotes. Oracle GoldenGate supports Oracle case-sensitivity. For information about Oracle GoldenGate support for object names and case, see Administering Oracle GoldenGate for Windows and UNIX.

Oracle object names are not case-sensitive by default, but you can use double quotes to make them case-sensitive. Oracle GoldenGate supports Oracle case sensitivity. For information about Oracle GoldenGate's support for object names and case, see Managing Oracle GoldenGate for Windows and UNIX.

2 Installing Oracle GoldenGate install Oracle GoldenGate

This chapter includes instructions for installing Oracle GoldenGate for the first time. Install Oracle GoldenGate installs all components required to run and manage the process (excluding any components required by other vendors, such as drivers or libraries), and installs the Oracle GoldenGate utility. This chapter includes the following sections:

Understanding and Obtaining the Oracle GoldenGate Distribution

Setting ORACLE_HOME and ORACLE_SID

Setting Library Paths for Dynamic Builds on UNIX

Preparing to Install Oracle GoldenGate Within a Cluster

Installing Oracle GoldenGate

Integrating Oracle GoldenGate into a Cluster

These instructions are for installing Oracle GoldenGate for the first time. Additionally, they are for downloading the base release of a new version of Oracle GoldenGate. These instructions are used to install Oracle GoldenGate for the first time. In addition, they are used to download the base version of the new version of Oracle GoldenGate.

To download and install subsequent patches to the base release, go to the Patches and Updates tab of My Oracle Support at: http://support.oracle.com

To upgrade Oracle GoldenGate from one version to another, follow the upgrade instructions at: http://docs.oracle.com/goldengate/c1221/gg-winux/index.html

2.1 Understanding and Obtaining the Oracle GoldenGate Distribution understand and obtain the Oracle GoldenGate distribution

For complete information about how to obtain Oracle Fusion Middleware software, see "Understanding and Obtaining Product Distributions" in Planning an Installation of Oracle Fusion Middleware.

To download the Oracle WebLogic Server and Coherence software for development or evaluation, see the following location on the Oracle Technology Network (OTN):

Http://www.oracle.com/technetwork/middleware/fusion-middleware/downloads/index.html

For more information about locating and downloading Oracle Fusion Middleware products, see the Oracle Fusion Middleware Download, Installation, and Configuration Readme Files on OTN.

To obtain Oracle GoldenGate follow these steps:

1.Go to Oracle Technology Network.

2.Find the Oracle GoldenGate 12c (12.2.0.1) release and download the ZIP file onto your system.

2.2 Setting ORACLE_HOME and ORACLE_SID sets ORACLE_HOME and ORACLE_SID

Ensure that the ORACLE_HOME and ORACLE_SID system environment variables are set to the correct Oracle instance. When you connect to a database, the Oracle GoldenGate process references them.

If there is one instance of Oracle Database on the system, set the ORACLE_HOME and ORACLE_SID environment variables at the system level. If you cannot set them that way, use the following SETENV statements in the parameter file of every Extract and Replicat group that will be connecting to the instance. The SETENV parameters override the system settings and allow the Oracle GoldenGate process to set the variables at the session level when it connects to the database.

If there is an Oracle database instance on the system, set the ORACLE_HOME and ORACLE_SID environment variables at the system level. If you cannot set it this way, use the following SETENV statement in the parameter file for each extract and copy group that will connect to the instance. The SETENV parameter overrides the system settings and allows the Oracle GoldenGate process to set the variable to the session level when connecting to the database.

SETENV (ORACLE_HOME = "path to Oracle home location")

SETENV (ORACLE_SID = "SID")

If there are multiple Oracle instances 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 process group. As input to the SETENV parameter, use the ORACLE_HOME and ORACLE_SID environment variables to point Oracle GoldenGate to the correct Oracle instance. For example, the following shows parameter files for two Extract groups, each capturing from a different Oracle instance.

If there are multiple Oracle instances on the system that connect Extract and Replicat processes, you need to use the SETENV statement in the parameter file for each process group. As input to the SETENV parameter, use the ORACLE_HOME and ORACLE_SID environment variables to point the Oracle GoldenGate to the correct Oracle instance. For example, the following shows the parameter files for two extract groups, each captured from a different Oracle instance.

Group 1:

EXTRACT ora9a

SETENV (ORACLE_HOME = "/ home/oracle/ora/product")

SETENV (ORACLE_SID = "oraa")

USERIDALIAS tiger1

RMTHOST sysb

RMTTRAIL / home/ggs/dirdat/rt

TABLE hr.emp

TABLE hr.salary

Group 2:

EXTRACT orab

SETENV (ORACLE_HOME = "/ home/oracle/ora/product")

SETENV (ORACLE_SID = "orab")

USERIDALIAS tiger1

RMTHOST sysb

RMTTRAIL / home/ggs/dirdat/st

TABLE fin.sales

TABLE fin.cust

2.3 Setting Library Paths for Dynamic Builds on UNIX: set the dynamically built library path on UNIX

Oracle GoldenGate uses shared libraries. When installing Oracle GoldenGate on a UNIX system, the following must be true before running GGSCI or any other Oracle GoldenGate process:

1. Be sure to add the database library to the system's shared library environment variable. This process is usually performed during database installation. If you have any questions, please consult your database administrator.

When Oracle GoldenGate is running on the same server as the database, all of the following must be 64-bit: Oracle library versions;Oracle GoldenGate version;Database versions

When Oracle GoldenGate connects remotely to the database server through SQL * Net, the following is required:

Replicat: The Oracle client library and the Oracle GoldenGate build must have the same Oracle version, bit type (64-bit or IA64), and operating system version.

Extract: The Oracle client library and the Oracle GoldenGate build must have the same Oracle version, bit type (64-bit or IA64), and operating system version. In addition, both operating systems must be the same endian.

two。 If you will run the Oracle GoldenGate program on a UNIX system from outside the Oracle GoldenGate installation directory

(Optional) Add the Oracle GoldenGate installation directory to the PATH environment variable.

(optional) add the Oracle GoldenGate installation directory to the PATH environment variable.

(Required) Add the Oracle GoldenGate installation directory to the shared-libraries environment variable.

(required) add the Oracle GoldenGate installation directory to the shared library environment variable.

Example 2-2 To Set the Variables in Bourne Shell:

Export PATH=installation_directory:$PATH

Export shared_libraries_variable=absolute_path_of_installation_directory:$shared_libraries_variable

Where shared libraries variable is one of the variables shown in Table 2-1: the shared library variable is one of the variables shown in Table 2-1

Platform Environment variable

LINUX LD_LIBRARY_PATH

Note:

To view the libraries that are required by an Oracle Oracle GoldenGate process, use the ldd goldengate_process shell command before starting the process. This command also shows an error message for any that are missing.

To view the libraries required by the Oracle Oracle GoldenGate process, use the ldd goldengate_process shell command before starting the process. This command also displays any missing error messages.

2.4 Preparing to Install Oracle GoldenGate Within a Cluster installs Oracle GoldenGate in the cluster

This topic describes the installation requirements for installing Oracle GoldenGate in a clustered environment. Oracle GoldenGate can be used with any cluster management solution that automatically fails over. The Oracle Clusterware solution provides the advantage of being able to use with or without Oracle RAC databases, which can include any non-database server running Oracle GoldenGate.

2.4.1 Deciding Where to Install Oracle GoldenGate Binaries and Files in the Cluster

2.4.2 Example Oracle Cluster Storage

2.5 Installing Oracle GoldenGate install Oracle GoldenGate

2.5.1 Performing an Interactive Installation with OUI performs an interactive installation using OUI

OUI is only supported when the database version is 11g or above.

The interactive installation provides a graphical user interface that prompts for the required installation information. These instructions apply to new installations as well as upgrades. However, to perform an upgrade to Oracle GoldenGate, follow the instructions in Upgrading Oracle GoldenGate for Windows and UNIX, which includes a prompt to run OUI at the appropriate time.

Interactive installation provides a graphical user interface that prompts you for the required installation information. These instructions apply to new installations and upgrades. However, to perform an upgrade to Oracle GoldenGate, follow the instructions for upgrading Oracle GoldenGate for Windows and UNIX, including prompts to run OUI at the appropriate time.

2.5.2 Performing a Silent Installation with OUI uses OUI to perform silent installation

You perform a silent installation by running a response file. You can create a response file by selecting the Save Response File option during an interactive OUI session or by editing a template, as shown in Example 2-4. To run a response file, issue the following command.

You can perform a silent installation by running the response file. You can create a response file by selecting the Save response file option during an interactive OUI session or by editing a template, as shown in examples 2-4. To run the response file, issue the following command.

. / runIntailler-silent-nowait-responseFile path_to_file

2.6 Integrating Oracle GoldenGate into a Cluster

If you installed Oracle GoldenGate in a cluster, take the following steps to integrate Oracle GoldenGate within the cluster solution.

For more information about installing and using Oracle GoldenGate in a cluster, see the Oracle GoldenGate with Oracle Real Application Clusters Configuration white paper http://www.oracle.com/technetwork/database/features/availability/maa-goldengate-rac-2007111.pdf.

2.6.1 General Requirements in a Cluster

2.6.2 Adding Oracle GoldenGate as a Windows Cluster Resource

3 Preparing the Database for Oracle GoldenGate prepare Oracle GoldenGate database

This chapter contains steps to take so that the source Oracle Database is configured properly to support the capture of transactional changes.

This chapter contains steps to take to properly configure the source Oracle database to support the capture of transactional changes.

This chapter includes the following sections: this chapter includes the following sections

Configuring Connections for Integrated Processes

Configuring Logging Properties

Enabling Oracle GoldenGate in the Database

Setting Flashback Query

Managing Server Resources

3.1 connection of Configuring Connections for Integrated Processes configuration integration process

If you will be using integrated capture and integrated Replicat, each requires a dedicated server connection in the tnsnames.ora file. You direct the processes to use these connections with the USERID or USERIDALIAS parameter in the Extract and Replicat parameter files when you configure those processes.

If you are going to use integrated capture and integrated Replicat, each requires a dedicated server connection in the tnsnames.ora file. When configuring these processes, you can use the USERID or USERIDALIAS parameters in the extract and copy parameter file to guide the process to use these connections.

Example:

The following is an example of the dedicated connection required for integrated capture (Extract) and integrated Replicat.

TEST =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP) (HOST = test2) (PORT = 1521))

)

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = test)

)

)

The following are the security options for specifying the connection string in the Extract or Replicat parameter file.

Password encryption method:

USERID intext@test, PASSWORD mypassword

Credential store method:

USERIDALIAS ext

In the case of USERIDALIAS, the alias ext is stored in the Oracle GoldenGate credential store with the actual connection string, as in the following example:

GGSCI > INFO CREDENTIALSTORE DOMAIN support

Domain: Support

Alias: ext

Userid: intext@test

For more information about specifying database connection information in the parameter file, see "Administering Oracle GoldenGate for Windows and UNIX".

3.2 Configuring Logging Properties configure logging properties

Oracle GoldenGate relies on redo logs to capture the data needed to replicate the source transaction. Before starting Oracle GoldenGate processing, you must correctly configure the Oracle redo log on the source system.

This section describes the following logging levels that apply to Oracle GoldenGate. The logging level you use depends on the Oracle GoldenGate feature or feature you use.

3.2.1 Enabling Minimum Database-level Supplemental Logging enables minimum database level supplementary logging

Oracle strongly recommends putting the Oracle source database into forced logging mode. Forced logging mode forces the logging of all transactions and loads, overriding any user or storage settings to the contrary. This ensures that no source data in the Extract configuration gets missed.

Oracle strongly recommends that you place the Oracle source database in forced login mode. Force logging mode forces all transactions to be logged and loaded, overwriting any user or reverse storage settings. This ensures that the source data in the extract configuration is not lost.

In addition, minimal supplemental logging, a database-level option, is required for an Oracle source database when using Oracle GoldenGate. This adds row chaining information, if any exists, to the redo log for update operations.

In addition, when using Oracle GoldenGate, the Oracle database requires minimal supplementary logging (database-level options). This adds line link information, if any, to the redo log for update operations.

Database-level primary key (competition) and unique index (UI) logging is strongly discouraged because of the excessive additional overhead it creates on tables outside of replication. Unless those logging options are required for business purposes, you only need to enable minimal supplemental logging at the database level and force logging for Oracle GoldenGate.

Database-level primary key (contention) and unique index (UI) logging are strongly discouraged because it creates additional overhead on tables other than replication. Unless these logging options are required for business purposes, you only need to enable minimal supplementary logging at the database level and enforce logging for Oracle GoldenGate.

Check whether the minimum supplementary log and force logging are enabled:

SELECT supplemental_log_data_min, force_logging FROM v$database

Enable the minimum supplementary log and force logging:

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA

ALTER DATABASE FORCE LOGGING

3.2.2 Enabling Schema-level Supplemental Logging enables schema-level supplementary logging

Oracle GoldenGate supports schema-level supplemental logging. Schema-level logging is required for an Oracle source database when using the Oracle GoldenGate DDL replication feature. In all other use cases, it is optional, but then you must use table-level logging instead (see Enabling Table-level Supplemental Logging).

Oracle GoldenGate supports Schema-level supplementary logging. When using the Oracle GoldenGate DDL replication feature, the Oracle source database requires Schema level logging. In all other use cases, it is optional, but you must use table-level logging (see enabling table-level supplementary logging).

Note: Oracle strongly recommends using schema-level logging instead of table-level logging because it ensures that any new tables added to the schema conform to the wildcard specification.

Perform the following steps on the source system to enable schema-level supplemental logging.

1.Apply Oracle Patch 13794550 to the source Oracle Database if the version is earlier than 11.2.0.2.

2.Run GGSCI on the source system.

3.Issue the DBLOGIN command with the alias of a user in the credential store who has privilege to enable schema-level supplemental logging.

DBLOGIN USERIDALIAS alias

See Reference for Oracle GoldenGate for Windows and UNIX for more information about DBLOGIN and additional options.

4.Issue the ADD SCHEMATRANDATA command for each schema for which you want to capture data changes with Oracle GoldenGate.

ADD SCHEMATRANDATA schema [ALLCOLS | NOSCHEDULINGCOLS]

Where:

Without options, ADD SCHEMATRANDATA schema enables the unconditional supplemental logging on the source system of the primary key and the conditional supplemental logging of all unique key (s) and foreign key (s) of all current and future tables in the given schema. Unconditional logging forces the primary key values to the log whether or not the key was changed in the current operation. Conditional logging logs all of the column values of a foreign or unique key if at least one of them was changed in the current operation. The default is optional to support nonintegrated Replicat but is required to support integrated Replicat because primary key, unique keys, and foreign keys must all be available to the inbound server to compute dependencies. For more information about integrated Replicat, see Deciding Which Apply Method to Use.

ALLCOLS can be used to enable the unconditional supplemental logging of all of the columns of a table and applies to all current and future tables in the given schema. Use to support integrated Replicat when the source and target tables have different scheduling columns. (Scheduling columns are the primary key, the unique key, and the foreign key.)

NOSCHEDULINGCOLS logs only the values of the primary key and all valid unique indexes for existing tables in the schema and new tables added later. This is the minimal required level of schema-level logging and is valid only for Replicat in nonintegrated mode.

In the following example, the command enables default supplemental logging for the finance schema.

ADD SCHEMATRANDATA finance

In the following example, the command enables the supplemental logging only for the primary key and valid unique indexes for the hr schema.

ADD SCHEMATRANDATA hr NOSCHEDULINGCOLS

See Reference for Oracle GoldenGate for Windows and UNIX for more information about ADD SCHEMATRANDATA.

3.2.3 Enabling Table-level Supplemental Logging enables table-level supplementary logging

Enable table-level supplementary logging on the source system when you do not use schema-level logging (see enabling schema-level supplementary logging), prevent primary key logging for any given table, and log non-critical column values at the table level to support specific Oracle GoldenGate features, such as filtering and conflict detection and resolution logic.

Perform the following steps on the source system to enable table-level supplemental logging or use the optional features of the command.

1.Run GGSCI on the source system.

2.Issue the DBLOGIN command using the alias of a user in the credential store who has privilege to enable table-level supplemental logging.

DBLOGIN USERIDALIAS alias

See Reference for Oracle GoldenGate for Windows and UNIX for more information about DBLOGIN and additional options.

3.Issue the ADD TRANDATA command.

ADD TRANDATA [container.] schema.table [, COLS (columns)] [, NOKEY] [, ALLCOLS | NOSCHEDULINGCOLS]

Where:

Container is the name of the root container or pluggable database if the table is in a multitenant container database.

Schema is the source schema that contains the table.

Table is the name of the table. See Administering Oracle GoldenGate for Windows and UNIX for instructions for specifying object names.

ADD TRANDATA without other options automatically enables unconditional supplemental logging of the primary key and conditional supplemental logging of unique key (s) and foreign key (s) of the table. Unconditional logging forces the primary key values to the log whether or not the key was changed in the current operation. Conditional logging logs all of the column values of a foreign or unique key if at least one of them was changed in the current operation. The default is optional to support nonintegrated Replicat (see also NOSCHEDULINGCOLS) but is required to support integrated Replicat because primary key, unique keys, and foreign keys must all be available to the inbound server to compute dependencies. For more information about integrated Replicat, see Deciding Which Apply Method to Use.

ADD TRANDATA with no other options can automatically enable unconditional supplementary logging for primary keys and unique keys and foreign keys for conditional supplementary logging tables. Unconditional logging forces the primary key value to the log, regardless of whether the key is changed during the current operation. The conditional record records all column values of an external or unique key if at least one value in the current operation is changed. The default value is optional to support non-integrated Replicat (see also NOSCHEDULINGCOLS), but integrated Replicat needs to be supported because primary keys, unique keys, and foreign keys must all be available to the inbound server to calculate dependencies. For more information about integrated Replicat, see determining which application method to use.

ALLCOLS enables the unconditional supplemental logging of all of the columns of the table. Use to support integrated Replicat when the source and target tables have different scheduling columns. (Scheduling columns are the primary key, the unique key, and the foreign key.)

ALLCOLS can supplement records unconditionally on all columns of the table. Used to support integrated Replicat when the source and target tables have different scheduling columns. The scheduling column is the primary key, unique key, and foreign key.

NOSCHEDULINGCOLS is valid for Replicat in nonintegrated mode only. It issues an ALTER TABLE command with an ADD SUPPLEMENTAL LOG DATA ALWAYS clause that is appropriate for the type of unique constraint that is defined for the table, or all columns in the absence of a unique constraint. This command satisfies the basic table-level logging requirements of Oracle GoldenGate when schema-level logging will not be used. See Ensuring Row Uniqueness in Source and Target Tables for how Oracle GoldenGate selects a key or index.

NOSCHEDULINGCOLS is only valid for Replicat in non-integrated mode. It uses the ADD SUPPLEMENTAL LOG DATA ALWAYS clause to issue an ALTER TABLE command that applies to the unique constraint type defined for the table, or to all columns that do not have unique constraints. This command meets the basic table-level logging requirements of Oracle GoldenGate when schema-level logging is not used. See determine row uniqueness in the source and target tables to see how Oracle GoldenGate selects a key or index.

COLS columns logs non-key columns that are required for a KEYCOLS clause or for filtering and manipulation. The parentheses are required. These columns will be logged in addition to the primary key unless the NOKEY option is also present.

The COLS column records the non-key columns or filters and actions required by the KEYCOLS clause. Parentheses are required. These columns will be recorded in addition to the primary key, unless the NOKEY option also exists.

NOKEY prevents the logging of the primary key or unique key. Requires a KEYCOLS clause in the TABLE and MAP parameters and a COLS clause in the ADD TRANDATA command to log the alternate KEYCOLS columns.

NOKEY prevents primary or unique keys from being recorded. The KEYCOLS clause in the TABLE and MAP parameters and the COLS clause in the ADD TRANDATA command are required to record the alternate key column.

4.If using ADD TRANDATA with the COLS option, create a unique index for those columns on the target to optimize row retrieval. If you are logging those columns as a substitute key for a KEYCOLS clause, make a note to add the KEYCOLS clause to the TABLE and MAP statements when you configure the Oracle GoldenGate processes.

If you use ADD TRANDATA with the COLS option, create unique indexes on those columns on the target to optimize row retrieval. If you are recording these columns as alternate keys for the KEYCOLS clause, make a note of adding the KEYCOLS clause to the TABLE and MAP statements when you configure the Oracle GoldenGate process.

See Reference for Oracle GoldenGate for Windows and UNIX for more information about ADD TRANDATA.

3.3The Enabling Oracle GoldenGate in the Database enables Oracle GoldenGate in the database

The database services required to support Oracle GoldenGate capture and application must be explicitly enabled for Oracle 11.2.0.4 or later databases. This is required for all modes of Extract and Replicat.

To enable Oracle GoldenGate, set the following database initialization parameters. All instances in Oracle RAC must have the same settings.

ENABLE_GOLDENGATE_REPLICATION = true

For more information about this parameter, see Oracle Database Reference.

3.4 Setting Flashback Query settings flashback query

To process certain update records, Extract fetches additional row data from the source database. Oracle GoldenGate fetches data for the following:

User-defined types

Nested tables

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 image as of a specific time or SCN to match the redo record.

By default, Oracle GoldenGate uses Flashback Query to get values from the undo (rollback) tablespace. In this way, Oracle GoldenGate can reconstruct a read-consistent row image based on a specific time or SCN to match the redo record.

For best fetch results, configure the source database as follows: for the best extraction results, configure the source database as follows

1. Set sufficient redo retention times by setting the Oracle initialization parameters UNDO_MANAGEMENT and UNDO_RETENTION

two。 Use the following formula to calculate the space required in the undo tablespace.

Undo_space = UNDO_RETENTION * UPS + overhead

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

3. For tables that contain LOB, do one of the following:

Set the LOB storage clause to RETENTION. This is the default for tables that are created when UNDO_MANAGEMENT is set to AUTO

If using PCTVERSION instead of RETENTION, set PCTVERSION to an initial value of 25. You can adjust it based on the fetch statistics that are reported with the STATS EXTRACT command (see Table 3-2). If the value of the STAT_OPER_ROWFETCH CURRENTBYROWID or STAT_OPER_ROWFETCH_CURRENTBYKEY field in these statistics is high, increase PCTVERSION in increments of 10 until the statistics show low values.

4.Grant either of the following privileges to the Oracle GoldenGate Extract user:

GRANT FLASHBACK ANY TABLE TO db_user:

GRANT FLASHBACK ON schema.table TO db_user

3.5 Managing Server Resources Management Server Resources

In integrated mode, Extract interacts with the underlying log server in the source database, and Replicat interacts with the inbound server in the target database. This section provides guidance on managing the shared memory used by these servers.

The shared memory used by the server comes from the Streams pool section of the system Global Zone (SGA) in the database. Therefore, you must set the database initialization parameter STREAMS_POOL_SIZE high enough to keep enough memory available for the number of Extract and Replicat processes that you want to run in integrated mode. Note that Streams pools are also used by other components of the database, such as Oracle Streams,Advanced Queuing and Datapump export / import, so be sure to consider them when determining Streams pools for Oracle GoldenGate.

By default, an integrated capture extraction request login server runs with MAX_SGA_SIZE as the number of rows of 1GB, and the PARALLELISM is 2. 5. Therefore, if you run three fetches in integrated capture mode in the same database instance, you need at least 3 GB of memory to the Streams pool. As a best practice, 25% of the Streams pool can be retained. For example, if there are three extracts in integrated capture mode, set the STREAMS_POOL_SIZE to the following:

3 GB + (3 GB * 0.25) = 3.75 GB

4. Establishing Oracle GoldenGate Credentials establishes Oracle GoldenGate certificate

This chapter provides guidelines for creating database users for the processes that will interact with the database, assigning the correct privileges, and securing the credentials from unauthorized use.

This chapter provides guidelines for creating database users for the process of interacting with the database, assigning the correct permissions, and protecting credentials to prevent unauthorized use.

This chapter includes the following sections: this chapter includes the following sections:

Assigning Credentials to Oracle GoldenGate

Securing the Oracle GoldenGate Credentials

4.1 Assigning Credentials to Oracle GoldenGate

The Oracle GoldenGate processes require one or more database credentials with the correct database privileges for the database version, database configuration, and Oracle GoldenGate features that you are using. Create a source database user and a target database user, each one dedicated to Oracle GoldenGate on the source and target systems. The assigned user can be the same user for all of the Oracle GoldenGate processes that must connect to a source or target Oracle Database.

The Oracle GoldenGate process requires one or more database credentials, as well as the correct database permissions for the database version, database configuration, and Oracle GoldenGate features being used. Create source and target database users, each dedicated to Oracle GoldenGate on the source and target systems. For all Oracle GoldenGate processes that must connect to the source or destination Oracle database, the assigned user can be the same user.

The following sections outline the Oracle GoldenGate processes that require user credentials:

Extract User

Replicat User

Other Oracle GoldenGate Users

4.1.1 Extract User

The Extract user performs metadata queries on the source database and fetches data from the source tables when needed. In a local mining deployment of integrated capture, this user also creates, alters, and connects to the logmining server and receives logical change records (LCR) from it. (See Deciding Which Capture Method to Use for more information about capture modes.)

If the source database is a multitenant container database, the Extract user must be a common user and must log into the root container. See Configuring Oracle GoldenGate in a Multitenant Container Database for more information.

You need to assign an additional user if Extract will be operating in integrated capture mode and you are using a downstream mining database. This user will be the mining user and is created in the downstream database. The mining user creates, alters, and connects to the logmining server on the mining database, and it receives logical change records (LCR) from it. This user can be the same as the source Extract user or different. Choose the name of the mining user carefully. Once created by this user, the database logmining server cannot be altered or used by another user. See Configuring a Downstream Mining Database for more information about configuring downstream mining.

4.1.2 Replicat User

The Replicat user creates the Replicat checkpoint table (if used) and applies DML and DDL operations through Oracle Call Interface or through a database inbound server, depending on the Replicat mode. (See Deciding Which Apply Method to Use for more information about Replicat modes.)

Replicat users create Replicat checkpoint tables (if used) and apply DML and DDL operations through the Oracle invocation interface or database inbound server according to the Replicat pattern. (for more information about replication modes, see determining which application method to use. )

4.1.3 Other Oracle GoldenGate Users

A user is required in the source database for the Manager process if you are using Oracle GoldenGate DDL support. This user performs maintenance on the Oracle GoldenGate database objects that support DDL capture.

If you are using Oracle GoldenGate DDL support, you need to use a user for the Manager process in the source database. This user performs maintenance on Oracle GoldenGate database objects that support DDL capture.

4.1.4 Granting the Appropriate User Privileges grants appropriate user permissions

The user privileges that are required for Oracle GoldenGate depend on the database version and the Extract or Replicat process mode. For more information about process modes, see Choosing Capture and Apply Modes.

4.1.4.1 Oracle 11.2.0.4 or Later Database Privileges

4.1.4.2 Oracle 11.2.0.3 or Earlier Database Privileges

4.1.4.3 About the dbms_goldengate_auth.grant_admin_privilege Package

Most of the privileges that are needed for Extract and Replicat to operate in classic and integrated mode are granted through the dbms_goldengate_auth.grant_admin_privilege package.

Most of the permissions required for Extract and Replicat to run in classic and integrated mode are granted through the dbms_goldengate_auth.grant_admin_privilege package.

4.1.4.4 Optional Grants for dbms_goldengate_auth.grant_admin_privilege

Additional grants can be added to dbms_goldengate_auth.grant_admin_privilege to support the optional features shown in Table 4-3.

4.2 Securing the Oracle GoldenGate Credentials

To preserve the 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, an Oracle GoldenGate database user.

In order to maintain the security of the data and accurately monitor Oracle GoldenGate processing, other users, applications, or processes are not allowed to log in or operate as Oracle GoldenGate database users.

Oracle GoldenGate provides different options for securing the login credentials assigned to Oracle GoldenGate processes. The recommended option is to use a credential store. You can create one credential store and store it in a shared location where all installations of Oracle GoldenGate can access it, or you can create a separate one on each system where Oracle GoldenGate is installed.

Oracle GoldenGate provides different options to protect the login credentials assigned to the Oracle GoldenGate process. The recommended option is to use credential storage. You can create a credential store and store it in a shared location accessible to all installations of Oracle GoldenGate, or you can create a separate credential store on each system on which Oracle GoldenGate is installed.

The credential store stores the user name and password for each of the assigned Oracle GoldenGate users. A user ID is associated with one or more aliases, and it is the alias that is supplied in commands and parameter files, not the actual user name or password. The credential file can be partitioned into domains, allowing a standard set of aliases to be used for the processes, while allowing the administrator on each system to manage credentials locally.

The credential store stores the username and password of each assigned Oracle GoldenGate user. The user ID is associated with one or more aliases, which are aliases provided in the command and parameter files, rather than the actual user name or password. You can partition credential files into domains, allowing a set of standard aliases to be used for processes, while allowing administrators on each system to manage credentials locally.

See "Administering Oracle GoldenGate for Windows and UNIX" for more information about creating a credential store and adding user credentials.

For more information about creating credential stores and adding user credentials, see Managing Oracle GoldenGate for Windows and UNIX.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.