DBASolved

Subscribe to  DBASolved feed  DBASolved
Updated: 2 days 20 hours ago

Oracle Database Views and Tables for Oracle GoldenGate

Fri, 2019-11-08 16:40

Oracle GoldenGate for Oracle over the last few releases have been moving towards an integrated architecture.  This means that there is more views and tables within the Oracle Database that support Oracle GoldenGate.  You can quickly find these views and tables by using a where clause with a filter for GoldenGate: select * from all_views […]

The post Oracle Database Views and Tables for Oracle GoldenGate appeared first on DBASolved.

Categories: DBA Blogs

Bridge network missing Gateway – Docker Issue

Sun, 2019-11-03 11:41

Here is a little something for you.  I’m working on building a demo of Oracle GoldenGate Microservices between three (3) containers. In order to do this, I wanted to setup a dedicated network between the containers. In order to setup a dedicated network, I needed to configure a network for the containers to use.  Docker […]

The post Bridge network missing Gateway – Docker Issue appeared first on DBASolved.

Categories: DBA Blogs

ServiceManager … as a daemon

Thu, 2019-10-24 15:34

In an earlier post on ServiceManager, I took a look at how you could start/stop the ServiceManager manually.  A lot of what was said in that post still applies to this post; however, in this one I’m going to take a look at how to review the ServiceManager when it is configured as a daemon […]

The post ServiceManager … as a daemon appeared first on DBASolved.

Categories: DBA Blogs

Where is my StreamAdmin account?

Wed, 2019-09-25 15:10

One of the huge benefits of Oracle GoldenGate Microservices is the security framework which comes standard when you install GoldenGate. As you setup the ServiceManager and first deployment, you are prompted to build an administration account. As a best practice we recommend that the account be named “oggdmin” with the password you define. Although it […]

The post Where is my StreamAdmin account? appeared first on DBASolved.

Categories: DBA Blogs

Understanding/Modifying Oracle GoldenGate Microservices Settings

Fri, 2019-09-20 10:40

Oracle GoldenGate Microservices provide a wide range of options from administration and security to enhance the replication setup and experience. The Microservices architecture makes interaction with Oracle GoldenGate much easier compared to the traditional Classic architecture. This architecture provides you with not one but four avenues to interact with GoldenGate to ensure replication is configured, […]

The post Understanding/Modifying Oracle GoldenGate Microservices Settings appeared first on DBASolved.

Categories: DBA Blogs

Improving URLs for Oracle GoldenGate Microservices using a Reverse Proxy

Fri, 2019-09-20 06:16

Oracle GoldenGate finally has a GUI/Web Page interface to work with the product. This has been a long over due and welcomed feature that was initally released with Oracle GoldenGate Microservices in 12.3. Since 12.3 and through 19.1, the Oracle GoldenGate team has been preaching the simplicity and securty benefits of using a reverse proxy […]

The post Improving URLs for Oracle GoldenGate Microservices using a Reverse Proxy appeared first on DBASolved.

Categories: DBA Blogs

Oracle GoldenGate Microservices Upgrade – 12.3.0.x/18.1.0.x to 19.1.0.0.x

Sun, 2019-09-08 16:45

Oracle GoldenGate Microservices have been out for a few years now. Many customers have pursued the architecture in many different industries and have this in many dfifernt use-cases and architectures. But what do you do when you want to upgrade your Oracle GoldenGate Microservices Architecture?

In a previous post, I wrote about how to upgrade Oracle GoldenGate Microservices using the GUI or HTML5 approach in this post – Upgrading GoldenGate Microservices Architecture – GUI Based (January 2018). Today, many of the steps are exactly the same as they were a year ago. The good news is that Oracle has documented the process a bit clearer in the lates upgrade document (here).

So why a new post on upgrading the architecture? Over the last few days, I’ve been looking into a problem that has been reported by customers. This problem affects the upgrade process, not so much in how to do the upgrade but when the upgrade is done.

In nutshell, the upgrade process for Oracle GoldenGate Microservices is done in these few steps:

1. Download the latest version of Oracle GoldenGate Microservices -> In this case: 19.1.0.0.1 (here); however, this approach will work with 19.1.0.0.2 as well.
2. Upload the software, if needed, to a staging area on the server where Oracle GoldenGate Microservices is running. Ideally, you should be upgrading from OGG 12c (12.3.x) or 18c (18.1.x).
3. Unzip the downloaded zip file to a temporary folder in the staging area
4. Execute runInstaller from the directory in the staging area. This will start the Oracle Universal Installer for Oracle GoldenGate.
5. Within the installation process, provide the Oracle GoldenGate Home for the Software Location.
6. Click Install to begin the installation into a New Oracle GoldenGate Home.

Note: At this point, you should have two Oracle GoldenGate Microservices Homes. One for the older version and one for the 19c version.

7. Login to the ServiceManager
8. Under Deployments -> select ServiceManager
9. Under Deployment Details -> select the pencil icon. This will open the edit field for the GoldenGate Home.
10. Edit the GoldenGate Home -> change to the new Oracle GoldenGate Microservices Home then click Apply.
This will force the ServiceManager to reboot.

At this point, you may be asking yourself, I’ve done everything but the ServiceManager has not come back up. What is going on?

If you have configured the ServiceManager as a daemon, you can try to start the ServiceManager by using the systemctl commands.

systemctl start OracleGoldenGate

 

This command will just return with nothing important. In order to find out if it start successfully or not, check the status of the service.

systemctl status OracleGoldenGate
OracleGoldenGate.service - Oracle GoldenGate Service Manager
   Loaded: loaded (/etc/systemd/system/OracleGoldenGate.service; enabled; vendor preset: disabled)
   Active: failed (Result: start-limit) since Sun 2019-09-08 21:27:59 UTC; 2s ago
  Process: 3430 ExecStart=/opt/app/oracle/product/12.3.0/oggcore_1/bin/ServiceManager (code=killed, signal=SEGV)
 Main PID: 3430 (code=killed, signal=SEGV)


Sep 08 21:27:59 OGG12c219cUpgrade systemd[1]: Unit OracleGoldenGate.service entered failed state.
Sep 08 21:27:59 OGG12c219cUpgrade systemd[1]: OracleGoldenGate.service failed.
Sep 08 21:27:59 OGG12c219cUpgrade systemd[1]: OracleGoldenGate.service holdoff time over, scheduling restart.
Sep 08 21:27:59 OGG12c219cUpgrade systemd[1]: Stopped Oracle GoldenGate Service Manager.
Sep 08 21:27:59 OGG12c219cUpgrade systemd[1]: start request repeated too quickly for OracleGoldenGate.service
Sep 08 21:27:59 OGG12c219cUpgrade systemd[1]: <strong>Failed to start Oracle GoldenGate Service Manage</strong>r.
Sep 08 21:27:59 OGG12c219cUpgrade systemd[1]: Unit OracleGoldenGate.service entered failed state.
Sep 08 21:27:59 OGG12c219cUpgrade systemd[1]: OracleGoldenGate.service failed.

 

As you can tell the ServiceManager has failed to start. Why is this?

If you look at the output of the last systemctl status command, you see that the service is still referencing the old Oracle GoldenGate Microservices home.

Now the question becomes, how to I fix this?

The solution here is simple. Go to the deployment home for the ServiceManager and look under the bin directory. You will see teh registerServiceManager.sh script. Edit this script and change the variable OGG_HOME to match the new Oracle GoldenGate Home for 19c.

$ cd /opt/app/oracle/gg_deployments/ServiceManager/bin
$ ls
registerServiceManager.sh
$ vi registerServiceManager.sh


#!/bin/bash

# Check if this script is being run as root user
if [[ $EUID -ne 0 ]]; then
  echo "Error: This script must be run as root."
  exit
fi


# OGG Software Home location
OGG_HOME="/opt/app/oracle/product/12.3.0/oggcore_1” <— Change to reflect new OGG_HOME

Wit the registerServiceManager.sh file edit, go back and re-run the file as the root user.

# cd /opt/app/oracle/gg_deployments/ServiceManager/bin
# ./registerServiceManager.sh
Copyright (c) 2017, Oracle and/or its affiliates. All rights reserved.
----------------------------------------------------
     Oracle GoldenGate Install As Service Script
----------------------------------------------------
OGG_HOME=/opt/app/oracle/product/19.1.0/oggcore_1
OGG_CONF_HOME=/opt/app/oracle/gg_deployments/ServiceManager/etc/conf
OGG_VAR_HOME=/opt/app/oracle/gg_deployments/ServiceManager/var
OGG_USER=oracle
Running OracleGoldenGateInstall.sh…

With the service now updated, you can start and check the service.

# systemctl start OracleGoldenGate
# systemctl status OracleGoldenGate
OracleGoldenGate.service - Oracle GoldenGate Service Manager
   Loaded: loaded (/etc/systemd/system/OracleGoldenGate.service; enabled; vendor preset: disabled)
   Active: active (running) since Sun 2019-09-08 21:39:58 UTC; 2s ago
 Main PID: 21946 (ServiceManager)
    Tasks: 13
   CGroup: /system.slice/OracleGoldenGate.service
           └─21946 /opt/app/oracle/product/19.1.0/oggcore_1/bin/ServiceManager

Sep 08 21:39:58 OGG12c219cUpgrade systemd[1]: Started Oracle GoldenGate Service Manager.
Sep 08 21:39:58 OGG12c219cUpgrade ServiceManager[21946]: 2019-09-08T21:39:58.509+0000 INFO | Configuring user authorization secure store path as '/opt/app/oracle/gg_deployments/Serv...ureStore/'.
Sep 08 21:39:58 OGG12c219cUpgrade ServiceManager[21946]: 2019-09-08T21:39:58.510+0000 INFO | Configuring user authorization as ENABLED.
Sep 08 21:39:58 OGG12c219cUpgrade ServiceManager[21946]: Oracle GoldenGate Service Manager for Oracle
Sep 08 21:39:58 OGG12c219cUpgrade ServiceManager[21946]: Version 19.1.0.0.0 OGGCORE_19.1.0.0.0_PLATFORMS_190508.1447
Sep 08 21:39:58 OGG12c219cUpgrade ServiceManager[21946]: Copyright (C) 1995, 2019, Oracle and/or its affiliates. All rights reserved.
Sep 08 21:39:58 OGG12c219cUpgrade ServiceManager[21946]: Linux, x64, 64bit (optimized) on May  8 2019 18:17:50
Sep 08 21:39:58 OGG12c219cUpgrade ServiceManager[21946]: Operating system character set identified as UTF-8.
Hint: Some lines were ellipsized, use -l to show in full.


At this point, you can now log back into the ServiceManager and confirm that the upgrade was done successfully.

Note: If you have your ServiceManager configured to be manually started and stopped, then you will need to edit the startSM.sh and stopSM.sh file. The OGG_HOME has to be changed in these files as well.

Enjoy!!!

Categories: DBA Blogs

Find Docker Container IP Address?

Wed, 2019-08-14 11:38

This is just simple post for later reference, if I need it …

In setting up some docker containers for testing Oracle GoldenGate, I needed to find the IP address of the container where my database was running (I keep my database in a seperate container in order not to rebuild it every time).

To find the address of my database container, I had to use the docker “inspect” command. This command returns low level infomation on Docker objects.

The syntax is as follows:

docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}'  

 

 

Enjoy!!!!

Categories: DBA Blogs

Identifying the TNS_ADMIN for an deployment in GoldenGate Microservices

Wed, 2019-08-14 10:30

Setting up network routing/access with Oracle GoldenGate Microservices (12.3 and later) can be an interesting experience. As many in the Oracle space knows, you simply have to setup TNS_ADMIN to point to the location where your sqlnet.ora and tnsnames.ora files are located. This would normally look like this:


export TNS_ADMIN=${ORACLE_HOME}/network/admin


or


export TNS_ADMIN=$(ORA_CLIENT_HOME}/network/admin

 

These examples still working for Oracle GoldenGate Classic, however, when we start looking at this through the lens of Microservices; it changes a bit. Within the Oracle GoldenGate Microservices architecture the TNS_ADMIN enviroment variable has to be set “per deployment”. Depending on the number of deployments that are deployed with in the architecture, it is possible to have 1+N TNS_ADMIN variables.

As a illistration, it would look something like this:

As you can see this is specific to the Microservices architecture and how to setup network routing for individual deployments.

Setting TNS_ADMIN

How do you set the TNS_ADMIN environment variable for each deployment? It is quite simple, when you are building a deployment using the Oracle GoldenGate Configuration Assistant (OGGCA). Priort to running OGGCA, you can set the TNS_ADMIN variable at the OS level and the OGGCA will pick it up for that run and configuration of that specific deployment.

Optionally, you don’t have to set it at the OS level. During the OGGCA walkthrough, you will be able to set the variable manually. The OGGCA will not move past the enviornment variables step until it is provided.

Changing TNS_ADMIN

After building a deployment, you many want to chang the location of your network related files. This can be done from either the HTML5 web page for the deployment or from REST API.

To change TNS_ADMIN from the HTML5 pages within Oracle GoldenGate Microservices, you need to start at the ServiceManager Overview page. At the bottom on this page, there is a section called “Deployments”

The select the deployment you want to work with. After clicking on the deployment name, you should now be on the “Deployment Information” page. This page has two tabs at the top. The first tab is related to details of the deployment. The second table is related to configurations for the deployment.

Within the second tab – Configurations, is where you can set/change the environment variables for the deployment. In this case, we want to to modify the TNS_ADMIN enviornment variable.

 

To the right of the variable in the “Actions” column, click on the pencil icon. This will allow you to edit the environment variable. Change to the new location and save it. You may need to restart the deployment (hint, that step is on the ServiceManager Overview page).

At this point, you should now be able to change the location of your TNS_ADMIN variable. This is also handy for Oracle GoldenGate Microserivces on Marketplace as well … just saying.

Using REST API

This same process can be done quickly using the REST API. The below sample code, is only and sample and has not been tested. Use at your own risk!

curl -X PATCH \
  <a href="https://<ip_address>/services/v2/deployments/alpha" target="_blank" rel="noopener">https://<ip_address>/services/v2/deployments/alpha</a> \
  -H 'cache-control: no-cache' \
  -d '{
    "oggHome":"/opt/app/oracle/product/19.1.0/oggcore_1",
    "oggEtcHome":"/opt/app/oracle/gg_deployments/Atlanta/etc",
    "oggVarHome":"/opt/app/oracle/gg_deployments/Atlanta/var",
    "environment"{
    	"tns_admin":"/opt/app/oracle/product/18.1.0/network/admin"
    }
    "status":"restart"
}'

Enjoy!!!

Categories: DBA Blogs

AdminClient and Set Commands

Fri, 2019-08-02 13:32

AdminClient is the “new” command line utility that is used with Oracle GoldenGate Microservices. Initally, AdminClient was released with Oracle GoldenGate 12c (12.3.0.0.1) and enhanced in each release there after. With this new command line tool, there are a few things you can do with it that makes it a powerful tool for administering Oracle GoldenGate.

Reminder: This is only avaliable in Oracle GoldenGate Microservices Editions.

Features that make this tool so nice:

  • Default command line tool for Microservices
  • Can be installed on a remote linux machine or Windows Workstations/Laptops
  • Can “Set” advanced setting that provide a few nice features

The third bullet is what will be the focus of this post.

The “Set” command within AdminClient provide you with options that allow you to extend the command line for Oracle GoldenGate. These features are:

After starting the AdminClient, it is possible to see the current settings of these values by using the SHOW command:

Oracle GoldenGate Administration Client for Oracle
Version 19.1.0.0.1 OGGCORE_19.1.0.0.0_PLATFORMS_190524.2201


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


Linux, x64, 64bit (optimized) on May 25 2019 02:00:23
Operating system character set identified as US-ASCII.


OGG (not connected) 1> show


Current directory: /home/oracle/software/scripts
COLOR            : OFF
DEBUG            : OFF
EDITOR           : vi
PAGER            : more
VERBOSE          : OFF


OGG (not connected) 2>

 

If you want to change any of these settings, you can simply run the “set <option> <value>” at the command prompt. For example, I want to turn on the color option.

OGG (not connected) 2> set color on


OGG (not connected) 3> show


Current directory: /home/oracle/software/scripts
COLOR            : ON
DEBUG            : OFF
EDITOR           : vi
PAGER            : more
VERBOSE          : OFF


OGG (not connected) 4>

 

Now, that we can set these values and change how AdminClient responds; how can these settings be automated (to a degree)? In order to do this, you can write a wrapper around the execution of the AdminClient executable (similar to my post on resolving OGG-01525 error). Within this wrapper, the setting you want to change has to be prefixed with ADMINCLIENT_. This would like this:

export ADMINCLIENT_COLOR=<value>

Note: The <value> is case sensitive.

My shell script for AdminClient with the settings I like to have turned on is setup as follows:

#/bin/bash


export OGG_VAR_HOME=/tmp
export ADMINCLIENT_COLOR=ON
export ADMINCLIENT_DEBUG=OFF


${OGG_HOME}/bin/adminclient

 

Now, when I start AdminClient, I have all the settings I want for my environment. Plus, the ones I do not set will take the default settings.

[oracle@ogg19c scripts]$ sh ./adminclient.sh
Oracle GoldenGate Administration Client for Oracle
Version 19.1.0.0.1 OGGCORE_19.1.0.0.0_PLATFORMS_190524.2201


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


Linux, x64, 64bit (optimized) on May 25 2019 02:00:23
Operating system character set identified as US-ASCII.


OGG (not connected) 1> show


Current directory: /home/oracle/software/scripts
COLOR            : ON
DEBUG            : OFF
EDITOR           : vi
PAGER            : more
VERBOSE          : OFF


OGG (not connected) 2>

 

Enjoy!!!

Categories: DBA Blogs

ServiceManager … Manually start/stop

Tue, 2019-07-30 09:58

Oracle GoldenGate Microservices, starting in 12c (12.3.0.0.1) through 19c (19.1.0.0.1), provide a set of services that you can interact with via a webpage, command line, REST API, and PL/SQL. All of which is great; however, for any of these items to work the ServiceManager has to be up and running.

There are three ways configure ServiceManager when an environment is initally setup. These three ways are:

  • Manually
  • As a daemon
  • Integration with XAG agent (9.1 or later)

For this post, I’ll just show you how to start or stop ServiceManager manually. Manually starting or stopping the ServiceManager is the default setting if you do not select either of the other two options while running Oracle GoldenGate Configuration Assistant (OGGCA.sh).

In order to start or stop the ServiceManager manually, you have to make sure you have two files. These files are:

  • startSM.sh
  • stopSM.sh

Both of these files will be in the $DEPLOYMENT_HOME/bin directory for the ServiceManager. On my system this location is:

/opt/app/oracle/gg_deployments/ServiceManager/bin

Note: If you are running ServiceManager as a daemon, you will not have these files. In the bin directory you will find a file that is used to register ServiceManager as a daemon.

Before you can start or stop the ServiceManager manually, there are two (2) environment variables that need to be set. These environment variables are:

  • OGG_ETC_HOME
  • OGG_VAR_HOME

These environment variables are set to the etc and var directory locations for the ServiceManager deployment. On my system these are set to:

export OGG_ETC_HOME=/opt/app/oracle/gg_deployments/ServiceManager/etc
export OGG_VAR_HOME=/opt/app/oracle/gg_deployments/ServiceManager/var

Now with all these requirements met, I can now go back to the $DEPLOYMENT_HOME/bin directory and start or stop the ServiceManager.

[oracle@ogg19c bin]$ cd /opt/app/oracle/gg_deployments/ServiceManager/bin
[oracle@ogg19c bin]$ sh ./startSM.sh

[oracle@ogg19c bin]$ sh ./startSM.sh
Starting Service Manager process…
Service Manager process started (PID: 376)

In order to stop the ServiceManager manually:

[oracle@ogg19c bin]$ cd /opt/app/oracle/gg_deployments/ServiceManager/bin
[oracle@ogg19c bin]$ sh ./stopSM.sh
Stopping Service Manager process (PID: 376)…
Service Manager stopped

Enjoy!!!

Categories: DBA Blogs

Certs and AdminClient … How to login?

Thu, 2019-07-25 15:26

I’ve been building a test environment using Docker for sometime (over and over), to validate some items within Oracle GoldenGate Microservices (current release as of writing – 19.1.0.0.1). Part of setting Oracle GoldenGate Microservices is to make the environment secure by using certificates. Per Oracle documentation, you can use Self-Signed Certificates for testing purposes (more on that in this post).

In my testing, I have built an Oracle GoldenGate 19c Microservices configuraiton with two deployments (Atlanta and New York). I can access the ServiceManager and login to the associated HTML5 pages with no problem. When I went to run items from the command line (adminclient), I wouldn’t login to the ServiceManager/Deployment due to a Network Error.

[oracle@ogg19c scripts]$ sh ./adminclient.sh
Oracle GoldenGate Administration Client for Oracle
Version 19.1.0.0.1 OGGCORE_19.1.0.0.0_PLATFORMS_190524.2201</p>
Copyright (C) 1995, 2019, Oracle and/or its affiliates. All rights reserved.

Linux, x64, 64bit (optimized) on May 25 2019 02:00:23
Operating system character set identified as US-ASCII.

OGG (not connected) 1> connect https://ogg19c:16000 deployment NewYork as oggadmin password ********

ERROR: Network error - Certificate validation error

OGG (not connected) 2> exit

This got me thinking and started to ask some questions internally. Which lead me to a new envionrment parameter. This enviornment variable is OGG_CLIENT_TLS_CAPATH. The OGG_CLIENT_TLS_CAPATH variable is used to specify the root certificate athority needed to login to the ServiceManager/Deployment that has been secured using the certificate … in my case, my Self-Signed Certs.

After setting the enviornment variable OGG_CLIENT_TLS_CAPATH, I can now login to the AdminClient as expected.

[oracle@ogg19c scripts]$ export OGG_CLIENT_TLS_CAPATH=/home/oracle/wallet/Root_CA.pem
[oracle@ogg19c scripts]$ sh ./adminclient.sh
Oracle GoldenGate Administration Client for Oracle
Version 19.1.0.0.1 OGGCORE_19.1.0.0.0_PLATFORMS_190524.2201


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


Linux, x64, 64bit (optimized) on May 25 2019 02:00:23
Operating system character set identified as US-ASCII.


OGG (not connected) 1> connect https://ogg19c:16000 deployment NewYork as oggadmin password ********


OGG (https://ogg19c:16000 NewYork) 2>

 

I found this quite helpful.

Enjoy!!!!

Categories: DBA Blogs

Simple way to get rid of OGG-01525 for AdminClient

Wed, 2019-07-24 22:22

While installing Oracle GoldenGate 19c tonight, I was wanting to work from the command line and play around with AdminClient. For those who are not up to speed, AdminClient is the replacement for GGSCI when using Microservices.

AdminClient in Microservices provide the same functionalty as GGSCI, but it is a thin, lightweight tool that can be installed on a remote linux box or windows desktop/laptop. It allows you to make simple GGSCI commands and convert them into RESTP API calls on the backend. All the while, providing the same command line interface as GGSCI provided.

It is great that there is still a command line option for Oracle GoldenGate within the Microservices Architecture, however, when you start it you get presented with a Warning. The Warning is an OGG-01525 message that states there is no place to produce a trace file for the session.

WARNING OGG-01525 Failed to open trace output file, ‘/opt/app/oracle/product/19.1.0/oggcore_1/var/log/adminclient.log’, error 2 (No such file or directory).

So how do you fix this issue?

Note: This is not a bug! AdminClient was designed this way.

In order to fix this issue and get rid of the warning, you need to set a new enviornment variable. Since Oracle GoldenGate Microservices has been out for a bit over 2 year, I guess the environment variable isn’t that new. Any ways, the environment variable that needs to be set is OGG_VAR_HOME.

export OGG_VAR_HOME=/tmp

The OGG_VAR_HOME variable is used to tell AdminClient where to keep the adminclient.log file. In my example above, I’m using the temp ( /tmp ) directory for the log file.

Now, there is only one problem with the OGG_VAR_HOME environment variable. This environment variable along with OGG_ETC_HOME have to be set per Deployment Home environment. Meaning, when you have more than one Deployment Home, these environment variables are specific to that deployment.

The question that is begging to asked is -> How do I assign an environment variable for AdminClient and Deployments at the same time?

To solve this problem, I just wrote a simple shell wrapper and placed it in my home directory. The script looks like this:

[oracle@ogg19c scripts]$ cat adminclient.sh
#/bin/bash

export OGG_VAR_HOME=/tmp

${OGG_HOME}/bin/adminclient

Now, I can run the shell script and execute the AdminClient without getting the OGG-01525 warning.

[oracle@ogg19c scripts]$ sh ./adminclient.sh
Oracle GoldenGate Administration Client for Oracle
Version 19.1.0.0.1 OGGCORE_19.1.0.0.0_PLATFORMS_190524.2201

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

Linux, x64, 64bit (optimized) on May 25 2019 02:00:23
Operating system character set identified as US-ASCII.

 

OGG (not connected) 1>

For everyone is likes the Oracle GoldenGate command line, you still have access there!

Enjoy!!!

Categories: DBA Blogs

Build an Oracle GoldenGate Compute Node on OCI Marketplace

Wed, 2019-06-26 11:03

Over the last few weeks, I have been working with Oracle GoldenGate Development on a solution to bring Oracle GoldenGate to the OCI framework. Well, last nigh it has been released – Oracle GoldenGate 19c Microservices on OCI Marketplace.

You can now provision Oracle GoldenGate 19c into an OCI compute node in under 11 minutes (assumption is 4 core box). This is huge and will allow you to quickly build Oracle GoldenGate Microservices environments that allow you to conect on-premise resources to cloud resources as well as cloud-to-cloud solutions.

To show you how easy it is to build an Oracle GoldenGate 19c Microservices Compute Node, I have put together this short video (don’t shoot the messenger – this is my first attempt at using videos on my blog).

For more details on how to build Oracle GoldenGate on the OCI Marketplace, you can reference the Oracle Documentation as well. The link to the Marketplace doc is: https://docs.oracle.com/en/middleware/goldengate/core/19.1/oggmp/

Enjoy!!

Categories: DBA Blogs

EZConnect Oracle GoldenGate to Oracle Database – On-Premise or Cloud (DBaaS)

Tue, 2019-06-25 12:53

With the release of Oracle GoldenGate 19c, it has been made easier to connect Oracle GoldenGate to the Oracle Database – source or target. Gone are the days that you need to update your local tnsnames.ora file to point to the desired database. The only thing you have to do now, is ensure that your database is reachable via an easy connect (ezconnect) string.

Within Oracle GoldenGate 19c Microservices, you would simply setup the connection in the Credential Store within the Administration Service of the deployment where your GoldenGate processes will be running. In order to do this, you simply do the following:

1. Login to the Administration Service as an authorized user
2. Navigate to the Configuration option

3. Click on the plus ( + ) sign to add a new Credential. Fill in all the needed information. When filling in the information for User Id make sure you use the format for EZConnect:

<username>@<host>:<port>/<service_name>

4. Then click Submit

5. This will result in a useridalias connection being created and stored for the database. At this point, you can test the connection by clicking on the database icon for the connection.

If you provided the correct password for the user id, you should easily login to the Oracle Database you are pointed to.

This connection feature has been carried over to Oracle GoldenGate 19c Classic as well; afterall connections are part of the core product and enables both archiectures to connect in the same manner. The only difference is you would be workign from the GGSCI command line building the credential store information with some typing. To use EZConnect from GGSCI, follow these steps:

1. Login to GGSCI

$ cd $OGG_HOME
$ ./ggsci

2. Add the credential store (if you don’t already have one)

GGSCI (ogg19cca) 1> add credentialstore

3. Add the user with ezconnect string to the credential store

GGSCI (ogg19cca) 2> alter credentialstore add user c##ggate@oggdbaas:1521/orclogg password ************ alias SGGATE domain OracleGoldenGate

4. Test the connection using the DBLOGIN option

GGSCI (ogg19cca) 3> dblogin useridalias SGGATE domain OracleGoldenGate
GGSCI (ogg19cca as c##ggate@orclogg/CDB$ROOT) 4>

Enjoy!!!

Categories: DBA Blogs

ServiceManager Daemon fails to start on reboot?

Thu, 2019-04-11 21:23

If you have been working with Oracle GoldenGate 12c (12.3.0.1.x) or 18c (18.1.0) recently, you may have setup the ServiceManager as a daemon process. This is a great option for setting up the ServiceManager. The benefit is provides is when you host is rebooted it comes back online and allows you to see all of your managers; however, there is a small issue with the process … not really the process but the environment where it runs.

If you are like me, you like to setup your environment variables for quick reference; I do this with $OGG_HOME a lot, especially setting up new enviornments. Having this enviornment variable set actually causes a problem with the ServiceManager. If the $OGG_HOME variable is set for the Oracle user environment; the ServiceManager will not restart upon reboot. This leads you to try to execute ServiceManager from the $OGG_HOME/bin directory, like so:

$ cd $OGG_HOME/bin
$ ./ServiceManager &

When you do this, you will be met with a message similar to this:

$ Service Manager is terminating because it cannot load the inventory from ‘/opt/app/oracle/product/18.1.0/oggcore_1/etc/conf/deploymentRegistry.dat

So what does this message mean? The ServiceManager is trying to find the deploymentRegistry.dat file. This file has all of the configurations that ServiceManager needs to start (BTW – DO NOT EDIT THIS FILE DIRECTLY). You will also notice that the directory structure after $OGG_HOME is not correct. That is because the deploymentRegistry.dat file is located in the $DEPLOYMENT_HOME for the ServiceManager.

So how do you fix this issue? The answer is quite simple. Just unset $OGG_HOME within the envrionment. Then ServiceManager can be started from $OGG_HOME/bin. If you remove/rename $OGG_HOME from your oracle profile (.bash_profile, .bashrc, etc…), the ServiceManager will restart on reboot as well.

When starting the ServiceManager from $OGG_HOME/bin, the output should look something similar to this:

[oracle@db18c_ogg18c bin]$ ./ServiceManager &
[1] 464
[oracle@db18c_ogg18c bin]$ Oracle GoldenGate Service Manager for Oracle
Version 18.1.0.0.0 OGGCORE_18.1.0.0.0_PLATFORMS_180928.0432

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

 

Linux, x64, 64bit (optimized) on Sep 28 2018 17:31:51
Operating system character set identified as US-ASCII.

 

[1]+ Done ./ServiceManager

With the ServiceManager stared, you can now access the HTML5 web page or the associated REST APIs.

Enjoy!!!

Categories: DBA Blogs

Running GoldenGate Installers within Docker containers on MacOS

Fri, 2019-04-05 21:56

Over the last few days, I’ve been trying to improve the speed at which I can setup and configure Oracle GoldenGate for testing purposes. What I settled on what setting up a Docker container to be a VM subsistute. Besides I’ve been playing with Docker, off and on, for over a year now; yet I’m finally investing the time to drive this forward.

One of the items I’ve been trying to solve is “how do I test the installers for Oracle GoldenGate”? In order to do this, I’ve had to figure out how to run an X11 interface from the Docker container. In order to do this, I’ve had to use the product XQuartz (download here).

Configure XQuartz

After you download the XQuartz software, you will need to enable the security setting “Allow connections from network clients”. This setting enables connections from remote applications, i.e. within the Docker container.

XQuartz -> Preferences

After setting the settings in XQuartz, restart the application. The restart will enable the settings. Then start XQuartz and minimize the window.

Prepare Docker

With te XQuartz running, now I can start using Docker to run the installers. The steps that I need to this are:

Start a Docker container:
When you start the Docker container, you will need to specify the DISPLAY port in the run command. Also notice that I’m using “docker.host.internal”.

docker run -dit –privileged –name oraogg -e DISPLAY=host.docker.internal:0 oraogg:18.1.0

Enable XHost from the OS:
Before you can bring the installer GUI up on my host display, I need to enable the host to allow the connection. This is simply enabling xhost for the localhost.

xhost + 127.0.0.1

Set DISPLAY within the Docker Container:
With the Docker container running, I can now access the container and specify the DISPLAY variable. Also notice that I’m using “docker.host.internal” inside of the Docker container.

docker exec -it oraogg /bin/bash
su – oracle

export DISPLAY=host.docker.internal:0

Run the Installer:
Now I’m ready to start the Oracle GoldenGate Installer(s). I navigate to the $OGG_HOME/bin and run the Oracle GoldenGate Configuration Assistant (OGGCA).

 

At this point, I can use xQuartz to provide the GUI interface for items I want to install within a Docker container.

Enjoy!!

Categories: DBA Blogs

Quickly build self-signed certificates for Oracle GoldenGate 18c

Wed, 2019-03-27 13:30

With Oracle GoldenGate Microservices 12c and 18c, the architecture can be configured to use SSL certificates for securing and replicating between sites. This is a huge improvement for securing the replication framework and makes it a lot simpler to replicate data over standard HTTPS ports.

In order to configure Oracle GoldenGate 12c/18c Microserivces with SSL certificates, you either have to generate a self-signed certificate or bring your own certificate (BYOC) to use. This also requires you to build an Oracle Wallet to store the certificates in. Additionally, to secure both sides of the replication environment within a Microservices environment; the wallet is required to be copied to any other environment where you will be replicating to or from.

In this post, I’m providing you with a simple python script that will build the Self-Signed Certificates needed for testing purposes. By using this overly-simplified, script you assume responsibility of using the generated certificates.

For more details on configuring Oracle GoldenGate Microservices 12c/18c using Self-Signed Certificates, refer to the Oracle documentation for Securing Oracle GoldenGate Microservices (here).

My overly-simple python script is located here.

Happy Securing and Enjoy!!!

Categories: DBA Blogs

Installing Oracle GoldenGate 18c Microservices on Windows…. I know, why?

Fri, 2019-03-01 12:00

I’m not a huge fan of the Windows platform although I’ve spent the early part of my career as a Systems Admin working on Windows. As I’ve gotten a bit older, Linux/Unix seem to be more my way of thinking; however, there are still many customers out there who run Oracle Databases and Microsoft SQL Server databases on the Windows platform. They still have a need to move data, right?

In this post, you’ll walk through how to install (yes a boring installation post) Oracle GoldenGate 18c Microservices on the Windows platform. This will include building the ServiceManager and first deployment. First there are a few prerequisites that need to be installed on the Microsoft Windows Platform. These items are:

  • Microsoft Visual C++ 2010 SP1 (64-bit)
  • Microsoft Visual C++ 2012 (64-bit)
  • Microsoft Visual C++ 2017 (64-bit)

You wll also need to confirm with the certification matrix on what platforms are supported. You can find the certification matrix here.

Installation:

Just like previous releases starting with Oracle GoldenGate 12c (12.1.x), where the Oracle Universal Installer (OUI) was added; Oracle GoldenGate 18c is installed the same way on Windows as on *nix platforms. For this post, you will look at the OUI and the Oracle GoldenGate Configuration Assistance (OGGCA) on Windows.

1. Unzip the downloaded zip file to a directory of your choice. The zip file can either be pulled from Oracle EDelivery or from the Oracle Technology Network. The command below will unzip the file from a Linux prompt, but you can use the Windows Extractor or Winzip to unzip the file.

unzip V980818-01.zip -d ./ogg18c_win

2. Navigate to the directory where the you unzipped the file. You will find a directory called fbo_gg_Windows_x64_services_shiphome. Inside of this directory you will find another called Disk1. You will need to be inside of the Disk1 directory.

3. From the Disk1 directory, you will run the Setup application. You can double-click this application. This will start the Oracle Universal Installer.

4. On the first step of the Oracle GoldenGate 18c installation, you need to specify what version of the Oracle Database you will run Oracle GoldenGate against. Since there is an Oracle Database 18c installed, select the Oracle GoldenGate for Oracle Database 18c.

5. The Software Location is the same at the Oracle GoldenGate Home (OGG_HOME) location. Specify where the software should be installed.

6. Finally, confirm everything you have selected during the installation wizard and click “Install”. At this time, you can also option to save the install steps into a response file by click the “Save Response File” button.

7. At this point, the installation will begin and should complete fairly quickly. Once the installation is done, the Oracle Universal Installer can be closed.

With the Oracle GoldenGate 18c (18.1.0) software installed, you now want to to build your ServiceManager and first deployment. In order to do this, you will need to go to the $OGG_HOME\bin directory and run the batch file called OGGCA.

To run the Oracle GoldenGate Configuration Assistant (OGGCA (batch file)):

1. Navigate to the Oracle GoldenGate Home and enter the $OGG_HOME\bin directory

2. Double-Click on the batch file for the Oracle GoldenGate Configuration Assistanct (oggca). This will start the configuration assistant.

3. Being that this is a new installation, you will provide all the following information:

  • Select the radio button for “Create New Service Manager”
  • Provide the ServiceManager Deployment Home location
  • Leave “Listening hostname/address” as the default
  • Provide a “Listening Port”
  • Select the checkbox for “Registering Service Manager as a system service/daemon”

After you have provide all the needed details, select Next to move through the wizard.

4. Next step, you will add a new GoldenGate Deployment. On this step, the only thing you need to do is click “Next”. The radio button should already be selected for you.

5. Now you will need to provide the deployment details. This consists of the Deployment Name and the Software Home. Keep in mind that the Software Home is the Oracle GoldenGate Home (OGG_HOME). Should be automatically populated as well.

6. After defining the name of the Deployment, you are given the opportunity to provide the deployment home location. On this screen, you can also choose to customize the locations of various deployment files. For now, just provide a deployment home.

7. Next step is to make sure your environment variables are correct.

8. Provide an administrator account. This account is defined at the “Security Role” within the Microservices Deployment framework. This is the same account that will be used to login to the ServiceManager and associated Deployments. If this account is lost, there is no way to recreate the account to date. This same account will need to be use when creating additional deployments under the same ServiceManager.

9. At this point, you have to choose if you want your deployment to be secure or un-secure. To simplify the understanding of the install, lets go with un-secure; however, we will not be able to change the decision unless we recreate the deployment. Use the checkbox for SSL/TLS security very wisely.

10. Now you will assign port numbers to all the services within the deployment. These port numbers will allow you to access each service individually of each other. There is a port number for the following services:

  • Administration Server
  • Distribution Server
  • Receiver Server
  • Performance Metric Server – TCP
  • Performance Metric Server – UDP

Additionally, you need to select the type of NoSQL database that will be used for storing performance metrics information. In the example, you selected Berkely database (BDB). You can also select Light Memory Database (LMDB). Lastly, you will provide a location where the database information will be stored.

11. Now, you will provide the default GoldenGate schema. This is the GoldenGate user that will be inside of the Oracle Database/Pluggable Database. Items like Automatic Heartbeat and Checkpoint tables will go into this schema. In this example, lets call it GGATE.

12. Before creating the deployment, you now have the opportunity to review your selections on the Summary page. At the same time, you can select the “Save Response File” and edit the resulting file for silent installs of the deployments as well. If you are happy with everything you are selecting, then you can click “Finish” to begin building the ServiceManager and associated first deployment.

After clicking “Finish”, the Oracle GoldenGate Configuration Assistant will build the ServiceManaager and the first deployment. At this point, you should be able to access the ServiceManager using the hostname and port number you specified during the configuration.

Categories: DBA Blogs

Performance Metric Service – Classic Configuration

Thu, 2018-06-28 16:37

Almost a year ago, Oracle released Oracle GoldenGate 12c (12.3.0.1.x). At that time, there were two architectures released; Microservices and Classic. Both architectures provided the same enterprise level replication. The only difference was that one enabled a RESTful API interface with HTML5 page and the other was still command line driven.

The biggest change though was with the addition of the Performance Metric Service/Server that come bundled with the core product. This is a huge addition to the core product and allows end-users to monitor their Oracle GoldenGate environment in near-realtime. On the Microservices architecture this service is enabled automatically and can be used on a per deployment basis. With the Classic architecture, it is there but requires a small configuration to get it to work.

In this post, I’ll show you how to get the Performance Metric Service (PMSRVR) in Classic Architecture configured and access the RESTful API endpoints. The context of this post actually builds upon a post I did almost 3 years ago (here), where I talked about how to pull XML information via a browser for Oracle GoldenGate.

After installing Oracle GoldenGate 12c (12.3.0.1.4) Classic Architecture, open GGSCI and evaluate the environment. You should notice that you have a Manager, JAgent, and Performance Metric Service (PMSRVR) all as defaults (Figure 1).

Figure 1:

Next start the Manager (MGR) process. This is done the same way as has been done in in the past – START MGR. Once the MGR process is started, your GGSCI should look like Figure 2.

Figure 2:

Now to get the PMSRVR to work. This requires the editing of the GLOBALS file. The GLOBALS files can be edited either from the command line (vi GLOBALS). Within the GLOBALS file, turn on the ENABLEMONITORING parameter. At this point, you need to understand that there has been a few changes to Oracle GoldenGate with the ENABLEMONTIORING parameter. Without getting into to much details of the changes, you now have to specify the option for UDP.

A simple GLOBALS file would look like this:

ENABLEMONITORING UDP

At this point, you can start the PMSRVR within GGSCI (start pmsrvr) (Figure 3). What this does is provide you with a default port of 9004 to access PMSRVR pages via HTTP. If you want to get more detail and have a bit more control over the port numbers, you can modify the GLOBALS file to specify the HTTP port you want to use.

An example would look like this:

ENABLEMONITORING UDP HTTPPORT 12000

Note: https://docs.oracle.com/goldengate/c1230/gg-winux/GWURF/Chunk1486599197.htm#GWURF474

Then restart the PMSRVR. After the restart, you will be able to access the PMSRVR via the HTTP port specified.

Figure 3:

Now to access the PMSRVR page, just navigate to http://hostname:port/groups (Figure 4). This is the starting point for checking the status.

Figure 4:

Notice that in Figure 4, you see a list of all services that are avaliable within the product. The services like AdminSrvr, Recvsrvr, Distsrvr, and Adminclnt are never executed. This is normal since this is not the Microservice Architecture. These services will not work.

At this point, you can use the web pages to drill into the PMSRVR, MGR and any capture/apply processes that are being monitored by the PMSRVR.

Enjoy!!

Categories: DBA Blogs

Pages