Middleware Diagnostics Advisor (MDA) Setup

One of the areas I’ve been exploring recently is the setup and use of the Middleware Diagnostics Advisor, more commonly known as MDA. MDA is an advisor in EM12c that analyzes the entire stack and provides diagnostic findings by identifying root causes for any problems it discovers. It correlates and analyzes the input and offers advice on how to resolve the problem. For example, it can help you identify that slow SQL statements or a JDBC connection pool is causing a performance bottleneck. As described in the documentation, MDA is currently supported for Oracle WebLogic Server 10g Release 3 (10.3) and higher. MDA monitors JDBC DataSources, EJBs, and JMS Queues.

MDA enables you to easily identify the underlying states in the application server environment that are causing degraded performance. These underlying states can manifest themselves as slow responses for requests, hung servers, slow servers, high memory utilization, high disk I/O, and so on.

MDA analyses the overall performance of an aspect in a runtime environment. When the overall performance of the aspect degrades beyond a certain limit, MDA diagnoses the issue to find the underlying cause. However, individual one off issues, which do not affect the overall performance, are not isolated by MDA.

MDA diagnoses performances issues in the following areas:

  • JDBC findings:
    • Checks if the SQL execution takes a long time.
    • Checks if the JDBC Pool size is small, and if the wait time for connections is high.
    • Checks if reclaimed connections are found for data sources, and if the effective pool size is small.
  • JMS findings:
    • Checks if the message processing is slow.
    • Checks if the number of messages reprocessed due to transaction timeout is high.
    • Checks if the number of messages reprocessed due to transaction rollback is high.
    • Checks if the message delivery is delayed.
    • Checks if the queue slowed down due to large number of messages.
    • Checks if the queue slowed down due to large size of messages.
  • EJB findings:
    • Checks if the remote call made by the EJB takes too long to return.
    • Checks if the EJB takes too long to execute.
  • Thread findings:
    • Checks if there are locks that are being waited on by other threads.

If you want to see a video of MDA in action, follow this link to see MDA sizing the JDBC connection pool.

Under the Covers

Now that you know a little bit more about what it does, let’s have a look at how you set up MDA and what happens under the covers.

Enabling and Disabling MDA

Firstly, let’s look at how MDA is enabled. That’s pretty straightforward, as it’s enabled out of the box when you deploy the JVMD agent. Once that’s done, you can disable it altogether if you want, or indeed enable it again, from the WebLogic Domain menu. Go to All Targets and select the WebLogic Domain you want to enable/disable MDA for, then from the WebLogic Domain menu select “Diagnostics” followed by “Middleware Diagnostics Advisor” as shown in the screenshot below:

MDA_Configuration1http://petewhodidnottweet.com/wp-content/uploads/2015/09/MDA_Configurati... 250w, http://petewhodidnottweet.com/wp-content/uploads/2015/09/MDA_Configurati... 725w" sizes="(max-width: 725px) 100vw, 725px" />

That will take you to the page shown in the next screenshot. In this example, I’ve drilled into the WebLogic Domain installed with the OMS, and selected the first OMS in the two OMS configuration I have in this example. Once you select the target name, the bottom half of the screen appears as shown, prompting you for login information. In this example, OMS1 already has MDA enabled, so the “Disable” button is now available to me:

MDA_Configuration2http://petewhodidnottweet.com/wp-content/uploads/2015/09/MDA_Configurati... 1024w, http://petewhodidnottweet.com/wp-content/uploads/2015/09/MDA_Configurati... 250w, http://petewhodidnottweet.com/wp-content/uploads/2015/09/MDA_Configurati... 150w" sizes="(max-width: 1636px) 100vw, 1636px" />

Now that enabling and disabling is at a fairly broad level – the WebLogic domain. What if you wanted to be a bit more granular than that? Well, you can do that too. So for each of the findings categories listed above (JDBC, JMS, EJB, and Thread) there’s a specific emctl command to either enable or disable the checks. Here’s an example for disabling the check for JMS findings:

bash-3.2$ which emctl
/u01/app/oracle/product/middleware/oms/bin/emctl
bash-3.2$ emctl set property -name oracle.sysman.emas.mda.disableJmsAnalysisForTargets -value all
Oracle Enterprise Manager Cloud Control 12c Release 4
Copyright (c) 1996, 2014 Oracle Corporation. All rights reserved.
SYSMAN password:
Property oracle.sysman.emas.mda.disableJmsAnalysisForTargets has been set to value all for all Management Servers
OMS restart is not required to reflect the new property value

OK, that was pretty easy. How about re-enabling it? Well, that’s not listed in the documentation and switching the property name from disableJmsAnalysisForTargets to enableJmsAnalysisForTargets isn’t the easy answer you might expect. </p />
</p></div>

    	  	<div class=