| Oracle® Fusion Middleware Administrator's Guide 11g Release 1 (11.1.1) Part Number E10105-11 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Middleware Administrator's Guide 11g Release 1 (11.1.1) Part Number E10105-11 |
|
|
PDF · Mobi · ePub |
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.A metadata repository contains metadata for Oracle Fusion Middleware components, such as Oracle BPEL Process Manager, Oracle B2B, and Oracle WebCenter. It can also contain metadata about the configuration of Oracle Fusion Middleware and metadata for your applications.
Oracle Fusion Middleware supports multiple repository types. A repository type represents a specific schema or set of schemas that belong to a specific Oracle Fusion Middleware component (for example, Oracle BPEL Process Manager or Oracle Internet Directory.)
A particular type of repository, the Oracle Metadata 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.
You use the Oracle Fusion Middleware Metadata Repository Creation Utility (RCU) to create the metadata repository in an existing database.
You can use RCU to create multiple repositories in a single database. You can use it to create the MDS Repository or a repository for metadata for particular components, such as Oracle WebCenter. RCU creates the necessary schemas for the components. See Appendix D for a list of the schemas and their tablespaces and datafiles.
With RCU, you can also drop component schemas.
For information about the supported versions of database platforms and versions, and other prerequisites for the database, see:
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
Note:
Oracle recommends that all metadata repositories reside on a database at the same site as the components to minimize network latency issues.For information about managing 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 repositoryOracle 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 custom Oracle WebCenter application.
You have a SOA composite application (SCA).
The following topics provide information about the MDS Repository:
Registering and Deregistering a Database-Based MDS Repository
Configuring an Application to Use a Different MDS Repository or Partition
Moving from a File-Based Repository to a Database-Based Repository
See Also:
Oracle Fusion Middleware High Availability Guide for information about using an MDS Repository with Oracle Real Application Clusters (Oracle RAC)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.
The MDS Repository supports Oracle databases, as well as non-Oracle databases, such as SQL Server and DB2. For more information about the supported versions of these databases, see:
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
Note that when you use an Oracle Database, the MDS database user created by Repository Creation Utility (RCU) requires EXECUTE privilege on DBMS_OUTPUT and DBMS_LOB. When you create a metadata repository using RCU, if PUBLIC does not have EXECUTE privilege on DBMS_OUTPUT and DBMS_LOB, the RCU user must have the privilege to grant EXECUTE privilege on DBMS_OUTPUT and DBMS_LOB to the MDS user.
To ensure that you have the correct privileges, login to RCU as a SYSDBA or as a DBA user who has EXECUTE privilege with GRANT OPTION on DBMS_OUTPUT and DBMS_LOB.
Note the following about using SQL Server as the database for MDS:
To create a metadata repository in SQL Server, set READ_COMMITTED_SNAPSHOT to ON for the hosting database. This enables the needed row versioning support. This feature can be enabled using the SQL command ALTER DATABASE, as in the following example:
ALTER DATABASE mds SET READ_COMMITTED_SNAPSHOT ON
You should use case-sensitive collation to support the case-sensitive semantics in the metadata repository. For example, if Latin1_General is used, select the SQL_Latin1_General_CP1_CS_AS collation using the following SQL command:
ALTER DATABASE mds COLLATE SQL_Latin1_General_CP1_CS_AS
In the example, the substring CS denotes case sensitivity.
When installed on SQL Server, Oracle Content Server 10g requires a database instance with case-insensitive collation. As a result, it cannot exist in the same SQL Server database instance as MDS. If you want to install both MDS and Oracle Content Server 10g, you must create a separate database instance with case-insensitive collation for installing the Oracle Content Server 10g schema.
There are some minor differences between an Oracle schema and a SQL Server schema. The length of the certain text fields are shorter for a SQL Server schema. For example, the full path name of the metadata in SQL Server is limited to 400 characters.
Note the following about using DB2 as the database for MDS:
Set the lock timeout parameter of the database to a low value. Unlike Oracle databases, DB2 does not support row versioning during update. If one user is updating a row, under some conditions, another user may be blocked when updating a different row and must wait until the transaction is committed or rolled back by the first user. To facilitate better concurrency, do not specify -1, which sets the lock timeout to infinity.
To query the lock timeout value for your DB2 database, use the following command:
db2 'get database config for database_alias' | grep -i timeout
If the value is too high, change it. For example, to change the lock timeout value to 180 seconds, use the following command:
db2 'update database config for database_alias using locktimout 180'
Set the DB2 registry variables DB2_EVALUNCOMMITTED, DB2_SKIPINSERTED, and DB2_SJIPDELETED to OFF to avoid deadlock and locking issues. By default, they are set to OFF. To view the current registry variables setting, use the db2set -all command.
If they are not set to OFF, use the following commands:
db2set DB2_EVALUNCOMMITTED=OFF db2set DB2_SKIPINSERTED=OFF db2set DB2_SKIPDELETED=OFF
Restart the database server using the using db2stop and db2start commands.
DB2 may escalate a row lock to a table lock due to memory stress or lock usage. As the result, a user's transaction may be rolled back as a victim of deadlock or lock timeout. To reduce lock escalation, you can increase the size of the MAXLOCKS and LOCKLIST configuration parameters. Use the following commands:
db2 'update database config for database_alias using locklist value' db2 'update database config for database_alias using maxlocks value'
The isolation level must be set to Currently Committed. To verify the setting, use the following command:
db2 'get database config for database_alias' | grep -i commit
To set the isolation level to Currently Committed, use the following command:
db2 'update database config for database_alias using CUR_COMMIT ON'
If the database transaction log is often full, increase the database configuration parameter to allow for a larger log file. A larger log file requires more space, but it reduces the need for applications to retry the operation. You should set the log file size to at least 10000 and the number of primary log files to at least 50. Use the following commands:
db2 'update database config for database_alias using LOGFILESIZ 10000' db2 'update database config for database_alias using LOGPRIMARY 50'
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.
The following topics describe how to register and deregister 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:
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:
From the navigation pane, expand the farm, then WebLogic Domain.
Select the domain.
From the WebLogic Domain menu, choose Metadata Repositories.
The Metadata Repositories page is displayed, as shown in the following figure:
In the Database-Based Repositories section, click Register.
The Register Database-Based Metadata Repository page is displayed.
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.
Click Query.
A table is displayed that the metadata repositories in the database, as shown in the following figure:
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.
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.
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')
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:
From the navigation pane, expand the farm, then Metadata Repositories.
Select the repository.
The repository home page is displayed, as shown in the following figure:
In the Targeted Servers section, click Add.
The Target the Repository dialog box is displayed.
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.
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:
From the navigation pane, expand the farm, then Metadata Repositories.
Select the repository.
The repository home page is displayed.
In the Targeted Servers section, select the target server and click Remove.
The Untarget the Repository dialog box is displayed.
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.
When the operation completes, click Close.
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:
To deregister an MDS Repository using Fusion Middleware Control:
From the navigation pane, expand the farm, then WebLogic Domain.
Select the domain.
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.
Select the repository from the table.
Click Deregister.
Click Yes in the Confirmation dialog box.
To deregister a database-based MDS Repository using the command line, you use the WLST deregisterMetadataDBRepository command. For example, to deregister the MDS Repository mds-repos1, use the following command:
deregisterMetadataDBRepository(name='mds-repos1')
The following topics describe how to register and deregister a file-based metadata repository:
You can create a file-based MDS Repository and register it with an Oracle WebLogic Server domain using Fusion Middleware Control.
To create and register a file-based repository using Fusion Middleware Control:
From the navigation pane, expand the farm, then WebLogic Domain.
Select the domain.
From the WebLogic Domain menu, choose Metadata Repositories.
The Metadata Repositories page is displayed.
In the File-Based Repository section, click Register.
The Register Metadata Repository page is displayed.
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.
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.
You can deregister a file-based MDS Repository using Fusion Middleware Control.
To deregister a file-based repository using Fusion Middleware Control:
From the navigation pane, expand the farm, then WebLogic Domain.
Select the domain.
From the WebLogic Domain menu, choose Metadata Repositories.
The Metadata Repositories page is displayed.
In the File-Based Repository section, select the repository and click Deregister.
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.
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:
From the navigation pane, expand the farm, then WebLogic Domain.
Select the domain.
From the WebLogic Domain menu, choose JDBC Data Sources.
The JDBC Data Sources page is displayed.
Select the data source you want to change and click Edit.
The Edit JDBC Data Source page is displayed.
Select the Connection Properties tab.
To change the database, modify the Database URL field. For example:
jdbc:oracle:thin:@hostname.domainname.com:1522/orcl
For Password, enter the password for the database.
To change the schema, modify the Properties section, changing the value for user.
If the database is a DB2 database, add the property sendStreamAsBlob, with a value of true.
Click Apply.
Restart the servers that use this data source.
Although most procedures in this chapter discuss using Fusion Middleware Control or WLST to manage the MDS Repository, you can also use system MBeans:
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.
In the page's navigation pane, expand Application Defined MBeans, then expand oracle.mds.lcm. Expand the domain, then MDSDomainRuntime, and then select MDSDomainRuntime.
In the Application Defined MBeans pane, select the Operations tab.
Click one of the operations, such as registerMetadataFileRepository.
The Operations page is displayed.
In the Value column, enter values for the operation.
Click Invoke.
You can view information about an MDS Repository using Fusion Middleware Control or system MBeans, as described in the following topics:
Viewing Information About an MDS Repository Using Fusion Middleware Control
Viewing Information About an MDS Repository Using System MBeans
To view information about an MDS Repository using Fusion Middleware Control:
From the navigation pane, expand the farm and then expand Metadata Repositories.
Select the repository.
The following figure shows the home page for an MDS Repository:
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:
Delete partitions, as described in Section 14.3.10.1.
Delete labels, as described in Section 14.3.12.5.
Add or remove targeted servers, as described in Section 14.3.2.2.
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:
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.
In the page's navigation pane, expand Application Defined MBeans, then expand oracle.mds.lcm. Expand the domain, then MDSDomainRuntime, and then select MDSDomainRuntime.
In the Application Defined MBeans pane, select the Operations tab.
Click one of the operations, such as listPartitions, listRepositories, and listRepositoryDetails.
The Operations page is displayed.
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.
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.
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:
Clone the partition, using the cloneMetadataPartition operation on the system MBean. The following example clones partition1 from the old repository to the new repository:
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.
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.
In the Application Defined MBeans pane, select the Operations tab.
The following figure shows the System MBeans Browser with the Application Defined MBeans pane:
Select cloneMetadataPartiton.
The Operation: cloneMetadataPartiton page is displayed.
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.
Click Invoke.
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.
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:
To change the repository, click the icon next to the Repository Name. In the Metadata Repositories dialog box, select the repository and click OK.
To change the partition, enter the partition name in Partition Name.
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:
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='/**')
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:
To change the repository, click the icon next to the Repository Name. In the Metadata Repositories dialog box, select the repository and click OK.
To change the partition, enter the partition name in Partition Name.
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='/**')
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')
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:
To use Fusion Middleware Control to transfer metadata:
From the navigation pane, expand the farm, expand Application Deployments, then select the application.
From the Application Deployment menu, choose MDS Configuration.
The MDS Configuration page is displayed, as shown in the following figure:
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.
If the production application is on a different system, copy the exported metadata to that system.
From the navigation pane for the production system, expand the farm, expand Application Deployments, then select the application.
From the Application Deployment menu, choose MDS Configuration.
The MDS Configuration page is displayed
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.
Click Import.
In the Confirmation dialog box, click Close.
To use WLST to transfer metadata:
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="%".
If the production application is on a different system, copy the exported metadata to that system.
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="%".
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:
Use RCU to create schemas in the new repository, as described in Section 14.2.
Create a new partition using the WLST command createMetadataPartition with same name as source partition:
createMetadataPartition(repository='mds-repos1', partition='partition1')
Export the metadata from the source partition to a directory on the file system:
exportMetadata(application='sampleApp', server='server1',
toLocation='/tmp/myrepos/partition1', docs='/**')
Import the metadata from the file system to the new partition:
importMetadata(application='sampleApp', server='server1',
fromLocation='/tmp/myrepos/partition1', docs='/**')
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:
To change the repository, click the icon next to the Repository Name. In the Metadata Repositories dialog box, select the repository and click OK.
To change the partition, enter the partition name in Partition Name.
Deregister the file-based repository, as described in Section 14.3.3.2.
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:
To delete a metadata partition from a repository partition using Fusion Middleware Control:
From the navigation pane, expand the farm and then expand Metadata Repositories.
Select the repository.
The repository home page is displayed.
In the Repository Partitions section, select the partition and click Delete.
In the confirmation dialog box, click OK.
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')
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:
To use Fusion Middleware Control to purge the metadata version history:
From the navigation pane, expand the farm, expand Application Deployments, then select the application.
From the Application Deployment menu, choose MDS Configuration.
The MDS Configuration page is displayed.
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.
Click Purge.
In the Confirmation dialog box, click Close.
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)
You can enable automatic purging using the MDSAppConfig MBean:
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.
Expand Application Defined MBeans, then oracle.adf.share.config, then Server: name, then Application: name, then ADFConfig, then ADFConfig, and ADFConfig.
Select MDSAppConfig.
The Application Defined MBeans page is displayed.
For AutoPurgeTimeToLive, enter a value, in seconds.
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 recreated.
The following topics describe how to manage 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.
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.
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.
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:
To metadata labels using Fusion Middleware Control:
Expand the farm, then expand Metadata Repositories.
Select the repository.
The repository home page is displayed.
Select a partition and click Manage Labels.
The Manage Labels page is displayed, as shown in the following figure:
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.
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.
To filter the labels displayed by name, enter the filter criteria in the box above Name. 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.
To filter the labels by those older than a particular time, select the time in Older Than. For example, if you specify 2 months, the labels older than 2 months are returned.
Select the label and click Delete Selected.
In the confirmation box, click OK.
If you want to purge all unused labels, for a particular deployed application:
Select Deployment.
Filter by name, using the string postDeployLabel_application_name%.
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.)
Click Delete Selected.
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:
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.
The following topics describe how to manage the metadata repository schemas:
The schema passwords are stored in the database.
For example, to change the password of the schema OFM_MDS:
Connect to the database using SQL*Plus. Connect as a user with SYSDBA privileges.
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;
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:
From Domain Structure, expand Services, then Data Sources.
Click the data source that is related to the MDS Repository.
Click the Configuration tab, then the Connection Pool tab.
For Password, enter the new password.
Click Save.
Restart the Managed Servers that consume the data source.
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.
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 |
|---|---|
|
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. |
|
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. |
|
See Section 14.3.11 for information on automatically and manually purging data. |
|
|
No configuration required. Automatically purges data. |
|
|
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 Fusion Middleware System Administrator's Guide for Content Server. |
|
|
Purge MDS metadata, as described in Section 14.3.11. |
|
|
Oracle WebCenter Activity Stream |
See Section 14.5.2.1. |
|
Oracle WebCenter 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. |
|
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.
Use the following script to purge data if WS-RM uses a database store:
ORACLE_COMMON_HOME/common/sql/ows_purge_wsrm_msgs.sql
The following topics describe purging Oracle WebCenter data:
Oracle WebCenter 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 decreases because of the large volume of data.
To purge Oracle WebCenter 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 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.
Oracle WebCenter 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 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 Analytics runs in a partitioned environment, you should use the drop partitioning feature of the database before running these scripts.
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:
Log in to the database as the schema user for the ACTIVITIES schema.
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
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:
If you are using a SQL Server database, edit the script to specify the criteria.
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.
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 uses the native partitioning of the database to automatically create partitions.
Oracle WebCenter 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;
|
 Copyright © 2009, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|