Simple Query to Check if Your EM12c Plugins Are Uptodate

It’s recommended to use latest plugins with EM12c (to minimize bugs, better support for new releases of target etc), and you probably set notifications to get mails about plugin updates, but sometimes you just ignore them because you don’t have time. So you may want to check if any plugins you use have updates. It’s possible to do it using EM12c web interface. All you need is to go to “self update” page, click on “plugin updates” and then sort the list by plug-in name.

pluginupdates

Using APEX to Create a Mobile User Interface for Enterprise Manager 12c

On November 11th, I will be presenting at Oracle Day Istanbul. My presentation will be about creating a mobile interface (a simple application) using Application Express to access Oracle Enterprise Manager repository views (and some procedures) to manage incidents and problems. I know that there’s already an application for idevices, but my application is a web application designed for mobile (thanks to APEX), so it’s compatible with all devices. The sessions are short, only 30 minutes. So I will not go deep on technical details but I think it will be still enough to show what can be done with a small effort. By the way, here’s a simple animated GIF showing some screenshots of early version of my APEX application (Click on the below image to make the animation start):

em12capex

How to Find Blocking Sessions in Enterprise Manager Cloud Control 12c

My friend Franck Pachot noticed that EM12c doesn’t show the blocking sessions across all RAC nodes. Let’s check if we can find them using EM12c. I have connected to first node of our RAC database, created a sample table, inserted a row, committed, and then deleted the row. While the session is open, I opened another terminal, connected to second node and tried to delete the rows in same table so my second session started to wait for the transaction of my first session completed.

blocking sessions menu

I opened the main page of the cluster database, selected “blocking sessions” under the performance menu.

blockingsessions

Using EMCLI to Create Named Credentials

One of my blog readers asked me to write a sample EMCLI codes to create named credentials for Database. To be able to create a named credential, you need to know the target name (unless you create a global credential), target type and credential type associated with the target type. Let’s say I want to create a named credential for my database named “TESTDB”. First I need to login to our EM12c server, and list targets named “TESTDB”:

The % sign after the TESTDB means any target type (be careful about the colon (:) symbol between target name and target type). So we know that our TESTDB is an “oracle_database”. I’m sure you will memorize most of the target types after you start to work with EMCLI but I still prefer to check them before executing commands. Now we need to get the credential types (and their attributes) associated with “oracle_database”:

Enterprise Manager 12c: Failed Jobs

After I added some database targets to my Enterprise Manager 12c, an incident opened for failed jobs on a newly added database. We have some jobs scheduled to run every 5 minutes on that database, and of course we have some error-handling and alerting mechanism which will notify us if any of them fails, so there shouldn’t be any failed job. I checked run logs of all the scheduler jobs to see if there are any failed runs, and also old-style jobs if there are any broken one. Everything seems OK so I waited Enterprise Manager to pool failed jobs again but the incident stays open. Then I wondered how Enterprise Manager checks the failed jobs. I see that it uses the following query:

So instead of checking if any scheduler job recently failed, it just checks “failure_count” of scheduler jobs. Although those jobs haven’t failed for months, these counters are not reset automatically unless you disable/enable or recreate the job. So I have used DBMS_SCHEDULER.DISABLE and DBMS_SCHEDULER.ENABLE for the jobs which have failed once. It did reset failure_count(s) of the scheduler jobs and the incident is closed automatically.