Oracle Golden Gate Interview Questions and Answers

GoldenGate supports the following topologies:

• Unidirectional
• Bidirectional
• Peer-to-peer
• Broadcast
• Consolidation
• Cascasding

The replication configuration consists of the following processes:

• Manager
• Extract
• Pump
• Replicate

Macro is an easier way to build your parameter file. Once a macro is written it can be called from different parameter files. Common parameters like username/password and other parameters can be included in these macros. A macro can either be another parameter file or a library.

Goldengate supports both DML and DDL Replication from the source to target.

The following supplemental logging is required.

• Database supplemental logging
• Object level logging

Classic Capture:

• The Classic Capture mode is the traditional Extract process that accesses the database redo logs (optionally archive logs) to capture the DML changes occurring on the objects specified in the parameter files.
• At the OS level, the GoldenGate user must be a part of the same database group which owns the database redo logs.
• This capture mode is available for another RDBMS as well.
• There are some data types that are not supported in Classic Capture mode.
• Classic capture can’t read data from the compressed tables/tablespaces.

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.

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

• EXTRACT NAME
• USERID
• EXTTRAIL
• TABLE

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.

Oracle Goldengate provides 3 types of Encryption.

• Data Encryption using Blow fish.
• Password Encryption.
• Network Encryption.

You can encrypt a password in OGG using

• Blowfish algorithm and
• Advance Encryption Standard (AES) algorithm

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

• 128 bit
• 192 bit and
• 256 bit

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

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

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

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).

ADD CREDENTIALSTORE.

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

GGSCI> INFO CREDENTIALSTORE

OR

GGSCI> INFO CREDENTIALSTORE DOMAIN OracleGoldenGate

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

Encrypt Data with Master Key and Wallet

Encrypt Data with ENCKEYS

The difference between classic mode and coordinated mode is that Replicate is multi-threaded in coordinated mode. Within a single Replicate 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 lag and checkpoint latency of the Extract, pump and Replicate processes are normally monitored.

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.

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:

• 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.

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

Oracle Integrated Delivery is only available for Oracle Databases.

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.

It is equivalent of the Oracle database SCN transaction number.

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.

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