1. Administering Oracle Fusion Middleware
  2. Advanced Administration
  3. Managing the Metadata Repository

14 Managing the Metadata Repository

Many Oracle Fusion Middleware components use metadata repositories to hold configuration information about the component and metadata for applications.

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

  • About Metadata Repositories
    A metadata repository contains metadata for Oracle Fusion Middleware components, such as Oracle Application Development Framework. It can also contain metadata about the configuration of Oracle Fusion Middleware and metadata for your applications.
  • Creating a Database-Based Metadata Repository
    You use the Oracle Fusion Middleware Repository Creation Utility (RCU) to create the metadata repository in an existing database.You can use RCU to create the MDS Repository or a repository for metadata for particular components. RCU creates the necessary schemas for the components.
  • Managing the MDS Repository
    Oracle Metadata Services (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.
  • Managing Metadata Repository Schemas
    Often, you need to change the passwords of the schemas in the metadata repository to enhance security. Less often, you may need to change the character set of the repository.
  • Purging Data
    When the amount of data in Oracle Fusion Middleware metadata repositories grows very large, maintaining the repositories can become difficult and can affect performance.

Parent topic: Advanced Administration

About Metadata Repositories

A metadata repository contains metadata for Oracle Fusion Middleware components, such as Oracle Application Development Framework. 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 Application Development Framework.) Oracle Fusion Middleware supports Edition-Based Redefinition (EBR), which enables you to upgrade the database component of an application while it is in use, thereby minimizing or eliminating down time. The schemas in a repository can be EBR-enabled schemas.

A particular type of repository, the Oracle Metadata Services (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. For information related specifically to the MDS Repository type, see Managing the MDS Repository.

You can create a database-based repository or, for MDS, a database-based repository or a file-based repository. For production environments, you use a database-based repository. Some components require that a schema be installed in a database, necessitating the use of a database-based repository. MDS supports Edition-Based Redefinition (EBR) enabled schemas.

Note:

After the database for the metadata repository has been used for the Oracle Fusion Middleware installation, the database service name or SID cannot be changed. However, the connect string may be changed due to High Availability or failover considerations, for example, to configure Oracle Data Guard to set up database failover.

For information on setting up database failover using Oracle Data Guard for FMW infrastructure 12c RCU created metadata repository schemas, see support Document 2142417.1 on My Oracle Support. You can access My Oracle Support at: https://support.oracle.com/.

For information on changing Oracle Fusion Middleware network configurations when moving a database to a new host, see Changing Oracle Fusion Middleware Network Configurations.

Parent topic: Managing the Metadata Repository

Creating a Database-Based Metadata Repository

You use the Oracle Fusion Middleware Repository Creation Utility (RCU) to create the metadata repository in an existing database.You can use RCU to create the MDS Repository or a repository for metadata for particular components. RCU creates the necessary schemas for the components.

See Repository Creation Utility Schemas, IDs, and Tablespaces in Creating Schemas with the Repository Creation Utility for a list of the schemas and their tablespaces and datafiles.

With RCU, you can also drop component schemas.

For information about the supported databases and the supported versions, as well as using these databases with the MDS Repository, see Supported Databases for the MDS Schema in Oracle Fusion Middleware System Requirements and Specifications.

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 an MDS Repository, see Managing the MDS Repository.

For information about how to use RCU to create a database-based metadata repository, see About the Repository Creation Utility in Creating Schemas with the Repository Creation Utility.

Parent topic: Managing the Metadata Repository

Managing the MDS Repository

Oracle Metadata Services (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 SOA composite application (SCA).

See Also:

About Oracle Real Application Clusters in the High Availability Guide for information about using an MDS Repository with Oracle Real Application Clusters (Oracle RAC)

Parent topic: Managing the Metadata Repository

Overview of 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 the 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 Developing Fusion Web Applications with 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 a set of criteria that restrict the search results to a certain set of attribute types and values, component types, text content, and metadata paths. The API allows multiple conditions to be combined 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: A database-based 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.

  • Isolate metadata changes: A database-based MDS Repository has the capability to isolate metadata changes in a running environment 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 that 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 to Managed Server A, the data is written to the database-based repository. The application deployed to Managed Server B uses the updated customizations. This supports high availability (in particular, active/active scenarios.)

  • Clustered updates: A database-based MDS Repository allows updates from multiple hosts to the metadata. 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.

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 Deploying Applications.

Note the following points about patching the MDS Repository:

  • An MDS Repository must be registered with a domain before it is patched. Otherwise, the applied patches cannot be rolled back and no additional patches can be applied.

  • You can apply patches to the following:

    • The MDS metadata.

    • An MDS jar file.

    • An MDS shared library.

    • An MDS schema in the database-based metadata repository. The patch can include additive changes such as adding a new column or increasing the size of a column. Note that you cannot rollback this type of patch.

    • The MDS database PL/SQL in the database-based metadata repository. The patch can include changes to a PL/SQL package or new PL/SQL packages and procedures.

    • An MDS schema or PL/SQL in the database-based metadata repository that requires a corresponding MDS JAR file patch.

Parent topic: Managing the MDS Repository

Databases Supported by MDS

The MDS Repository supports Oracle databases, as well as non-Oracle databases, including SQL Server, DB2, and MySQL.

For information about the supported databases and the supported versions, as well as using these databases with the MDS Repository, see Supported Databases for the MDS Schema in the Oracle Fusion Middleware System Requirements and Specifications

About 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 sections that follow 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 sections that follow:

  • 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. If you export to a directory, the directory must be accessible from the host where the application is running. If you export to an archive, the archive can be located on the system on which you are executing the command.

    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 an MDS Repository partition. If you exported to a directory, the directory must be accessible from the host where the application is running. If you exported to an archive, the archive can be located on the system on which you are executing the command.

    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 14-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 14-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

Destroy sandbox

Admin role for application

Export metadata

Monitor role for application

Export sandbox metadata

Monitor role for application

Import MAR

Admin role for application

Import metadata

Admin role for application

Import sandbox metadata

Admin role for application

List metadata label

Monitor role for application

List sandboxes

Monitor role for application

Promote metadata label

Admin role for application

Purge metadata

Admin role for application

Purge metadata labels

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 Securing Applications with Oracle Platform Security Services.

Registering and Deregistering a Database-Based MDS Repository

Note:

Note the following if you invoke the following WLST commands or comparable MBeans in a script:

  • registerMetadataDBRepository

  • deregisterMetadataDBRepository

In this release and previous releases, the commands or MBeans have the following behavior:

  1. Starts an Oracle WebLogic Server editing session.

  2. Registers or deregisters the repository.

  3. Activates the changes.

However, you can start an editing session explicitly. If you do, the automatic activation of the changes are deprecated.

Parent topic: Managing the MDS Repository

Registering a Database-Based MDS Repository

Before you can deploy an application to an MDS Repository, you must register the repository with the Oracle WebLogic Server domain. You can register a database-based MDS Repository using Fusion Middleware Control or WLST, as described in the following topics:

Registering a Database-Based MDS Repository Using Fusion Middleware Control

You create a database-based MDS Repository using RCU, as described in Creating a Database-Based Metadata Repository.

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

  1. From the WebLogic Domain menu, choose Other Services, then 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
  2. In the Database-Based Repositories section, click Register.

    The Register Database-Based Metadata Repository page is displayed.

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

    • For Database Type, 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.

  4. Click Query.

    A table is displayed that shows the metadata repositories in the database, as shown in the following figure:


    Description of mds_reg.gif follows
    Description of the illustration mds_reg.gif
  5. Select a repository, then enter the following information at the bottom of the page:

    • For Repository Name, enter a name.

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

  6. Click OK.

    The repository is registered with the Oracle WebLogic Server domain and is targeted to the Administration Server. To target the repository to other servers, see Targeting Additional Servers to an MDS Repository.

    In addition, a system data source is created with the name mds-repository_name. Global transaction support is disabled for the data source.

Registering a Database-Based MDS Repository Using WLST

To register a database-based MDS Repository using the command line, you use the WLST registerMetadataDBRepository command. You can specify the The WebLogic Server instances or clusters to which this repository will be registered. For example, to register the MDS Repository mds-repos1, to the server, server1, use the following command: 

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

You can specify a cluster by specifying the cluster name in the targetServers parameter.

Targeting Additional Servers to an MDS Repository

When you register an MDS Repository using Fusion Middleware Control, the repository is targeted to the Administration Server. You can target the repository to additional servers.

To target the MDS Repository to additional servers:

  1. From the navigation pane, expand Metadata Repositories.
  2. Select the repository.

    The repository home page is displayed, as shown in the following figure:

    Description of mr_home1.gif follows
    Description of the illustration mr_home1.gif
  3. In the Targeted Servers section, click Add.

    The Target the Repository dialog box is displayed.

  4. Select the server or cluster and click Target.

    You can expand the cluster to see the servers in the cluster. However, if you select a cluster, the repository is targeted to all servers in the cluster.

  5. When the operation completes, click Close.

    The server is now listed in the Targeted Servers section.

Removing Servers Targeted to a Metadata Repository

To remove a server as a target for the repository:

  1. From the navigation pane, expand Metadata Repositories.
  2. Select the repository.

    The repository home page is displayed.

  3. In the Targeted Servers section, select the target server and click Remove.

    The Untarget the Repository dialog box is displayed.

  4. Select the server or cluster and click Untarget.

    You can expand the cluster to see the servers in the cluster. However, if you select a cluster, the repository will be untargeted from all servers in the cluster.

  5. When the operation completes, click Close.
Deregistering a Database-Based MDS Repository

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

You can deregister a database-based MDS Repository using Fusion Middleware Control or WLST, as described in the following topics:

Deregistering a Database-Based MDS Repository Using Fusion Middleware Control

To deregister an MDS Repository using Fusion Middleware Control:

  1. From the WebLogic Domain menu, choose Other Services, then 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.

  2. Select the repository from the table.
  3. Click Deregister.
  4. Click Yes in the Confirmation dialog box.
Deregistering a Database-Based MDS Repository Using WLST

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')

Registering and Deregistering a File-Based MDS Repository

Note:

Note the following if you invoke the following MBeans in a script:

  • registerMetadataFileRepository

  • deregisterMetadataFileRepository

In this release and previous releases, the MBeans have the following behavior:

  1. Start an Oracle WebLogic Server editing session.

  2. Register or deregister the repository.

  3. Activate the changes.

However, you can start an editing session explicitly. If you do, the automatic activation of the changes are deprecated.

Parent topic: Managing the MDS Repository

Creating and Registering a File-Based MDS Repository

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

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

  1. From the WebLogic Domain menu, choose Other Services, then Metadata Repositories.

    The Metadata Repositories page is displayed.

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

    The Register Metadata Repository page is displayed.

  3. 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.

      Note the following:

      • If an absolute path is not given, the directory will be created under the DOMAIN_HOME directory.

      • If the specified path 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, an error is displayed and the registration fails.

      • If the specified path exists, but as a file not a directory, an error is not displayed and the registration succeeds.

  4. From Scope, select Global or a name of a partition.
  5. Click OK.

The repository is created and registered and is 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 Using System MBeans to Manage an MDS Repository.

Deregistering a File-Based MDS 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 WebLogic Domain menu, choose Other Services, then Metadata Repositories.

    The Metadata Repositories page is displayed.

  2. In the File-Based Repository section, select the repository and click Deregister.
  3. 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 Using System MBeans to Manage an MDS Repository.

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 can use Oracle WebLogic Server Administration Console or Fusion Middleware Control. To use Fusion Middleware Control:

  1. From the WebLogic Domain menu, choose JDBC Data Sources.

    The JDBC Data Sources page is displayed.

  2. Select the data source you want to change.

    The JDBC Data Source page for the selected data source is displayed.

  3. Select the Connection Pool tab.
  4. To change the database, modify the Database URL field. For example:
    jdbc:oracle:thin:@hostname.domainname.com:1522/orcl
  5. For Password, enter the password for the database.
  6. For Confirm Password, reenter the password for the database.
  7. To change the schema, modify the Properties section, changing the value for user.
  8. If the database is a DB2 database, add the property sendStreamAsBlob, with a value of true.
  9. Click Save.
  10. Restart the servers that use this data source.

Parent topic: Managing the MDS Repository

Using System MBeans to Manage an MDS Repository

Although most procedures in this chapter discuss using Fusion Middleware Control or WLST to manage the MDS Repository, you can also use system MBeans:

  1. 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, such as registerMetadataFileRepository.

    The Operations page is displayed.

  5. In the Value column, enter values for the operation.
  6. Click Invoke.

Parent topic: Managing the MDS Repository

Viewing Information About an MDS Repository

You can view information about an MDS Repository using Fusion Middleware Control or system MBeans, as described in the following topics:

Parent topic: Managing the MDS Repository

Viewing Information About an MDS Repository Using Fusion Middleware Control

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

  1. From the navigation pane, 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 which applications use the repository, click the icon in the Applications column. The Applications using the partition dialog box is displayed:

    • The Deployed Applications tab shows the list of applications whose metadata is deployed to the repository partition.

    • The Referenced by Applications tab shows the list of applications that refer to the metadata stored in the repository partition.

From this page, you can also:

Viewing Information About an MDS Repository Using System MBeans

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. 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, such as listPartitions, listRepositories, and listRepositoryDetails.

    The Operations page is displayed.

  5. Click Invoke.

    The information is displayed in the Return Value table.

For information about changing the MDS configuration attributes for an application, see Changing MDS Configuration Attributes for Deployed Applications.

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 new 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.

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

    • Create a new partition, then export the metadata from the current partition and import the metadata into the new partition.

      Creating a New Partition and Reassociating the Application to It describes how to create the partition and export and import data and how to redeploy the application, specifying the 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.

    Changing the System Data Source describes how to change the system data source.

Parent topic: Managing the MDS Repository

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 Redeploying Oracle ADF Applications or Redeploying SOA Composite Applications, 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.

Creating a New Partition and Reassociating the Application to It

You can create a new partition in the same or a different 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 Redeploying Oracle ADF Applications or Redeploying SOA Composite Applications, 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 Deregistering a File-Based MDS Repository or Deregistering a Database-Based MDS Repository.

Alternatively, you can create a 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')

Moving Metadata from a Source System to a Target 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, as described in the following topics:

Parent topic: Managing the MDS Repository

Transferring Metadata Using Fusion Middleware Control

To use Fusion Middleware Control to transfer metadata:

  1. From the WebLogic Domain menu, select Deployments.
  2. Select the application.
  3. From the Application Deployment menu, choose MDS Configuration.

    The MDS Configuration page is displayed, as shown in the following figure:

    Description of mds_config.gif follows
    Description of the illustration mds_config.gif
  4. In the Export section, select one of the following:

    • Export metadata documents to an archive on the machine where this web browser is running.

      Click Export.

      The export operation exports a zip file. Depending on the operating system and browser, a dialog box is displayed that asks you if you want to save or open the file.

    • Export metadata documents to a directory or archive on the machine where this application is running.

      Enter a directory location or archive to which the metadata can be exported.

      The target directory or archive file (.jar, .JAR, .zip or .ZIP) to which to transfer the documents selected from the source partition. If you export to a directory, the directory must be a local or network directory or file where the application is physically deployed. If you export to an archive, the archive can be located on a local or network directory or file where the application is physically deployed, or on the system on which you are executing the command.

      If the location does not exist in the file system, a directory is created except that when the names ends with .jar, .JAR, .zip or .ZIP, an archive file is created. If the archive file already exists, the exportMetadata operation overwrites the file.

      Click Export. Then, in the Confirmation dialog box, click Close.

    If you check Exclude base documents, this operation exports only the customizations, not the base documents. See Overview of the MDS Repository for information about base documents and customizations.

  5. If the target application is on a different system, copy the exported metadata to that system.
  6. On the target system, from the WebLogic Domain menu, select Deployments.
  7. Select the application.
  8. From the Application Deployment menu, choose MDS Configuration.

    The MDS Configuration page is displayed

  9. In the Import section, select one of the following:

    • Import metadata documents from an archive on the machine where this web browser is running.

      Click Browse and select the file.

    • Import metadata documents from a directory or archive on the machine where this application is running.

      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 Import.
  11. In the Confirmation dialog box, click Close.
Transferring Metadata using WLST

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. Only customization classes declared in the cust-config element of adf-config.xml are exported. If there is no cust-config element declared in adf-config.xml, all customization classes are exported.

    To export all customizations, use the option restrictCustTo="%".

  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\.

    Only customization classes declared in the cust-config element of adf-config.xml are imported. If there is no cust-config element declared in adf-config.xml, all customization classes are imported.

    To import all customizations, use the option restrictCustTo="%".

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 Creating a Database-Based Metadata Repository.

  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 Redeploying Oracle ADF Applications or Redeploying SOA Composite Applications, 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 Deregistering a File-Based MDS Repository.

Parent topic: Managing the MDS Repository

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.

You can delete a metadata partition using WLST or Fusion Middleware Control, as described in the following topics:

Parent topic: Managing the MDS Repository

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 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.
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 mds-repos1, use the following command: 

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

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 metadata labels, you use the purgeMetadataLabels command, as described in Purging Metadata Labels. Then, you can purge the metadata version history.

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. Note that MDS purges 300 documents in each iteration, commits the change, and repeats until all purgeable documents are processed.

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

You can purge metadata version history using WLST or Fusion Middleware Control, as described in the following topics:

Parent topic: Managing the MDS Repository

Purging Metadata Version History Using Fusion Middleware Control

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

  1. From the navigation pane, expand Application Deployments, then select the application.
  2. From the Application Deployment menu, choose MDS Configuration.

    For Oracle SOA Suite, you can expand SOA in the navigation tree, then select soa-infra. From the SOA Infrastructure menu, select Administration, then MDS Configuration.

    The MDS Configuration page is displayed.

  3. In the Purge section, in the Purge all unlabeled past versions older than field, enter a number and select the unit of time. For example, enter 3 and select months.
  4. Click Purge.
  5. In the Confirmation dialog box, click Close.
Purging Metadata Version History Using WLST

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)
Enabling Auto-Purge

You can enable automatic purging using the MDSAppConfig MBean:

  1. From the WebLogic Domain menu, choose System MBean Browser.

    The System MBean Browser page is displayed.

  2. Expand Application Defined MBeans, then oracle.adf.share.config, then Server: name, then Application: name, then ADFConfig, then ADFConfig, and ADFConfig.
  3. Select MDSAppConfig.

    The Application Defined MBeans page is displayed.

  4. For AutoPurgeTimeToLive, enter a value, in seconds.
  5. Navigate up to ADFConfig (the parent of MDSAppConfig) and select it.
  6. In the Operations tab, click Save.

Managing Metadata Labels in the MDS Repository

Parent topic: Managing the MDS Repository

About Metadata Labels

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.

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.

Labels are supported only in database-based repositories.

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.

When an application that contains a MAR is deployed, a label with the prefix postDeployLabel_ is created. For example: postDeployLabel_mdsappdb_mdsappdb.mar_2556916398.

Each time you patch the MAR, a new deployment label is created, but the previous deployment label is not deleted Similarly, when you undeploy an application that contains a MAR, the application is undeployed, but the label remains in the metadata repository partition.

If you delete a deployment label, when the application is restarted, the MAR is automatically redeployed, and the deployment label is also re-created.

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')
Executing operation: createMetadataLabel.

Created metadata label "prod1".

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

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')
Executing operation: listMetadataLabels.

Database Repository partition contains the following labels:
prod1
prod2
postDeployLabel_mdsappdb_mdsappdb.mar_2556916398

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

Promoting Metadata Labels

You can promote documents associated with a metadata label so that they become the latest 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')
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root. 
For more help, use help(domainRuntime)

Executing operation: promoteMetadataLabel.

Promoted metadata label "prod1" to tip.

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

Purging Metadata Labels

You can purge metadata labels that match the given name pattern or age, allowing you to purge labels that are no longer in use. This reduces the size of the database, improving performance. You must delete the labels associated with unused metadata documents before you can purge the documents and revision history from the repository.

You may want to delete a label for older applications that were undeployed, but the labels were not deleted. Each time you patch the MAR, a new label is created, but the previous label is not deleted.

You can use Fusion Middleware Control or WLST to purge metadata labels, as described in the following topics:

Purging Metadata Labels Using Fusion Middleware Control

To purge metadata labels using Fusion Middleware Control:

  1. From the navigation pane, expand Metadata Repositories.

  2. Select the repository.

    The repository home page is displayed.

  3. Select a partition and click Manage Labels.

    The Manage Labels page is displayed, as shown in the following figure:

    Description of mds_labels.gif follows
    Description of the illustration mds_labels.gif

    By default, the table lists all metadata labels created in the selected partition that are more than one year old and that are not deployed or associated with a sandbox.

  4. To search for a particular label or labels, you can:

    • For Label Name, select an operator and enter the filter criteria. The characters are case sensitive. You can use the following wildcards:

      • Percent (%): Matches any number of characters

      • Underscore (_): Matches a single character

      • Backslash (\): Used as an escape character for the wildcards

      For example, the string postDeployLabel% returns any label beginning with postDeployLabel. As a result, it displays labels associated with a deployed MAR.

    • For Age, enter a number, such as 2. (The only operator available is Older Than.)

    • For Age (units), select a unit, such as Hours, Days, Weeks, Months, Years. The only operator available is Equals.

  5. Click Search.

  6. By default, labels associated with sandboxes and deployed applications are not shown. To display those labels, select Sandboxes or Deployment or both. Note the following:

    • You cannot delete a label associated with a sandbox.

    • If you select Deployment, the labels that are associated with MAR deployments are displayed.

  7. Select the label and click Delete Selected.

  8. In the confirmation box, click OK.

If you want to purge all unused labels, for a particular deployed application:

  1. Select Deployment.
  2. Filter by name, using the string postDeployLabel_application_name%.
  3. Select all but the latest (which is in use) to delete. (The most recent label---the one that is currently being used---is listed first.)
  4. Click Delete Selected.

Parent topic: Purging Metadata Labels

Purging Metadata Labels Using WLST

You can purge metadata labels that match the given pattern or age, using the WLST command purgeMetadataLabels. The command purges the labels that match the criteria specified, but it does not delete the metadata documents that were specified by the labels.

For example, to purge all metadata labels that match the specified namePattern and that are older than 30 minutes:

purgeMetadataLabels(repository='mds-myRepos', partition='partition1',
                      namePattern='prod*', olderThanInMin='30')
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root. 
For more help, use help(domainRuntime)

Executing operation: purgeMetadataLabels.

The following metadata labels were purged: repository=mds-soa,parititon=partition1,namePattern=prod*,olderThanInMin=30:

Parent topic: Purging Metadata Labels

Deleting Metadata Labels

To delete a specified 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 Listing Metadata Labels.

Managing Metadata Repository Schemas

Often, you need to change the passwords of the schemas in the metadata repository to enhance security. Less often, you may need to change the character set of the repository.

Parent topic: Managing the Metadata Repository

Changing Metadata Repository Schema Passwords

The schema passwords are stored in the database. Note that passwords expire after a period of time. For example, for an 11g Oracle Database, by default, the passwords expire after 180 days.

For most components, you only need to change the password in the database. However, for Oracle Platform Security Services, you need to take additional steps.

Parent topic: Managing Metadata Repository Schemas

Changing the Schema Passwords for Most Components

To change the schema password of most components, you change the password 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;
COMMIT;

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

    SQL> ALTER USER OFM_MDS IDENTIFIED BY abc123;
COMMIT;

  3. If you change the MDS Repository schema password, you must change the password for the corresponding MDS Repository data source, using Fusion Middleware Control:

    1. From the WebLogic Domain menu, select JDBC 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.

Changing the Schema Password for Oracle Platform Security Services

To change the schema password for Oracle Platform Security Services:

  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;
COMMIT;

    Be sure to issue the commit command before proceeding to the next step.

  3. Run the WLST command modifyBootStrapCredential to update the JPS configuration file.

    1. Invoke WLST from the following directory:

      ORACLE_HOME/oracle_common/common/bin/wlst.sh

    2. Specify the full path to the JPS configuration file in the modifyBootStrapCredentials command. For example:

      modifyBootStrapCredential(jpsConfigFile='/scratch/oracle//config/domains/soa_domain/config/fmwconfig/jps-config.xml',username='schema_username',password='password')

      At this point, the Administration Server can be started, however, the log file will show the following exception:

      ####<Jun 01, 2017 2:15:09 PM CEST> <Error> <Deployer> <deployer> <AdminServer> <[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default
(self-tuning)'> <<WLS Kernel>> <>
<f9d07f66-36d0-462e-83fd-6ca40ac15a8a-00000004> <1402936508655> <BEA-149205>
<Failed to initialize the application "opss-data-source" due to error
weblogic.application.ModuleException:
weblogic.common.resourcepool.ResourceSystemException:
Could not connect to 'oracle.jdbc.OracleDriver'.

The returned message is: ORA-01017: invalid username/password; logon denied.

      To avoid this error, execute next step.

  4. Update the data source configuration, as described in Changing the Schema Passwords for Most Components, step 3.

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/technetwork/database/enterprise-edition/documentation/index.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 ultimately saves time and money and gives 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.

Parent topic: Managing Metadata Repository Schemas

Purging Data

When the amount of data in Oracle Fusion Middleware metadata repositories grows very large, maintaining the repositories can become difficult and can affect performance.

In some cases, Oracle Fusion Middleware automatically purges data from the repositories. In other cases, Oracle Fusion Middleware provides methods to manage growth, including scripts to purge data that can accumulate over time and that can affect performance.

Many of the Oracle Fusion Middleware components provide scripts written as PL/SQL procedures to purge the data. The scripts are located in: 

ORACLE_HOME/common/sql/component-name_purge_purgetype.sql

For example, a script that purges logs for Oracle Business Process Management is located in: 

ORACLE_HOME/common/sql/bpm_purge_logs.sql

Table 14-2 provides pointers to information about purging data for Oracle Fusion Middleware components.

Table 14-2 Purging Data Documentation

Component Description

MDS Repository

See Purging Metadata Version History for information on automatically and manually purging data.

Oracle Application Development Framework

See Cleaning Up Temporary Storage Tables in Developing Fusion Web Applications with Oracle Application Development Framework.

Oracle Application Development Framework Business Components

Use the following script to purge rows in the database used by Oracle ADF Business Components to store user session state and temporary persistent collections: 

ORACLE_HOME/oracle_common/common/sql/adfbc_purge_statesnapshots.sql

The PS_TXN table is automatically purged.

Oracle BI Enterprise Edition

No configuration required. Automatically purges data.

Oracle Business Intelligence Publisher

Delete job history, as described in Deleting a Job History in the User's Guide for Oracle Business Intelligence Publisher.

Oracle Web Services Manager

No configuration required. Automatically purges data.

Oracle WebCenter Content

Export the data with deletion, as described in Exporting Data in Archives. Then, remove the collection, as described in Removing a Collection. Both sections are in the Administering Oracle WebCenter Content.

Oracle WebCenter Portal Analytics

See Partitioning Oracle WebCenter Portal's Analytics Data.

Oracle WebCenter Portal's Activity Stream

See Purging Oracle WebCenter Portal's Activity Stream Data.

Oracle WebLogic Server: JAXWS Web Services

Clean up the Web service persistence store, as described in Cleaning Up Web Service Persistence in Developing JAX-WS Web Services for Oracle WebLogic Server.

Use the defaultMaximumObjectLifetime field of the WebServicePersistenceMBean to set the maximum lifetime of the objects. See Understanding WebLogic Server MBeans in Developing Custom Management Utilities Using JMX for Oracle WebLogic Server.

Oracle WebLogic Server: JMS

See Configuring Basic JMS System Resources and Managing JMS Messages in Administering JMS Resources for Oracle WebLogic Server.

Also see Tuning WebLogic JMS in Tuning Performance of Oracle WebLogic Server.

Oracle WebLogic Server: Oracle Infrastructure Web Services

Use the following script to purge data if WS-RM uses a database store:

ORACLE_HOME/oracle_common/common/sql/ows_purge_wsrm_msgs.sql

Oracle WebLogic Server: Session persistence for JDBC or file-based data sources

No configuration required. Automatically purges data.

Oracle WebLogic Server: Stateful EJBs

No configuration required. Automatically purges data.

In certain circumstances, you can consider using Oracle Scheduler to automate the running of the scripts. For example, you may want to set up a scheduled job to purge the last 14 days for completed instances.

In certain circumstances, you can consider using Oracle Scheduler to automate the running of the scripts. For example, you may want to set up a scheduled job to purge the last 14 days for completed instances for Oracle SOA Suite.

Oracle Scheduler, an enterprise job scheduler, is part of Oracle Database. Oracle Scheduler is implemented by the procedures and functions in the DBMS_SCHEDULER PL/SQL package. For information about Oracle Scheduler, see Oracle Scheduler Concepts and Creating, Running, and Managing Jobs in the Oracle Database Administrator's Guide.

Parent topic: Managing the Metadata Repository

Purging Oracle Infrastructure Web Services Data

Use the following script to purge data if WS-RM uses a database store:

ORACLE_HOME/oracle_common/common/sql/ows_purge_wsrm_msgs.sql

Parent topic: Purging Data

Purging Oracle WebCenter Portal Data

Parent topic: Purging Data

Purging Oracle WebCenter Portal's Activity Stream Data

Oracle WebCenter Portal's Activity Stream provides a set of WLST commands for purging database records in a nonpartitioned environment. Purging is necessary when a database contains records that are not needed as an analysis in reports or when the performance of Oracle WebCenter Portal decreases because of the large volume of data.

To purge Oracle WebCenter Portal's Activity Stream data, you use the following WLST commands:

  • archiveASByDate: Archives activity stream data that is older than a specified date.

  • archiveASByDeletedObjects: Archives activity stream data associated with deleted objects

  • archiveASByClosedSpaces: Archives activity stream data associated with Spaces that are currently closed.

  • archiveASByInactiveSpaces: Archives activity stream data associated with Spaces that have been inactive since a specified date.

  • restoreASByDate: Restores archived activity stream data from a specified date into production tables.

For more information about these commands, see Activity Stream in the WebCenter WLST Command Reference Reference.

Purging Oracle WebCenter Portal's Analytics Data

Oracle WebCenter Portal's Analytics provides a script for purging database records in a nonpartitioned environment. Purging is necessary when a database contains records that are not needed for analysis in reports or when the performance of Oracle WebCenter Portal decreases because of the large volume of data.

The script, analytics_purge_facts.sql, deletes all fact tables that meet the specified criteria.

When Oracle WebCenter Portal's Analytics runs in a partitioned environment, you should use the drop partitioning feature of the database before running these scripts.

Loading the Oracle WebCenter Portal Purge Package

Before you run the script for the first time, you must install the purge package into the database by running the analytics_purge_package script:

  1. Log in to the database as the schema user for the ACTIVITIES schema.
  2. Execute the analytics_purge_package script. For example, for an Oracle Database:
    @ORACLE_HOME/oracle_common/common/sql/oracle/analytics_purge_package.sql

    For a DB2 database, use the following command:

    db2 -td@ -f analytics_purge_package.sql
Running the Oracle WebCenter Portal Purge Script

The location of the analytics_purge_facts.sql script differs depending on the type of database used:

  • Oracle Database:

    ORACLE_HOME/oracle_common/common/sql/oracle/analytics_purge_facts.sql

  • SQL Server:

    ORACLE_HOME/oracle_common/common/sql/sqlserver/analytics_purge_facts.sql

  • DB2:

    ORACLE_HOME/oracle_common/common/sql/db2/analytics_purge_facts.sql

The analytics_purge_facts.sql script takes the following parameters:

  • Month From: The script purges data that was created after the beginning of the specified month. Enter the month in the format MM. For example, 08 to specify August.

  • Year From: With the Month From parameter, the script purges data that was created after the beginning of the specified month in the specified year. Enter the year in YYYY format. For example, 2017.

  • Month To: The script purges data that was created through the end of the specified month. Enter the month in the format MM. For example, if you specify 09 for September, the script purges all data that was created before the end of September.

  • Year To: With the Month To parameter, the script purges data that was created through the end of the specified month in the specified year. Enter the year in YYYY format. For example, 2017.

  • Record Batch Size: The maximum size of records to commit at one time.

  • Max Run Time: The maximum amount of time, in minutes, that the you want the process to run. When the process reaches this time, it stops, regardless of the progress of the purge.

Note:

You cannot delete the current month. If you specify the current month, the script returns an error.

When you are using an Oracle Database or a DB2 database, the script prompts you for input for each parameter.

When you are using a SQL Server database, you must edit the analytics_purge_facts.sql script to specify the criteria for purging data.

The following shows an example of the script for SQL Server that deletes all Analytics fact database records from February 1, 2017 through May 31, 2017:

CALL ANALYTICS_PURGE 
        (
        2, --from month
        2017, --from year
        5, --to month
        2017, --to_year
        1000, --commit batch size
        60 --max run time minutes
        );

To use the script:

  1. If you are using a SQL Server database, edit the script to specify the criteria.
  2. Execute the script. For example, to execute the script on an Oracle Database:
    sqlplus analytics_user/analytics_user_pwd @analytics_purge_facts.sql
Enter value for month_from: 2
old   4: ANALYTICS_PURGE.PURGE_ANALYTICS_INSTANCES ( &month_from,  
-- MM format
new   4: ANALYTICS_PURGE.PURGE_ANALYTICS_INSTANCES ( 2,     -- MM format
Enter value for year_from: 2017
old   5:                          &year_from,               -- YYYY format
new   5:                          2017,                     -- YYYY format
Enter value for month_to: 5
old   6:                          &month_to,                -- MM format
new   6:                          5,                       -- MM format
Enter value for year_to: 2017
old   7:                          &year_to,                 -- YYYY format
new   7:                          2017,                     -- YYYY format
Enter value for record_commit_batch_size: 1000
old   8:                          &record_commit_batch_size,
new   8:                          1000,
Enter value for max_minutes_run: 60
old  10:                          &max_minutes_run) ;
new  10:                            60) ;
Log (06-01-2017 08:27:49) Purge Process Started
 .
 .
 .
Log (06-01-2017 08:27:49)
Log (06-01-2017 08:27:49) Purge Process Finished

PL/SQL procedure successfully completed.
Partitioning Oracle WebCenter Portal's Analytics Data

When you use the Oracle Fusion Middleware Repository Creation Utility (RCU) to create schemas, you can specify that Activity Graph and Analytics tables are partitioned (see the Custom Variables screen in RCU). If you chose to partition the tables, Oracle WebCenter Portal uses the native partitioning of the database to automatically create partitions.

Oracle WebCenter Portal provides a partition manager process, which runs once every 24 hours as a separate thread. It creates partitions on each Analytics fact table (ASFACT_*) in the database. Initially, the process generates six partitions in advance, with each partition corresponding to a month in the future. Whenever a new month starts, the partition manager creates a new partition.

Partitioning the data makes it easier to purge data, because you can purge the data by dropping the older partitions that the partition manager creates. Thus, in a partitioned environment, the recommended method for purging data is simply to drop the month-based partitions that are no longer required.

Note:

The WC_Utilities Managed Server must be started for the partition manager process to run.

For example, to drop older partitions for a table, use the following SQL command:

alter table table_name drop partition partition_name;