Skip Headers
Oracle® Fusion Middleware Administrator's Guide
11g Release 1 (11.1.1.8.0)

Part Number E10105-15
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

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.

It contains the following topics:

Note:

For information about managing a metadata repository for IBM WebSphere, see "Configuring Metadata Services (MDS) on IBM WebSphere" in the Oracle Fusion Middleware Third-Party Application Server Guide.

14.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 Portal. 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.) 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, such as Oracle B2B. For information related specifically to the MDS Repository type, see Section 14.3.

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

14.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 Portal. 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 an MDS Repository, see Section 14.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

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

14.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 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 Chapter 10.

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.

14.3.1.1 Databases Supported by MDS

The MDS Repository supports Oracle databases, as well as non-Oracle databases, including SQL Server, DB2, and MySQL. For more information about the supported versions of these databases, see:

http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-requirements-100147.html

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

14.3.1.2 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 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 a 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:

  • To use the custom WLST MDS commands, you must invoke the WLST script from the Oracle Common home. See Section 3.5.1.1 for more information.

  • For more information about the custom WLST MDS commands, see "Metadata Services (MDS) Custom WLST Commands" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

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

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

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 the Oracle Fusion Middleware Application Security Guide.

14.3.2 Registering and Deregistering a Database-Based MDS Repository

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

14.3.2.1 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:

14.3.2.1.1 Registering a Database-Based MDS Repository Using Fusion Middleware Control

You create a database-based MDS Repository using RCU, as described in Section 14.2.

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

  6. Click Query.

    A table is displayed that 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

  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 and is targeted to the Administration Server. To target the repository to other servers, see Section 14.3.2.2.

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

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

14.3.2.2 Adding or Removing Servers Targeted to the 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 or remove servers as targets.

To target the MDS Repository to additional servers:

  1. From the navigation pane, expand the farm, then 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.

To remove a server as a target for the repository:

  1. From the navigation pane, expand the farm, then 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.

14.3.2.3 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:

14.3.2.3.1 Deregistering a Database-Based MDS Repository Using Fusion Middleware Control

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.

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

14.3.3 Registering and Deregistering a File-Based MDS Repository

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

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

      Note the following:

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

  6. 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 Section 14.3.5.

14.3.3.2 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 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 14.3.5.

14.3.4 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 navigation pane, expand the farm, then WebLogic Domain.

  2. Select the domain.

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

    The JDBC Data Sources page is displayed.

  4. Select the data source you want to change and click Edit.

    The Edit JDBC Data Source page is displayed.

  5. Select the Connection Properties tab.

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

    jdbc:oracle:thin:@hostname.domainname.com:1522/orcl
    
  7. For Password, enter the password for the database.

  8. To change the schema, modify the Properties section, changing the value for user.

  9. If the database is a DB2 database, add the property sendStreamAsBlob, with a value of true.

  10. Click Apply.

  11. Restart the servers that use this data source, as described in Section 4.2.3.

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

    The Operations page is displayed.

  5. In the Value column, enter values for the operation.

  6. Click Invoke.

14.3.6 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:

14.3.6.1 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 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 which applications use the repository, click the icon in the Applications column. The Applications using the partition dialog box is displayed, with tabs for Deployed Applications and Referenced by Applications:

    • 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:

14.3.6.2 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. 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, 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 Section 10.9.

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

      Section 14.3.7.1 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.

      Section 14.3.7.2 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.

    Section 14.3.4 describes how to change the system data source.

14.3.7.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 10.4.3, Section 10.5.3, or Section 10.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.

14.3.7.2 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 Section 10.4.3, Section 10.5.3, or Section 10.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 14.3.3.2 or Section 14.3.2.3.

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

14.3.8 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:

14.3.8.1 Transferring Metadata Using Fusion Middleware Control

To use Fusion Middleware Control to transfer metadata:

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

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

  3. 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 Section 14.3.1 for information about base documents and customizations.

  4. If the target application is on a different system, copy the exported metadata to that system.

  5. From the navigation pane for the target system, expand the farm, expand Application Deployments, then select the application.

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

    The MDS Configuration page is displayed

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

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

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

  8. Click Import.

  9. In the Confirmation dialog box, click Close.

14.3.8.2 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="%".

14.3.9 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 14.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 10.4.3, Section 10.5.3, or Section 10.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 14.3.3.2.

14.3.10 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:

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

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

14.3.11 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 Section 14.3.12.4. 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.

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:

14.3.11.1 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 the farm, 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.

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

14.3.11.3 Enabling Auto-Purge

You can enable automatic purging using the MDSAppConfig MBean:

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

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

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.

The following topics describe how to manage labels:

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

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

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

14.3.12.4 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:

14.3.12.4.1 Purging Metadata Labels Using Fusion Middleware Control

To purge metadata labels using Fusion Middleware Control:

  1. Expand the farm, then 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.

14.3.12.4.2 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: 

14.3.12.5 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 Section 14.3.12.2.

14.4 Managing Metadata Repository Schemas

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

14.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 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, as described in Section 4.2.3.

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

14.5 Purging Data

When the amount of data in Oracle Fusion Middleware databases grows very large, maintaining the databases can become difficult and can affect performance. In some cases, Oracle Fusion Middleware automatically purges data. 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

Oracle Application Development Framework

See "Cleaning Up Temporary Storage Tables" in the Oracle Fusion Middleware Fusion Developer's Guide for 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_COMMON_HOME/common/sql/adfbc_purge_statesnapshots.sql

The PS_TXN table is automatically purged.

Oracle SOA Suite

See "Managing Database Growth" in the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite.

Oracle WebLogic Server: Oracle Infrastructure Web Services

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

ORACLE_COMMON_HOME/common/sql/ows_purge_wsrm_msgs.sql

Oracle WebLogic Server: JAXWS Web Services

Clean up the Web service persistence store, as described in "Cleaning Up Web Service Persistence" in Oracle Fusion Middleware Programming Advanced Features of 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 Oracle Fusion Middleware Developing Custom Management Utilities With JMX for Oracle WebLogic Server.

Oracle WebLogic Server: Stateful EJBs

No configuration required. Automatically purges data.

Oracle WebLogic Server: JMS

See "Configuring Basic JMS System Resources" and "Managing JMS Messages" in Oracle Fusion Middleware Configuring and Managing JMS for Oracle WebLogic Server.

Also see "Tuning WebLogic JMS" in Oracle Fusion Middleware Performance and Tuning for Oracle WebLogic Server.

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

No configuration required. Automatically purges data.

MDS Repository

See Section 14.3.11 for information on automatically and manually purging data.

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 Oracle WebCenter Content System Administrator's Guide for Content Server.

Oracle WebCenter Portal and Lists

Purge MDS metadata, as described in Section 14.3.11.

Oracle WebCenter Portal's Activity Stream

See Section 14.5.2.1.

Oracle WebCenter Portal Analytics

See Section 14.5.2.2.

Oracle Real-Time Decisions

No configuration required. Automatically purges data.

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 Oracle Fusion Middleware Report Designer's Guide for Oracle Business Intelligence Publisher.

Oracle Internet Directory

No configuration required. Automatically purges data.

Oracle Identity Manager

No configuration required. Automatically purges data.

Oracle Identity Federation

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

14.5.1 Purging Oracle Infrastructure Web Services Data

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

ORACLE_COMMON_HOME/common/sql/ows_purge_wsrm_msgs.sql

14.5.2 Purging Oracle WebCenter Portal Data

The following topics describe purging Oracle WebCenter Portal data:

14.5.2.1 Purging Oracle WebCenter Portal's Activity Stream Data

Oracle WebCenter Portal's Activity Streaming 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.

Note that you must invoke the WLST script from the Oracle home containing Oracle WebCenter Portal Activity Streaming. Do not use the WLST script in the WebLogic Server home.

For more information about these commands, see "Activity Stream" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

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

14.5.2.2.1 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
    
14.5.2.2.2 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, 2010.

  • 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, 2010.

  • 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 August 1, 2010 through November 30, 2010:

CALL ANALYTICS_PURGE 
        (
        8, --from month
        2010, --from year
        11, --to month
        2010, --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: 8
    old   4: ANALYTICS_PURGE.PURGE_ANALYTICS_INSTANCES ( &month_from,  
    -- MM format
    new   4: ANALYTICS_PURGE.PURGE_ANALYTICS_INSTANCES ( 8,     -- MM format
    Enter value for year_from: 2010
    old   5:                          &year_from,               -- YYYY format
    new   5:                          2010,                     -- YYYY format
    Enter value for month_to: 11
    old   6:                          &month_to,                -- MM format
    new   6:                          11,                       -- MM format
    Enter value for year_to: 2010
    old   7:                          &year_to,                 -- YYYY format
    new   7:                          2010,                     -- 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 (09-12-2010 08:27:49) Purge Process Started
     .
     .
     .
    Log (09-12-2010 08:27:49)
    Log (09-12-2010 08:27:49) Purge Process Finished
    
    PL/SQL procedure successfully completed.
    

14.5.2.3 Partitioning Oracle WebCenter Portal's Analytics Data

When you use the Oracle Fusion Middleware Metadata 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;