Category: GoldenGate

Approach to Troubleshoot an Abended OGG Process

Oracle GoldenGate is an Heterogeneous replication tool. It is very easy to install and configure Oracle GoldenGate. The real challenge comes when the Processes gets ABEND. Sometimes it is easy to detect problems, but sometimes we will be really not knowing how to proceed or approach to solve or troubleshoot the issue.

This article explains,

1. Levels of Failure in Oracle GoldenGate.
2. The approach to Troubleshoot Oracle GoldenGate.
3. How to identify the issue.
4. What are the files to be looked for Troubleshooting Oracle GoldenGate.
5. Tools to Monitor and Troubleshoot Oracle GoldenGate.

1. LEVELS OF FAILURE

Oracle GoldenGate can Abend or Fail at different levels. There might be many reasons for the Oracle GoldenGate Process failures. The different levels at which the Oracle GoldenGate processes fails or Abends are .,

1. Database Level
2. Network Level
3. Storage Level
4. User Level

a. DATABASE LEVEL OF FAILURE

Oracle GoldenGate also fails if you have issues at the Database Level. Below are some of the issues listed.,

Tablespace filled
Redo log corruption
Archive log destination filled
No Primary Key or Unique Index on the tables
Archive log Mode not enabled
Reset Log performed
Memory Problem with Streams_Pool_Size 
Database Hung

b. NETWORK LEVEL OF FAILURE

Network plays a vital role in the Oracle GoldenGate Replication. For each and every commands you execute in the GGSCI prompt, the Manager Process opens a port. There should be a proper, speedy network between the Source and Target sides. Some of the Network level failures are listed below.,

Network Fails
Network slow
Ports Unavailability
Firewall Enabled

c. STORAGE LEVEL OF FAILURE

There should be sufficient storage space available for the Oracle GoldenGate to keep the Trail files. Even at Oracle Database level, there should be sufficient space to retain the Archive Log files and also space for tablespaces. Proper privileges should be given to the file system so that, Oracle GoldenGate Processes creates the trail files in the location.

File System fills
File System corruption
No Proper privileges given to the File System
Connection Problem between Database Server and Storage
No Free Disks Available in Storage

d. USER LEVEL OF FAILURE

Of course, we users make some mistakes. Some of the user level of failures are below.,

Mistakenly Delete the GoldenGate Admin User at Database level.
Manually Performing Operations like Insert, Delete and Update at Target Side.
Manually deleting / removing the Trail Files either from Source server or Target server.
Forcefully Stopping any Oracle GoldenGate Processes like Manager, Extract, Pump, Collector or Replicat.
Killing the Oracle GoldenGate Processes at OS level.
Performing an ETROLLOVER at Extract / Pump / Replicat Processes.

So we have seen the different levels of Failures in Oracle GoldenGate. How to proceed if you face these failures in your day to day life. What is the approach to identify the issue and solve it.

2. HOW TO APPROACH?

The below are the steps on how to approach to the problem. If the environment is a known one, then you can skip some of the steps.

Learn and Understand the Environment
Operating Provider and Operating System Version
Database Provider and Database Version
Is it a Cluster, Active / Passive?
Oracle GoldenGate UniDirectional or Bi-Directional
If Oracle, then is it a Single Instance or RAC – Real Application Clusters
Is it a Homogeneous or Heterogeneous Environment Replication
Network Flow, Ports Used and Firewalls configured
Components used in Oracle GoldenGate like Extract, Pump, Replicat processes and Trails files.

After seeing all the prerequisites like Environment study etc, check if the Processes are up and running. INFO ALL is the command to check the status of the processes. There are different status of process.

RUNNING
The Process has started and running normally.

STOPPED
The Process has stopped either normally (Controlled Manner) or due to an error.

STARTING
The Process is starting.

ABENDED
The Process has been stopped in an uncontrolled manner. Abnormal End is known was ABEND.

From the above status of the Processes status, RUNNING, STOPPED and ABENDED are common. But what is STARTING? What actually happens when the Oracle GoldenGate process is in this state?

Whenever you start an Abended Extract Process, it will take some time to get started. It is because, the process is getting recovered from its last Abend point. To recover it’s processing state, the Extract Process search back to its Online Redo Log file or Archive log file, to find the first log record for the opened transactions when it is crashed. The more back the Extract Process goes in search, the more it takes to recover itself and get started. So, It takes more time depending upon how long back the Open transaction is in the Redo Logs or Archive Logs.

To check the status of the Extract Process and also to check if it is recovering properly, issue the command.,

THREE BASIC FILES

There are many files which needs to be checked whenever you face issue in Oracle GoldenGate. Out of which Oracle GoldenGate logs the activity in three files.

1. Error Log File – ggserr.log
2. Report File
3. Discard File

4. Trace File
5. Alert Log File
6. DDL Trace File

The first three are the very basic, also can be called as major files which are to be looked in to whenever there are problems in the Oracle GoldenGate. Below, is the explanation for these three files.

What is Error Log file – ggserr.log?

This file is created during the Installation of the Oracle GoldenGate. The file is created in the Oracle GoldenGate home directory with the name ggserr.log. For each installation of Oracle GoldenGate, a ggserr.log file is created in the respective Oracle GoldenGate directory. This file is updated by all the processes of Oracle GoldenGate and the below information are logged in this file.,

 Start and Stop of the Oracle GoldenGate Processes.
 Processing Information like Bounded Recovery operations.
 Error Messages.
 Informational messages like normal operations happening in Oracle GoldenGate.
 WARNING Messages like Long Running Transactions.
 Commands executed in GGSCI Prompt.

The format in which the Oracle GoldenGate processes logs the information in to this ggserr.log file is below.,

You can view this file in the ggsci prompt itself by using the command VIEW GGSEVT. But it is always better to view it using the OS tool as this file can grow a lot. The below is the example.,

So with the ggserr.log file you basically identify the below.,

 What is the Error?
 When the Error occurred?
 How Frequently it occurred?
 What were the operations performed before the Error occurred?
 How Frequently the error occurred?

What is Report File?

A Report file is a process specific log file. Each process has its own report file created and this file is created during the instantiation of the process. This file is stored in the directory /dirrpt and the format of this file is .rpt. This file is automatically renamed on the next instantiation of the process. If a process starts all the log entries for that process are written to its respective report file.

Let’s consider a process called EXT and the report file during instantiation of this process is called as EXT.rpt. If this process is stopped and started again, existing file EXT.rpt will be automatically renamed to EXT0.rpt and a new file will be generated with the name EXT.rpt and this occurs recursively till the value of the sequence reaches 9. If the last report file name for the process EXT is created as EXT9, now during the new file generation, the last file EXT9.rpt will be removed and EXT8.rpt will be renamed as EXT9.rpt. So, the report file with the lower sequence value will be the latest and younger one when compared with older sequence valued report file.

REPORTROLLOVER parameter is used to manually or forcefully create a new report file for the processes. To view the current report of the process the below command is used.,

To get the runtime statistics report of a process, use the below command,

The below information can be seen in the report file of a particular process.,

	Oracle GoldenGate Product Version and Release
	Operating Version, Release, Machine Type, Hostname and Ulimit settings of the respective process
	Memory Utilized by the respective process
	Configured Parameters of the respective Oracle GoldenGate Process
	Database Provider, Version and Release
	Trail files Information
	Mapping of Tables
	Informational messages with respective to a particular process
	Warning messages with respective to a particular process
	Error messages with respective to a particular process
	All DDL Operations performed.
	All the Discarded Errors and Ignored Operations
	Crash dumps
	Any commands which are performed on that particular process.

The below is the example of the Report file which I had split it to many parts so that you will get an clear understanding.

1. Oracle GoldenGate Product Version and Release. Operating Version, Release, Machine Type, Hostname and Ulimit settings of the respective process

2. Configured Parameters of the respective Oracle GoldenGate Process

3. Database Provider, Version, Release and Trail File information.

4. Mapping of tables and Informational messages with respect to the Process.

5. Crash dump and Error messages of the respective process.

Above examples clearly shows the contents of a Report file. So with the help of a Report file, the following can be known,

 In which Trail File the Process gets Abend.
 Whether the Trail File is moving forward?
 Whether the process is getting failed with Same Trail File?
 What operations has been performed before the process abend?
 Whether any errors in the Parameter configuration?
 Whether the MAP statements has the correct table names?

What is Discard File?

A log file for logging failed operations of the Oracle GoldenGate processes. It is mainly used for Data errors. In Oracle GoldenGate 11g, this file is not created by default. We have to mention a keyword DISCARDFILE to enable discard file logging. But from Oracle GoldenGate 12c, this file is generated by default during the instantiation of the process.

The Naming format of the Log file is ., but this file can named manually when enabling. Extension of this file is .DSC and this file is located in the directory /dirrpt

PURGE and APPEND keywords are used in the process parameter files to manually maintain the Discard File. Similar to the Report file, the Discard file can also be rolled over using the keyword DISCARDFILEROLLOVER. The syntax is as below.,

file_name
The relative or fully qualified name of the discard file, including the actual file name.

APPEND
Adds new content to existing content if the file already exists.

PURGE
Purges the file before writing new content.

MAXBYTESn | MEGABYTESn
File size in Bytes. For file size in bytes the valid range is from 1 to 2147483646. The default is 50000000. For file size in megabytes the valid range is from 1 to 2147. The default size is 50MB. If the specified size is exceeded, the process Abends.

NODISCARDFILE
When using this parameter, there will be no discard file creation. It prevents generating the Discard file.

The below is the example for the Discard file parameter used in the Replicat process parameter file.,

The Discard File is mainly used in the Target Side. Each and Every Replicat Process should have its own Discard File. This is a mandatory one.

The below is the example which shows the contents of the Discard file. The Replicat process got Abended due to the error OCI Error ORA-01403 : no data found. The discard file is as below.,

So, we have seen about the three basic and important file where Oracle GoldenGate Processes logs the information. There is also a tool which is used to troubleshoot Oracle GoldenGate during Data corruption or trail file corruption. This is mainly used when Data error occurs in the Oracle GoldenGate.

The tool is called LOGDUMP. It is a very useful tool which allows a user to navigate through the trail file and compare the information of the trail file with the data extracted and replicated by the processes. The below can be seen in the trail file using the LOGDUMP utility.,

 Transactions Information
 Operation type and Time when the Record written.
 Source Object name
 Image type, whether it is a Before Image or After Image.
 Column information with data and sequence information.
 Record length, Record data in ASCII format.
 RBA Information.

The below is the example of the contents of the Trail File.,

Some of the Logdump commands with the description are below., To get in to the logdump prompt, just run the logdump program from the Oracle GoldenGate Home directory.

Logdump 1> GHDR ON – To view the Record Header.

Logdump 2> DETAIL ON – To view the column information.

Logdump 3> DETAIL DATA – To view the Hex and ASCII values of the Column.

Logdump 4> USERTOKEN ON – User defined information specified in the Table of Map statements. These information are stored in the Trail file.

Logdump 4> GGSTOKEN ON – Oracle GoldenGate generated tokens. These tokens contains the Transaction ID, Row ID etc.,

Logdump 5> RECLEN length – Manually control the length of the record.

Logdump 6> OPEN file_name – To open a Trail file.

Logdump 7> NEXT – To move to the next File record. In short, you can use the letter N.

Logdump 8> POS rba – To position to a particular RBA.

Logdump 9> POS FIRST – To go to the position of the first record in the file.

Logdump 10> POS 0 – This is the alternate command for the POS FIRST. Either of this can be used.

Logdump 11> SCANFORENDTRANS – To go to the end of the transaction.

Logdump 12> HELP – To get the online help.

Logdump 13> EXIT – To exit from the Logdump prompt. You can also use QUIT alternatively.

Hope you got a clear view on how to approach to a Oracle GoldenGate problem and also find who stopped the Oracle GoldenGate process and the reason behind it.

Oracle GoldenGate Extract Trail Formats FORMATASCII | FORMATSQL | FORMATXML

By default Oracle GoldenGate will write the trail files in it’s own Canonical Format. But other than this default format, we can make the Extract Process to write the Trail files in the below formats which is offered by Oracle GoldenGate itself.,

ASCII
SQL
XML

In this article, we will see how to make the Extract process to write it’s file in the above formats.

ASCII Format

To make the Extract process write the data in an ASCII format, you need to use the below parameter in the Extract process parameter file,

FORMATASCII

You can format output that is compatible with most database load utilities and other programs that require ASCII input. This parameter is required by the file-to-database-utility initial load method.

A FORMATASCII statement affects all extract files or trails that are listed after it in the parameter file. The relative order of the statements in the parameter file is important. If listed after a file or trail specification, FORMATASCII will not take effect.

All the trail files (extract files) will be affected if they are mentioned or listed after the parameter FORMATASCII in the parameter file.

There are certain limitations needs to be noted when this parameter is used.,

Do not use FORMATASCII

if the data will be processed by the Replicat process. Replicat expects the default canonical format.
if FORMATSQL or FORMATXML is being used.
if the data contains LOBs.
if Extract is connected to a multi-byte DB2 subsystem.
if Oracle GoldenGate DDL support is active.
in pass-through mode in a data pump because there is no table metadata available to generate trail output in the specified form.,

Now, let us see how to use this parameter FORMATASCII and how the output is generated.,

I have a table as below in the source schema and it contains no rows.,

SQL> desc source.t1
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 EMP_ID                                    NOT NULL NUMBER
 EMP_NAME                                           VARCHAR2(20)
 SALARY                                             NUMBER(6)

SQL> select * from source.t1;

no rows selected

Add the parameter to the Extract process parameter file as below,

GGSCI (OGGR2-1.localdomain) 9> view params ext1

EXTRACT EXT1
USERID ggadmin, PASSWORD oracle
FORMATASCII
EXTTRAIL /vol3/ogg/dirdat/et
TABLE source.*;

Let us start the extract now.

GGSCI (OGGR2-1.localdomain as ggadmin@GGDB1) 52> info ext1

EXTRACT    EXT1      Last Started 2017-05-25 18:51   Status RUNNING
Checkpoint Lag       00:00:00 (updated 00:00:02 ago)
Process ID           3106
Log Read Checkpoint  Oracle Redo Logs
                     2017-05-25 18:51:51  Seqno 255, RBA 4478464
                     SCN 0.3646969 (3646969)

Now the Extract EXT1 is started and it is in RUNNING state. Let us insert a record in the table SOURCE.T1 and update it. Check how the data is written in the extract file (trail file)

SQL> insert into source.t1 values(1,'VEERA',1000);

1 row created.

SQL> update source.t1 set salary=2000 where emp_id=1;

1 row updated.

SQL> commit;

Commit complete.

SQL> select * from source.t1;

    EMP_ID EMP_NAME                 SALARY
---------- -------------------- ----------
         1 VEERA                      2000

Let us open the extract file et000000 and check how the record is written.,

[oracle@OGGR2-1 dirdat]$ cat et000000
B,2017-05-28:16:05:37.000000,1495967737,256,
I,A,SOURCE.T1,EMP_ID,'1',EMP_NAME,'VEERA',SALARY,1000
V,B,SOURCE.T1,EMP_ID,'1',SALARY,1000
V,A,SOURCE.T1,EMP_ID,'1',SALARY,2000
C,

In the above output both Before and After images are captured by default. So by default the output contains the below,

1. Database object names, such as table and column names, and CHAR and VARCHAR data are written in the default character set of the operating system.
2. Without specifying any parameter options, FORMATASCII generates records in the following format.

Line 1 contains the following tab-delimited list:

The operation-type indicator: I, D, U, V (insert, delete, update, compressed update).
A before or after image indicator: B or A.
The table name in the character set of the operating system.
A column name, column value, column name, column value, and so forth.
A newline character (starts a new line).

Line 2 contains the following tab-delimited begin-transaction record:

The begin transaction indicator, B.
The timestamp at which the transaction committed.
The sequence number of the transaction log in which the commit was found.
The relative byte address (RBA) of the commit record within the transaction log.
Line 3 contains the following tab-delimited commit record:
The commit character C.
A newline character.

There are lot more options which can used with the FORMATASCII parameter. For complete detail of the options used please check the “Oracle GoldenGate Reference Guide”.

SQL Format

If you want the output of the Extract file in an SQL format then use the below parameter in the Extract process parameter file.

FORMATSQL

This parameter also have some limitations as below,

Do not use FORMATSQL

if the data will be processed by the Replicat process. Replicat expects the default canonical format.
if FORMATASCII or FORMATXML is being used.
if Oracle GoldenGate DDL support is active.
in pass-through mode in a data pump because there is no table metadata available to generate trail output in the specified form.

Now, I have edited the parameter file of the Extract process EXT1 as below,

GGSCI (OGGR2-1.localdomain as ggadmin@GGDB1) 67> view params ext1

EXTRACT EXT1
USERID ggadmin, PASSWORD oracle
FORMATSQL
EXTTRAIL /vol3/ogg/dirdat/et
TABLE source.*;

Now the Extract EXT1 is started and it is in RUNNING state. Let us insert a record in the table SOURCE.T1 and update it. Check how the data is written in the extract file (trail file)

SQL> select * from source.t1;

no rows selected

SQL> insert into source.t1 values(1,'VEERA',1000);

1 row created.

SQL> update source.t1 set salary=2000 where emp_id=1;

1 row updated.

SQL> commit;

Commit complete.

SQL> select * from source.t1;

    EMP_ID EMP_NAME                 SALARY
---------- -------------------- ----------
         1 VEERA                      2000

Let us open the extract file et000000 and check how the record is written.,

[oracle@OGGR2-1 dirdat]$ cat et000000
B,2017-05-28:16:12:43.000000,1495968163,259,
INSERT INTO SOURCE.T1 (EMP_ID,EMP_NAME,SALARY) VALUES ('1','VEERA',1000);
UPDATE SOURCE.T1 SET SALARY=1000 WHERE EMP_ID='1';
UPDATE SOURCE.T1 SET SALARY=2000 WHERE EMP_ID='1';
C,

The default output is as below,
Database object names, such as table and column names, and CHAR and VARCHAR data are written in the default character set of the operating system.

Without options, FORMATSQL transactions are output as follows, in comma-delimited format:

The begin-transaction indicator, B.
The timestamp at which the transaction was committed.
The sequence number of the transaction log in which the commit was found.
The relative byte address (RBA) of the commit record within the transaction log.
The SQL statements.
The commit indicator, C.
A newline indicator.

This parameter FORMATSQL has three options which are below,

NONAMES

Omits column names for insert operations, because inserts contain all column names. This option conserves file size.

NOPKUPDATES

Converts UPDATE operations that affect columns in the target primary key to a DELETE followed by an INSERT. By default (without NOPKUPDATES), the output is a standard UPDATE operation.

ORACLE

Formats records for compatibility with Oracle databases by converting date and time columns to a format accepted by SQL*Plus.

For complete detail of the options used please check the “Oracle GoldenGate Reference Guide”.

XML Format

If you want the output of the Extract file in an XML format then use the below parameter in the Extract process parameter file.

FORMATXML

This parameter also have some limitations as below,

Do not use FORMATXML

if the data will be processed by the Replicat process. Replicat expects the default canonical format. Do not use FORMATXML if FORMATASCII or FORMATSQL is being used.
if Extract is connected to a multi-byte DB2 subsystem.
if Oracle GoldenGate DDL support is active.
in pass-through mode in a data pump because there is no table metadata available to generate trail output in the specified form.

Now, I have edited the parameter file of the Extract process EXT1 as below,

GGSCI (OGGR2-1.localdomain as ggadmin@GGDB1) 86> view params ext1

EXTRACT EXT1
USERID ggadmin, PASSWORD oracle
FORMATXML
EXTTRAIL /vol3/ogg/dirdat/et
TABLE source.*;

Now the Extract EXT1 is started and it is in RUNNING state. Let us insert a record in the table SOURCE.T1 and update it. Check how the data is written in the extract file (trail file)

SQL> select * from source.t1;

no rows selected

SQL> insert into source.t1 values(1,'VEERA',1000);

1 row created.

SQL> update source.t1 set salary=2000 where emp_id=1;

1 row updated.

SQL> commit;

Commit complete.

SQL> select * from source.t1;

    EMP_ID EMP_NAME                 SALARY
---------- -------------------- ----------
         1 VEERA                      2000

Let us open the extract file et000000 and check how the record is written.,

The parameter FORMATXML have below options which can used along with this.,

ENCODING UTF-8

Outputs the full sized XML to the XML file in UTF-8, but does not output headers.
The XML header tag and root node are included in the XML output. The root node is output as OracleGoldenGateFormatXML.
Regardless of their size, XML stored as CLOB is output in a CDATA section and binary data including BLOB is output to Base64 encoding.

INLINEPROPERTIES | NOINLINEPROPERTIES

Controls whether or not properties are included within the XML tag or written separately. INLINEPROPERTIES is the default.

TRANS | NOTRANS

Controls whether or not transaction boundaries and commit timestamps should be included in the XML output. TRANS is the default.

For complete detail of the options used please check the “Oracle GoldenGate Reference Guide”.

Hope this was helpful. Your comments and suggestions are always welcome.

Cheers,
Veera 🙂

Oracle GoldenGate Veridata 122 Step by Step Installation

Oracle GoldenGate Veridata is a high-speed data-comparison and repair solution that identifies, reports on, and fixes data discrepancies between heterogeneous databases without interrupting ongoing business processes.

This post explains the step by step installation and configuration of Oracle GoldenGate Veridata 12.2 in Linux.

The first and primary point to be considered before installing any Binaries are the Pre-requisites. For installing the Oracle GoldenGate Veridata, below are the pre-requisites which needs to be taken care.

Certification and System Requirements - Check if the hardware or software configuration supports the product which you are going to install.
Install JDK on the Target Machine -  A minimum of JDK 1.8.0_101 or higher is required.
Install Oracle WebLogic Server - Oracle Fusion Middleware 12.2.1.2.0 Infrastructure installer to install Oracle WebLogic Server and the Oracle Java Required Files (JRF) Infrastructure services.

You can either download it from the below links,

http://www.oracle.com/technetwork/developer-tools/adf/downloads/index.html
or 
https://edelivery.oracle.com/

Install a Certified Database for Configuring Veridata Repository - Oracle GoldenGate Veridata supports the following databases:
Oracle
Microsoft SQL Server

You can refer the Installation Guide below for more information on the Pre-requisites,

https://docs.oracle.com/goldengate/v12212/gg-veridata/GVDIS/GVDIS.pdf

So, now let us go into the Installation part.

INFRASTRUCTURE INSTALLATION

Firstly, we need to install both WebLogic Server (WLS) and the Oracle Fusion Middleware (FMW) Infrastructure.

1. Open a terminal and run the below command,

java -jar fmw_12.2.1.0.0_infrastructure.jar


2. A welcome screen appears. Just click Next button.

3. Check the option Skip Auto Updates and proceed.

4. Enter the location for Oracle Home to store the binary files.

5. Select either installation type, with or without examples. Notice at the bottom that WLS is going to be installed.

6. Wait for the progress bar to reach 100%. The minimum Java version that it is looking for is greater than 1.8. Here, in my installation, it threw a warning and I ignored it as I had already jdk 1.8 installed.

7. If you want to enter your email, you may. Otherwise, accept the warning that it is blank.

8. An Installation summary is displayed. Simply press the Install button below.

9. Wait for the progress bar to reach 100%. You can optionally view the logs.

10. Click the Finish Button.

Now we have successfully install the Infrastructure Binaries. The second step is to install the Oracle GoldenGate Veridata.

INSTALLATION OF ORACLE GOLDENGATE VERIDATA

Open a terminal session and execute the below command to invoke the Veridata Installation Screen,

java -jar fmw_12.2.1.0.0_ogg.jar

2. A welcome screen appears. Just click Next button.

3. Check the option Skip Auto Updates and proceed.

4. Enter the location for Oracle Home to store the binary files.

5. Select either installation type. Here we are going to install Veridata Server. You can install this in two ways

1. Oracle GoldenGate Veridata Server and Agent together (or)
2. Oracle GoldenGate Veridata Server separately and Oracle GoldenGate Veridata Agent separately.

Here I am selecting the “Oracle GoldenGate Veridata Server and Agent” as my installation type.
Click Next button

6. Wait for the progress bar to reach 100%. The minimum Java version JDK 1.8.0_101 or higher is required.

7. A summary page is displayed. Just click Next Button.

8. Wait for the progress bar to reach 100%. You can view the Logs by clicking the “View Log” button in the right bottom of the screen.

9. Installation is complete. Click the Finish button.

The beauty in here is, it tells you what is the next step you need to perform. This you can see in the bottom of the “Installation Complete” screen.

REPOSITORY CREATION (RCU)

The Repository Creation Utility (RCU) presumes that you have already installed a compatible database to house the repository.

1. Open a Terminal and Invoke the RCU by issuing the below command.

2. As usual a Welcome Screen appears. Click Next.

3. By default “System Load and Product Load” will be checked. Click the Next button

4. Enter the appropriate information to log in to your database with full privileges.

5. If this is the first time you have run RCU, then the only option is to create a new prefix. If you have run RCU in the past, then it will increment the new prefix to be one more than the last existing one, for example, DEV2 or DEV3. You can override the suggestion.

6. Select Oracle GoldenGate, Veridata Repository.

7. Enter the same password twice. Many of the sample VM databases use oracle (all lower case) as the default password for all schemas.

8. The respective Tablespaces will be created. Accept the default tablespace allocations.

9. A Summary Page will be displayed. Simply click on the Create button.

10. The Repository is created and you can see the details in the screen.

11. Click on the rcu.log to check the logs else you can click the Close button.

DOMAIN CREATION

The Configuration Wizard can either create a new domain or extend an existing domain. Here, I am creating a new Domain.

1. Open a terminal session. Invoke the Configuration wizard by entering

2. It will ask whether you need to create a new domain or extend an existing one. Select the 1st option “Create a new domain”. Provide the domain location and click on Next button.

3. Check if the Basic WebLogic Server Domain is pre-selected and then select Veridata Standard Server Domain. This will cause additional options to be selected automatically. If Oracle JRF is not auto-selected, then you did not install the Infrastructure correctly. Click on Next to continue.

4. Enter the same password twice for the WebLogic Administrator Account. Complexity rules require a number or special character in the password. Click on Next to continue.

5. If you plan to use localhost/127.0.0.1 as the host name/address, you must select Development. In production you would not use localhost, but would use the real host name/address. Click on Next to continue.

6. Fill in the Service, Host Name, Port, Schema, and Password. Click Get RCU Configuration to continue.

7. You must receive the message “Successfully Done.” Click Next to continue.

8. Verify that the host names and passwords are all filled in. Click on Next.

9. The “Test Selected Connections” happens automatically. Looking in the result log, make sure all six are successful. Click on the Next Button.

10. Enter the Password and Click on the Next button.

11. Select the Administration Server and click the Next button to continue.

12. Provide the port details and click on Next to continue.

13. You will see the Configuration Summary page. Just click the Create button.

14. When the progress bar reaches 100%, it should say, “Domain Created Successfully!”. Click the Next to continue.

15. Note the URLs to use from a web browser to reach the WebLogic Administration Console. Often there are two: an http URL which is insecure, and an https URL which uses SSL for increased security. Click on the Finish button.

START WEBLOGIC SERVER

Start the WebLogic Server by issuing the below command.

cd /vol3/oracle/user_projects/domains/base_domain/bin

sh startWebLogic.sh

Open the below URL.

http://oggr2-1.localdomain:7001/login/LoginForm.jsp

Enter the username and password. Click the Login button.

You will be entered into the WebLogic Server.

START VERIDATA SERVER

Start the WebLogic Server by issuing the below command.

cd /vol3/oracle/user_projects/domains/base_domain/veridata/bin

sh veridataServer.sh start

Provide the username and password.

You could see the below message in the screen.

Server state changed to RUNNING.

VERIDATA SERVER USER CREATION

Now we need to create a user for accessing the Veridata GUI. Navigate to the below page.

Home >Summary of Servers >Summary of Security Realms >myrealm >Users and Groups >weblogic >Users and Groups >Summary of Security Realms >myrealm >Users and Groups

1. Click on the New Tab

2. Create the new user. Enter the username and password. Click OK button.

3. You could see the message “User created successfully” and the user will be displayed in the list.

4. Now click on the veridata user. Click on Groups tab and select all the Veridata related groups and move them

5. Click on the Save button. You could see the message “Settings updated successfully”.

CONFIGURATION OF AGENT

1. Deploy the Agent as below.

1a. Under the Middleware home, navigate to the directory “veridata/agent”. You could see the file “agent_config.sh”. Execute the file as below,

sh agent_config.sh AGENT_HOME

You will see the message as “Successfully deployed the agent”.

2. Start the Agent as below.

2a. Under the Agent Home where you deployed the Agent, there will be a file named as “agent.properties.sample”. Take a backup of this and rename it as “agent.properties”.

2b. Edit the “agent.properties” file and give the port and jdbc url as below.

2c. Start the Agent as below. Navigate to the Agent Home and issue the below command.

cd /vol3/oracle/Agent
./agent.sh start agent.properties

Now login to the Veridata Server using the below URL

http://oggr2-1.localdomain:8830/veridata/login.jsf

Now you can perform your tasks like Comparison, Repair etc., using Oracle GoldenGate Veridata

TO BE NOTED IN WINDOWS

When installing in Windows, there is a slight change in starting the Agent after deploying it. You need to create the Agent as a service in Windows. I had already performed the installation in Windows and this is how it should be done.

Go to the below location and edit the agent_services.properties file.

C:\oracle\Middleware\Oracle_Home\Agent\service

_VERIDATA_SERVICE_NAME=

Give a name to the agent as below,

_VERIDATA_SERVICE_NAME=VAgent

Install the Agent as below.

Now start the Veridata Agent using the below command.

Start_Veridata_Agent.bat agent_service.properties

Hope you enjoyed this article. Your comments and suggestions are always welcome.

Cheers
Veera

Oracle GoldenGate 12.2 New Feature – Performance Toolkit Monitor

One of the features which I like most and released in Oracle GoldenGate 12.2 is the Oracle GoldenGate Performance Toolkit Monitor. This is a monitoring tool with Graphical User Interface programmed in JAVA.

The Performance Toolkit Monitor provides new metrics for diagnostics and tuning which includes the below.,:

CPU
I/O
Transactions in flight
Cache memory usage and statistics
Improved capture and apply performance

A simple jar file “OGGPTK.jar” needs to be run in the server to invoke this Performance Monitor tool. This free java program jar file can be downloaded from the below link,

https://java.net/projects/oracledi/downloads/download/GoldenGate/OGGPTK.jar

I have two Virtual Machines installed with Oracle GoldenGate 12.2.x

Virtual Machine 1 - OGGR2-1 - 192.168.0.10 - Manager, Extract and Extract Pump

Virtual Machine 2 - OGGR2-2 - 192.168.0.11 - Manager and Replicat

I had downloaded and copied the OGGPTK.jar file in the J:\OGGPTK.jar, This is my host machine where I had installed Virtual Box and have two Virtual Machines as mentioned above. The two virtual machines are already started and all the Oracle GoldenGate processes like Extract, Pump and Replicat are running currently.

picture1

picture2

Firstly, I need to start the OGGPTK.jar using the java command as below,

picture3

picture4

Oracle GoldenGate Performance Tool Kit window will be opened.

picture5

To monitor the GoldenGate instance, connection configuration must be done as below.,

picture6

picture7

Hostname of the Oracle GoldenGate instance and the Port of the Manager process running in that respective instance must be given as below. Save the configuration.

picture8

picture9

I have already configured the connection for my OGG instances. To start monitoring the Oracle GoldenGate instances go to File–>Connect–>Click the Connection Name

picture10

I have selected my Source OGG instance and the Monitoring windows for that instance will be opened as below. Click on any Process in the Left pane. For example Extract Process,

picture11

The below information can be seen in the OGGPTK window,

Process Performance
Thread Performance
Status and Configuration
Trail Files
Cache Statistics
Database Statistics
Queue Statistics
Inflight Transactions

Let us see what information each tab gives us.,

Thread Performance

picture12

Status and Configuration

picture13

Trail Files

picture14

Cache Statistics

picture15

Database Statistics

picture16

Queue Statistics

picture17

Inflight Transactions

picture18

The same kind of information we can see for the other Oracle GoldenGate processes in the instances too..

Hope this is helpful..!! Your comments and suggestions are always welcome. Thanks for your continuous support 🙂

Oracle GoldenGate 12.2 New Feature – New GoldenGate Extended Metrics

Oracle GoldenGate Extended Metrics provides the real-time insight of the Oracle GoldenGate processes Extract, Extract Pump and Replicat. This can be accessed through the RESTful Web Interface.

The New Metrics provides the below information,

Status and Configuration Information

Process and Thread Level Metrics for Extract, Pump and Replicat

Database Statistics for Extract and Replicat & Network Statistics for Pump

In-flight transactions and queue statistics for Extract

Table statistics for Replicat

This is a fine grained performance monitoring window which can be accessed through the RESTful Web Services as below,

extmetrics5

I have two Virtual Machines installed with Oracle GoldenGate 12.2.x

Virtual Machine 1 - OGGR2-1 - 192.168.0.10 - Manager, Extract and Extract Pump

Virtual Machine 2 - OGGR2-2 - 192.168.0.11 - Manager and Replicat

Below is how the information is displayed.,

General and Status information of the Extract process EXT1

Configuration information of the Extract process

Database information where the Extract Process EXT1 is running

Trail File information of the Extract process EXT1

Position, Lag and Checkpoint information of the Extract process EXT1

Performance information of the Extract process EXT1

extmetrics

extmetrics2

extmetrics3

Similar information can be seen for the Replicat process also which is running in the other virtual machine

extmetrics4

This is an excellent tool to monitor the progress and performance of the Oracle GoldenGate processes.

Oracle GoldenGate Integration with DATAPUMP – DBOPTIONS ENABLE_INSTANTIATION_FILTERING – Oracle GoldenGate 12.2 New Feature

There are many methods to perform the Initial Load before starting the Online Replication or Real Time Replication processes in Oracle GoldenGate. They are as below,

1. Oracle Transportable Tablespaces
2. Oracle Export / Import or Datapump (Expdp / Impdp)
3. RMAN
4. Oracle Warehouse Builder or Some third party tools like ETL etc.,

Oracle GoldenGate offers different types of Initial Loads.

1. File to Replicat
2. File to Database Utility
3. Direct Load
4. Direct Bulk Load.

In this article, we are going to see about Performing Initial Load with Oracle DataPump Utility (Expdp/Impdp). The below are the basic steps to perform the Initial Load using the Oracle DATAPUMP (Expdp/Impdp).

1. Create the necessary tables (only structures) on the Target side.
2. Start the Change Synchronization Capture / Online Extract process.
3. Start the Datapump Process.
4. Check the current scn of the database using the below command,

select current_scn from V$database;

5. Export the table from Source with the following parameter in the EXPDP flashback_scn=.
6. Import the table dump in the Target.
7. Start the Online Replication process on the Target with the below command,

start replicat , aftercsn

So many steps to be followed to do the Initial Load using Expdp/Impdp. Here the SCN plays a vital role to maintain the Data Integrity. From Oracle GoldenGate 12.2, this method of Initial Load using DATAPUMP utility has been made in more simpler way.

From Oracle GoldenGate 12.2, there is a new feature introduced. Below are the parameters,

ADD SCHEMATRANDATA|TRANDATA SCHEMA|SCHEMA.TABLE PREPARECSN

DBOPTIONS ENABLE_INSTANTIATION_FILTERING

You don’t want to note down the SCN and this will be taken care automatically when executing the ADD SCHEMATRANDATA or ADD TRANDATA command with the optional parameter PREPARECSN at the Oracle GoldenGate level.

ADD SCHEMATRANDATA SCHEMA PREPARECSN

ADD TRANDATA SCHEMA.TABLE PREPARECSN

When you use this parameter PREPARECSN when adding the trandata, it automatically prepares the SCN for that particular table or schema and the SCN part is automatically takencare. There is no requirement of noting down the SCN (FLASHBACK_SCN) over here.

WAIT - Wait for any in-flight transactions and prepare table instantiation.
LOCK - Put a lock on the table (to prepare for table instantiation).
NOWAIT - Default behavior, preparing for instantiation is done immediately.
NONE - No instantiation preparation occurs.

This is at the Source Side. At the Target side, you need to add the below parameter to the Replicat process parameter file,

DBOPTIONS ENABLE_INSTANTIATION_FILTERING

This parameter let’s the Replicat process know after which CSN it should start replicating or applying the data to the Target tables. On the target, the data pump import populates the system tables and views with instantiation SCNs using the DBOPTIONS ENABLE_INSTANTIATION_FILTERING parameter to enable table-level instantiation filtering. So the parameter,

1. Filters out DDL and DML records based on each table’s instantiation CSN

2. Eliminates need for HANDLE_COLLISIONS or specification of individual MAP for each imported table with the @FILTER(@GETENV(‘TRANSACTION’,‘CSN’) clause.

Let us see below in detail on how this feature works.

On the Source side, I have created table VEERA.TEST as below,

SQL> create table veera.test as select * from dba_objects;

Table created.
SQL> desc veera.test
Name                Null?    Type
------------------ --------- --------------
OWNER                        VARCHAR2(30)
OBJECT_NAME                  VARCHAR2(128)
SUBOBJECT_NAME               VARCHAR2(30)
OBJECT_ID                    NUMBER
DATA_OBJECT_ID               NUMBER
OBJECT_TYPE                  VARCHAR2(19)
CREATED                      DATE
LAST_DDL_TIME                DATE
TIMESTAMP                    VARCHAR2(19)
STATUS                       VARCHAR2(7)
TEMPORARY                    VARCHAR2(1)
GENERATED                    VARCHAR2(1)
SECONDARY                    VARCHAR2(1)
NAMESPACE                    NUMBER
EDITION_NAME                 VARCHAR2(30)
SQL> select count(1) from veera.test;

COUNT(1)
----------
88803

At the OGG level, I am executing the ADD SCHEMATRANDATA with the PREPARECSN option.

GGSCI (OGGR2-1.localdomain as ggadmin@GGDB1) 4> ADD SCHEMATRANDATA VEERA PREPARECSN

2016-09-30 12:02:18 INFO OGG-01788 SCHEMATRANDATA has been added on schema VEERA.

2016-09-30 12:02:18 INFO OGG-01976 SCHEMATRANDATA for scheduling columns has been added on schema VEERA.

2016-09-30 12:02:18 INFO OGG-10154 Schema level PREPARECSN set to mode NOWAIT on schema VEERA.
GGSCI (OGGR2-1.localdomain as ggadmin@GGDB1) 5> INFO SCHEMATRANDATA VEERA

2016-09-30 12:02:43 INFO OGG-06480 Schema level supplemental logging, excluding non-validated keys, is enabled on schema VEERA.

2016-09-30 12:02:43 INFO OGG-01980 Schema level supplemental logging is enabled on schema VEERA for all scheduling columns.

2016-09-30 12:02:43 INFO OGG-10462 Schema VEERA have 1 prepared tables for instantiation.

In the above output, you can clearly see the message Schema VEERA has been prepared for instantiation.

Already the Manager process was started and now I have started the Extract and Pump processes.

GGSCI (OGGR2-1.localdomain as ggadmin@GGDB1) 15> info all

Program Status Group Lag at Chkpt Time Since Chkpt

MANAGER RUNNING
EXTRACT RUNNING DMP1 00:00:00      00:00:07
EXTRACT RUNNING EXT1 00:00:00      00:00:00

Now, let us take an export of the schema VEERA. Here we do not need to mention any SCN (FLASHBACK_SCN) for taking an Export.

[oracle@OGGR2-1 ~]$ expdp directory=DATA_PUMP_DIR dumpfile=test.dmp tables=veera.test

[oracle@OGGR2-1 ~]$ expdp directory=DATA_PUMP_DIR dumpfile=test.dmp tables=veera.test

Export: Release 11.2.0.4.0 - Production on Fri Sep 30 12:11:13 2016

Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.

Username: / as sysdba

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
FLASHBACK automatically enabled to preserve database integrity.
Starting "SYS"."SYS_EXPORT_TABLE_01": /******** AS SYSDBA directory=DATA_PUMP_DIR dumpfile=test.dmp tables=veera.test
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 21 MB
Processing object type TABLE_EXPORT/TABLE/PROCACT_INSTANCE
Processing object type TABLE_EXPORT/TABLE/TABLE
. . exported "VEERA"."TEST" 8.618 MB 88803 rows
Master table "SYS"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded
******************************************************************************
Dump file set for SYS.SYS_EXPORT_TABLE_01 is:
/oracle/admin/GGDB1/dpdump/test.dmp
Job "SYS"."SYS_EXPORT_TABLE_01" successfully completed at Fri Sep 30 12:11:25 2016 elapsed 0 00:00:04

The Export (Expdp) has completed successfully. But during the course of the Expdp, I had inserted more rows in to the table VEERA.TEST and these rows are not captured in the export dump. The count before exporting and the count in the Expdp is same 88803.

SQL> insert into veera.test (select * from dba_objects);

88803 rows created.

SQL> commit;

Commit complete.

SQL> select count(1) from veera.test;

COUNT(1)
----------
177606

Since I had inserted more rows, the current count of the table is 177606.

At the Target side, edit the parameter of the Replicat process parameter file REP1 and add the below parameter,

DBOPTIONS ENABLE_INSTANTIATION_FILTERING
GGSCI (OGGR2-2.localdomain as ggadmin@GGDB2) 13> view params rep1

REPLICAT REP1
USERID ggadmin, PASSWORD oracle
MAP veera.test, TARGET veera.test;
GGSCI (OGGR2-2.localdomain as ggadmin@GGDB2) 15> view params rep1

REPLICAT REP1
USERID ggadmin, PASSWORD oracle
DBOPTIONS ENABLE_INSTANTIATION_FILTERING
MAP veera.test, TARGET veera.test;

Already same table VEERA.TEST has been created in the Target side which you can see below,

SQL> desc veera.test
Name                Null?    Type
------------------ --------- --------------
OWNER                        VARCHAR2(30)
OBJECT_NAME                  VARCHAR2(128)
SUBOBJECT_NAME               VARCHAR2(30)
OBJECT_ID                    NUMBER
DATA_OBJECT_ID               NUMBER
OBJECT_TYPE                  VARCHAR2(19)
CREATED                      DATE
LAST_DDL_TIME                DATE
TIMESTAMP                    VARCHAR2(19)
STATUS                       VARCHAR2(7)
TEMPORARY                    VARCHAR2(1)
GENERATED                    VARCHAR2(1)
SECONDARY                    VARCHAR2(1)
NAMESPACE                    NUMBER
EDITION_NAME                 VARCHAR2(30)

I had moved the Export Dump file to the Target server using the SCP and I am importing the dump using the IMPDP utility as below,

[oracle@OGGR2-2 ~]$ impdp directory=DATA_PUMP_DIR dumpfile=test.dmp full=y

Import: Release 11.2.0.4.0 - Production on Fri Sep 30 12:28:23 2016

Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.

Username: / as sysdba

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Master table "SYS"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "SYS"."SYS_IMPORT_FULL_01": /******** AS SYSDBA directory=DATA_PUMP_DIR dumpfile=test.dmp full=y
Processing object type TABLE_EXPORT/TABLE/PROCACT_INSTANCE
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
. . imported "VEERA"."TEST" 8.618 MB 88803 rows
Job "SYS"."SYS_IMPORT_FULL_01" successfully completed at Fri Sep 30 12:28:36 2016 elapsed 0 00:00:04
SQL> select count(1) from veera.test;

COUNT(1)
----------
88803

So, 88803 rows are imported to the table VEERA.TEST at the Target side. The rows which are inserted during the Export at the source are not come here.

Start the Replicat process REP1.

GGSCI (OGGR2-2.localdomain as ggadmin@GGDB2) 27> start replicat rep1

Sending START request to MANAGER ...
REPLICAT REP1 starting

The Replicat process REP1 has started and it is in RUNNING state.

GGSCI (OGGR2-2.localdomain as ggadmin@GGDB2) 28> info all

Program  Status  Group Lag at Chkpt  Time Since Chkpt

MANAGER  RUNNING
REPLICAT RUNNING REP1  00:00:00      00:00:06

Below is the report file of the Replicat process REP1.

2016-09-30 12:37:34 INFO OGG-02243 Opened trail file /ogg/dirdat/ft000000004 at 2016-09-30 12:37:34.103888.

2016-09-30 12:37:34 INFO OGG-03522 Setting session time zone to source database time zone 'GMT'.

2016-09-30 12:37:34 INFO OGG-03506 The source database character set, as determined from the trail file, is we8mswin1252.
Processed extract process graceful restart record at seq 4, rba 1459.

2016-09-30 12:37:34 INFO OGG-06505 MAP resolved (entry veera.test): MAP "VEERA"."TEST", TARGET veera.test.

2016-09-30 12:37:36 WARNING OGG-06439 No unique key is defined for table TEST. All viable columns will be used to represent the key, but may not guarantee uniqueness. KEYCOLS may be used to define the key.

2016-09-30 12:37:36 INFO OGG-02756 The definition for table VEERA.TEST is obtained from the trail file.

2016-09-30 12:37:36 INFO OGG-06511 Using following columns in default map by name: OWNER, OBJECT_NAME, SUBOBJECT_NAME, OBJECT_ID, DATA_OBJECT_ID, OBJECT_TYPE, CREATED,
LAST_DDL_TIME, TIMESTAMP, STATUS, TEMPORARY, GENERATED, SECONDARY, NAMESPACE, EDITION_NAME.

2016-09-30 12:37:36 INFO OGG-10155 Instantiation CSN filtering is enabled on table VEERA.TEST at CSN 2,972,839.

2016-09-30 12:37:36 INFO OGG-06510 Using the following key columns for target table VEERA.TEST: OWNER, OBJECT_NAME, SUBOBJECT_NAME, OBJECT_ID, DATA_OBJECT_ID, OBJECT_TYPE, CREATED, LAST_DDL_TIME, TIMESTAMP, STATUS, TEMPORARY, GENERATED, SECONDARY, NAMESPACE, EDITION_NAME.

The Replicat process REP1 automatically picks up the CSN and starts applying the record after this CSN. This you can clearly see it from the below line in the above report file.,

2016-09-30 12:37:36 INFO OGG-10155 Instantiation CSN filtering is enabled on table VEERA.TEST at CSN 2,972,839.

Check the count of the table VEERA.TEST at the target side and it is in sync now.

SQL> select count(1) from veera.test;

COUNT(1)
----------
177606

Hope the article was much helpful. Will see another new feature of Oracle GoldenGate 12.2 in the next article.

Oracle GoldenGate Studio 12.2.1 – Repository Creation Utility (RCU)

Hope you would have enjoyed installing the Oracle GoldenGate Studio in my last post. So the next step is to create a Repository for Oracle GoldenGate Studio.

A Repository database is needed for the Oracle GoldenGate Studio to store all the information of the architecture and mappings. To create the repository, Oracle GoldenGate studio provides us with REPOSITORY CREATION UTILITY (RCU). We need to run this to create the Repository.

Now, let get in to on How to create the Repository.

  1. As I already mentioned that there is a file “rcu” to be run to create the Repository. This file will be in the below mentioned directory,

Continue reading…

Oracle GoldenGate Studio 12.2.1

A Long time awaited Oracle GoldenGate Studio 12.2.1 got released on 21-Jan-2016. The binaries are available in the below link,

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

oggs18

What is Oracle GoldenGate Studio?

Oracle GoldenGate Studio is a Graphical based designing tool for Oracle GoldenGate which enables deploying High volumes of data with real time replication by automatically handling table and column mappings. It also has a drag and drop feature of custom mappings. So Oracle GoldenGate Studio allows the new users to Oracle GoldenGate start configuring and replicating data in a ease manner with less effort. No worries about the experienced users, since they are offered with the Advanced Replication Options with Oracle GoldenGate Studio.
Continue reading…

ORACLE GOLDENGATE CHECKPOINTS

Each and every processes in Oracle GoldenGate has it’s own checkpoints to maintain data integrity.

This article explains the different types of checkpoints and the uses of it.

As we know there are multiple processes involved in Oracle GoldenGate replication, the below are the processes which maintains the checkpoint information for each and every operations it does.,

1. Extract or Capture Process
2. Secondary Extract or DataPump Process
3. Replicat Process

EXTRACT PROCESS

This process captures the committed changes from the Redo Log or Archive Log files and writes them to the Trail files called Local Trails. The Extract Process
not only captures the committed changes but also keeps track of all the Open transactions so that it ensures that it does not misses any data or no data loss.
Continue reading…

ORACLE GOLDENGATE INSERTALLRECORDS – To Maintain Transaction History

This parameter is used at the Replicat Side. When using this parameter, it causes Replicat process to insert each and every change that has been made to a record as a new record in the database. So whatever operations are performed in the source table (Insert or Delete or Update), everything will be converted in to the insert statement and will be inserted to the target table. The initial insert and subsequent updates and deletes are maintained as point-in-time snapshots.

There are two major reasons for using the parameter INSERTALLRECORDS,

1. When exception MAP statement is used in the target. The operations which causes error will be inserted in the Exception table. This is called as Error Handling.
Continue reading…