Explore topic-wise InterviewSolutions in .

You MUST use OGG 11.2 and configure GoldenGate INTEGRATED CAPTURE process to extract data from COMPRESSED tables.

Note: Pre OGG 11.2 doesn’t support EXTRACTING data from compressed tables

You must use OGG 11.2 and configure GoldenGate Integrated Capture process to extract data from compressed tables.

Note: Pre OGG 11.2 doesn’t support extracting data from compressed tables

It is recommended that all instances of Oracle GoldenGate be the same VERSION to take ADVANTAGE of the new functionality, but this is not possible all the time and is not required. In this scenario, OGG provides a parameter called ‘FORMAT RELEASE’ which allows customers to use different versions of Oracle GoldenGate Extract, trail files, and REPLICAT together.

EXAMPLE: RmtTrail /u01/app/oracle/dirdat, Format Release 11.1

Note: The input and OUTPUT trails of a data pump must have the same trail file version.

It is recommended that all instances of Oracle GoldenGate be the same version to take advantage of the new functionality, but this is not possible all the time and is not required. In this scenario, OGG provides a parameter called ‘FORMAT RELEASE’ which allows customers to use different versions of Oracle GoldenGate Extract, trail files, and Replicat together.

Example: RmtTrail /u01/app/oracle/dirdat, Format Release 11.1

Note: The input and output trails of a data pump must have the same trail file version.

OGG has 2 functionalities, one it is used for Online data Replication and second for Initial Loading.

If you are replicating data between 2 homogeneous databases then the best method is to use database specific method (Exp/Imp, RMAN, Transportable tablespaces, Physical Standby and so on). Database specific methods are usually faster than the other methods.

—If you are replicating data between 2 heterogeneous databases or your replicat involves complex transformations, then the database specific method can’t be used. In those cases you can ALWAYS use Oracle GoldenGate to perform initial load.

Within Oracle GoldenGate you have 4 different ways to perform initial load.

• Direct Load – Faster but doesn’t SUPPORT LOB data types (12c include support for LOB)
• Direct Bulk Load – Uses SQL*LOAD API for Oracle and SSIS for MS SQL SERVER
• File to replicat – Fast but the rmtfile limit is 2GB. If the table can’t be fit in 1 rmtfile you can use maxfiles but the replicat NEED to be registered on the target OGG home to read the rmtfiles from source.
• File to Database utility – depending on the target database, use SQL*LOAD for Oracle and SSIS for MS SQL SERVER and so on.

Oracle GoldenGate initial loading reads data directly from the source database tables without locking them. So you don’t need downtime but it will use database resources and can cause performance issues. Take extra precaution to perform the initial load during the non-peak time so that you don’t run into resource contention.

OGG has 2 functionalities, one it is used for Online data Replication and second for Initial Loading.

If you are replicating data between 2 homogeneous databases then the best method is to use database specific method (Exp/Imp, RMAN, Transportable tablespaces, Physical Standby and so on). Database specific methods are usually faster than the other methods.

—If you are replicating data between 2 heterogeneous databases or your replicat involves complex transformations, then the database specific method can’t be used. In those cases you can always use Oracle GoldenGate to perform initial load.

Within Oracle GoldenGate you have 4 different ways to perform initial load.

Oracle GoldenGate initial loading reads data directly from the source database tables without locking them. So you don’t need downtime but it will use database resources and can cause performance issues. Take extra precaution to perform the initial load during the non-peak time so that you don’t run into resource contention.

OGG by default ASSUMES that the sources and TARGET tables are IDENTICAL. A table is said to be identical if and only if the table structure, data type and column order are the same on both the SOURCE and the target.

If the tables are not identical you must use the parameter ‘SOURCEDEFS’ pointing to the source table definition and ‘COLMAP’ parameter to map the columns from source to target.

OGG by default assumes that the sources and target tables are identical. A table is said to be identical if and only if the table structure, data type and column order are the same on both the source and the target.

If the tables are not identical you must use the parameter ‘SOURCEDEFS’ pointing to the source table definition and ‘COLMAP’ parameter to map the columns from source to target.

USE the manager PROCESS to delete the extract files after they are consumed by the extract/replicat process

PURGEOLDEXTRACTS /u01/app/oracle/dirdat/et*, USECHECKPOINTS, MINKEEPHOURS 2

Use the manager process to delete the extract files after they are consumed by the extract/replicat process

PURGEOLDEXTRACTS /u01/app/oracle/dirdat/et*, USECHECKPOINTS, MINKEEPHOURS 2

USE the TRANLOGOPTIONS ARCHIVEDLOGONLY OPTION in the PARAMETER FILE.

Use the TRANLOGOPTIONS ARCHIVEDLOGONLY option in the parameter file.

Procedure:

• CHECK to make sure that the Extract has processed all the records in the data source (Online Redo/archive logs)

GGSCI> send extract , logend
(The above command should print YES)

• Verify the extract, pump and replicat has ZERO lag.

GGSCI> send extract , getlag
GGSCI> send extract , getlag
GGSCI> send replicat , getlag

(The above command should pring “At EOF, no more records to PROCESS.”)

• STOP all application and database activity.
• Make sure that the primary extract is reading the end of the redolog and that there is no LAG at all for the PROCESSES.
• Now proceed with stopping the processes:

Source:

• Stop the primary extract
• Stop the pump extract
• Stop the manager process
• Make sure all the processes are down.

Target:

• Stop replicat process
• Stop mgr
• Make sure that all the processes are down.
• Proceed with the maintenance
• After the maintenance, proceed with starting up the processes:

Source:

• Start the manager process
• Start the primary extract
• Start the pump extract

(Or simply all the extract processes as GGSCI> start extract *)

• Make sure all that the processes are up.

Target:

• Start the manager process
• Start the replicat process.
• Make sure that all the processes are up.

Procedure:

GGSCI> send extract , logend
(The above command should print YES)

GGSCI> send extract , getlag
GGSCI> send extract , getlag
GGSCI> send replicat , getlag

(The above command should pring “At EOF, no more records to process.”)

Source:

Target:

Source:

(Or simply all the extract processes as GGSCI> start extract *)

Target:

There are 3 basic RESOURCES REQUIRED:

• Virtual IP
• SHARED storage
• Action SCRIPT

There are 3 basic resources required:

When the source and the target schema objects are not the same (different DDL’s) the REPLICAT process needs to KNOW the source definition of the objects. The OUTPUT from the DEFGEN utility is USED in conjunction with the trail data to determine which column VALUE in the trail belongs to which column.

When the source and the target schema objects are not the same (different DDL’s) the Replicat process needs to know the source definition of the objects. The output from the DEFGEN utility is used in conjunction with the trail data to determine which column value in the trail belongs to which column.

You will have to use the CSV Flat File Adaptor to CREATE CSV files. The SOURCE would be the EXTRACT trail files which use the configuration of the adaptor settings to generate CSV files.

You will have to use the CSV Flat File Adaptor to create CSV files. The source would be the extract trail files which use the configuration of the adaptor settings to generate CSV files.

It is EQUIVALENT of the ORACLE DATABASE SCN transaction NUMBER.

It is equivalent of the Oracle database SCN transaction number.

The steps to be executed would be the following:

• INCLUDE the new table to the Extract & pump PROCESS.
• Obtain starting DATABASE SCN and COPY the source table data to the target database
• Start REPLICAT on target at the source SCN database point.

The steps to be executed would be the following:

Yes with 12C, PERFORMANCE statistics are collected in the AWR REPOSITORY and the DATA is available via the normal AWR reports.

Yes with 12c, performance statistics are collected in the AWR repository and the data is available via the normal AWR reports.

ORACLE INTEGRATED DELIVERY is only AVAILABLE for Oracle DATABASES.

Oracle Integrated Delivery is only available for Oracle Databases.

ORACLE 11.2.0.4 is the the minimum required DATABASE VERSION which supports both Integrated extract and Integrated Reaplicat.

Oracle 11.2.0.4 is the the minimum required database version which supports both Integrated extract and Integrated Reaplicat.

Oracle is able to provide FASTER integration of the NEW database FEATURES by moving the GoldenGate Extraction processes into the database. Due to this, the GoldenGate Integrated EXTRACT has a number of features LIKE Compression which are not supported in the traditional Extract. You can read more about how to upgrade to Integrated Extract and more about Integrated Delivery. Going forward preference should be give to create new extracts as Integrated Extracts and also to upgrade existing traditional Extracts.

Oracle is able to provide faster integration of the new database features by moving the GoldenGate Extraction processes into the database. Due to this, the GoldenGate Integrated Extract has a number of features like Compression which are not supported in the traditional Extract. You can read more about how to upgrade to Integrated Extract and more about Integrated Delivery. Going forward preference should be give to create new extracts as Integrated Extracts and also to upgrade existing traditional Extracts.

You must use the DECRYPT option before viewing data in the Trail data.
List few useful Logdump commands to view and search data stored in OGG trail files.
Below are few logdump commands used on a DAILY basis for displaying or analyzing data stored in a trail file.
$ ./logdump – to connect to the logdump prompt
logdump> open /u01/app/oracle/dirdat/et000001 – to open a trail file in logdump
logdump> fileheader on – to view the trail file header
logdump> ghdr on – to view the record header with data
logdump> DETAIL on – to view COLUMN information
logdump> detail data – to display HEX and ASCII data values to the column list
logdump> reclen 200 – to control how much record data is displayed
logdump> pos 0 – To go to the first record
logdump> next (or simply n) – to move from one record to another in sequence
logdump> count – counting records in a trail

You must use the DECRYPT option before viewing data in the Trail data.
List few useful Logdump commands to view and search data stored in OGG trail files.
Below are few logdump commands used on a daily basis for displaying or analyzing data stored in a trail file.
$ ./logdump – to connect to the logdump prompt
logdump> open /u01/app/oracle/dirdat/et000001 – to open a trail file in logdump
logdump> fileheader on – to view the trail file header
logdump> ghdr on – to view the record header with data
logdump> detail on – to view column information
logdump> detail data – to display HEX and ASCII data values to the column list
logdump> reclen 200 – to control how much record data is displayed
logdump> pos 0 – To go to the first record
logdump> next (or simply n) – to move from one record to another in sequence
logdump> count – counting records in a trail

This occurs when the V$ARCHIVED_LOG.NEXT_CHANGE# is greater than the SCN required by the GoldenGate Capture process and RMAN is trying to delete the archived logs. The RMAN-08147 ERROR is raised when RMAN tries to delete these FILES.

When the database is open it uses the DBA_CAPTURE values to determine the log files required for MINING. However if the database is in the mount state the V$ARCHIVED_LOG. NEXT_CHANGE# value is used.

This occurs when the V$ARCHIVED_LOG.NEXT_CHANGE# is greater than the SCN required by the GoldenGate Capture process and RMAN is trying to delete the archived logs. The RMAN-08147 error is raised when RMAN tries to delete these files.

When the database is open it uses the DBA_CAPTURE values to determine the log files required for mining. However if the database is in the mount state the V$ARCHIVED_LOG. NEXT_CHANGE# value is used.

The LOGDUMP utility is used to open the TRAIL FILES and look at the actual records that have been extracted from the REDO or the archive LOG files.

The logdump utility is used to open the trail files and look at the actual records that have been extracted from the redo or the archive log files.

The RESTARTCOLLISION parameter is used to skip ONE transaction only in a situation when the GoldenGate PROCESS crashed and performed an OPERATION (INSERT, UPDATE & DELETE) in the database but COULD not checkpoint the process information to the checkpoint file/table. On RECOVERY it will skip the transaction and AUTOMATICALLY continue to the next operation in the trail file.

When using HANDLECOLLISION GoldenGate will continue to overwritten and process transactions until the parameter is removed from the parameter files and the PROCESSES restarted.

The RESTARTCOLLISION parameter is used to skip ONE transaction only in a situation when the GoldenGate process crashed and performed an operation (INSERT, UPDATE & DELETE) in the database but could not checkpoint the process information to the checkpoint file/table. On recovery it will skip the transaction and AUTOMATICALLY continue to the next operation in the trail file.

When using HANDLECOLLISION GoldenGate will continue to overwritten and process transactions until the parameter is removed from the parameter files and the processes restarted.

Use the FOLLOWING COMMAND to view the Extract CHECKPOINT INFORMATION.

GGSCI> info extract , showch

GGSCI> info extract ext_fin, showch

Use the following command to view the Extract checkpoint information.

GGSCI> info extract , showch

GGSCI> info extract ext_fin, showch

The WARNLONGTRANS parameter can be SPECIFIED with a threshold time that a transaction can be open before Extract writes a warning message to the GGS error log.

EXAMPLE: WARNLONGTRANS 1h, CHECKINTERVAL 10M

The WARNLONGTRANS parameter can be specified with a threshold time that a transaction can be open before Extract writes a warning message to the ggs error log.

Example: WARNLONGTRANS 1h, CHECKINTERVAL 10m

In OGG you can configure replicat at the data at the schema level or at the table level using TABLE parameter of extract and MAP parameter of replicat.
For REPLICATING the entire database you can list all the schemas in the database in the extract/replicat parameter file.
Depending the amount of redo generation you can split the tables in a schema in multiple extracts and replicats to improve the performance of data REPLICATION. Alternatively youcan also group a set of tables in the confiuration by the application functionality.
Alternatively you may need to REMOVE tables which have long running transactions in a seperate extract process to eliminte lag on the other tables.
Let’s say that you have a schema NAMED SCOTT and it has 100 hundred tables.
Out of these hundred tables, 50 tables are heavily utilized by application.

To improve the overall replication performance you create 3 extract and 3 replicats as follows:
Ext_1/Rep_1 –> 25 tables
Ext_2/Rep_2 –> 25 tables
Ext_3/Rep_3 –> 50 tables
Ext_1/Rep_1 and Ext_2/Rep_2 contains 25 table each which are heavily utilized or generate more redo.
Ext_3/Rep_3 contains all the other 50 tables which are LEAST used.

In OGG you can configure replicat at the data at the schema level or at the table level using TABLE parameter of extract and MAP parameter of replicat.
For replicating the entire database you can list all the schemas in the database in the extract/replicat parameter file.
Depending the amount of redo generation you can split the tables in a schema in multiple extracts and replicats to improve the performance of data replication. Alternatively youcan also group a set of tables in the confiuration by the application functionality.
Alternatively you may need to remove tables which have long running transactions in a seperate extract process to eliminte lag on the other tables.
Let’s say that you have a schema named SCOTT and it has 100 hundred tables.
Out of these hundred tables, 50 tables are heavily utilized by application.

To improve the overall replication performance you create 3 extract and 3 replicats as follows:
Ext_1/Rep_1 –> 25 tables
Ext_2/Rep_2 –> 25 tables
Ext_3/Rep_3 –> 50 tables
Ext_1/Rep_1 and Ext_2/Rep_2 contains 25 table each which are heavily utilized or generate more redo.
Ext_3/Rep_3 contains all the other 50 tables which are least used.

When OPERATING in integrated capture mode, you must make sure that you have assigned sufficient memory to STREAMS_POOL_SIZE. An undersized STREAMS_POOL_SIZE or limiting the STREAMS pool to use a SPECIFIC AMOUNT of memory can cause troubles.

The BEST practice is to allocate STREAMS_POOL_SIZE at the instance level and allocate the MAX. SGA at GG process level as below:

SQL> alter system set STREAMS_POOL_SIZE=3G

TRANLOGOPTIONS INTEGRATEDPARAMS (MAX_SGA_SIZE 2048, PARALLELISM 4)

When operating in integrated capture mode, you must make sure that you have assigned sufficient memory to STREAMS_POOL_SIZE. An undersized STREAMS_POOL_SIZE or limiting the streams pool to use a specific amount of memory can cause troubles.

The best practice is to allocate STREAMS_POOL_SIZE at the instance level and allocate the MAX. SGA at GG process level as below:

SQL> alter system set STREAMS_POOL_SIZE=3G

TRANLOGOPTIONS INTEGRATEDPARAMS (MAX_SGA_SIZE 2048, PARALLELISM 4)

OGG checkpoint provides the FAULT TOLERANCE and make sure that the transaction marked for committed is capture and captured only once. Even if the EXTRACT went down abnormally, when you start the process again it reads the checkpoint FILE to provide the READ consistency and transaction recovery.

OGG checkpoint provides the fault tolerance and make sure that the transaction marked for committed is capture and captured only once. Even if the extract went down abnormally, when you start the process again it reads the checkpoint file to provide the read consistency and transaction recovery.

Some of the possible reasons are:

• Large amount of transactions on a particular table.
• Blocking sessions on the destination DATABASE where non-Goldengate transactions are also taking place on the same table as the replicat PROCESSING.
• If using DBFS, WRITING & reading of trail files may be slow if SGA parameters are not tuned.
• For slow Replicat’s, LATENCY may be due to missing indexes on target.
• Replicat having to process Update, delete of rows in very large tables.

Some of the possible reasons are:

Some of the possible reasons are:

• Long running batch transactions on a table.
• Insufficient memory on the Extract side. Uncommitted, long running transactions can cause WRITING of a transaction to a TEMPORARY area (dirtmp) on disk. Once the transaction is committed it is read from the temporary location on the FILE system and converted to trail files.
• SLOW or overburdened Network.

Some of the possible reasons are:

In pass-through mode, the Extract process does not LOOK up the table definitions, EITHER from the database or from a data definitions file. This increases the THROUGHPUT of the data pump, as the OBJECT definition look-up is bypassed.

In pass-through mode, the Extract process does not look up the table definitions, either from the database or from a data definitions file. This increases the throughput of the data pump, as the object definition look-up is bypassed.

The lag and CHECKPOINT latency of the Extract, pump and Replicat processes are NORMALLY MONITORED.

The lag and checkpoint latency of the Extract, pump and Replicat processes are normally monitored.

The PARAMETERS below can be USED to IMPROVE the REPLICAT PERFORMANCE:

• BATCHSQL
• GROUPTRANSOPS
• INSERTAPPEND

The parameters below can be used to improve the replicat performance:

Yes, Starting with OGG 12c you can now START Extract at a SPECIFIC CSN in the transaction LOG or trail.

Example:

• START EXTRACT fin ATCSN 12345
• START EXTRACT finance AFTERCSN 67890

Yes, Starting with OGG 12c you can now start Extract at a specific CSN in the transaction log or trail.

Example:

Starting with OGG 12c, if you don’t SPECIFY a DISCARDFILE OGG process now generates a dicard file with DEFAULT values whenever a process is started with START COMMAND through GGSCI.

Starting with OGG 12c, if you don’t specify a DISCARDFILE OGG process now generates a dicard file with default values whenever a process is started with START command through GGSCI.

You can create the COORDINATED REPLICATE with the following OGG Command:

ADD REPLICAT rfin, COORDINATED MAXTHREADS 50, EXTTRAIL dirdat/et

You can create the COORDINATED REPLICATE with the following OGG Command:

ADD REPLICAT rfin, COORDINATED MAXTHREADS 50, EXTTRAIL dirdat/et

The difference between classic MODE and coordinated mode is that Replicat is multi-threaded in coordinated mode. Within a single Replicat INSTANCE, multiple threads read the trail independently and APPLY transactions in parallel. Each thread handles all of the filtering, mapping, conversion, SQL construction, and error handling for its ASSIGNED workload. A coordinator thread coordinates the transactions across threads to ACCOUNT for dependencies among the threads.

The difference between classic mode and coordinated mode is that Replicat is multi-threaded in coordinated mode. Within a single Replicat instance, multiple threads read the trail independently and apply transactions in parallel. Each thread handles all of the filtering, mapping, conversion, SQL construction, and error handling for its assigned workload. A coordinator thread coordinates the transactions across threads to account for dependencies among the threads.

In a Coordinated MODE Replicat operates as follows:

• Reads the Oracle GoldenGate trail.
• Performs data filtering, mapping, and conversion.
• Constructs SQL statements that represent source database DML or DDL transactions (in committed order).
• Applies the SQL to the target through the SQL interface that is supported for the given target database, such as ODBC or the NATIVE database interface.

In a Coordinated Mode Replicat operates as follows:

The database services REQUIRED to support ORACLE GoldenGate capture and apply must be ENABLED explicitly for an Oracle 11.2.0.4 database. This is required for all modes of Extract and Replicat.

To ENABLE Oracle GoldenGate, SET the following database initialization parameter. All instances in Oracle RAC must have the same setting.

ENABLE_GOLDENGATE_REPLICATION=true

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

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

ENABLE_GOLDENGATE_REPLICATION=true

In OGG 12c you can ENCRYPT DATA with the following 2 METHODS:

• Encrypt Data with MASTER KEY and Wallet
• Encrypt Data with ENCKEYS

In OGG 12c you can encrypt data with the following 2 methods:

GGSCI> INFO CREDENTIALSTORE
OR
GGSCI> INFO CREDENTIALSTORE DOMAIN OracleGoldenGate

GGSCI> INFO CREDENTIALSTORE
OR
GGSCI> INFO CREDENTIALSTORE DOMAIN OracleGoldenGate

ALTER CREDENTIALSTORE ADD USER userid,
[PASSWORD password]
[ALIAS alias]
[DOMAIN domain]
EXAMPLE: GGSCI> ALTER CREDENTIALSTORE ADD USER GGS@orcl, PASSWORD oracle ALIAS extorcl DOMAIN OracleGoldenGate

ALTER CREDENTIALSTORE ADD USER userid,
[PASSWORD password]
[ALIAS alias]
[DOMAIN domain]
Example: GGSCI> ALTER CREDENTIALSTORE ADD USER GGS@orcl, PASSWORD oracle ALIAS extorcl DOMAIN OracleGoldenGate

ADD CREDENTIALSTORE.

ADD CREDENTIALSTORE.

Steps to CONFIGURE Oracle CREDENTIAL Store are as follows:

• By Default Credential Store is is located under “dircrd” DIRECTORY.

If you want to specify a different location use can specidy “CREDENTIALSTORELOCATION” parameter in GLOBALS file.
Example: CREDENTIALSTORELOCATION /u01/app/oracle/OGG_PASSWD

• Goto OGG home and connect to GGSCI.

cd $OGG_HOME
./ggsci
GGSCI>

Steps to configure Oracle Credential Store are as follows:

If you want to specify a different location use can specidy “CREDENTIALSTORELOCATION” parameter in GLOBALS file.
Example: CREDENTIALSTORELOCATION /u01/app/oracle/OGG_PASSWD

cd $OGG_HOME
./ggsci
GGSCI>

OGG Credential Store MANAGES Encrypted Passwords and USERIDs that are used to interact with the LOCAL database and Associate them with an Alias. INSTEAD of SPECIFYING ACTUAL USERID and Password in a command or a parameter file, you can use an alias. The Credential Store is implemented as an auto login wallet within the Oracle Credential Store Framework (CSF).

OGG Credential Store manages Encrypted Passwords and USERIDs that are used to interact with the local database and Associate them with an Alias. Instead of specifying actual USERID and Password in a command or a parameter file, you can use an alias. The Credential Store is implemented as an auto login wallet within the Oracle Credential Store Framework (CSF).

You can INSTALL Oracle GoldenGate 12C using in 2 ways:

• Interactive INSTALLATION with OUI – Graphical interface
• Silent Installation with OUI – Command Interface

You can install Oracle GoldenGate 12c using in 2 ways:

The following are some of the more interesting features of Oracle GoldenGate 12C:

• Support for Multitenant Database
• Coordinated Replicat
• Integrated Replicat Mode
• Use of Credential store
• Use of Wallet and master key
• Trigger-less DDL REPLICATION
• Automatically adjusts threads when RAC node failure/start
• Supports RAC PDML Distributed TRANSACTION
• RMAN Support for mined archive logs

The following are some of the more interesting features of Oracle GoldenGate 12c:

You can encrypt the password/data USING the AES in three different keys

• 128 BIT
• 192 bit and
• 256 bit

You can encrypt the password/data using the AES in three different keys

You can encrypt a PASSWORD in OGG USING

• Blowfish ALGORITHM and
• ADVANCE ENCRYPTION Standard (AES) algorithm

You can encrypt a password in OGG using

Oracle Goldengate provides 3 TYPES of Encryption.

• Data Encryption USING Blow FISH.
• PASSWORD Encryption.
• Network Encryption.

Oracle Goldengate provides 3 types of Encryption.

Only ONE Extract process can WRITE to one exttrail at a time. So you can’t configure MULTIPLE EXTRACTS to write to the same exttrail.

Only one Extract process can write to one exttrail at a time. So you can’t configure multiple extracts to write to the same exttrail.

The FOLLOWING are the minimum required PARAMETERS which MUST be defined in the extract parameter file.

• EXTRACT NAME
• USERID
• EXTTRAIL
• TABLE

The following are the minimum required parameters which must be defined in the extract parameter file.

Integrated Capture (IC):

• In the Integrated Capture mode, GoldenGate works directly with the database log MINING server to receive the data changes in the form of logical change records (LCRs).
• IC mode does not require any special SETUP for the databases using ASM, transparent data encryption, or Oracle RAC.
• This feature is only available for oracle databases in Version 11.2.0.3 or higher.
• It also supports various object TYPES which were previously not supported by Classic Capture.
• This Capture mode supports EXTRACTING data from source databases using compression.
• Integrated Capture can be configured in an online or downstream mode.

Integrated Capture (IC):