13 Managing the Metadata Repository

This chapter provides information on managing the metadata repositories used by Oracle Fusion Middleware.

It contains the following topics:

13.1 Understanding a Metadata Repository

A metadata repository contains metadata for Oracle Fusion Middleware components, such as Oracle BPEL Process Manager, Oracle B2B, and Oracle WebCenter. It can also contain metadata about the configuration of Oracle Fusion Middleware and metadata for your applications.

Oracle Fusion Middleware supports multiple repository types. A repository type represents a specific schema or set of schemas that belong to a specific Oracle Fusion Middleware component (for example, Oracle BPEL Process Manager or Oracle Internet Directory.)

A particular type of repository, the Oracle Metadata Service (MDS) repository, contains metadata for certain types of deployed applications. This includes custom Java EE applications developed by your organization and some Oracle Fusion Middleware component applications, such as Oracle B2B. For information related specifically to the MDS Repository type, see Section 13.3.

You can create a database-based repository or, for MDS, a file-based repository. For production environments, you use a database-based repository. Most components, such as Oracle BPEL Process Manager, require that a schema be installed in a database, necessitating the use of a database-based repository.

13.2 Creating a Database-Based Metadata Repository

You use the Oracle Fusion Middleware Metadata Repository Creation Utility (RCU) to create the metadata repository in an existing database.

You can use RCU to create multiple repositories in a single database. You can use it to create the MDS Repository or a repository for metadata for particular components, such as Oracle WebCenter. RCU creates the necessary schemas for the components. See Appendix D for a list of the schemas and their tablespaces and datafiles.

With RCU, you can also drop component schemas.

For information about the supported versions of database platforms and versions, and other prerequisites for the database, see:

http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html

Note:

Oracle recommends that all metadata repositories reside on a database at the same site as the components to minimize network latency issues.

For information about managing a database-based MDS Repository, see Section 13.3.

See Also:

Oracle Fusion Middleware Repository Creation Utility User's Guide for information about how to use RCU to create a database-based metadata repository

13.3 Managing the MDS Repository

Oracle Metadata Service (MDS) repository contains metadata for certain types of deployed applications. Those deployed applications can be custom Java EE applications developed by your organization and some Oracle Fusion Middleware component applications, such as Oracle B2B and Oracle Web Services Manager. A Metadata Archive (MAR), a compressed archive of selected metadata, is used to deploy metadata content to the MDS Repository, which contains the metadata for the application.

You should deploy your applications to MDS in the following situations, so that the metadata can be managed after deployment:

  • The application contains seeded metadata packaged in a MAR.

  • You want to enable user personalizations at run time.

  • You have a custom Oracle WebCenter application.

  • You have a SOA composite application (SCA).

The following topics provide information about the MDS Repository:

See Also:

Oracle Fusion Middleware High Availability Guide for information about using an MDS Repository with Oracle Real Application Clusters (Oracle RAC)

13.3.1 Understanding the MDS Repository

The MDS framework allows you to create customizable applications. A customized application contains a base application (the base documents) and one or more layers containing customizations. MDS stores the customizations in a metadata repository and retrieves them at run time to merge the customizations with the base metadata to reveal the customized application. Since the customizations are saved separately from the base, the customizations are upgrade safe; a new patch to base can be applied without breaking customizations. When a customized application is launched, the customization content is applied over the base application.

A customizable application can have multiple customization layers. Examples of customization layers are industry and site. Each layer can have multiple customization layer values, but typically only one such layer value from each layer is applied at run time. For example, the industry layer for a customizable application can contain values for health care and financial industries; but in the deployed customized application, only one of the values from this layer is used at a time. For more information about base documents and customization layers, see "Customizing Applications with MDS" in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.

An MDS Repository can be file-based or database-based. For production environments, you use a database-based repository. You can have more than one MDS Repository for a domain.

A database-based MDS Repository provides the following features that are not supported by a file-based MDS Repository:

  • Efficient query capability: A database-based MDS Repository is optimized for set-based queries. As a result, it provides better performance on such searches with the database repository.

    The MDS Repository query API provides constructs to define the query operation and to specify conditions on metadata objects. These conditions are essentially a set of criteria that restrict the search results to certain set of attribute types and values, component types, text content, and metadata paths. The API allows multiple conditions to be combined together to achieve dynamic recursive composition using OR and AND constructs.

  • Atomic transaction semantics: A database-based MDS Repository uses the database transaction semantics, which provides rollbacks of failed transactions, such as failed imports or deployments.

  • Versioning: The MDS Repository maintains versions of the documents in a database-based repository. Versioning allows changes to metadata objects to be stored as separate versions rather than simply overwriting the existing data in the metadata repository. It provides version history, as well as the ability to label versions so that you can access the set of metadata as it was at a given point in time.

  • The capability in a running environment to isolate metadata changes and test them for a subset of users before committing them for all users.

  • Support for external change detection based on polling. This allows one application to detect changes another application makes to shared metadata. For example, if you have an application deployed to Managed Servers A and B in a cluster, and you modify the customizations for the application deployed in Managed Server A, the data is written to the database-based repository. The application deployed in Managed Server B uses the updated customizations. This supports high availability (in particular, active/active scenarios.)

  • Clustered updates: Updates from multiple hosts to the metadata are allowed. For a file-based MDS Repository, updates can be made from only one host at a time.

Multiple applications can share metadata by configuring a shared metadata repository. When you do this, changes made by one application to the metadata in this repository are seen by other applications using the shared repository, if you configure external change detection for the applications.

The MDS Repository supports Oracle databases, as well as non-Oracle databases. For more information about the supported databases, see:

http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html

Note:

To create a metadata repository in SQL Server, set READ_COMMITTED_SNAPSHOT to ON for the hosting database. This enables the needed row versioning support. This feature can be enabled using SQL command ALTER DATABASE, as in the following example:
ALTER DATABASE mds SET READ_COMMITTED_SNAPSHOT ON

Furthermore, you should use case sensitive collation to support the case-sensitive semantics in the metadata repository. For example, if Latin1_General is used, select the SQL_Latin1_General_CP1_CS_AS collation using the following SQL command:

ALTER DATABASE mds COLLATE SQL_Latin1_General_CP1_CS_AS

In the example, the substring of "CS" denotes case sensitivity.

Also note that when installed on SQL Server, Oracle Content Server 10g requires a database instance with case insensitive collation. As a result, it cannot exist in the same SQL Server database instance as MDS. If you wish to install both MDS and Oracle Content Server 10g, you must create a separate database instance with case insensitive collation for installing the Oracle Content Server 10g schema.

Note that there are some minor differences between an Oracle schema and a SQL Server schema. The length of the certain text fields are shorter for a SQL Server schema. For example, the full path name of the metadata in SQL Server is limited to 400 characters.

In an MDS Repository, each application, including Oracle Fusion Middleware components, is deployed to its own partition. A partition is an independent logical repository within one physical MDS Repository, whether it is database-based or file-based.

For information about deploying applications and associating them with an MDS Repository, see Chapter 9.

13.3.1.1 Understanding MDS Operations

You can use Fusion Middleware Control or WLST commands to perform most operations on the MDS Repository. However, for some operations that do not have a custom user interface in Fusion Middleware Control or do not have WLST commands, you must use the System MBeans.

The following sections describe using Fusion Middleware Control and WLST commands to perform the operations, unless only System MBeans are supported. In that case, the sections describe how to use System MBeans to perform the operation.

You can view information about the repositories, including the partitions and the applications deployed to each partition. You can also perform operations on the partitions, such as purging, deleting, importing metadata, or exporting metadata.

Note the following when you use the MDS operations described in the following sections:

  • The export operation exports a versioned stripe (either the tip version or based on a label) of metadata documents from an MDS Repository partition to a file system directory or archive. The directory or archive must be accessible from the host where the application is running. Because versioning of metadata is not supported for file-based repositories, the tip version (which is also the only version) is exported from a file-based repository.

  • The import operation imports metadata documents from a file system directory or archive to a MDS Repository partition. The directory or archive must be accessible from the host where the application is running. If the target repository is a database-based repository, the metadata documents are imported as new tip versions. If the target repository is a file-based repository, the metadata documents are overwritten.

Note:

Table 13-1 lists the logical roles needed for each operation. The roles apply whether the operations are performed through the WLST commands, Fusion Middleware Control, or MBeans.

Table 13-1 MDS Operations and Required Roles

Operation Logical Role

Clear cache

Operator role for application

Clone metadata partition

Admin role for domain

Create metadata label

Admin role for application

Create metadata partition

Admin role for domain

Delete metadata

Admin role for application

Delete metadata label

Admin role for application

Delete metadata partition

Admin role for domain

Deregister metadata database repository

Admin role for domain

Deregister metadata file repository

Admin role for domain

Export metadata

Operator role for application

Import MAR

Admin role for application

Import metadata

Admin role for application

List metadata label

Monitor role for application

Promote metadata label

Admin role for application

Purge metadata

Admin role for application

Register metadata database repository

Admin role for domain

Register metadata file repository

Admin role for domain


For information about how these roles map to WebLogic Server roles, see "Mapping of Logical Roles to WebLogic Roles" in the Oracle Fusion Middleware Security Guide.

13.3.2 Registering and Deregistering a Database-Based Metadata Repository

The following sections describe how to register and deregister a database-based MDS Repository:

13.3.2.1 Registering a Database-Based MDS Repository

You create a database-based MDS Repository using RCU, as described in Section 13.2. Before you can deploy an application to an MDS Repository, you must register the repository with the Oracle WebLogic Server domain.

To register a database-based MDS Repository using Fusion Middleware Control:

  1. From the navigation pane, expand the farm, then WebLogic Domain.

  2. Select the domain.

  3. From the WebLogic Domain menu, choose Metadata Repositories.

    The Metadata Repositories page is displayed, as shown in the following figure:

    Description of mr_home.gif follows
    Description of the illustration mr_home.gif

  4. In the Database-Based Repositories section, click Register.

    The Register Database-Based Metadata Repository page is displayed.

  5. In the Database Connection section, enter the following information:

    • For Database, select the type of database.

    • For Host Name, enter the name of the host.

    • For Port, enter the port number for the database, for example: 1521.

    • For Service Name, enter the service name for the database. The default service name for a database is the global database name, comprising the database name, such as orcl, and the domain name. In this case, the service name would be orcl.domain_name.com.

    • For User Name, enter a user name for the database which is assigned the SYSDBA role, for example: SYS.

    • For Password, enter the password for the user.

    • For Role, select a database role, for example, SYSDBA.

  6. Click Query.

    A table is displayed that lists the schemas and their metadata repositories in the database, as shown in the following figure:

    Description of mds_reg.gif follows
    Description of the illustration mds_reg.gif

  7. Select a repository, then enter the following information:

    • For Repository Name, enter a name.

    • For Schema Password, enter the password you specified when you created the schema.

  8. Click OK.

    The repository is registered with the Oracle WebLogic Server domain. In addition, a system data source is created with the name mds-repository_name. Global transaction support is disabled for the data source.

To register a database-based MDS Repository using the command line, you use the WLST registerMetadataDBRepository command. For example, to register the MDS Repository mds-repos1, use the following command:

registerMetadataDBRepository(name='mds-repos1', dbVendor='ORACLE',
    host='hostname', port='1521', dbName='ora11', 
    user='username', password='password', targetServers='server1')

13.3.2.2 Deregistering a Database-Based MDS Repository

Deregistration does not result in loss of data stored in the repository. However, any applications using this repository would not function after the repository is deregistered. You must ensure that no application is using the repository before you deregister it.

To deregister an MDS Repository using Fusion Middleware Control:

  1. From the navigation pane, expand the farm, then WebLogic Domain.

  2. Select the domain.

  3. From the WebLogic Domain menu, choose Metadata Repositories.

    The Metadata Repositories page is displayed.

    Alternatively, you can navigate to the Register Metadata Repositories page by choosing Administration, then Register/Deregister from the Metadata Repository menu when you are viewing a metadata repository home page.

  4. Select the repository from the table.

  5. Click Deregister.

  6. Click Yes in the Confirmation dialog box.

To deregister a database-based MDS Repository using the command line, you use the WLST deregisterMetadataDBRepository command. For example, to deregister the MDS Repository mds-repos1, use the following command:

deregisterMetadataDBRepository(name='mds-repos1')

13.3.3 Registering and Deregistering a File-Based Metadata Repository

The following topics describe how to register and deregister a file-based metadata repository:

13.3.3.1 Creating and Registering a File-Based Metadata Repository

You can create a file-based MDS Repository and register it with an Oracle WebLogic Server domain using Fusion Middleware Control.

To register a file-based repository using Fusion Middleware Control:

  1. From the navigation pane, expand the farm, then WebLogic Domain.

  2. Select the domain.

  3. From the WebLogic Domain menu, choose Metadata Repositories.

    The Metadata Repositories page is displayed.

  4. In the File-Based Repository section, click Register.

    The Register Metadata Repository page is displayed.

  5. Enter the following information:

    • For Name, enter a name. For example, enter repos1. The prefix mds- is added to the name and a repository with the name mds-repos1 is registered. If you enter a name that begins with mds-, a repository with the given name is registered.

    • For Directory, specify the directory. The Administration Server and Managed Servers that run the applications that use this repository must have write access to the directory. The directory is created if it does not exist.

      Note the following:

      • If the path specified exists on the file system, the metadata file repository is registered; all the subdirectories under this path are automatically loaded as partitions of this file-based repository.

      • If the path specified does not exist, a directory with this name is created on the file system during the registration. Because there are no partitions created yet, there are no subdirectories to load.

      • If the specified path is invalid and cannot be created for some reason, such as permission denied or the path exists as a file not a directory, an error is displayed and the registration fails.

  6. Click OK.

The repository is created and registered. It is now displayed on the Metadata Repositories page.

You can now create and delete partitions. Those changes are reflected in the directory on the file system.

You can also create a file-based repository using system MBeans. For information about using the System MBean Browser, see Section 3.6.

13.3.3.2 Deregistering a File-Based Repository

You can deregister a file-based MDS Repository using Fusion Middleware Control.

To deregister a file-based repository using Fusion Middleware Control:

  1. From the navigation pane, expand the farm, then WebLogic Domain.

  2. Select the domain.

  3. From the WebLogic Domain menu, choose Metadata Repositories.

    The Metadata Repositories page is displayed.

  4. In the File-Based Repository section, select the repository and click Deregister.

  5. Click OK in the Confirmation dialog box.

    If the file-based repository is valid, it is removed from the repository list. Otherwise, an error is displayed.

You can also deregister a file-based repository using system MBeans. For information about using the System MBean Browser, see Section 3.6.

13.3.4 Viewing Information about an MDS Repository

To view information about an MDS Repository with Fusion Middleware Control:

  1. From the navigation pane, expand the farm and then expand Metadata Repositories.

  2. Select the repository.

    The following figure shows the home page for an MDS Repository:

    Description of mds_home.gif follows
    Description of the illustration mds_home.gif

  3. To see general information about the repository, such as the type of repository and location, click the Info icon in the context pane, as described in Section 3.3.3.

13.3.5 Listing Repositories and Partitions

You can use the System MBean operations listPartitions, listRepositories, and listRepositoryDetails to get a list of partitions in the repository, a list of repositories, and details of the repository registered with the domain:

  1. In Fusion Middleware Control, from the navigation pane, navigate to the domain and select it. From the WebLogic Domain menu, choose System MBean Browser.

    The System MBean Browser page is displayed.

  2. In the page's navigation pane, expand Application Defined MBeans, then expand oracle.mds.lcm. Expand the domain, then MDSDomainRuntime, and then select MDSDomainRuntime.

  3. In the Application Defined MBeans pane, select the Operations tab.

  4. Click one of the operations to view the information.

13.3.6 Configuring an Application to Use a Different MDS Repository or Partition

When you deploy an application, you can associate it with an MDS Repository. You can subsequently change the MDS Repository or partition to which an application is associated, using WLST or Fusion Middleware Control. For example, a different repository contains different metadata that needs to be used for a particular application.

To associate an application with a new MDS Repository or partition, you can either:

  • Redeploy the application, specifying the new repository or partition. To create a partition, you can either:

    • Clone the partition to a different repository. Cloning the partition is valid only with a database-based repository with databases of the same type and version. When you clone the partition, you preserve the metadata version history, including any customizations and labels.

      Section 13.3.6.1 describes how to clone a partition and how to redeploy the application, specifying the partition that you have cloned.

    • Export the metadata from the current partition and import the metadata into the new partition, then redeploy the application, specifying a new partition.

      Section 13.3.6.2 describes how to redeploy the application, specifying a new repository or partition.

  • Change the system data source. When you change the system data source, you can change the database or the schema in which it is stored.

    Section 13.3.6.3 describes how to change the system data source.

13.3.6.1 Cloning a Partition

You can clone a partition to the same repository or a different repository using the system MBean cloneMetadataPartition. Both the original repository and the target repository must be a database-based repository.

To clone the partition, and then redeploy the application to a new repository or to the same repository:

  1. Clone the partition, using the cloneMetadataPartition operation on the system MBean. The following example clones partition1 from the old repository to the new repository:

    1. In Fusion Middleware Control, from the navigation pane, navigate to the Managed Server from which the application is deployed. From the WebLogic Server menu, choose System MBean Browser.

      The System MBean Browser page is displayed.

    2. In the System MBean Browser's navigation pane, expand Application Defined MBeans, then expand oracle.mds.lcm. Expand the domain, and then MDSDomainRuntime. Select MDSDomainRuntime.

    3. In the Application Defined MBeans pane, select the Operations tab.

      The following figure shows the System MBeans Browser with the Application Defined MBeans pane:

      Description of mds_mbean.gif follows
      Description of the illustration mds_mbean.gif

    4. Select cloneMetadataPartiton.

      The Operation: cloneMetadataPartiton page is displayed.

    5. In the Parameters table, enter the following values:

      • For fromRepository, enter the name of the metadata repository that contains the metadata partition from which the metadata documents are to be cloned.

      • For fromPartition, enter the name of the partition from which the metadata documents are to be cloned.

      • For toRepository, enter the name of the metadata repository to which the metadata documents from the source repository partition are to be cloned.

      • For toPartition, enter the name of metadata repository partition to be used for the target partition. The name must be unique within the repository. If you do not supply a value for this parameter, the name of the source partition is used for the target partition.

        If the toRepository name is the same as the original repository, you must enter a partition name and the name must be unique within the repository.

    6. Click Invoke.

    7. Verify that the partition has been created by selecting the repository in the navigation pane. The partition is listed in the Partitions table on the Metadata Repository home page.

  2. Redeploy the application, as described in Section 9.4.3, Section 9.5.3, or Section 9.6.3 depending on the type of application. When you do so, you specify the new partition and repository in the Application Attributes page:

    1. To change the repository, click the icon next to the Repository Name. In the Metadata Repositories dialog box, select the repository and click OK.

    2. To change the partition, enter the partition name in Partition Name.

13.3.6.2 Creating a New Partition and Reassociating the Application to It

You can create a new partition in the new repository by redeploying the application and specifying the new partition. Then, you transfer the metadata to the new partition using WLST.

You can use this procedure to transfer metadata between two different types of repositories (file-based to database-based, or from an Oracle Database to another database).

To create a new partition and reassociate the application to it:

  1. Export the metadata from the source partition to a directory on the file system using the WLST exportMetadata command:

    exportMetadata(application='sampleApp', server='server1',
           toLocation='/tmp/myrepos/mypartition', docs='/**')
    
  2. Redeploy the application, as described in Section 9.4.3, Section 9.5.3, or Section 9.6.3 depending on the type of application. When you do so, you specify the new partition and repository in the Application Attributes page:

    1. To change the repository, click the icon next to the Repository Name. In the Metadata Repositories dialog box, select the repository and click OK.

    2. To change the partition, enter the partition name in Partition Name.

  3. Import the metadata from the file system to the new partition using the WLST importMetadata command:

    importMetadata(application='sampleApp', server='server1',
           fromLocation='/tmp/myrepos/mypartiton', docs='/**')
    
  4. Optionally, deregister the original repository, as described in Section 13.3.3.2 or Section 13.3.2.2.

Alternatively, you can create new partition using the WLST command createMetadataPartition. The partition name must be unique within the repository. If the partition parameter is missing, the name of the source partition is used for the target partition. The following example creates the partition partition1:

createMetadataPartition(repository='mds-repos1', partition='partition1')

13.3.6.3 Changing the System Data Source

You can change the system data source to reassociate an application to a new repository. You can change the database or the schema that contains the data source. To do so, you use Oracle WebLogic Server Administration Console:

  1. In the Change Center, click Lock & Edit.

  2. In the Domain Structure section, expand Services, then JDBC, and select Data Sources.

    The Summary of JDBC Data Sources page is displayed.

  3. Select the data source you want to change.

    The Settings page is displayed.

  4. Select the Connection Pool tab.

  5. To change the database, modify the URL field. For example:

    jdbc:oracle:thin:@hostname.domainname.com:1522/orcl
    
  6. To change the schema, modify the Properties field, changing the user property. For example, to specify a schema named OFM-MDS, use the following:

    user=OFM-MDS
    
  7. For Password, enter the password for the schema, then confirm the password.

  8. Click Save.

  9. Restart the servers that use this data source. (Click the Target tab to see the servers that use this data source.)

13.3.7 Moving Metadata from a Test System to a Production System

You can transfer the metadata in MDS from one partition to another. As an example, you want to move an application from a test system to a production system. You have a test application that is deployed in a domain in the test system and a production application deployed in a domain in the production system. You want to transfer the customizations from the test system to the production system. To do that, you transfer the metadata from the partition in the test system to a partition in the production system.

To transfer the metadata from one partition to another, you export the metadata from the partition and then import it into the other partition. You can use Fusion Middleware Control or WLST to transfer the metadata.

To use Fusion Middleware Control to transfer metadata:

  1. From the navigation pane, expand the farm, expand Application Deployments, then select the application.

  2. From the Application Deployment menu, choose MDS Configuration.

    The MDS Configuration page is displayed.

  3. Click Export. The Export dialog box is displayed, as shown in the following figure:

    Description of export_mds.gif follows
    Description of the illustration export_mds.gif

  4. In the Export dialog box, enter a directory location or archive to which the metadata can be exported. The directory or archive file must be a local or network directory or file where the application is physically deployed. If the location does not exist in the file system, a directory is created except that, when the name ends with .jar, .JAR, .zip, or .ZIP, an archive is created. Exporting metadata to an existing archive overwrites the existing file.

    If you specify a directory, the metadata is written to a subdirectory of the directory that you specified, with the name of the partition that was exported as the name of the subdirectory.

    If you check Exclude base documents, this operation exports only the customizations, not the base documents. See Section 13.3.1 for information about base documents and customizations.

    Click OK.

  5. In the Confirmation dialog box, click Close.

  6. If the production application is on a different system, copy the exported metadata to that system.

  7. From the navigation pane for the production system, expand the farm, expand Application Deployments, then select the application.

  8. Click Import.

    The Import dialog box is displayed, as shown in the following figure:

    Description of import.gif follows
    Description of the illustration import.gif

  9. In the Import dialog box, enter the location of the directory or archive that contains the exported metadata. If you specify a directory, include the subdirectory with the partition name in the specification. The directory or archive file must be a local or network directory or file where the application is physically deployed.

  10. Click OK.

To use WLST to transfer metadata:

  1. Export the metadata from the original partition using the exportMetadata command:

    exportMetadata(application='sampleApp', server='server1',
           toLocation='/tmp/myrepos/mypartition', docs='/**')
    

    This command exports a versioned stripe of the metadata documents from the metadata partition to a file system directory.

  2. If the production application is on a different system, copy the exported metadata to that system.

  3. Import the metadata to the other partition using the WLST importMetadata command:

    importMetadata(application='sampleApp', server='server1',
           fromLocation='/tmp/myrepos/mypartiton', docs='/**')
    

    The value of the fromLocation parameter must be on the same system that is running WLST or on a mapped network drive or directory mount. You cannot use direct network references such as \\mymachine\repositories\.

13.3.8 Moving from a File-Based Repository to a Database-Based Repository

You can move from a file-based repository to a database-based repository. (You cannot move from a database-based repository to a file-based repository.)

To minimize downtime, take the following steps to move an application's metadata from a file-based repository to a database-based repository:

  1. Use RCU to create schemas in the new repository, as described in Section 13.2.

  2. Create a new partition using the WLST command createMetadataPartition with same name as source partition:

    createMetadataPartition(repository='mds-repos1', partition='partition1')
    
  3. Export the metadata from the source partition to a directory on the file system:

    exportMetadata(application='sampleApp', server='server1',
          toLocation='/tmp/myrepos/partition1', docs='/**')
    
  4. Import the metadata from the file system to the new partition:

    importMetadata(application='sampleApp', server='server1',
           fromLocation='/tmp/myrepos/partition1', docs='/**')
    
  5. Redeploy the application, as described in Section 9.4.3, Section 9.5.3, or Section 9.6.3 depending on the type of application. When you do so, you specify the new partition and repository in the Application Attributes page:

    1. To change the repository, click the icon next to the Repository Name. In the Metadata Repositories dialog box, select the repository and click OK.

    2. To change the partition, enter the partition name in Partition Name.

  6. Deregister the file-based repository, as described in Section 13.3.3.2.

13.3.9 Deleting a Metadata Partition from a Repository

You can delete metadata partitions if there are no applications either deployed to the partition or referring to the partition. You may want to delete a metadata partition from the repository in the following circumstances:

  • When you undeploy an application. Oracle Fusion Middleware leaves the metadata partition because you may still want the metadata, such as user customizations, in the partition. If you do not need the metadata, you can delete the partition.

  • When you have transferred metadata from one partition to another and configured the application to use the new partition.

  • When you have cloned a partition and configured the application to use the new partition.

Note that deleting a partition deletes all the data contained in the partition.

13.3.9.1 Deleting a Metadata Partition Using WLST

To delete a metadata partition from a repository, you can use the WLST command deleteMetadataPartition. For example, to delete the metadata partition from the file-based repository repository1, use the following command:

deleteMetadataPartition(repository='mds-repos1', partition='partition1')

13.3.9.2 Deleting a Metadata Partition Using Fusion Middleware Control

To delete a metadata partition from a repository partition using Fusion Middleware Control:

  1. From the navigation pane, expand the farm and then expand Metadata Repositories.

  2. Select the repository.

    The repository home page is displayed.

  3. In the Repository Partitions section, select the partition and click Delete.

  4. In the confirmation dialog box, click OK.

13.3.10 Purging Metadata Version History

For database-based MDS repositories, you can purge the metadata version history from a partition. (File-based MDS repositories do not maintain version history.) This operation purges version history of unlabeled documents from the application's repository partition. The tip version (the latest version) is not purged, even if it is unlabeled.

To purge labeled documents, you must first delete the label, as described in Section 13.3.11.2.

Consider purging metadata version history on a regular basis as part of MDS Repository maintenance, when you suspect that the database is running out of space or performance is becoming slower. This operation may be performance intensive, so plan to do it in a maintenance window or when the system is not busy.

For specific recommendations for particular types of applications, see the documentation for a particular component.

To use WLST to purge metadata version history, use the purgeMetadata command. You specify the documents to be purged by using the olderThan parameter, specifying the number of seconds. The following example purges all documents older than 100 seconds:

purgeMetadata(application='sampleApp', server='server1', olderThan=100)

To use Fusion Middleware Control to purge the metadata version history:

  1. From the navigation pane, expand the farm, expand Application Deployments, then select the application.

  2. From the Application Deployment menu, choose MDS Configuration.

    The MDS Configuration page is displayed.

  3. Click Purge.

    The Purge dialog box is displayed, as shown in the following figure:

    Description of mds_purge.gif follows
    Description of the illustration mds_purge.gif

  4. In the Purge all unlabeled past versions that are older than field, enter a number and select the unit of time. For example, enter 3 and select months.

  5. Click OK.

    A progress box is displayed. When the operation completes, a completion box is displayed.

  6. Click Close.

13.3.11 Managing Metadata Labels in the MDS Repository

A metadata label is a means of selecting a particular version of each object from a metadata repository partition. Conceptually, it is a collection of document 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.

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.

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 commands to support logical backup and recovery of an application's metadata contained in the partition.

Labels are supported only in database-based repositories.

The following topics describe how to manage labels:

13.3.11.1 Creating Metadata Labels

To create a label for a particular version of objects in a partition in an MDS Repository, you use the WLST command createMetadataLabel. For example, to create a label named prod1 for the application my_mds_app, use the following command:

createMetadataLabel(application='my_mds_app', server='server1', name='prod1')

If the application has more than one version, you must use the applicationVersion parameter to specify the version.

13.3.11.2 Deleting Metadata Labels

To delete a metadata label, you use the WLST command deleteMetadataLabel. For example, to delete a label named prod1 for the application my_mds_app, use the following command:

deleteMetadataLabel(application='my_mds_app', server='server1', name='prod1')

If the application has more than one version, you must use the applicationVersion parameter to specify the version.

To find the labels associated with an application, use the listMetadataLabels command, as described in Section 13.3.11.3.

13.3.11.3 Listing Metadata Labels

You can list the metadata labels for a particular application. To do so, use the WLST command listMetadataLabel. For example, to list the labels for the application my_mds_app, use the following command:

listMetadataLabels(application='my_mds_app', server='server1')

If the application has more than one version, you must use the applicationVersion parameter to specify the version.

13.3.11.4 Promoting Metadata Labels

You can promote documents associated with a metadata label so that they are now the last version. That is, you can promote them to the tip. Promote a label if you want to roll back to an earlier version of all of the documents captured by the label.

To promote a label to the tip, use the WLST command promoteMetadataLabel. For example to promote the label prod1, use the following command:

promoteMetadataLabel(application='my_mds_app', server='server1', name='prod1')

If the application has more than one version, you must use the applicationVersion parameter to specify the version.

13.4 Managing Metadata Repository Schemas

The following topics describe how to manage the metadata repository schemas:

13.4.1 Changing Metadata Repository Schema Passwords

The schema passwords are stored in the database.

For example, to change the password of the schema OFM_MDS:

  1. Connect to the database using SQL*Plus. Connect as a user with SYSDBA privileges.

  2. Issue the following command:

    SQL> ALTER USER schema IDENTIFIED BY new_password;
    

    For example, to change the OFM_ MDS password to abc123:

    SQL> ALTER USER OFM_MDS IDENTIFIED BY abc123;
    
  3. If you change the MDS Repository schema password, you must change the password for the corresponding MDS Repository data source, using Oracle WebLogic Server Administration Console:

    1. From Domain Structure, expand Services, then JDBC, and select Data Sources.

    2. Click the data source that is related to the MDS Repository.

    3. Click the Configuration tab, then the Connection Pool tab.

    4. For Password, enter the new password.

    5. Click Save.

    6. Restart the Managed Servers that consume the data source.

13.4.2 Changing the Character Set of the Metadata Repository

For information about changing the character set of metadata repository that is stored in an Oracle Database, see Oracle Database Globalization Support Guide:

http://www.oracle.com/technology/documentation/database.html

Oracle recommends using Unicode for all new system deployments. Deploying your systems in Unicode offers many advantages in usability, compatibility, and extensibility. Oracle Database enables you to deploy high-performing systems faster and more easily while utilizing the advantages of Unicode. Even if you do not need to support multilingual data today, nor have any requirement for Unicode, it is still likely to be the best choice for a new system in the long run and will ultimately save you time and money as well as give you competitive advantages in the long term.

When storing the metadata in a SQL Server database, if the character set being considered for your locale is not case neutral, the case-sensitive collation must be selected during the creation of the database instance. Unicode support is the default when creating the MDS schema for SQL Server using RCU. You may overwrite this default to use non-unicode schema if that meets your requirements