Oracle Golden Gate series 13-configuration of GG process checkpoints

 

I. Checkpoints theory description

Checkpoints for Gg are described in the architecture of Series 1 and GG:

Oraclegolden gate Series 1-GG architecture description

Http://blog.csdn.net/tianlesoftware/article/details/6925907

 

Here we will explain it separately, because this is a more important concept.

 

Checkpoints storethe current read and write positions of a process to disk for recovery purposes. these checkpoints ensure that data changes that are marked for synchronizationactually are extracted by extract and replicated by replicat, And they preventredundant processing.

-- Checkpoint stores the current read and write locations of processes. Checkpoints ensures that changed data has been synchronized to prevent other redundant operations.

They providefault tolerance by preventing the loss of data shoshould the system, the network, or an oracle goldengate process need to be restarted. for complexsynchronization invocations, checkpoints enable multiple extract or replicatprocesses to read from the same set of trails.

-- Checkpoints can be used to restart the GG process in the following situations: system or network faults. Checkpoints supports multiple extact or replicat processes to read the same trail file.

Checkpoints workwith inter-process acknowledgments to prevent messages from being lost in thenetwork. Oracle goldengate has a proprietary guaranteed-message delivery technology.

 

Extract createscheckpoints for its positions in the data source and in the trail. replicat createscheckpoints for its position in the trail.

-- By default, both the extract and replicat processes record the checkpoints position in the trail file.

 

A checkpointsystem is used by extract and replicat processes that operate continuously, butit is not required by extract and replicat processes that run in batch mode. abatch process can be re-run from its start point, whereas continuous processingrequires the support for planned or unplanned interruptions that is provided bycheckpoints.

-- The checkpoints mechanism ensures that extract and replicat processes can operate continuously.

 

Replicat storesits checkpoints in a checkpoint table in the target database to couple the commitof its transaction with its position in the trail file. this ensures that atransaction will only be applied once, even if there is a failure of thereplicat process or the database process. for reporting purposes, replicat alsohas a checkpoint file on disk in the dirchk subdirectory of the oraclegoldengate directory.

-- Replicat records the committed transactions in the checkpoint table of the target database in the trail file. This ensures that the transaction is only applied once, even when the replicat process or DB fails. For reporting purposes, replicat also stores a checkpoint file in the dirchk directory of the GG installation directory.

 

You canoptionally configure replicat to use this file as its sole checkpoint store, and not use a checkpoint table at all. in this mode, however, there can becases where the checkpoint in the file is not consistent with what was appliedafter a database recovery, if the failure either rolled back or rolled forwarda transaction that was considered applied by replicat. the checkpoint table guaranteesconsistency after recovery.

-- We can configure the replicat process to use this local file to store the checkpoint without using the checkpoint, but use the local checkpoint file to recover the database, data Consistency cannot be guaranteed.

When the Transaction rolled back or rolledforward fails, the use of the local checkpoint file can still ensure consistency.

If checkpoint table is used, Data Consistency can be ensured in the case of databaserecover. Therefore, checkpont is recommended.

 

Replicatmaintains checkpoints that provide a known position in the trail from which to startafter an expected or unexpected shutdown. to store a record of its checkpoints, replicat uses a checkpoint table in the target database. this enables thereplicat checkpoint to be writable ded within the replicat transaction itself, toensure that a transaction will only be applied once, even if there is a failureof the replicat process or the database process. thecheckpoint table remains small because rows are deleted when no longer needed, andit does not affect database performance.

-- The checkpoint retains a small number of records and automatically deletes unnecessary data for a long time. Therefore, the checkpoint does not affect the database performance.

 

 

There are two storage methods for goldengate checkpoint information:

1. The files are stored in gghome \ dirchk.

This is the default method. A process corresponds to a file. The extract process can only use this mode. Checkpoint table is not required. However, this method may cause data inconsistency after dB recovery.

 

Gg2:/u01/backup> Cd/u01/ggate/dirchk

Gg2:/u01/ggate/dirchk> ls

Rep1.cpr rept2.cpr

 

2. The table is stored in the specified database and must be configured separately.

 

The configuration steps are as follows:

(1) Add the checkpoint table name to the./globals file.

Checkpointtable [<owner>. <Table>] -- the specified checkpoint record table

(2) connect to the database and create a checkpoint table

Ggsci> dblogin [sourcedb <DSN>] [, userid <db_user> [, password <PW>]

Ggsci> Add checkpointtable [<owner>. <Table>] -- generate this checkpoint record table

(3) When adding a replication process, you can specify checkpointtable [<owner>. <Table>] to replace nodbcheckpoint and use the database to record the checkpoint information.

 

Ii. Example

2.1 configure the./globals Parameter

Ggsci (gg2) 65> View Params./globals

 

Ggschema ggate

Checkpointtable ggate. Checkpoint

 

After we specify the default checkpoint in the globals file, the new replicat groups will automatically use this parameter at creation without other commands.

 

2.2 connect to the database and create a checkpoint table

 

Ggsci (gg2) 58> dblogin useridggate @ gg2, password ggate

Successfully logged into database.

 

Ggsci (gg2) 59> Add checkpointtableggate. Checkpoint

Successfully created checkpoint tableggate. Checkpoint.

 

2.3 specify the checkpoint table when creating the replicat Process

Ggsci (gg2) 14> Add replicatrep1, exttrail/u01/ggate/dirdat/LT, checkpointtable ggate. Checkpoint

Replicat added.

 

Now, the checkpoint configuration is complete. Let's take a look at the checkpoint table.

 

SQL> conn ggate/ggate

Deconnected.

SQL> DESC checkpoint

Name null? Type

-----------------------------------------------------------------------------

Group_name not nullvarchar2 (8)

Group_key not nullnumber (19)

Seqno number (10)

RBA not nullnumber (19)

Audit_ts varchar2 (29)

Create_ts not null date

Last_update_ts not null date

Current_dir not nullvarchar2 (255)

 

SQL> select * from checkpoint;

 

Group_na group_key seqno RBA audit_ts create_ts last_update _ current_dir

-----------------------------------------------------------------------------------------------------------------

Rep1 3987940558 12 1564 17:21:55. 471376 17-nov-11 17-nov-11/u01/ggate

 

 

 

 

 

 

Bytes -------------------------------------------------------------------------------------------------------

All rights reserved. reprinted articles are allowed, but source addresses must be indicated by links. Otherwise, the documents will be held legally responsible!

Blog: http://blog.csdn.net/tianlesoftware

WEAVER: http://weibo.com/tianlesoftware

Email: tianlesoftware@gmail.com

Skype: tianlesoftware

 

------- Add a group to describe the relationship between Oracle tablespace and data files in the remarks section. Otherwise, reject the application ----

Dba1 group: 62697716 (full); dba2 group: 62697977 (full) dba3 group: 62697850 (full)

Super DBA group: 63306533 (full); dba4 group: 83829929 (full) dba5 group: 142216823 (full)

Dba6 group: 158654907 (full) dba7 group: 69087192 (full) dba8 group: 172855474

DBA super group 2: 151508914 dba9 group: 102954821 chat group: 40132017 (full)