Ogg Capture Client Successfully Detached From Goldengate Capture

0 views
Skip to first unread message

Glendora Starr

unread,
Jul 21, 2024, 5:32:09 AM7/21/24
to niscontsersleads

Hi Jinyu,

Great blog! I find it very informative. Regarding the remote extract configuration, is this something that you had success with? I thought the only way to set up remote golden gate server capture was through downstream capture, but you're saying you've done it with just an integrated capture? I have a golden gate middle tier server and need to connect to remote databases to log mine and create the trails on that server.

Thank you!!

Yes, this is the recommended approach for Oracle cloud solutions.

Downstream Capture and Remote Integrated Capture approach both have pros and cons.

Downstream capture still requires the log shipping over the network which means a large volume of data delivery from the source to the remote capturing machine. The remote capture with integrated capture only sends LCR (logical change record) which reduces the volume of data sending to the remote machine,

When using remote integrated capture, the data mining is still processed in the source database while downstream capture decouples GoldenGate capture from the source database. However, you have to maintain the downstream database on a remote server.

When setting up remote GoldenGate capture, you would like to set up the remote machine close to the source DB(s). This is like setting up a replication hub. You might need multiple replication hubs based on geographic or logical locations.

ogg capture client successfully detached from goldengate capture


Downloadhttps://urllie.com/2zveOP



Hi Jinyu,

I do remote capture and delivery via real-time IE with downstream log mining. One of the challenges I am facing is the delivery part. As my client have different versions of Oracle. That forces me to run different versions of GG (e.g. GG 12.1 for Oralce 11g and GG12.1 for oracle 12c) against the same trail file that was generated from my log mining server.

Yes, this is the challenge because Oracle GoldenGate sometimes needs to use different versions (binary ship homes) for different DBs. You can consider setting up hubs based on the GG versions. After the transactions are captured by GG, you can set up the hub-spoke architecture. When planning your replication hubs, you would consider not only the DB versions, but also locations, timezones and the data volume.

We don't do remote capture for DB2 for i in general. But if DB2 for I has remote journal setup, GG can capture from it. Please refer to this blog for more information: -platform/oracle-goldengate-remote-capture-and-delivery-support-overview

The correct order is:

1. Start the GG extract
2. Start the initial loading from to a given CSN (Oracle DB is SCN)
3. Start the replicat but only apply the transactions after the CSN of step #2.

Yes, you database can keep running as usual when performing these operations. No collision handling is needed if CSN is used. Otherwise, you can include the handlecollisions parameter in the replicat at the beginning.

You can install Oracle GoldenGate in any directory on the remote server. You need to have Oracle DB client installed first which gives you the Oracle home. I updated the blog with a new installation section to explain this. Feel free to me know if you need more info.

Thanks Jinyu, great article. I went through a lot of Oracle doc and GG books, looks like you are the only one brought up this great way of setup. So under the impression, golden gate can manage remote capture to multiple source databases and then a remote delivery to multiple target databases?

You can set up an Oracle GoldenGate Hub with remote capture from multiple source DBs and remote delivery to multiple target DBs. You might need multiple Oracle GoldenGate downloads based on the DBs that you are dealing with. For example, if you capture from a Oracle DB and delivery to a Big Data repository. Then, you need GG for Oracle and GG for Big Data installed on the hub.

Jinyu, so in the example here, there is no need for a pump process? as the extract and replicat process are running from the same host already, see if my understanding being correct. Only one copy of goldengate is needed (source and target all being Oracle)? thanks for hint

Do you know if the GoldenGate licenses would be based on the remote server where the GG binaries are installed or would they be based on the source and/or target DB servers? Assuming the licenses are based on the server where GG is installed, this architecture could save on licence costs, especially if source/target is a large Exadata server with many cores.

P.S. I do intend to check with my Sales Rep, but hoping for a reply based on other user's experience.

Hi Jinyu ,

Greetings. I found your article very informative and have few questions. I am planning to setup Oracle golden gate
Hub with integrated Capture. My source and target databases are on same version (19c) running on different machines. I will be installing the oracle Client 19c with administrator option and Oracle GoldenGate 19c on standalone server as OGG HUB. As per my understanding I need to install only one Oracle GoldenGate software on HUB but wondering what would be the directory structure of the software ? As we know without Hub architecture, we used to have 2 copies of OGG software, 2 manager processes(one for source and target) , Extract and pump processes on source , replicat process on target , and separate ggserr.log for source and target.
What is your recommendations for Oracle golden gate Hub for above scenario ?

Regards,
Abhishek Maloo

Hello Jinyu,
Article well explained and very informative. I do have a similar project as Abhishek.
My source is Oracle 19c on premise and target 19c Oracle DB on AWS RDS.
I do have a copy of golden gate with like version installed on an EC2 instance in AWS as my hub.
Per your post, having the extract on the Source without GG copy and the replicat on the target without GG copy should be the ideal way to go right?
Awaitng your response when you get the chance. thanks

Hi Jinyu,

Nice work and explanation really appreciate your effort.
Please what I want to simulate is
source DB = SQL Server
GG Hub (Remote Server)
Target DB = Oracle
any idea how to go about this?
on the remote GG Hub am I installing both goldengate for sqlserver and goldengate for oracle on different filesystem to achieve this?
I will be glad if you have any documents I can follow to do achieve this.
Thanks in advance

Hi Jinyu,

I have to install GG hub for application people with restricted activity like start/stop/edit processes along with basic troubleshooting. Could you please guide me how can I achieve this with OS user and group.

Regards,
Ravin

XStream Out provides a transaction-based interface for streaming these changes to client applications. The client application can interact with other systems, including non-Oracle systems, such as non-Oracle databases or file systems.

The primary function of the redo log is to record all of the changes made to the database. A capture process captures database changes from the redo log, and the database where the changes were generated is called the source database for the capture process.

When a capture process captures a database change, it converts it into a specific message format called a logical change record (LCR). In an XStream Out configuration, the capture process sends these LCRs to an outbound server.

You can also capture changes for the source database by running the capture process on different server. When a capture process runs on a remote database, the capture process is called a downstream capture process, and the remote database is called the downstream database. The log files are written to the remote database and to the source database. In this configuration, the source logfiles must be available at the downstream capture database. The capture process on the remote database mines the logs from the source database and stages them locally. This configuration can be helpful when you want to offload the processing of capture changes from a production database to different, remote database.

If XStream is replicating data for an object type, then the replication must be unidirectional, and all replication sites must agree on the names and data types of the attributes in the object type. You establish the names and data types of the attributes when you create the object type. For example, consider the following object type:

The maximum size of the VARCHAR2, NVARCHAR2, and RAW data types has been increased in Oracle Database 12c when the COMPATIBLE initialization parameter is set to 12.0.0 and the MAX_STRING_SIZE initialization parameter is set to EXTENDED.

ID key LCRs do not contain all of the columns for a row change. Instead, they contain the rowid of the changed row, a group of key columns to identify the row in the table, and the data for the scalar columns of the table that are supported by XStream Out. ID key LCRs do not contain data for columns of unsupported data types.

XStream Out can capture changes for tables that are not fully supported by setting the CAPTURE_IDKEY_OBJECTS capture process parameter to Y. An XStream client application can use ID key LCRs in the following ways:

If the application requires the data in the unsupported columns, then the application can use the information in an ID key LCR to query the correct row in the database and consume the unsupported data for the row.

You can use the DBA_XSTREAM_OUT_SUPPORT_MODE view to display a list of local tables supported by ID key LCRs. This view shows the following types of XStream Out support for tables in the SUPPORT_MODE column:

Specifically, the client application attaches to an XStream outbound server and waits for LCRs from the outbound server. When the client application receives an ID key LCR, it can query the appropriate source database table using the rowid in the ID key LCR.

A single database can have one or more capture processes that capture local changes and other capture processes that capture changes from a remote source database. That is, you can configure a single database to perform both local capture and downstream capture.

e59dfda104
Reply all
Reply to author
Forward
0 new messages