April 16th, 2013 by Mark Rittman
In the previous post in this series, we looked at what Oracle Enterprise Manager 12cR2 and the BI Management Pack could do for OBIEE 11g admins, and how it manages a number of Oracle products from the database through to Fusion Middleware and the ERP applications. In today’s post I’m going to look at how an OBIEE system (or “target”) is registered so that we can then use BI Management Pack features, and how you make use of new features in the BI Management Pack such as support for Essbase targets.
I’ll work on the assumption that you’ve already got EM12cR2 installed, either on 64-bit Windows or 64-bit Unix (my preference is 64-bit Oracle Linux 5, though all should work); if you’ve not got EM12cR2 installed or your on an earlier version, the software is available on OTN and you’ll also need a suitable, recent and patched-up database to store the EM repository. Once you’ve got everything installed we can now login and take a look around – note that there’s no separate BI Management Pack download; all functionality is included but you need to be aware of what’s extra-cost and what’s not – the licensing guide is your best reference here, but at a high-level there are some parts of EM12cR2 that all licensed BI customers can use, whilst other features require the BI Management pack – we’ll cover this in more details in tomorrow’s post.
Logging into EM12cR2 presents you with a summary of the health and status of your systems, and you can see from the pie chart on the left that some of my systems are up, some are down and so forth. The Targets menu at the top of the screen lets me view similar information for hosts, middleware installations, databases and so on. My EM12cR2 installation has a number of OBIEE and other systems already registered with it, all of which are on VMs of which only a few are currently powered up.
In this example, I’m going to add a new host to this list, which is actually an Exalytics demo VM containing OBIEE 188.8.131.52 and TimesTen. Later on, we’ll look at adding Essbase to the list of monitored targets, both in terms of Essbase integrated into an OBIEE 184.108.40.206 install, and standalone as a separate install; finally, we’ll see how the BI Apps DAC is registered, so we can view the progress of Informatica ETL runs into the BI Apps data warehouse.
As I mentioned in yesterday’s post, EM12cR2 monitors and manages other servers by installing management agents on them; to do this, it needs to connect to the server via SSH, in order to install the agents software on there. To enable this, you need to provide the login credentials for a user on that server with “sudo” (act as an administrator) privileges, and a number of other settings have to be enabled for this process to work; to check that all of these are in place, let’s open up a console session on the Exalytics server and see how it looks:
[oracle@exalytics ~]$ sudo vi /etc/hosts
[sudo] password for oracle:
oracle is not in the shudders file. This incident will be reported.
What happened here is that I tried to run a command as the superuser, and the system asked for my password, but it turns out that this user isn’t in the list of users authorised to act as the superuser. To fix this, I need to now actually log in as root, and then issue the command:
to open up a special version of “vi” used for editing the sudoers file, and then add the line:
oracle ALL=(ALL) ALL
to the end to enable the “oracle” user to use the sudo command. After doing this and trying the previous commands again, I can now use the sudo command. Let’s now move over to the EM12cR2 website and start the process of registering the host, and thereafter registering the various software components on the Exalytics server.
There are various automated and semi-automated ways of discovering candidate servers on your network, but for simplicity I just select Setup > Add Target > Add Targets Manually from the menu in to top right-hand corner of the screen, which allows me to add details of the host directly rather than let EM scan the network to find them.
The Add Targets Manually page is then displayed. I select Add Host Targets from the set of radio button options, and then press the Add Host … button.
I then type in the name of the host (or IP address), and select the platform type. Note that unless your target is Linux x64, you’ll probably need to download the required agent software for that platform before you perform this task, using the Self Update feature.
Then, type in the location on the remote server that you want to install the agent software to, and the login credentials of the user that you’ve just enabled for sudo access on that server.
EM12cR2 will then attempt to install the agent. If you’re lucky, it’ll install first time, but more likely you’ll see a message like the one in the screenshot below saying that there was a problem with the agent installation.
What this is saying is that you need to make some further changes to the “sudoers” file on the remote server before EM can properly use it to install the agent. There are usually actually two issues, and you hit the second one after fixing the first, so let’s tackle them both now. Going back over to the remote server and logging in as the “oracle” user, let’s use sudo again to fix the issue:
[oracle@exalytics ~]$ sudo /usr/sbin/visudo
The first bit to find in the file is the line that says (assuming Oracle Linux 5, as I’m using):
This setting means that all users trying to use the sudo command need to be actually logging in via the server’s own console, not remotely via SSH; by default this is the setting with Oracle Linux 5, so to change it to not require access through the console for users, I change it to:
While you’re there, also add the line:
to the file as well, as EM will complain about that not being set if you try and deploy again now. Once both of these are set, go back to EM, retry the deployment with the existing settings, and the agent should deploy successfully. Note also that if your OBEE installation is on a Windows server, you’ll need to install the cygwin Unix-like environment on the server before you do all this, to enable the SSH service and BASH command shell that EM requires – see these notes in the EM12cR2 docs for more details.
So at this point the management agent software will be deployed to the server, but none of the WebLogic, database or BI software will be registered with EM yet. To do this, on the screen that’s again displayed after you’ve registered the host itself, select Add Non-Host Targets using Guided Process (Also Adds Related Targets) option, then from the Target Type drop-down menu select Oracle Fusion Middleware, and then press the Add Using Guided Discovery… button to start the process by registering the WebLogic installation which in turn hosts OBIEE 11g.
When prompted, select the host that you’ve just installed the agent to as the WebLogic Administration Server Host, put in the web logic administration user details to connect to the admin server (not the OS user details you used earlier), leave the rest of the settings at their default values and press Continue.
If all goes to plan EM should then report a number of targets found in the scan – these are the WebLogic Server components, plus the BI components that we’re actually interested in.
On the next page, add any notes that you want to the target registration details, then press the Add Targets button add these to the EM repository.
On the Middleware targets page that is displayed once the targets are registered, you should see your WebLogic installation now listed, and if you drill into the Farm entry you’ll see the domain and the coreapplication entry that represents your Oracle instance. Click on the details for the farm, and you’ll then see something that looks familiar from Fusion Middleware Control – the view of your OBIEE installation, where you can also drill into core application and see details of your instance. We’ll cover more on what this screen can do in tomorrows, final post on this topic.
At this point our OBIEE system is mostly registered and configured, but we still need to register the repository database, so the dashboard and scheduler reports can work. To do this, select Business Intelligence Instance > Target Setup > Monitoring Credentials from the coreapplication drop-down menu, and then enter the details for that server’s BIPLATFORM schema, like this:
You should then be able to select Business Intelligence Instance > Dashboard Reports from the coreapplication drop-down menu to see details of which dashboards have run, what error messages were logged and so forth.
Note that this is a fairly minimal set of reports against usage tracking data – there’s no ability to graph the results, for example, and no ability to view individual report usage, just dashboards. But at least it’s something.
So that’s taken care of the OBIEE elements of the Exalytics server install. But what about TimesTen server that provides the in-memory database cache on the Exalytics server? TimesTen support doesn’t come out-of-the-box with EM12cR2, but you can enable it through a plug-in that you enable via EM12cR2’s “self-update” feature. To do this, from the Setup menu on the top-right hand side select Setup > Extensibility > Self Update, click on Plug-in in the list of folders that are then displayed, and then locate the Oracle TimesTen In-Memory Database entry in the Plug-in Updates listing that is then displayed. Assuming that its not been downloaded by someone else beforehand, click on it and press the Download button, to start the download process into EM’s software library.
After a short while the plug-in should be downloaded from Oracle’s support website, and you can then make it available for use with an agent. To do so, locate it in the list of agents again, click on it to select it, and then press the Apply button that’s next to the (greyed-out) Download button. You’ll then be taken to the Plug-ins page where you should use the Deploy On button to deploy it first to the Management Server (i.e. the EM12cR2 server) and then the Management Agent server (in this case, our Exalytics server) – note that you’ll need to know the SYS password for the database that holds your EM repository to do the OMS registration part.
If all goes to plan EM should then start the process of deploying the TimesTen plugin to the Management Server first, once its checked prerequisites and so forth. On my system, it also actually deployed the plug-in to the Exalytics server too, even though I don’t think I actually requested it.
The final configuration step now is to use the plug-in to register the TimesTen target on the Exalytics server. To do this I return to the main Setup menu in the EM web console, and select Setup > Add Target > Add Targets Manually, and then select the Add Non-Host Targets by Specifying Target Monitoring Properties radio button. Then, when the Target Type drop-down menu is displayed, select TimesTen In Memory Database 11g from the list, and then select the management agent that’s on the Exalytics server. Once done, press the Add Manually… to go on to the next stage of the target registration process.
Then, when prompted, enter the connection details to your TimesTen instance, as used on the Exalytics server.
And that should be it – the TimesTen server should be registered and then available as a target to view in EM. It’ll take a while for metrics to start getting collected and displayed in the various graphs, but you can take a look at what’s recorded and what actions you can take from the menu that’ll now appear when you view a TimesTen target.
For Essbase, how to register the Essbase server as a target depends on whether Essbase is installed standalone in just a WebLogic managed server (as it is with Oracle’s SampleApp demo VMs), installed alongside OBIEE 220.127.116.11 or 18.104.22.168.2 BP1 as part of a single BI domain, or installed in its own full WebLogic domain with a WebLogic Server administration server. If its installed standalone, the initial registration of the WebLogic domain on the server concerned won’t register the Essbase server, and instead you’ll need to register it manually afterwards in a similar manner to the TimesTen server. If you’ve installed Essbase along with OBIEE as part of the combined 22.214.171.124 install, it’ll get registered along with OBIEE, and be displayed underneath coreapplication as shown in the screenshot below. Finally, if Essbase has its own WebLogic domain, then it gets detected as a target type as part of that domain’s registration, the same way that OBIEE does when registering it’s WebLogic domain as a target.
Finally, the BI Apps Data Warehouse Administration Console (DAC) is registered similarly to Essbase and TimesTen, except that like Essbase the plug-in required for management is already included in most EM12cR2 installations. As the DAC isn’t associated with any particular middleware home (at least, not with BI Apps 126.96.36.199) you’ll need to find it within the general list of targets rather than with the OBIEE installation its linked with.
So, with all of this set up, what can you do with it? In the final part of this series tomorrow, we’ll look at some common questions and usage scenarios around EM12cR2 and the BI Management Pack, and try and answer some of these questions.