As you may already know, WebCenter makes extensive use of the Metadata Service (MDS) repository. The MDS repository ensures the consistent, and reliable access to the metadata for the WebCenter portal application. The same metadata that is used during the design/development phase of the application lifecycle is also used during runtime. Since all of the assets (pages, task flows, definitions, XML configuration files, customizations, .etc) that make up a WebCenter custom portal application is stored in the repository, MDS also provides common administrative tooling for managing the metadata. The tooling can be done either via the Enterprise Manager, or through the WebLogic (command line) scripting tool (WLST). This blog will be covering one important concept with managing the MDS, and that is the usage of metadata labels when performing customizations. Please consult the WebCenter documentation for more information about MDS and about using the other management tools.
What is a metadata label? A metadata label enables you to select a particular version of each asset from a metadata repository partition. Conceptually, a label is a collection of xml based document (i.e. customizations) versions, one version per document, representing a horizontal stripe through the various document versions. This stripe comprises the document versions, which were the tip versions (latest versions) at the time the label was created. You can use a label to view the metadata as it was at the point in time when the label was created. You can use the WLST commands to support logical backup and recovery of an application's metadata contained in the partition. Document versions belonging to a label are not deleted by automatic purging, unless the label is explicitly deleted. In this way, creating a label guarantees that a view of the metadata as it was at the time the label was created remains available until the label is deleted.
Creating a metadata label is easy. It can be done via Enterprise Manager, or through WLST. For example, the following is how to create a label named beforeCustomization, for myCustomApp, which is deployed to WC_CustomPortal, using WLST:
createMetadataLabel(application='myCustomApp', server='WC_CustomPortal', name='beforeCustomization')
Upon successful execution of the command, WLST will report Created metadata label beforeCustomization. Now any customization that is done will be stored under this label. If another label is created (i.e. after Customization), then the contents between the 2 labels can now be exported for manual manipulation. This process is sometimes necessary during backups, or in the case where the MDS is out of sync. Another operation that can now be performed is the promotion or even a purging of a particular label. The purging of the MDS is beneficial, since this operation will reduce the size of the database and improve the MDS performance. However, keep in mind that extreme caution should be noted as purging cannot be undone. To assist in the investigation of what is the state of the versions in MDS, the following two SQL based queries can help.
select docs.*, labels.count_labels, can_be_purged, round(100*(can_be_purged/docs.total)) pct_can_be_purged from (select partition_name, count(*) total, sum(decode(PATH_HIGH_CN, null, 1, 0)) tip, sum(decode(PATH_HIGH_CN, null, 0, 1)) non_tip, round(100*(sum(decode(PATH_HIGH_CN, null, 0, 1))/count(*))) percent_non_tip from MDS_PATHS x, MDS_PARTITIONS y where x.PATH_PARTITION_ID = y.PARTITION_ID and path_type = 'DOCUMENT' group by partition_name) docs, (select PARTITION_name, count(label_name) count_labels from MDS_LABELS l, MDS_PARTITIONS p where p.partition_id = l.label_partition_id(+) group by PARTITION_name, partition_id) labels, (SELECT partition_name, count (*) can_be_purged FROM MDS_PATHS path, MDS_TXN_LOCKS, MDS_PARTITIONS p WHERE partition_id = path_partition_id and path_low_cn <= lock_txn_cn AND path_low_cn > 0 AND NOT EXISTS (SELECT label_cn from MDS_LABELS WHERE path.path_low_cn <= label_cn AND (path.path_high_cn > label_cn OR path.path_high_cn IS NULL) AND label_partition_id = path.path_partition_id) AND path_high_cn IS NOT NULL AND path_partition_id = lock_partition_id and path_type = 'DOCUMENT' GROUP BY partition_name ) can_purge WHERE docs.partition_name = labels.partition_name AND docs.partition_name = can_purge.partition_name(+) order by total
The executions displays the following example:
This SQL query will return what versions are pinned by the labels. Note: the partition ID (B1) can be discovered by querying the MDS_PARTITIONS table:
select label_name, label_cn, (SELECT count( * ) FROM mds_paths path WHERE path_high_cn IS NOT NULL and path_low_cn <= label_cn AND path_low_cn > 0 and path_high_cn > label_cn AND path_partition_id = :B1) versHeld, txn_time from mds_labels, mds_transactions where label_partition_id=txn_partition_id and label_cn=txn_cn and label_partition_id=:B1 order by versHeld desc
Using these undocumented commands will hopefully help you to determine what you can purge, before you execute the command. In addition, here is a document that provides an overview of the label process in Enterprise Manager. Please consult the Managing the MDS chapter in the Oracle Fusion Middleware Administration Guide if you need more information about MDS.