Tuesday, July 19, 2011

UserWarning: MDS-91002: MDS Application runtime MBean for "soa-infra" is not available. "deleteMetadata" operation failure

You are trying to clean up the MDS using below steps:

  1. Execute SOA_HOME/common/bin/wlst.sh
  2. Connect to admin server by running connect()
  3. Enter the domain config by running domainConfig()
  4. Delete Metadata by running deleteMetadata('soa-infra', 'soa_server1','/apps/AIAMetaData/**')

    You encounter below error:

    UserWarning: MDS-91002: MDS Application runtime MBean for "soa-infra" is not available. "deleteMetadata" operation failure

    The SOA Managed Server is up and so s the SOAINFRA. What could be the possible reason?

    The reason for the above error is the name of the managed server used. In case your admin renamed the default managed server on which SOA is deployed (the default name is soa_server1) you would get the above stated error.

    So in case you get the above error, check with your admin the name of the SOA managed server. So in case your SOA managed server name is SOA_MS_1, the MDS purge command would be as follows:

    deleteMetadata('soa-infra', 'soa_ms_1','/apps/AIAMetaData/**')

    Hope this helps...

    Now you can folow us on facebook and post your comments/views and questions for expert advise. Check this out facebook

    Find us on facebook here

Thursday, July 14, 2011

How to Check Fusion Middleware and WebLogic Component Versions

Applies to:
Oracle Fusion Middleware - Version: to - Release: to Oracle11g
Information in this document applies to any platform.

This document describes how to determine the versions of installed Fusion Middleware Components and Weblogic Server.

Fusion Middleware components including WebLogic Server, RCU, and components such as SOA, Identity Management, Portal-Forms-Reports-Discover, and JDeveloper must have concordant versions. This affects configuration, but not installation, and can cause a variety of failures, including ClassDefNotFound exceptions when trying to configure a new domain or managed server.

1. To determine the WebLogic Server version. There are several ways to confirm the version:
  •  Enter this command with the weblogic environment enabled:
$ java weblogic.version

  • Look in the file Middleware Home/registry.xml, and note the component tag
  • The exact WLS version can be checked using the following commands:

    On Unix:
cat $MW_HOME/wlserver_10.3/.product.properties | grep WLS_PRODUCT_VERSION

On Windows:
type %MW_HOME%\wlserver_10.3\.product.properties | findstr WLS_PRODUCT_VERSION
  • Use SmartUpdate to check the Product Version:

    On Unix:
$MW_HOME/utils/bsu/bsu.sh -view -status=applied -prod_dir=$MW_HOME/wlserver_10.3 | grep ProductVersion

On Windows:
%MW_HOME%\utils\bsu\bsu.sh -view -status=applied -prod_dir=$MW_HOME\wlserver_10.3 | findstr ProductVersion

You should see a result such as this:
ProductVersion: 10.3 MP5

2. For JDeveloper, look in the Middleware Home/registry.xml file for the following:

3. For Fusion Middleware products, use the command Oracle Home/Opatch/opatch lsinventory and note the output:
Installed Top-level Products (2):

Application Server 11g SOA Patchset
Oracle SOA Suite 11g
There are 2 products installed in this Oracle Home.

4. For the MDS version, look in the file RCU Home/rcu/log/logdir./mds.log:
REPOS_VERSION CONSTANT VARCHAR2(32) := '' (this is for

To get the schema version from the database, login to the database as sysdba and enter the command as shown (example here for
SQL> select comp_id, comp_name, version from schema_version_registry;

Audit Service

Metadata Services

Oracle Internet Directory

Oracle Identity Federation Database Schema

Enterprise Scheduler Service

SIP Infrastructure Location Service

SIP Infrastructure Subscriber Data Service


8 rows selected.

You can also get the schema prefix from the database using the following command:
SQL> select username, created from dba_users order by 2;

------------------------------ ---------
OE 12-MAY-10
SH 12-MAY-10
BI 12-MAY-10
PM 12-MAY-10
TEST01_MDS 21-JAN-11
TEST01_IAU 21-JAN-11
ODS 21-JAN-11

------------------------------ ---------
TEST01_OIF 21-JAN-11

The prefix given in the Repository Creation Utility (RCU) dialog is TEST01.

Large number of instances in the SOA 11g dehydration store causes EM console performance issues

Applies To:

SOA Suite 11g R1(,,

Scenario and Symptoms:

The BPEL Engine Audit level is set to Development.

The BPEL engine is load tested with some huge number of transactions causing to generate large number of instances in the dehydration store(SOAINFRA Schema)

The number of instances is say 10-50 Lacs.The developers complain about EM Console being very slow. Drilling into composites and instances take minutes.Below activities in EM console take time:

1.       EM Login Page Load time
2.       Time taken for logging in to the EM
3.       Time taken to render homepage for SOAINFRA
4.       Expanding the SOAINFRA and each partition within
5.       Time taken to render home page for each  deployed composite
6.       Time taken to render details for each instance of any deployed composite


Large number of instances in the dehydration store with audit level set to Development. When you login to EM console it tries to load the large amounts of instance and fault data from database leading to slowing up the EM console response time.


Improving the Loading of Pages in Oracle Enterprise Manager Fusion Middleware Control Console

You can improve the loading of pages that display large amounts of instance and fault data in Oracle Enterprise Manager Fusion Middleware Control Console by setting two properties in the Display Data Counts section of the SOA Infrastructure Common Properties page.

These two properties enable you to perform the following:
  • Disable the fetching of instance and fault count data to improve loading times for the following pages:
    • Dashboard pages of the SOA Infrastructure, SOA composite applications, service engines, and service components
    • Delete with Options: Instances dialog

    These settings disable the loading of all metrics information upon page load. For example, on the Dashboard page for the SOA Infrastructure, the values that typically appear in the Running and Total fields in the Recent Composite Instances section and the Instances column of the Deployed Composites section are replaced with links. When these values are large, it can take time to load this page and other pages with similar information.

  • Specify a default time period that is used as part of the search criteria for retrieving recent instances and faults for display on the following pages:

    • Dashboard pages and Instances pages of the SOA Infrastructure, SOA composite applications, service engines, and service components
    • Dashboard pages of services and references
    • Faults and Rejected Messages pages of the SOA Infrastructure, SOA composite applications, services, and references
    • Faults pages of service engines and service components

Other Suggestions/Best Practices:

1. Purge the instance-The moment we purge the instances, we see good performance.The flipside is you cannot be purging data regularly in production (to meet SLAs). My take is if you are in development server you can afford frequent purging of the instances. In Stage/Prod the Audit level would be set to production,hence performance issues due to large number of instances would not be seen. After you purge the dehydration store make sure you shrink the SOAINFRA tables along with indexes (or rebuild indexes)

2. Set Audit Level to Production/Off-The flip side is developers won't be able to troubleshoot issues with their composites. Go ahead with these settings in Production.

3. Another strategy is Switching the audit configuration to 'Deferred' which allows the auditing operations to be performed in an ansynchronous manner resulting in performance comparable to setting the audit level to disabled.Please refer Tuning BPEL audit performance [ID 1328382.1].This is recommended in production.Also can be applied to Dev/Stage environments.

4. As the number of record grows in the dehydration the EM console takes longer time to return information about instances. I believe this is a result of bad performing querries and full table scans. Generate an AWR report and see if you can tune some querries and build some indexes on tables. Get this gone by the DBAs.

5. Using a fast single threaded server(eg M5000/9000) for database instead of using slow CMT servers like the Sun T5140/5240. Please refer Migration from fast single threaded CPU machine to CMT UltraSPARC T1 and T2 results in increased CPU reporting and diminished performance [ID 781763.1]

6. Try using M series boxes for the application tier as well. But if you have to use CMT servers like T5240 make sure you follow note 860459.1 and apply the steps in the solution part to adapt all the components with CMT machine.

Let me know if the above article helps.