This post is meant to be more of a note for me to refer to later, but it is also good to share knowledge so here you go.
Note: Hostnames are blacked out for a reason. Commands are the same though.
Recently, I just installed an em agent using the silent install method I blogged about earlier (here). After installing the agent, everything was working fine and the agent could upload to the OMS. As I started to look around, within EM, I noticed that the host was not being monitored. I confirmed this by using “emctl config agent listtargets” in $EM_AGENT_HOME/bin.
In most cases, the agent installation, silent or otherwise, will pick up the host and turn the host from unmanaged host to manage host. Not in this case. So how can the host be discovered now?
In order to re-discover the host target on the machine, I needed to run “emctl config agent addInternalTargets”. This forced the agent to go out and rediscover the host and any potential targets on the host. Once it returns to the command prompt, then I ran “emctl config agent listtargets” again to verify that the host is now discovered.
Filed under: OEM
The Oracle Database Appliance (ODA) has been around for a few years now. It is a great, compact, and powerful machine for running at two-node Oracle Real Application Cluster (RAC). The adoption of the ODA has been mostly seen in medium sized organizations that need a work horse but cannot afford the sticker price of an Oracle Exadata.
Just like all the appliances that Oracle puts out, there is a need to monitor these appliances from top to bottom. This is achived by using Oracle Enterprise Manager 12c Plug-ins. Recently, Oracle let it be known that the ODA Plug-in has been released; however, from searching online it is not easily found. Hence the reason for this blog post…. :)
To find the ODA Plug-in, you need to basically download it from within the Self-Update area inside of Oracle Enterprise Manager 12c. In order to do this, you need to set you MOS credientials to access MOS.
Using Setup -> My Oracle Support -> Set Credentials
Once your MOS credentials are set, then you can got to the Self-Update page and update the plug-ins for your Oracle Enterprise Manager (Setup -> Extensibility -> Self-Update).
From the Self-Update page, select the Check Update.
After clicking the Check Update button, Oracle Enterprise Manager will kick off a job to update all the plug-ins in the software library. Once the job completes, you can look at the status of the job and see that the Oracle Database Appliance plug-in was downloaded successfully.
Now that the plug-in has been downloaded, you can go back to the Plug-in Page and deploy the plug-in to the agents that are running on the ODA targets (Setup -> Extensibility -> Plug-ins).
Listed under the Engineered Systems plug-ins, you will not see version 220.127.116.11.0 of the Oracle Database Appliance plug-in.
Now that the plug-in has been downloaded, it can be deployed to the required targets and configured (more on this later, hopefully).
Filed under: OEM
Like many other Oracle professionals and speakers I will be attending IOUG Collaborate 2015 this year in Las Vegas. I’m not a big fan of Las Vegas, but hey cannot turn down an opportunity to speak, especially when IOUG asked me to do more than one session.
This year my schedule is going to keep me busy; yet full of good topics that cover both EM12c and GoldenGate. If you are going to be a Collaborate, come check out my sessions and many others.
My sessions this year:
09:00 am – 03:00 pm – RAC SIG Function (RAC Attack)
10:30 am – Writing to Lead Panel discussion
12:00 pm – Exadata Exachk and EM12c: Keeping up with Exadata
17:30 pm – IOUG Data Integration SIG Meeting
11:00 am – Enable Oracle GoldenGate Monitoring for the Masses with EM12c
08:00 am – Examine Oracle GoldenGate Trail Files: How and When to use Logdump Utility
10:45 am – Extreme Replication: Performance Tuning Oracle GoldenGate for the Real World
If you are going to be a Collaborate, I look forward to see you there and hopefully in one of my sessions.
Filed under: Database, Golden Gate, OEM
In a few weeks I’ll be talking about monitoring Oracle GoldenGolden using Oracle Enterprise Manager 12c at IOUG Collaborate in Las Vegas. This is one of the few presentations I will be giving that week (going to be a busy week). Although this posting, kinda mirrors a previous post on how to configure the Oracle GoldenGate JAgent, it is relevant because:
1. Oracle changed the name of the JAgent to Oracle Monitor Agent
2. Steps are a bit different with this configuration
Most people running Oracle GoldenGate and want to monitor the processes with EM12c, will try to use the embedded JAgent. This JAgent will work with the OGG Plug-in 18.104.22.168. To get many of the new features and use the new plug-in (22.214.171.124), the new Oracle Monitor Agent (126.96.36.199) needs to be downloaded and installed. Finding the binaries for this is not that easy though. In order to get the binaires, download Oracle GoldenGate Monitor v188.8.131.52.0 from OTN.oracle.com.
Once downloaded, unzip the file to a directory to a temp location
$ unzip ./fmw_184.108.40.206.0_ogg_Disk1_1of1.zip -d ./oggmonitor Archive: ./fmw_220.127.116.11.0_ogg_Disk1_1of1.zip inflating: ./oggmonitor/fmw_18.104.22.168.0_ogg.jar
In order to install the agent, you need to have java 1.8 installed somewhere that can be used. The 22.214.171.124.0 software is built using JDK 1.8.
$ ./java -jar ../../ggmonitor/fmw_126.96.36.199.0_ogg.jar
After executing the command, the OUI installer will start. As you walk through the OUI, when the select page comes up; select the option to only install the Oracle GoldenGate Monitor Agent.
After the installation is complete, then the JAgent needs to be configured. In order to do this, navigate to the directory where the binaries were installed.
$ cd /u01/app/oracle/product/jagent/oggmon/ogg_agent
In this directory, look for a file called create_ogg_agent_instance.sh. This files has to be ran first to create the JAgent that will be associated with Oracle GoldenGate. In order to run this script, the $JAVA_HOME variable needs to be pointed to the JDK 1.8 location as well. Inputs that will need to be provided are the Oracle GoldenGate Home and where to install the JAgent (this is different from where the OUI installed).
$ ./create_ogg_agent_instance.sh Please enter absolute path of Oracle GoldenGate home directory : /u01/app/oracle/product/188.8.131.52/12c/oggcore_1 Please enter absolute path of OGG Agent instance : /u01/app/oracle/product/184.108.40.206/jagent Sucessfully created OGG Agent instance.
Next, go to the directory for the OGG Agent Instance (JAgent), then to the configuration (cfg) directory. In this directory, the Config.properities file needs to be edited. Just like with the old embedded JAgent, the same variables have to be changed.
$ cd /u01/app/oracle/product/220.127.116.11/jagent $ cd ./cfg $ vi ./Config.properties
Change the following or keep the defaults, then save the file:
jagent.host=fred.acme.com (default is localhost) jagent.jmx.port=5555 (default is 5555) jagent.username=root (default oggmajmxuser) jagent.rmi.port=5559 (default is 5559) agent.type.enabled=OEM (default is OGGMON)
Then create the password that will be stored in the wallet directory under $OGG_HOME.
cd /u01/app/oracle/product/18.104.22.168/jagent $ cd ./bin $ ./pw_agent_util.sh -jagentonly Please create a password for Java Agent: Please confirm password for Java Agent: Mar 26, 2015 3:18:46 PM oracle.security.jps.JpsStartup start INFO: Jps initializing. Mar 26, 2015 3:18:47 PM oracle.security.jps.JpsStartup start INFO: Jps started. Wallet is created successfully.
Now, enable monitoring in the GLOBALS file in $OGG_HOME.
$ cd /u01/app/oracle/product/22.214.171.124/12c/oggcore_1 $ vi ./GLOBALS
$ ./ggsci Oracle GoldenGate Command Interpreter for Oracle<br>Version 126.96.36.199.0 OGGCORE_188.8.131.52.0_PLATFORMS_140727.2135.1_FBO Linux, x64, 64bit (optimized), Oracle 12c on Aug 7 2014 10:21:34 Operating system character set identified as UTF-8. Copyright (C) 1995, 2014, Oracle and/or its affiliates. All rights reserved. GGSCI (fred.acme.com)> info all Program Group Lag at Chkpt Time Since Chkpt MANAGER RUNNING JAGENT STOPPED GGSCI (fred.acme.com)>; stop mgr! Sending STOP request to MANAGER ... Request processed. Manager stopped. GGSCI (fred.acme.com)>; delete datastore Are you sure you want to delete the datastore? yes Datastore deleted. GGSCI (fred.acme.com)>; exit $ ./ggsci Oracle GoldenGate Command Interpreter for Oracle Version 184.108.40.206.0 OGGCORE_220.127.116.11.0_PLATFORMS_140727.2135.1_FBO Linux, x64, 64bit (optimized), Oracle 12c on Aug 7 2014 10:21:34 Operating system character set identified as UTF-8. Copyright (C) 1995, 2014, Oracle and/or its affiliates. All rights reserved. GGSCI (fred.acme.com)>; create datastore Datastore created. GGSCI (fred.acme.com)>; start mgr Manager started. GGSCI (fred.acme.com)>; start jagent Sending START request to MANAGER ... JAGENT starting GGSCI (fred.acme.com)>; info all Program Group Lag at Chkpt Time Since Chkpt MANAGER RUNNING JAGENT RUNNING
With the JAgent running, now configure Oracle Enterprise Manager 12c to use the JAgent.
Note: In order to monitor Oracle GoldenGate with Oracle Enterprise Manager 12c, you need to deploy the Oracle GoldenGate Plug-in (18.104.22.168).
To configure discovery of the Oracle GoldenGate process, go to Setup -> Add Target -> Configure Auto Discovery
Select the Host where the JAgent is running.
Ensure the the Discovery Module for GoldenGate Discovery is enabled and then click the Edit Parameters to provided the username and rmx port specified in the Config.properties file. And provide the password was setup in the wallet. Then click OK.
If the discovery was successful, the Oracle GoldenGate Manager process should be able to be seen and promoted for monitoring.
After promoting the Oracle GoldenGate processes, they can then be seen in the Oracle GoldenGate Interface within Oracle Enterprise Manager 12c (Target -> GoldenGate).
At this point, Oracle GoldenGate is being monitored by Oracle Enterprise Manager 12c. The new plug-in for Oracle GoldenGate is way better than the previous one; however, there still are a few thing that could be better. More on that later.
Filed under: Golden Gate
In an earlier post, I mentioned that Oracle has finally, offcially supported the Oracle Management Repository (OMR) on Database 12c (22.214.171.124). As I’ve been working on a DBaaS project, I built a new Oracle Enterprise Manager (OEM) enivornment to test out a few things. Since I was rebuilding, I decided to try out the PDB as an OMR (afterall I’ve been asking about this approach). In the past, installation would fail around 63%. This time around, OEM installed in a PDB with no issue at all!
To verify that the OMR was actually in an PDB, I had to dig around a bit. Durning the installation, I had to provide connection information. This configuration can be verified by going to Management Services and Repository page within OEM. Once on this page, the Repository Details section (see image) will show you the database name and the connection string used. The connection string identified the PDB being used in the Service Name part of the connection.
In the image, you can see that I’m using a database named MGMT, yet the connection string is going to service name OEM1.acme.com. OEM1 is the PDB that is running under the MGMT consoldiated database (see image).
What makes this work this time around? There are a few patches that have to be applied to the Oracle Database (126.96.36.199) before the PDB can be used for the OMR. These patches are 19769480, 19877336, and 20243268. These patches are required (more details here). These patches require using OPatch 188.8.131.52.0 or higher which can be downloaded from MOS Note: 274526.1 (Patch 6880880).
Overall, Oracle did a good job in resolving this issue and giving the ability to host OEM in a PDB. There are a few questions that come to mind now. Here are just a few that I have:
1. What use cases will come out of this?
2. How will performance of OEM look in using a PDB?
3. How will licensing change with OEM and PDBs?
Anyways, give it a try!
Filed under: OEM
Last October (2014), at Oracle Open World 2014, I posted about a discussion where there was confusion on if Oracle Database 12c was supported as the Oracle Management Repository (OMR). At the time, Oracle had put a temporary suspension on support for the OMR running on Oracle Database 12c.
Over the last week or so, in discussions with some friends I heard that there may be an announcement on this topic soon. As of yesterday, I was provided a MOS note number to reference (1987905.1) for OMR support on database 12c. In checking out the note, it appears that the OMR can now be ran on a database 12c instance (184.108.40.206) with some restrictions.
These restrictions are:
- Must apply database patch 20243268
- Must apply patchset 220.127.116.11.1 (OCT PSU) or later
This note (1987905.1) is welcomed by many in the community who want to build their OMS on the latested database version. What is missing from the note is if installing the OMR into a pluggable database (PDB) is support. Guess the only way to find out is to try building a new Oracle Enterprise Manager 12c on top of a pluggable and see what happens. At least for now, Oracle Database 12c is supported as the OMR.
Filed under: OEM