Install Oracle goldengate under Windows (difference between dual standby and master-slave replication) __oracle

Oracle goldengate Test Documentation

 

1. Oracle Goldengate Introduction 1

2. Oracle Goldengate for Oracle (Windows platform) installation 5

3. database replication Implementation document (DML) 7

3.1 Preparation Work 7

3.2 Configuration Goldengate 8

3.2.1 Configuration Sourcedb's Goldengate 8

3.2.2 Configuration Targetdb's Goldengate 9

3.3 Test DML Operations 11

4. Goldengate Support DDL Installation 15

5. Play Goldengate 23

The difference between hot standby and master-slave replication: Dual-machine thermal standby consists of two computers and a shared storage device, through Third-party software (HA rose, etc.) to achieve switching, do not need to do data synchronization 1. Oracle goldengate Introduction

Goldengate TDM (transaction data management) software is a kind of structured data replication software based on log, which can be used to analyze and change the data from the online log or archive log of the source database, then apply these changes to the target database, and realize the synchronization and double live of the source database and target database. Goldengate TDM software enables real-time replication of a large amount of data in a heterogeneous IT infrastructure, including almost all common operating system platforms and database platforms, and its replication process is as follows:

As shown in the figure above, the data replication process for Goldengate TDM is as follows:

Using the capture process (Capture process) to read the online Redo log or archive log on the source system side, and then parse it, only extract the data changes such as adding, deleting and changing the operation, and converting the relevant information to Goldengate TDM's Custom intermediate format is stored in the queue file. The routing process is then used to transfer the queue files over TCP/IP to the target system. Capturing the process after each read data changes in the log and after the data is transferred to the target system, will write checkpoints, record the current completion of the capture log location, Checkpoint can make the capture process can be aborted and recovered from the checkpoint location to continue copying;

The target system accepts data changes and caches it into the Goldengate TDM queue, queues a series of files that temporarily store data changes, waiting for the delivery process to read the data;

The Goldengate TDM delivery process reads the data changes from the queue and creates the corresponding SQL statements, executes through the local interface of the database, updates its checkpoint after the database has been successfully submitted, records the location where the replication has been completed, and the data copy process is finally completed.

Thus, Goldengate TDM is a software-based method of data replication, which resolves data changes from the log of the database (the amount of data is only about One-fourth of the log). Goldengate TDM transforms data changes into its own format, directly via TCP/IP networks, without relying on the way the database itself is delivered, and compresses data by up to 9:1 compression, which can greatly reduce bandwidth requirements. On the target side, Goldengate TDM can greatly accelerate the speed and efficiency of data delivery by means of transaction reorganization, batch loading and so on, reduce the resource occupancy of the target system, and realize a large amount of data replication at the sub-second level, and the target-side database is active

Goldengate TDM provides a flexible application solution based on its advanced, flexible technology architecture that can be composed of a variety of topologies based on user requirements, as shown in the figure:

Goldengate TDM can provide reliable data replication, mainly in the following three points:

Ensure transactional consistency

Goldengate TDM in the disaster preparedness database The order of the replicated database transactions is the same as that in the Production Center database, and the same transaction environment is submitted to ensure the integrity and read consistency of the data on the target system, creating the conditions for real-time query and transaction processing.

checkpoint mechanism guarantees no loss of data

The Goldengate TDM extraction and replication process uses the checkpoint mechanism to record where replication is completed. For the extraction process, the checkpoint records the location of the currently extracted log and the location of the write queue file, and for the drop process, its checkpoint records the location of the currently read queue file. The checkpoint mechanism ensures that data is not lost after the system, network, or goldengate TDM process fails to restart.

reliable data transmission mechanism

Goldengate TDM transmits transaction data using the answering mechanism, and the data is automatically retransmitted only after the confirmation message is received, which ensures that all the extracted data can be sent to the backup end. 128-bit encryption and data compression are supported during data transfer.

Oracle's goldengate product, which enables data capture, conversion, and delivery of a large amount of data between heterogeneous IT infrastructures. Goldengate can support almost all common operating systems such as and database platforms, as shown in the following table:

Operating system	Database
MS NT, Watts, XP, Linux, Sun Solaris, HP-UX, IBM AIX, HP Nonstop, TRU64, IBM z/os,os/390	Oracle, DB2, MS SQL Server, MySQL, Enscribe, SQL/MP, Sql/mx, Sybase, Teradata, other ODBC-compliant databases

2. Oracle Goldengate for Oracle (Windows platform) installation

Goldengate installation is very simple, will extract the installation files to the specified directory. For example, after the installation file uncompressed path for D:\ggs

The installation steps are as follows:

1. Enter command line

2. Switch to the GGs directory

3. Enter command install AddService addevents

4. Enter Ggsci to enter goldengate command line

5. Enter Create Subdirs

The Ok,goldengate installation is complete.

The actual operation is as follows

C:\Documents and Settings\pony>d:

D:\>CD GGs

D:\ggs>install AddService addevents

Oracle goldengate messages installed successfully.

Service ' Ggsmgr ' created.

Install program terminated normally.

D:\ggs>ggsci

Oracle Goldengate Command Interpreter for Oracle

Version 10.4.0.19 Build 002

Windows (optimized), Oracle on Sep 18 2009 15:54:55

Copyright (C) 1995, 2009, Oracle and/or its affiliates. All rights reserved.

Ggsci (PONY) 1> Create Subdirs

Creating subdirectories under current directory D:\ggs

Parameter Files d:\ggs\dirprm:created

The Files d:\ggs\dirrpt:created

Checkpoint Files d:\ggs\dirchk:created

Process Status Files d:\ggs\dirpcs:created

SQL script Files d:\ggs\dirsql:created

Database Definitions Files d:\ggs\dirdef:created

Extract Data Files d:\ggs\dirdat:created

Temporary Files d:\ggs\dirtmp:created

Veridata Files d:\ggs\dirver:created

Veridata Lock Files d:\ggs\dirver\lock:created

Veridata out-of-sync Files d:\ggs\dirver\oos:created

Veridata out-of-sync XML Files d:\ggs\dirver\oosxml:created

Veridata Parameter Files d:\ggs\dirver\params:created

Veridata The Files d:\ggs\dirver\report:created

Veridata Status Files d:\ggs\dirver\status:created

Veridata Trace Files d:\ggs\dirver\trace:created

Stdout Files d:\ggs\dirout:created

3. database replication Implementation document (DML) 3.1 preparation

Prepare two machines, respectively Sourcedb, TARGETDB, interconnect via TCP/IP network

Sourcedb:win XP environment, Oracle 10g 10.2.0.1.0

Targetdb:win 2003 Environment Oracle 10g 10.2.0.1.0

You must ensure that Sourcedb is running in archive mode.

Objective: To replicate the data in the related schema in Sourcedb to the corresponding sechema in Targetdb

In this article, you want to synchronize the Sajet,sj,smt,lang in Soucedb to the Sajet,sj,smt,lang user in target

First of all, to maintain sourced, targetdb the original data in the relevant schema consistent, can be achieved through Exp/imp,rman, Lengbei and other means.

Both DB establishes the Goldengate user and gives DBA authority for Goldengate Connection db.

Both DB installation Goldengate, installation mode as shown in the second chapter

Sourcedb must start minimum additional log mode

See whether DB has the minimum additional log mode turned on by using the following statement

Sql> select Supplemental_log_data_min from V$database;

Suppleme
--------
YES

If you do not have the minimum additional log to open the database, open it by using the following statement

Sql>alter database add supplemental log data;

Opens the minimum additional log for the table, which is added by the goldengate command line

Ggsci (PONY) 1> dblogin userid Sajet Password Tech

Successfully logged into database.

Ggsci (PONY) 2> add Trandata sajet.*

The first command indicates that you are logged on to the database

The second command represents the minimum additional log for all tables under the Sajet user added

The same command opens the minimum additional log for the table under the SJ,LANG,SMT user.

3.2 Configure goldengate 3.2.1 Configuration sourcedb goldengate (two processes)

The sourcedb end needs to configure the MGR process, add a extract process, and a remote queue.

1. Configure MGR Parameters

Ggsci (PONY) 2> edit param Mgr

The system automatically creates a new parameter file named Mgr, which is saved after filling in the following content

PORT 7809

TCP/IP Port listening requests used by the--MGR process

2. Add a new extraction process, enter the following command on the GGSCI command line:

Ggsci (PONY) 1> Add extract Ext1,tranlog,begin now

EXTRACT added.

---Add an extraction process, responsible for capturing the changes in the Sourcedb data, based on the log method, immediately effective

3. Configure the extraction process

Ggsci (PONY) 2> edit param Ext1

The system will automatically create a new parameter file named Ext1, fill in the following contents and save

Extract Ext1

userid Goldengate,password goldengate

rmthost 172.17.17.61, Mgrport 7809

Rmttrail d:\ggs\dirdat\r1

dynamicresolution

gettruncates

table sajet.*;

table sj.*;

table smt.*;

table lang.*;

 

 

 

--

Extract Process name ext2

Connect the account number and password for native DB

Remote host address and service port number (TARGETDB)

Location of remote queues (TARGETDB)

Optimization parameters, dynamic analysis table structure

Whether to crawl truncate data

Which table you want to extract.

4. New Remote Queue location

Ggsci (PONY) 3> add rmttrail d:\ggs\dirdat\r1 extract ext2

Rmttrail added.

 

--

Add a remote queue, located in the Targetdb D:\GGS\DIRDAT\R1, is the extraction process ext1 extraction of the data queue, attention and extraction process configured Rmttrail d:\ggs\dirdat\r1 consistent.

Open All Processes

Ggsci (PONY) 11> start Mgr

 

starting Manager as service (' Ggsmgr ') ...

Service started.

 

Ggsci (PONY) 14> start Ext1

 

sending START request to MANAGER (' ggsmgr ') ...

EXTRACT EXT1 Starting

 

To view the running of a process

Ggsci (PONY) 185> info All

 

Program Status Group Lag time Since chkpt

 

MANAGER RUNNING

EXTRACT RUNNING EXT1 00:00:00 00:00:06

 

Both the ok,mgr process and the EXT process are running correctly

The configuration of the Soucedb end is complete.

3.2.2 Configuration targetdb goldengate (two processes)

1. Configure MGR Parameters

Ggsci (PONY) 2> edit param Mgr

At this point, the system automatically creates a new Mgr parameter file, fills in the following contents and saves

PORT 7809

dynamicportlist 7840-7850

TCP/IP Port listening requests used by the--MGR process

Accept the list of ports for the remote queue.

2. A new replication process

Ggsci (PONY) 2>add replicat rep1 exttrail d:\ggs\dirdat\r1, Nodbcheckpoint

 

--A new replication process that parses the files extracted into the queue and writes them into the TARGETDB

3. Configuring the replication process

Ggsci (PONY) 2> edit param Rep1

At this point the system will automatically create a new parameter file, fill in the content after saving

Replicat Rep1

userid Goldengate,password goldengate

Assumetargetdefs

Reperror Default,discard

discardfile d:\oradata\discard\repsz.dsc,append,megabytes

gettruncate

map sajet.*, target sajet.*;

map sj.*, target sj.*;

map lang.*, target lang.*;

map smt.*, target smt.*;

 

 

--Copy process name

Login to Targetdb's account number and password

Use this parameter when two DB data structures are consistent

If replication is wrong, continue and put the error in the Discardfile

Copy truncate operation

The copied source table is all tables under the SAJET,SJ,LANG,SMT user, and the target is all tables under the user in the Targetdb

Opening MGR and rep processes

Ggsci (PONY) 20> start Mgr

 

starting Manager as service (' Ggsmgr ') ...

Service started.

 

 

Ggsci (PONY) 21> start Rep1

 

sending START request to MANAGER (' ggsmgr ') ...

Replicat REP1 Starting

To view the running of a process

Ggsci (PONY) 22> info All

 

Program Status Group Lag time Since chkpt

 

MANAGER RUNNING

replicat RUNNING REP1 00:00:00 00:00:07

 

Ok,mgr processes and rep processes are functioning properly

At this point, both DB Goldengate have been configured to complete.

3.3 Test DML operations

First insert a row into the Sourcedb

C:\Documents and Settings\administrator>sqlplus

Sql*plus:release 10.2.0.1.0-production on Mon Mar 8 15:33:47 2010

Copyright (c) 1982, +, Oracle. All rights reserved.

Enter User-name:sajet/tech@hitron

Connected to:

Oracle Database 10g Enterprise Edition release 10.2.0.1.0-64bit Production

With the partitioning, OLAP and Data Mining options