Wouldn’t be nice to get regularly informed how (in)compliant you are with Oracle licenses in an easy – centralized – way, and therefore not have to worry about visits of Oracle’s LMS – License Management Services? I think that would be nice for the most of us. Running LMS-scripts on the target databases, hosts and middleware is for now the most thorough way to get informed about possible incompliancy. Or in some cased, using some clever – but informal and mostly incomplete – scripting on the OEM-repository.
But… Oracle is making serious attempts to make this easier, by integrating the LMS-information in the repository of Oracle Enterprise Manager and make this available through a couple of (BI Publisher) reports:
- Database Usage Tracking Report
- Database Usage Tracking Summary Report
When running these reports (Enterprise –> Reports -> BI Publisher Reports) with OEM 220.127.116.11 out of the box, unfortunately no data will be shown. There are some manual configuration and upgrades to be done. In the rest of the post I’ll explain some hurdles you have to overcome to get this working.
By the way, it’s not unthinkable that LMS will accept the outcome of these reports as a valid source for counting the (in)compliancy on a relative short notice.
As said, this post is about the following reports:
The Database Usage Tracking Summary Report can be run online, the Database Usage Tracking Report must be run through a scheduled job and the output will be sent to a ftp-server.
The steps to get output from these reports:
- The reports are BI Publisher reports. Although BI Publisher is the primary reporting tool for OEM12c and ships standard with OEM12c, it has to be configured to work properly.
The script ‘configureBIP’ has to be run, explained here. Be aware, Oracle Enterprise Manager will be restarted.
Note: BI Publisher may be used with OEM12C as a so-called ‘restricted license’. In short: free of charge as long as you use BI Publisher just for reporting the repository of Enterprise Manager.
- Database usage tracking credentials has to be set, just follow the instructions in the documentation. Note: this has to be done per database target, and the authorization is a kind of bizar:
This will be a next target for me why and if this is needed.
- Enabling the metric collection through monitoring templates, according to the same documentation mentioned before.
- Configuring a ftp-server via this same documentation (part : ‘generating database usage tracking report), only needed for the Database Usage Tracking Report. For the purpose of this post, I used the same host where OEM has been installed.
So far the technical documentation. It should work now, or is it? Almost. A few additional requirements are needed:
- The repository view SYSMAN.MGMT$DB_FEATUREUSEAGE is populated when the metric ‘Feature Usage’ has been enabled. This is well explained in note 1970236.1.
- The following tables should be populated too when enabling this metric, but weren’t at 18.104.22.168.0:
- Installing patch PSU3 was needed to get this right. Be aware: also OPatch needs to be upgraded. I used 22.214.171.124.6, to be found on the latest OPatch download-page. Don’t use the 12-Opatch, you get something like ‘cannot run as root’…
After that, the output of the Database Usage Tracking Summary Report looks like this (the database of the repository is shown here, for this is my lab-environment):
Then, the report Database Usage Tracking Report has to be scheduled through BI Publisher ‘Schedule Report Job’:
The output of the Database Usage Tracking Report shows like this and looks a lot like some output we had to send to LMS (excel-sheets) when executing the LMS-scripts on the target database:
O.k. It works. But now what? Is this the right information, and what is the incompliancy in relation to what you’re entitled to use (NUP’s, processor based, etc.).
Regarding the first question; is this the right information?
I configured and ran this report on a virtual box, and the only database target is the repository database itself. Based on this information the output of the ‘summary’ report is not correct, and probably the detail-report neither. But this conclusion is not fair, and it can only be answered when comparing customer LMS-data against the output of the script. I think Oracle is serious about this and undoubtedly they will get right as soon as possible (need one or two patches I think).
The next step for me will be to ask a few customers if they are willing to configure their Enterprise Manager the right way, and run on the other hand LMS scripts on their target databases in order to compare the outputs. I feel a new blog post coming up….
Regarding the second question: ‘what is the incompliancy’:
When the information is correct, you will always need somebody to interpret the data in relation to the use (production, development etc.), and put it next to what you’re entitled to with Oracle. So it’s not the script that shows unquestionably how much incompliant you are. But It’s definitely a step forward compared with running the LMS scripts on every target.
Configuring Usage reports: http://docs.oracle.com/cd/E24628_01/doc.121/e24473/usage_reports.htm#EMADM13567
OPatch download page: https://updates.oracle.com/download/6880880.html