6
Managing an OracleAS Metadata Repository

This chapter provides information on managing an OracleAS Metadata Repository.

It contains the following topics:

• Frequently Asked Questions About the Metadata Repository

• Changing Schema Passwords

• Changing the Character Set of the Metadata Repository

• Renaming and Relocating Datafiles

• Specifying Segment Space Management When Creating Tablespaces

6.1 Frequently Asked Questions About the Metadata Repository

The OracleAS Metadata Repository is an Oracle9i database and can be managed using standard database procedures and tools. However, there are some considerations for managing the Metadata Repository within the Oracle Application Server environment. This section answers frequently asked questions about managing the Metadata Repository.

• What is a Metadata Repository?

  A Metadata Repository is an Oracle9i Release 1 Enterprise Edition database. It is pre-seeded with schemas to support Oracle Application Server components and services.

  See Also: Appendix D, "Metadata Repository Schemas" for information on the schemas that are pre-seeded in the Metadata Repository

• When is a Metadata Repository required?

  A Metadata Repository is required by the following installations:

  • An Identity Management installation requires a Metadata Repository for Identity Management schemas

  • A J2EE and Web Cache installation that is part of an OracleAS Cluster Managed using a Database Repository requires a Metadata Repository for the Management (DCM) schema

  • A Portal and Wireless installation requires a Metadata Repository for Product Metadata schemas

  • A Business Intelligence and Forms installation requires a Metadata Repository for Product Metadata schemas

• How can I obtain a Metadata Repository?

  You can obtain a Metadata Repository in either of the following ways:

  • You can install a Metadata Repository as part of an Infrastructure installation with Oracle Universal Installer. This installs the Metadata Repository from scratch.

  • You can install a Metadata Repository into an existing Oracle9i database using the Oracle Application Server Repository Creation Assistant (OracleAS RepCA).

    See Also: Oracle Application Server 10g Installation Guide

• Must the Metadata Repository be registered with Oracle Internet Directory?

  It depends on what type of installation is using the Metadata Repository.

  A Metadata Repository must be registered with Oracle Internet Directory for the following installations:

  • Identity Management--the Metadata Repository must be registered with the Oracle Internet Directory within the Identity Management installation

  • Portal and Wireless--the Metadata Repository must be registered with the Oracle Internet Directory within the Identity Management installation used by the Portal and Wireless installation

  • Business Intelligence and Forms--the Metadata Repository must be registered with the Oracle Internet Directory within the Identity Management installation used by the Business Intelligence and Forms installation

  You have the option of registering the Metadata Repository with Oracle Internet Directory for a J2EE and Web Cache using OracleAS Single Sign-On--you may register the Metadata Repository with the Oracle Internet Directory in the Identity Management used by J2EE and Web Cache, or, you may use a free-standing Metadata Repository. Either one will allow you to use OracleAS Clusters Managed using a Database Repository.

• Are there any tools for managing the Metadata Repository?

  You can use Oracle Enterprise Manager, refer to Section 2.5, "Managing the OracleAS Metadata Repository Database".

• Can I use the Metadata Repository to deploy applications?

  No. The Metadata Repository is not intended for deploying applications.

• Can a Metadata Repository coexist on a host with other databases?

  Yes. As long as each database has a unique SID and global database identifier. The databases may be able to share a Net listener as follows:

  • Multiple Oracle9i databases can share the same Net listener port. So, if the other databases on your host are Oracle9i databases, the Metadata Repository can use the same Net listener port (for example. 1521) as the other databases.

  • If the other databases on your system are Oracle8i databases running Oracle Net8 listener, then the Metadata Repository must use a different port for its Net listener.

• Can I change the character set of the Metadata Repository?

  Yes. Follow the instructions for changing the character set in the database documentation, then refer to Section 6.3, "Changing the Character Set of the Metadata Repository" for updates you need to make to Oracle Application Server.

• Can I tune the Metadata Repository?

  Yes, you can apply database tuning strategies to the Metadata Repository.

  One important point to be aware of is that the processes and sessions parameters in the Oracle init$SID.ora configuration file should be tuned to allow the Metadata Repository to handle the maximum number of database sessions used by Oracle Application Server 10g middle-tier installations, or other middle-tier installations accessing the Metadata Repository.

  The primary consumers of database sessions are OracleAS Portal and OracleAS Wireless. An init$SID.ora setting of processes=150 should support four middle-tier installations that include these components. Note that an OracleAS Portal best practice recommendation is to relocate the Portal instance out of the Infrastructure, which would reduce the database connections requirement.

  See Also: Oracle Application Server 10g Performance Guide for a detailed description of the database connection usage of mod_plsql in an OracleAS Portal installation

• Can I change Metadata Repository schema passwords?

  Yes. However, you must make sure to use the correct procedure. Some schemas store their passwords in Oracle Internet Directory and you must change their passwords using Application Server Control so the password is updated in Oracle Internet Directory and the database.

  See Also: Section 6.2, "Changing Schema Passwords"

• Can I delete schemas from the Metadata Repository that I am not using?

  No. You should never delete any of the schemas that come with the Metadata Repository.

• Can I rename or relocated Metadata Repository datafiles after installation?

  Yes.

  See Also: Section 6.4, "Renaming and Relocating Datafiles"

• Can I configure my Metadata Repository for high availability?

  Yes. Oracle Application Server offers several high availability options for the Metadata Repository, including:

  • Oracle Application Server Cold Failover Cluster

  • Oracle Application Server Active Failover Cluster (Limited Release)

  • Oracle Application Server Disaster Recovery

    See Also: Oracle Application Server 10g High Availability Guide

• Can I enable archive logging on the Metadata Repository?

  Yes. This is part of the Oracle-recommended backup and recovery strategy.

  See Also: Section 13.2.1, "Enabling ARCHIVELOG Mode"

• How can I backup and recover the Metadata Repository?

  Oracle provides a backup and recovery strategy for your entire Oracle Application Server environment, including the Metadata Repository.

  See Also: Part IV, "Backup and Recovery"

6.2 Changing Schema Passwords

The method for changing schemas passwords in the Metadata Repository varies by schema. Some schemas store their passwords in Oracle Internet Directory; you must change their passwords using Application Server Control so that both Oracle Internet Directory and the database are updated. Other schemas do not store their passwords in Oracle Internet Directory; you can change their passwords in the database using SQL*Plus. A few schemas require special steps for changing their passwords.

Table 6-1 lists the appropriate method for change each Metadata Repository schema.

Table 6-1   Methods for Changing Metadata Repository Schema Passwords

Schema	Method for Changing Password
DCM	If the Metadata Repository is registered with Oracle Internet Directory, you must change the password in two places: Use SQL*Plus to change the password directly in the database. Refer to Section 6.2.2, "Changing Schema Passwords Using SQL*Plus". Manually change the password in Oracle Internet Directory. Refer to Section 6.2.3, "Viewing and Changing Schema Passwords in Oracle Internet Directory". If the Metadata Repository is not registered with Oracle Internet Directory, you only need to change the password directly in the database using SQL*Plus.
DISCOVERER5	Use Application Server Control. Navigate to the Home Page for the middle-tier instance that uses this schema and follow the instructions in Section 6.2.1, "Changing Schema Passwords Using Application Server Control".
DSGATEWAY	Use Application Server Control. Navigate to the Home Page for the middle-tier instance that uses this schema and follow the instructions in Section 6.2.1, "Changing Schema Passwords Using Application Server Control".
IP	You must change the password in two places: Use SQL*Plus to change the password directly in the database. Refer to Section 6.2.2, "Changing Schema Passwords Using SQL*Plus". Manually change the password in Oracle Internet Directory. Refer to Section 6.2.3, "Viewing and Changing Schema Passwords in Oracle Internet Directory".
OCA	This schema requires special steps. Refer to Oracle Application Server Certificate Authority Administrator's Guide for advanced topics in administration.
ODS	This schema requires special steps. Refer to Oracle Internet Directory Administrator's Guide for information on resetting the default password for the database.
ORAOCA_PUBLIC	This schema requires special steps. Refer to Oracle Application Server Certificate Authority Administrator's Guide for advanced topics in administration.
ORASSO	Use Application Server Control. Navigate to the Home Page for the Infrastructure (Identity Management) installation and follow the instructions in Section 6.2.1, "Changing Schema Passwords Using Application Server Control". After you change the password, restart Oracle HTTP Server: opmnctl stopproc ias-component=HTTP_Server opmnctl startproc ias-component=HTTP_Server
ORASSO_DS	Use Application Server Control. Navigate to the Home Page for the Infrastructure (Identity Management) installation and follow the instructions in Section 6.2.1, "Changing Schema Passwords Using Application Server Control".
ORASSO_PA	Use Application Server Control. Navigate to the Home Page for the Infrastructure (Identity Management) installation and follow the instructions in Section 6.2.1, "Changing Schema Passwords Using Application Server Control".
ORASSO_PS	Use Application Server Control. Navigate to the Home Page for the Infrastructure (Identity Management) installation and follow the instructions in Section 6.2.1, "Changing Schema Passwords Using Application Server Control". Changing the ORASSO_PS password requires that the database link from all Portal schemas to the ORASSO_PS schema be recreated. To do this, run the following command for each affected Portal instance: ORACLE_HOME/portal/conf/ptlconfig -dad dad_name -site Refer to Oracle Application Server Portal Configuration Guide.
ORASSO_PUBLIC	Use Application Server Control. Navigate to the Home Page for the Infrastructure (Identity Management) installation and follow the instructions in Section 6.2.1, "Changing Schema Passwords Using Application Server Control".
OWF_MGR	You must change the password in two places: Use SQL*Plus to change the password directly in the database. Refer to Section 6.2.2, "Changing Schema Passwords Using SQL*Plus". Manually change the password in Oracle Internet Directory. Refer to Section 6.2.3, "Viewing and Changing Schema Passwords in Oracle Internet Directory".
PORTAL	Use Application Server Control. Navigate to the Home Page for the middle-tier instance that uses this schema and follow the instructions in Section 6.2.1, "Changing Schema Passwords Using Application Server Control". After you change the password, restart Oracle HTTP Server: opmnctl stopproc ias-component=HTTP_Server opmnctl startproc ias-component=HTTP_Server
PORTAL_APP	Use Application Server Control. Navigate to the Home Page for the middle-tier instance that uses this schema and follow the instructions in Section 6.2.1, "Changing Schema Passwords Using Application Server Control".
PORTAL_DEMO	Use Application Server Control. Navigate to the Home Page for the middle-tier instance that uses this schema and follow the instructions in Section 6.2.1, "Changing Schema Passwords Using Application Server Control".
PORTAL_PUBLIC	Use Application Server Control. Navigate to the Home Page for the middle-tier instance that uses this schema and follow the instructions in Section 6.2.1, "Changing Schema Passwords Using Application Server Control".
SCOTT	Use SQL*Plus to change the password directly in the database. Refer to Section 6.2.2, "Changing Schema Passwords Using SQL*Plus".
SYS	Use SQL*Plus to change the password directly in the database. Refer to Section 6.2.2, "Changing Schema Passwords Using SQL*Plus".
SYSTEM	Use SQL*Plus to change the password directly in the database. Refer to Section 6.2.2, "Changing Schema Passwords Using SQL*Plus".
UDDISYS	Use Application Server Control. Navigate to the Home Page for the middle-tier instance that uses this schema and follow the instructions in Section 6.2.1, "Changing Schema Passwords Using Application Server Control".
WCRSYS	Use Application Server Control. Navigate to the Home Page for the middle-tier instance that uses this schema and follow the instructions in Section 6.2.1, "Changing Schema Passwords Using Application Server Control".
WIRELESS	Use Application Server Control. Navigate to the Home Page for the middle-tier instance that uses this schema and follow the instructions in Section 6.2.1, "Changing Schema Passwords Using Application Server Control".
WK_TEST	Use SQL*Plus to change the password directly in the database. Refer to Section 6.2.2, "Changing Schema Passwords Using SQL*Plus".
WKPROXY	Use Application Server Control. Navigate to the Home Page for the middle-tier instance that uses this schema and follow the instructions in Section 6.2.1, "Changing Schema Passwords Using Application Server Control".
WKSYS	Use Application Server Control. Navigate to the Home Page for the middle-tier instance that uses this schema and follow the instructions in Section 6.2.1, "Changing Schema Passwords Using Application Server Control".

6.2.1 Changing Schema Passwords Using Application Server Control

Some schemas store their passwords in Oracle Internet Directory. You must change their passwords using Application Server Control so the password is updated in both the database and Oracle Internet Directory.

To change a schema password using Application Server Control:

1. Depending on the schema, navigate to the home page for the middle-tier instance or the Infrastructure. Refer to Table 6-1 to determine which home page to use.

2. On the home page, click Infrastructure.

3. On the Infrastructure page, click Change Schema Password.

4. On the Change Schema Password page, select the radio button for the schema. Enter the new password in the Password and Confirm Password fields. Click OK.

6.2.2 Changing Schema Passwords Using SQL*Plus

You can change some schema passwords directly in the database using SQL*Plus. To do so, connect to the database as a user with SYSDBA privileges and issue the following command:

SQL> ALTER USER schema identified by new_password;

For example, to change the SCOTT schema password to "abc123":

SQL> ALTER USER SCOTT IDENTIFIED BY abc123;

6.2.3 Viewing and Changing Schema Passwords in Oracle Internet Directory

A few schemas (DCM, IP, OWF_MGR) require you to manually update the password in the Metadata Repository and in Oracle Internet Directory. You can use this procedure to change these passwords and to view any schema password in Oracle Internet Directory.

1. Start Oracle Directory Manager with the following command:

   ORACLE_HOME/bin/oidadmin
   
   

2. Log in to Oracle Directory Manager as the orcladmin user.

3. In the System Objects frame, expand Entry Management, expand cn=OracleContext, expand cn=Products, expand cn=IAS, expand cn=IAS Infrastructure Databases, and expand the orclReferenceName for the Metadata Repository.

4. Select the OrclResourceName entry for the schema whose password you want to change.

5. In the Properties tab, you can view and update the password in the orclpasswordattribute field.

6. Click Apply.

6.3 Changing the Character Set of the Metadata Repository

To configure the middle-tier and infrastructure to work with the metadata repository after its character set has been changed:

1. Modify the character set of all Database Access Descriptors (DADs) accessing the metadata repository to the new database character set.
   1. Using Application Server Control, navigate to the middle-tier instance home page.

   2. In the System Components section, click HTTP_Server.

   3. On the HTTP_Server home page, click Administration.

   4. On the HTTP_Server Administration page, select "PL/SQL Properties". This opens the mod_plsql Services page.

   5. Scroll to the DADs section and click the name of the DAD that you want to configure. This opens the Edit DAD page.

   6. In the NLS Language field, type in a NLS_LANG value whose character set is the same as the new character set for the metadata repository.

   7. Click OK.

   8. Repeat steps e to g for all DADs accessing the Metadata Repository.

2. Reconfigure the Ultra Search index, using the two SQL scripts provided for this purpose: wk0prefcheck.sql and wk0idxcheck.sql under $ORACLE_HOME/ultrasearch/admin.
   • wk0prefcheck.sql is invoked under wksys to reconfigure default cache character set and index preference.

   • wk0idxcheck.sql is needed for reconfiguring instance(s) created before database character set change, e.g., the default instance. This script must be invoked by the instance owner and wk0prefcheck.sql must be run first as it depends on reconfigured default settings generated by wk0prefcheck.sql.

   • Running wk0idxcheck.sql will also drop and recreate the Oracle Text index used by Ultra Search. So if there are already data source indexed then user must force recrawl all of the data sources.

   • Note that wk0idxcheck.sql must be run once for each instance. So if there are two instances "inst1" and "inst2" owned by "owner1" and "owner2" respectively then wk0idxcheck.sql should be run twice; once by "owner1" and once by "owner2".

6.4 Renaming and Relocating Datafiles

When you install a Metadata Repository, you can choose the location for its datafiles. The default location is ORACLE_HOME/oradata/SID. After installation, you may want to relocate datafiles to a different directory. For example, you may want to move them to a directory on a filesystem with more space. Or, you may want to move them to a directory on a different disk for performance reasons. Another thing you may want to do is keep the datafiles in the same directory, but rename them.

This section provides a procedure for renaming or relocating datafiles. You can use this procedure on one or more datafiles, and the datafiles may be in multiple tablespaces.

This procedure applies to:

• The datafiles associated with Oracle Application Server schemas and tablespaces.

  See Also: Appendix D, "Metadata Repository Schemas"

• The following standard Oracle database datafiles:
  • drsys01.dbf

  • system01.dbf

  • temp01.dbf

  • users01.dbf

The following example shows how to relocate two datafiles in two different tablespaces, as follows:

• Relocate the oca.dbf datafile in the OCATS tablespace from /infra_home/oradata/asdb/oca.dbf to /new_directory/oca.dbf

• Relocate the dcm.dbf datafile in the DCM schema from /infra_home/oradata/asdb/dcm.dbf to /new_directory/dcm.dbf

Before you start the procedure:

• Make sure you have a complete cold backup of the Metadata Repository

• Connect to the Metadata Repository as a user with administrator privileges. You must have the ALTER DATABASE system privilege to relocate datafiles.

• Read through the entire procedure before you start.

The procedure is as follows:

1. Verify the location of your datafiles.

   You can verify the location of datafiles in a particular tablespace by querying the data dictionary view DBA_DATA_FILES.

   For example, to query the location of datafiles in the OCATS and DCM tablespaces:

   SQL> SELECT FILE_NAME, BYTES FROM DBA_DATA_FILES
   WHERE TABLESPACE_NAME = 'OCATS' OR TABLESPACE_NAME = 'DCM';
   
   FILE_NAME 	BYTES
   ----------------------------------------------	------------
   /infra_home/oradata/asdb/oca.dbf	78643200
   /infra_home/oradata/asdb/dcm.dbf	96993280
   
   

2. Shut down all middle-tier instances that use the Metadata Repository.

3. Stop the Infrastructure that contains the Metadata Repository, then start a Metadata Repository instance and mount the database without opening it, as follows:
   1. Stop Application Server Control and OPMN-managed processes:

      ORACLE_HOME/bin/emctl stop iasconsole
      ORACLE_HOME/opmn/bin/opmnctl stopall
      
      

   2. Leave the Metadata Repository listener running.

   3. Stop the Metadata Repository instance:

      ORACLE_HOME/bin/sqlplus /nolog
      SQL> connect SYS as SYSDBA
      SQL> SHUTDOWN
      
      

   4. Start a Metadata Repository instance and mount the database without opening it:

      SQL> STARTUP MOUNT
      
      

4. Move the datafiles to their new location using the operating system. For example:

   (UNIX)
   mv /infra_home/oradata/asdb/oca.dbf /new_directory/oca.dbf
   mv /infra_home/oradata/asdb/dcm.dbf /new_directory/dcm.dbf
   
   (Windows)
   rename C:\infra_home\oradata\asdb\oca.dbf D:\new_directory\oca.dbf
   rename C:\infra_home\oradata\asdb\dcm.dbf D:\new_directory\dcm.dbf
   

   Note: You can execute an operating system command to copy a file by using the SQL*Plus HOST command.

5. Use ALTER DATABASE to rename the file pointers in the database's control file.

   SQL> ALTER DATABASE
   RENAME FILE	'/infra_home/oradata/asdb/oca.dbf',
   	'/infra_home/oradata/asdb/dcm.dbf'
   TO	'/new_directory/oca.dbf',
   	'/new_directory/dcm.dbf';
   
   

   The new files must already exist; this statement does not create the files. Also, always provide complete filenames (including their full paths) to properly identify the old and new datafiles. In particular, specify the old datafile name exactly as it appears in the DBA_DATA_FILES view of the data dictionary.

6. Shut down the Metadata Repository, then perform a normal startup of the Infrastructure:
   1. Leave the Metadata Repository listener running.

   2. Shut down the Metadata Repository

      SQL> SHUTDOWN
      
      

   3. Start the Metadata Repository:

      SQL> STARTUP
      
      

   4. Start OPMN-managed processes and Application Server Control:

      ORACLE_HOME/opmn/bin/opmnctl startall
      ORACLE_HOME/bin/emctl start iasconsole
      
      

7. Start the middle-tier instances that use the Infrastructure.

8. Verify the new location of your datafiles.

   SQL> SELECT FILE_NAME, BYTES FROM DBA_DATA_FILES
   WHERE TABLESPACE_NAME = 'OCATS' OR TABLESPACE_NAME = 'DCM';
   
   FILE_NAME 	BYTES
   ----------------------------------------------	------------
   /new_directory/oca.dbf	78643200
   /new_directory/dcm.dbf	96993280
   
   

9. Perform a complete cold backup of the Metadata Repository. After making any structural changes to a database, always perform an immediate and complete backup.

6.5 Specifying Segment Space Management When Creating Tablespaces

When you create a locally managed tablespace using the CREATE TABLESPACE statement, the SEGMENT SPACE MANAGEMENT clause allows you to specify how free and used space within a segment is to be managed. Your choices are:

• MANUAL--specifies that you want to use free lists for managing free space within segments. This is the default.

• AUTO--specifies that you want to use bitmaps to manage the free space within segments.

Most tablespaces in the Metadata Repository are created using MANUAL mode, with the following exceptions, which use AUTO mode:

• OLTS_ATTRSTORE

• OLTS_CT_STORE

• OLTS_DEFAULT

Therefore, it is important to follow these rules if you create a tablespace in preparation for importing a tablespace from a Metadata Repository:

• If you are creating the OLTS_ATTRSTORE, OLTS_CT_STORE, or OLTS_DEFAULT tablespace, include the SEGMENT SPACE MANAGEMENT AUTO clause in the creation statement.

  For example, to create the OLTS_DEFAULT tablespace of size 10M:

  create tablespace OLTS_DEFAULT datafile
    'gdefault1_oid.dbf' size 10M
    reuse autoextend ON
    EXTENT MANAGEMENT LOCAL AUTOALLOCATE SEGMENT SPACE MANAGEMENT AUTO;
  

• If you are creating any other tablespaces, do not specify SEGMENT SPACE MANAGEMENT AUTO.

  See Also: Oracle9i Database Administrator's Guide