7 Tuning Oracle Metadata Service

You can tune Oracle Metadata Services (MDS) to optimize its performance as an application server and Oracle relational database.

About Oracle Metadata Services (MDS)

Oracle Metadata Services (MDS) is an application server and Oracle relational database that keeps metadata in these areas: the ClassPath, the ServletContext, database repository and, sometimes, the file system.

One of the primary uses of MDS is to store customizations and persisted personalization for Oracle applications. MDS is used by components such as Oracle Application Development Framework (ADF) to manage metadata. Examples of metadata objects managed by MDS are: JSP pages and page fragments, ADF page definitions and task flows, and customized variants of those objects.


Most of the Oracle Metadata Services configuration parameters are immutable and cannot be changed at runtime unless otherwise specified.

Tuning MDS tablespace and cache size is important before you tune Oracle B2B and other Oracle products. If you are using the User's Guide for Oracle B2B to tune B2B, make sure you have completed the tuning described here first.

Monitoring Oracle Metadata Service Performance

MDS uses DMS sensors to provide tuning and diagnostic information, which can be viewed by using Enterprise Manager. This information is useful, for example, to see if the MDS caches are large enough.

Information on DMS metrics can be found in the Fusion Middleware Control Console. Click Help at the top of the page to get more information. In most cases, the Help window displays a help topic about the current page. Click Contents in the Help window to browse the list of help topics, or click Search to search for a particular word or phrase.

Basic Tuning Considerations

Tuning the MDS configuration is essential for improving performance.

The default MDS configuration must be tuned in almost all deployments. It is important to review the requirements and recommendations carefully.

Tuning Database Repository

For optimal performance of MDS APIs, the database schema for the MDS repository must be monitored and tuned by the database administrator.

For additional information on tuning the database, see Optimizing Instance Performance in Oracle Database Performance Tuning Guide.

Collecting Schema Statistics

While MDS provides database indexes, they might not be used as expected due to a lack of schema statistics. If performance is an issue with MDS operations such as accessing or updating metadata in the database repository, the database administrator must ensure that the statistics are available and current.

The following example shows one way that the Oracle database schema statistics can be collected:

execute dbms_stats.gather_schema_stats(ownname => '<username>',
estimate_percent => dbms_stats.auto_sample_size, method_opt=> 'for all 
columns size auto', cascade=>true);

If performance does not improve after statistics collection, then try to flush the database shared pool to clear out the existing SQL plans by using the following command:

alter system flush shared_pool;

In general, the database must be configured with automatic statistics recollection. For additional information on gathering statistics, see Automatic Performance Statistics in Oracle Database Performance Tuning Guide.

Increasing Redo Log Size

The size of the redo log files can influence performance because the behavior of the database writer and archiver processes depend on the redo log sizes. Generally, larger redo log files provide better performance. Undersized log files increase checkpoint activity and can reduce performance.

For more information, see Sizing Redo Log Files in Oracle Database Performance Tuning Guide.

Reclaiming Disk Space

While manual and auto-purge operations delete the metadata content from the repository, the database may not immediately reclaim the space held by tables and indexes. This may result in the disk space that is consumed by MDS schema to grow. Database administrators can manually rebuild the indexes and shrink the tables to increase performance and to reclaim disk space.

For more information, see Reclaiming Unused Space in Oracle Database Performance Tuning Guide.

Monitoring the Database Performance

Database administrators must monitor the database (for example, by generating automatic workload repository (AWR) reports for Oracle database) to observe lock contention, I/O usage and take appropriate action to address the issues.


Tuning Cache Configuration

MDS uses a cache to store metadata objects and related objects (such as XML content) in memory. MDS Cache is a shared cache that is accessible to all users of the application (on the same JVM). If a metadata object is requested repeatedly, with the same customizations, that object might be retrieved more quickly from the cache (a warmread). If the metadata object is not found in the cache (a cold read), then MDS might cache that object to facilitate subsequent read operations depending on the cache configuration, the type of metadata object and the frequency of access.

Cache can be configured or changed post deployment through MBeans. This element maps to the MaximumCacheSize attribute of the MDSAppConfig MBean. For more information, see Changing MDS Configuration Attributes for Deployed Applications in Administering Oracle Fusion Middleware.


MDS Metrics, visible in Enterprise Manager, are useful for tuning the MDS cache. In particular, IOs Per MO Content Get or IOs Per Metadata Object Get must be less than 1. If not, consider increasing the size of the MDS cache. For more information on viewing DMS metric information, see .

Having a correctly sized cache can significantly improve throughput for repeated reading of metadata objects. The optimal cache size depends on the number of metadata objects used and the individual sizes of these objects. Manually update the cache-config in the adf-config.xml file by adding the following entry prior to packaging the Enterprise ARchive (EAR) file:



MDS cache grows in size as metadata objects are accessed until it hits max-size-kb. After that, objects are removed from the cache to make room as needed on a least recently used (LRU) basis to make room for new objects.

Enabling Document Cache

In addition to the main MDS cache, MDS uses a document cache with each metadata store to store thumbnail information about metadata documents (base document and customization documents) in memory. The entry for each document is small (<100 bytes) and the cache size limit is specified in terms of the number of document entries. MDS calculates an appropriate default size limit for the document cache based on the configured maximum size of the MDS Cache, as follows:

  • If MDS cache is disabled, MDS defaults to having no document cache.

  • If MDS cache is enabled, MDS defaults the document cache size to one document entry per KB of document cache configured.

  • If cache-config is not specified, MDS defaults to 10000 document entries.

  • If MDS cache is set to a small value, MDS uses a minimum size of 500 for document cache.

In general, the defaults must be sufficient usually. However, insufficient document cache size might impact performance. Set document cache size by adding this entry to the adf-config.xml file prior to packaging the Enterprise ARchive (EAR) file:

<metadata-store-usage id="db1">
  <metadata-store …>
    <property name = …/>
  <document-cache max-entries="10000"/>


Document cache is cleared when it exceeds the document-cache max-entries value. To avoid performance issues, consider increasing the document cache size if you receive a notification like the following for example:

NOTIFICATION: Document cache DBMetadataStore : MDS Repository connection = <> exceeds its maximum number of entries <NNNN>, so the cache is cleared.

The DMS metric IOs Per Document Get (visible in Enterprise Manager, see Monitoring Oracle Metadata Service Performance) must be less than 1. If not, consider increasing the document cache size.

Purging Document Version History

MDS keeps document version history in the database's metadata store. As version history accumulates, it requires more disk space and degrades read/write performance. Assuming the document versions are not part of an active label, you can purge version history automatically or manually.


Purging version history manually may impact performance depending on the number of metadata updates that have been made since the last purge.

Using Auto Purge

The auto-purge interval can be configured or changed post deployment through MBeans. This element maps to the AutoPurgeTimeToLive attribute of the MDSAppConfig MBean. If your application uses the database store for MDS, you can set auto-purge by adding this entry in the adf-config.xml file prior to packaging the EAR:

  <auto-purge seconds-to-live="T"/>

In the example above, the auto-purge is executed every T seconds and removes versions that are older than the specified time T (in seconds). For more information, see Changing MDS Configuration Attributes for Deployed Applications in Administering Oracle Fusion Middleware.

Purging Manually

When you suspect that the database is running out of space or performance is becoming slower, you can manually purge existing version history by using the WLST command or through Oracle Enterprise Manager. Manual purging may impact performance, so plan to purge during a maintenance window or when the system is not busy.

See Purging Metadata Version History in Administering Oracle Fusion Middleware.

Using Database Polling Interval for Change Detection

MDS employs a polling thread, which queries the database to check if the data in the MDS in-memory cache is out of sync with data in the database. It happens when metadata is updated in another JVM. If it is out of sync, MDS clears any out-of-date-cached data so subsequent operations see the latest versions of the metadata. MDS invalidates the document cache, as well as MDS cache, so subsequent operations have the latest version of the metadata.

The polling interval can be configured or changed post deployment through MBeans. The element maps to the ExternalChangeDetection and ExternalChangeDetectionInterval attributes of the MDSAppConfig MBean. Configure the polling interval by adding this entry in the adf-config.xml file prior to packaging the Enterprise ARchive (EAR) file:

    <external-change-detection enabled="true" polling-interval-secs="T"/>

In the example mentioned, T specifies the polling interval in seconds. The minimum value is 1. Lower values cause metadata updates, that are made in other JVMs, to be seen more quickly. It is important to note, however, that a lower value can also create increased middle tier and database CPU consumption due to the frequent queries. By default, polling is enabled (true) and the default value of 30 seconds is suitable for most purposes. See Changing MDS Configuration Attributes for Deployed Applications in Administering Oracle Fusion Middleware.


When setting the polling interval, consider the following: if you poll too frequently, the database is queried for out-of-date versions; too infrequently, and those versions might stack up and polling can take longer to process.

Advanced Tuning Considerations

After you have performed recommended modifications, you can make additional changes that are specific to your deployment. Consider carefully whether the advance tuning recommendations are appropriate for your environment.

Analyzing Performance Impact from Customization

MDS customization might impact performance at run-time. The impact from customization depends on many factors including:

  • The type of customization that has been created (shared or user level).

  • The percentage of metadata objects in the system that is customized. The lower this percentage, the lower the impact of customization.

  • The number of configured customization layers, and the efficiency of the customization classes.

There are two main types of customization:

  • Shared Customizations: are layers of customization corresponding to customization classes whose getCacheHint method returns ALL_USERS or MULTI_USER, meaning the layer applies to all or multiple users. Shared customizations are cached in the (shared) MDS cache.

  • User Level Customizations (also known as Personalizations): are layers of customization corresponding to customization classes whose getCacheHint method returns SINGLE_USER, meaning the layer applies to one user. User customizations are cached on the user's session (Session) until the user logs out.

For details on customization concepts, writing customization classes, and configuring customization classes, see Customizing Applications with MDS in Developing Fusion Web Applications with Oracle Application Development Framework.