When we face issues in GoldenGate extract or replicat setup, we follow some of the tried and tested initial troubleshooting steps mentioned below that helps us in pointing out the exact case of the issue.
To start with, GGSCI commands which are useful for Gathering evidences of issue:
During one of our 11gR2 database restore activity we found below error message in the RMAN “duplicate database command”
channel aux4: ORA-19870: error while restoring backup piece /oraclone/ORCL/rman_clone/ORCL_F_20170605_c1s60alv_1_1
ORA-19504: failed to create file "+DATA3"
ORA-15045: ASM file name '+DATA3' is not in reference form
ORA-17502: ksfdcre:5 Failed to create file +DATA3
ORA-15081: failed to submit an I/O operation to a disk
ORA-27091: unable to queue I/O
ORA-27041: unable to open file
SVR4 Error: 13: Permission denied
GoldenGate Downstream deployment allows you to offload the source database extract load to intermediate or target server. The source database ships its redo logs to a downstream database, and Extract uses the logmining server at the downstream database to mine the redo logs. A downstream mining database can accept both archived logs and online redo logs from a source database
There are a number of factors that we need to keep in mind to be able to successfully tune a GoldenGate Setup. If you carefully design your system keeping in mind the end goal and apply some proven performance tuning measures you should be able to get real time replication from your GoldenGate setup.
After successfully installing Oracle GoldenGate 12c, it will create a lot of sub-directories structure which will be used by the different components of Oracle GoldenGate. There are so many directories that new user will get confused what to look where.The directories are the default locations for GoldenGate when creating objects and parameter files.
Usually in OLTP environment like EBS Applications, tables are often get fragmented due to multiple DML activities that happens.Fragmented tables cause queries on those tables to slow down. It is very important to de-fragment this table and to reclaim the fragmented space from these objects.
For EBS we have also seen that usually gathered statistics, indexing and proper SQL tuning is plenty to improve and maintain acceptable performance but sometime it is required to reorg the table.
One primary cause of fragmentation is that when you run delete command on the tables it delete the rows but doesn’t frees up the memory and also do not changes the high water mark.
Oracle E-Business Suite is one of the most comprehensive suite of integrated, global business applications used by many organization around the globe. Clients usually host E-Business Suite environment In-house which requires upfront investment and ongoing maintenance costs. This approach is proven to be non-scalable and non-flexible for the rapidly changing business needs. Cloud solutions are the way to go for these applications. Oracle Cloud Solutions with all their features and integrated security can handle the robust and complex architectures of the E-Business suite seamlessly. Oracle EBS on cloud can help organizations with its scalability, elasticity and performance at much lower costs.
In this post we will explore one of the method for moving your on-premise database to the Database Cloud Service. There are multiple options for solving this data movement challenge. In this post our focus will be to use SQL*Developer and command line tools to clone and move a pluggable database from our on-premise database to our cloud database. Pluggable databases is a feature of Oracle database 12c. We are using version 188.8.131.52 of Oracle database 12c.
There can be other simpler methods also if you have infrastructure/network in place to connect from your cloud databse to your on-premise database directly, like:
Using OEM, you can do this work very easily in a few click-and-watch steps.
Using DBLINK. This is the also one of the easiest way
Using SQLDVELOPER and choosing “Clone PDB to oracle Cloud” option. All required ports b/w on-premise and Oracle Cloud must be open and network/firewall related requirements must be met to use this option.
For this example we are using SQL Developer to clone the PDB but will not be using direct “Clone PDB to Oracle Cloud” option. We will be making a clone copy of the on-premise database, unplug it, copy over the data files to Oracle Cloud and plug it there.