7-2 Oracle Fusion Middleware Performance and Tuning Guide
■
Monitor the Database Performance For additional information on tuning the database, see Optimizing Instance
Performance in Oracle Database Performance Tuning Guide.
7.2.1 Collect Schema Statistics
While MDS provides database indexes, they may 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 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_statsownname = username, estimate_ percent = dbms_stats.auto_sample_size,
method_opt= for all columns size auto, cascade=true;
For additional information on gathering statistics, see Automatic Performance Statistics in Oracle Database Performance Tuning Guide.
7.2.2 Increase 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 reduce performance.
For more information see Sizing Redo Log Files in Oracle Database Performance Tuning Guide.
7.2.3 Reclaim 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 consumed by MDS schema growing. 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.
7.2.4 Monitor 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, IO usage and take appropriate action to address the issues.
For more information see:
■
Generating Automatic Workload Repository Reports in Oracle Database Performance Tuning Guide
■
Monitoring Performance in Oracle Database Administrators Guide.
Oracle Metadata Service MDS Performance Tuning 7-3
7.3 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 readwrite
performance. Assuming the document versions are not part of an active label, there are two ways to purge version history:
■
Auto Purge
■
Manual Purge
7.3.1 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 adf-config.xml prior to packaging the EAR:
persistence-config auto-purge seconds-to-live=T
persistence-config
In the example above, the auto-purge interval removes versions that are older than the specified time T in seconds. For more information, see Changing MDS
Configuration Attributes for Deployed Applications in Oracle Fusion Middleware Administrators Guide.
7.3.2 Manual Purge
When you suspect that the database is running out of space or performance is becoming slower, you can manually purge existing version history using WLST
command or through Oracle Enterprise Manager. Manual purging may impact performance, so plan to purge in a maintenance window or when the system is not
busy.
For more information about manually purging version history, see Purging Metadata Version History in Oracle Fusion Middleware Administrators Guide.
7.4 Using Database Polling Interval for Change Detection
MDS employs a polling thread which queries the database to gauge if the data in the MDS in-memory cache is out of sync with data in the database. This can happen 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
Note: Purging version history manually may impact performance
depending on the number of metadata updates that have been made since the last purge.
Tip:
Adjust the auto-purge interval based on document versions created in your application. Purging can take longer based on number
of versions created. See also Setting MDS Cache Size and Purge Rate in Oracle Fusion Middleware Administrators Guide for Oracle WebCenter.
7-4 Oracle Fusion Middleware Performance and Tuning Guide
ExternalChangeDetectionInterval attributes of the MDSAppConfig MBean. Prior to packaging the Enterprise ARchive EAR file, you can configure the polling
interval by adding this entry in adf-config.xml:
mds-config persistence-config
external-change-detection enabled=true polling-interval-secs=T persistence-config
mds-config In the example above, ’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 should be
suitable for most purposes. For more information, see Changing MDS Configuration Attributes for Deployed Applications in Oracle Fusion Middleware Administrators
Guide .
7.5 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 may be retrieved more quickly from the cache a
“warm” read. If the metadata object is not found in the cache a “cold” read, then MDS may 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 Oracle Fusion Middleware Administrators Guide.
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. Prior to packaging the Enterprise ARchive EAR file, you can manually update the cache-config in
adf-config.xml, by adding the following entry:
mds-config cache-config
max-size-kb200000max-size-kb cache-config
Note: 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 may stack up and
polling can take longer to process.
Note: 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 should be less than 1. If not,
consider increasing the size of the MDS cache. For more information on viewing DMS metric information, see
Section 7.7, Understanding DMS metrics and Characteristics
.
Oracle Metadata Service MDS Performance Tuning 7-5
mds-config
7.5.1 Document Cache
In addition to the main MDS cache, MDS uses a document cache in conjunction 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 very small value, MDS uses a minimum size of 500 for document cache.
In general, the defaults should be sufficient in most cases. However, insufficient document cache size may impact performance. Prior to packaging the Enterprise
ARchive EAR file, you can explicitly set document cache size by adding this entry to adf-config.xml:
metadata-store-usage id=db1 metadata-store …
property name = … metadata-store
document-cache max-entries=10000 metadata-store-usage
The DMS metric IOs Per Document Get visible in Enterprise Manager, see Section 7.7
should be less than 1. If not, consider increasing the document cache size.
7.6 Analyzing Performance Impact from Customization
MDS customization may impact performance at run time.The impact from customization depends on many factors including:
Note: 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. Unless time-to-live TTL is set, the MDS cache continues to occupy the max-size-kb of memory.
Note:
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.