- Oracle GoldenGate Cloud Service Documentation: How Do I Replicate Data to Oracle Autonomous Data Warehouse Cloud?
- Oracle GoldenGate Documentation: 19 Replicating Data to Oracle Autonomous Data Warehouse Cloud
Oracle GoldenGate and Oracle GoldenGate Cloud Service now supports Oracle Autonomous Data Warehouse Cloud (ADWCS). The documentation is available at:
23 Comments
Oracle GoldenGate Cloud Service (GGCS) provides real-time data replication in the cloud. It is fully compatible with the Oracle GoldenGate on-premise software. The seamless integration of GGCS and Oracle GoldenGate on-premises enables real-time data replications in hybrid cloud. This blog walks through the steps to help you get started with this cloud service. Additional Reading
The followings tutorials can lead you further down the road with hands-on experiences: Don't miss that Oracle GoldenGate can also be used on other cloud platforms such as Amazon AWS and Microsoft Azure. Some blogs are posted related to this topic: Moving to the cloud? You have the real-time replication to move data. Created: 12/9/2016 Last Updated: 2/3/2018
This blog discusses what sources and targets supported by Oracle GoldenGate Cloud Service (GGCS).
1. Background Information Let me give some background information to help you understand the support discussion later. 1.1 What is GGCS? GGCS is now an unmanaged PaaS service, which means GGCS provides a virtual machine hosting the software, and you as a user need to configure and to maintain the software execution. GGCS now has the following Oracle GoldenGate software installed on the virtual machine by default:
1.2 What is Oracle GoldenGate Remote Capture and Delivery? Oracle GoldenGate 12.2 now supports remote capture and delivery for the following databases/servers:
2. What is Supported? Let's talk about what's supported. 2.1 GGCS Supported Sources and Targets on Oracle Public Cloud When running Oracle GoldenGate Cloud Service (GGCS), the following sources and targets are certified on Oracle Public Cloud:
2.2. GGCS Supported Source and Target On-Premises and 3rd Party Cloud GGCS can be configured to perform Remote Capture and Delivery for the On-Premises Databases and Databases running on the 3rd Party Cloud and the following sources and targets are the supported:
After the orders of GoldenGate Cloud Service is completed and activated, the service is then listed on your Oracle Cloud My Services dashboard.
Note: Database as Cloud Service (DBaaS) is now a pre-requisite of GGCS and it is normally ordered with Oracle Compute and Storage Service.
To provisioning an GGCS instance, you normally need to complete the following steps:
Note: Note: The UI might be different over versions. The current GGCS version provides an unmanaged (VM only) service.
If you choose to enable backup service of GGCS configurations, you need to create a new storage repository in your current account. When creating it, please make sure you set the storage service name to be:
Why do I get the "Create of cloud storage container...cannot connect to storage service" error?
Please make sure you use the storage container name: e.g. https://a228251.storage.oraclecloud.com/v1/Storage-a228251/ggcs. The REST endpoint is https://a228251.storage.oraclecloud.com/v1/Storage-a228251, the container name is ggcs.
You need to specify the correct database username and password for the Database Cloud Service. GGCS provisioning process will proceed only after the Database Cloud Service connection from GGCS is validated.
Created: 3/18/2016, Last Updated: 10/20/2017
Oracle GoldenGate Cloud Service is now offered as part of Oracle's new pricing model, Universal Credits. "With Universal Credits, customers have one simple contract that provides unlimited access to all current and future Oracle PaaS and IaaS services, spanning Oracle Cloud and Oracle Cloud at Customer." [1] Please refer to the Oracle PaaS and IaaS Universal Credits Service Description (Sept 27, 2017) [2] for the details. Resources
The extract lag time in Oracle GoldenGate shows the difference between the time when the record was processed by the extract and the timestamp of that record in the database [1]. The extract processing time is based on the operating system clock running Oracle GoldenGate. The time of the record in the database is based on the database clock.If the value is shown as unknown, there could be several reasons:
Best Practices
When performing remote capture/delivery, it's recommended that Oracle GoldenGate's operating system (OS) clock is synchronized with the database clock and is within the same timezone. GGSCI> info all Program Status Group Lag at Chkpt Time Since Chkpt MANAGER RUNNING JAGENT STOPPED EXTRACT RUNNING EXTECS1 unknown 00:00:06 EXTRACT ABENDED PMPECS1 00:00:00 01:22:07
What could be the reasons for an "unknown" lag at checkpoint?
Answer: If the extract lag value is shown as unknown, then there could be two reasons:
You can use the lag extract <extract_group_name> command to find more information shown as follows:
GGSCI> lag extgdrds Sending GETLAG request to EXTRACT EXTGDRDS ... Lag unknown (timestamp mismatch between source and target).
When this happens, you can first check the database time and the timezone information using the following SQL command (for Oracle Database):
SQL> SELECT DBTIMEZONE FROM DUAL; DBTIME ------ +00:00 SQL> SELECT TO_CHAR (SYSDATE, 'MM-DD-YYYY HH24:MI:SS') "NOW" FROM DUAL; NOW ------------------- 05-17-2017 15:50:21
You can check Oracle GoldenGate operating system time and timezone with the date command on Linux:
>date Wed May 17 11:50:21 EDT 2017
The preceding result shows that the clocks are synchronized but with different timezone. The database is in the UTC time zone. The Oracle GoldenGate machine is in US East time zone.
To show the correct lag time, you can change the time and timezone setup on the Oracle GoldenGate side. The following is an example to change the time zone GGCS virtual machine timezone to UTC:
1. Backup your current time zone info:
sudo cp -p /etc/localtime ~backup_localtime_$(date +%Y%m%d_%T) sudo cp -p /etc/sysconfig/clock backup_clock_$(date +%Y%m%d_%T)
2. Edit/Modify the ZONE entry line in the /etc/sysconfig/clock to the correct time zone (if available). The entry for this ZONE line is based on the time zone in /usr/share/zoneinfo directory. As an example, for UTC time zone, the entry should be as follows:
ZONE="Etc/UTC"
3. Copy the correct time zone file to the /etc/localtime file (you can also do a soft link if you want):
sudo cp –p /usr/share/zoneinfo/UTC /etc/localtime
4. Restart/reboot the instance via shutdown command: (Optional)
sudo shutdown -r now
After the timezone is changed, you should be able to find the checkpoint by login to GGSCI (no restarting is needed for both extract group or the manager process.)
GGSCI (ip-172-30-3-169.ec2.internal) 1> info all Program Status Group Lag at Chkpt Time Since Chkpt MANAGER RUNNING EXTRACT RUNNING EXTGDRDS 00:00:09 00:00:05 EXTRACT ABENDED PMPGDRDS 00:00:00 00:00:16
As this point, the issue is resolved. We also find the clock not synchronized, you can use NTP server to synchronize the clock. [2]
Best Practices
Use lag extract, instead of info extract, get the lag time more precisely, because it directly communicates with extract to obtain the lag time rather than reading the checkpoint position in the trail.
Resources
Created 5/17/2017, Last Updated: 10/17/2017
Oracle Public Cloud customers can now configure Oracle GoldenGate Cloud Service (GGCS) to deliver real-time transactions to Oracle Event Hub Cloud Service (EHCS) . A new Oracle A-Team is published to walk you through how to integrate GGCS with EHCS at http://www.ateam-oracle.com/integration-of-ggcs-with-ehcs.
The demonstration will be available at OpenWorld 2017, Join the following sessions for more information:
Yes, please refer to the following document
Oracle A-Team recently published a blog on how to apply patches in GGCS:
Detail: After turning on DDL replication,the GoldenGate replication stops after the RDSADMIN perform operations at the backend. The replicat abended with the following error message:
OGG-00519 Fatal error executing DDL replication: error [Error code [1918], ORA-01918: user 'RDSADMIN' does not exist SQL /* GOLDENGATE_DDL_REPLICATION */ ALTER USER RDSADMIN IDENTIFIED BY VALUES 'S:09E677F1EA54AF1925BFBD45B711898AFEECB073BF92D4121D9039B941E2;H:5914B325962646A6BF25A5ED11D05EB6;T:0D26A57D 465696E608FDF426F80983E15C089BE83F94132B2E5CA957E6F54668DAB561414ED67CBCEE87A3BCF2AA124BE2C514F779AD15C2C1B3E4 337671D8341DEC0FA8F67FED0A17BC9B3610AA33CE;3870B0091A7B89C5' /* GOLDENGATE_DDL_REPLICATION */], no error handler present.
How can I avoid such abend later?
Answer: To resolve this issue, you can preposition the replicat with the alter replicat command, such as " alter replicat repgdrds extseqno 3, extrba 9115". After the replicat is running, you can then create the exception handling to handing the error:
MACRO #exception_handler BEGIN , TARGET ggadmin.exceptions , COLMAP ( rep_name = "REPGDRDS" , table_name = @GETENV ("GGHEADER", "TABLENAME") , errno = @GETENV ("LASTERR", "DBERRNUM") , dberrmsg = @GETENV ("LASTERR", "DBERRMSG") , optype = @GETENV ("LASTERR", "OPTYPE") , errtype = @GETENV ("LASTERR", "ERRTYPE") , logrba = @GETENV ("GGHEADER", "LOGRBA") , logposition = @GETENV ("GGHEADER", "LOGPOSITION") , committimestamp = @GETENV ("GGHEADER", "COMMITTIMESTAMP")) , INSERTALLRECORDS , EXCEPTIONSONLY; END; REPERROR (DEFAULT, EXCEPTION) REPERROR (1918, exception)
You can also exclude replicating operations under RDSADMIN user using the EXCLUDEUSER configuration.
Resources
|
GoldenGate Cloud ServiceOracle GoldenGate Cloud Service (GGCS) is an extension of Oracle GoldenGate to provide rea-time replication in Cloud. Links
Buzzwords
Disruption Dynamic Mobile Real-Time Security Data-Driven Globalization High Performance Digitization Web Scale Last Updated
March 2018
Categories
All
|