| Oracle® Fusion Middleware Performance and Tuning Guide 11g Release 1 (11.1.1) Part Number E10108-04 |
|
|
View PDF |
| Oracle® Fusion Middleware Performance and Tuning Guide 11g Release 1 (11.1.1) Part Number E10108-04 |
|
|
View PDF |
This chapter provides tuning tips for Oracle Metadata Service (MDS).
Section 7.4, "Using Database Polling Interval for Change Detection"
Section 7.6, "Analyzing Performance Impact from Customization"
Section 7.7, "Understanding DMS metrics and Characteristics"
Oracle Metadata Services (MDS) is an application server and Oracle relational database that keeps metadata in these areas: a file-based repository data, dictionary tables (accessed by built-in functions) and a metadata registry. One of the primary uses of MDS is to store customizations and persisted personalization for Oracle applications. Oracle Metadata Services (MDS) is used by components such as Oracle WebCenter Framework and 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.
Note:
Most of the Oracle Metadata Service configuration parameters are immutable and cannot be changed at run time unless otherwise specified.For optimal performance of MDS APIs, the database schema for the MDS repository must be monitored and tuned by the database administrator. This section lists some recommended actions to tune the database repository:
For additional information on tuning the database, see "Optimizing Instance Performance" in Oracle Database Performance Tuning Guide.
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_stats(ownname => <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.
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.
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.
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.
For more information see:
"Generating Automatic Workload Repository Reports" in Oracle Database Performance Tuning Guide
"Monitoring Performance" in Oracle Database Administrator's Guide.
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, there are two ways to purge version history:
Note:
Purging version history manually may impact performance depending on the number of metadata updates that have been made since the last 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 Administrator's Guide.
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 Administrator's Guide for Oracle WebCenter.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 Administrator's Guide.
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 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 Administrator's Guide ".
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.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 Administrator's Guide.
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".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-kb>200000</max-size-kb>
</cache-config>
</mds-config>
Note:
MDS cache grows in size as metadata objects are accessed until it hitsmax-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.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>
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.
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.
MDS customization may 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 which 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: these 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): these are layers of customization corresponding to customization classes whose getCacheHint method returns SINGLE_USER, meaning the layer applies to just one user. User customizations are generally cached on the user's session (HttpSession) until the user logs out.
For more information about customization concepts, writing customization classes, and configuring customization classes, see "Customizing Applications with MDS" in Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
MDS uses DMS sensors to provide tuning and diagnostic information which can be viewed 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.
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|