6 Managing an OracleAS Metadata Repository

6.1 Frequently Asked Questions About OracleAS Metadata Repository

OracleAS Metadata Repository is an Oracle Database 10g database and can be managed using standard database procedures and tools. However, there are some considerations for managing OracleAS 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 a database. It is pre-seeded with schemas to support Oracle Application Server components and services. See Appendix E 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 one for Identity Management schemas.

  • A J2EE and Web Cache installation that is part of an OracleAS Cluster managed by a database repository requires one for the Management (DCM) schema.

  • A Portal and Wireless installation requires one for product metadata schemas.

  • A Business Intelligence and Forms installation requires one 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.

    
    

    See Also: Oracle Application Server Installation Guide

    
    

  • You can install a Metadata Repository into an existing database using the Oracle Application Server Metadata Repository Creation Assistant.

    
    

    See Also: Oracle Application Server Metadata Repository Creation Assistant User's Guide

    
    

• Are there any tools for managing the Metadata Repository?

  You can use Oracle Enterprise Manager. See Section 2.5, "Managing the OracleAS Metadata Repository Database with Database Control" for more information.

• Can I use the Metadata Repository to deploy applications?

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

• Are there any database features that are not supported by the Metadata Repository?

  The following tablespace management features are not supported:

  • Using ALTER TABLESPACE to assign a different default tablespace to a user

  • Using ALTER TABLESPACE to reduce the number of tablespaces that were created when you initially created the Metadata Repository

  • Renaming a tablespace

  It is, however, possible to use ALTER TABLESPACE to do segment management using autoextend or any other feature.

• 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 and Oracle 10g databases can share the same Net listener port. If the other databases on your host are Oracle9i or Oracle 10g 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 Metadata Repository Net listener port after installation?

  Yes. Refer to Section 4.4.1, "Changing theOracleAS Metadata Repository Net Listener Port" for more information.

• Can I change the Metadata Repository SID and global database name after installation?

  No. This is not supported.

• 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.5, "Changing the Character Set of OracleAS 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 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 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 reduces the database connections requirement.

  
  

  See Also: Oracle Application Server 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 the Application Server Control Console so the password is updated in Oracle Internet Directory and the database. See Section 6.4, "Changing OracleAS Metadata Repository Schema Passwords" for more information.

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

  No. You should never delete any of the schemas are provided with the Metadata Repository.

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

  Yes. See Section 6.6, "Renaming and Relocating OracleAS Metadata Repository Datafiles" for more information.

• Can I configure my Metadata Repository for high availability?

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

  • Oracle Application Server Cold Failover Cluster

  • DCM-Managed Oracle Application Server Cluster

  • Oracle Application Server Disaster Recovery

    
    

    See Also: Oracle Application Server 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 Section 21.2.2, "Enabling ARCHIVELOG Mode" for more information.

• How can I back up and recover the Metadata Repository?

  Oracle provides a backup and recovery strategy for your entire Oracle Application Server environment, including the Metadata Repository. See Part V, "Backup and Recovery" for more information.

6.2 Postinstallation Status of OracleAS Metadata Repository Schemas

Table 6-1 shows the status of Metadata Repository schemas immediately after installation. The table contains the account status and initial password for each schema, depending on whether the Metadata Repository is registered with Oracle Internet Directory.

To unlock an account using SQL*Plus (be sure to set your ORACLE_HOME and ORACLE_SID environment variables before you run these commands):

ORACLE_HOME/bin/sqlplus "SYS/password_for_sys AS SYSDBA"
SQL> ALTER USER schema ACCOUNT UNLOCK;

To lock an account:

ORACLE_HOME/bin/sqlplus "SYS/password_for_sys AS SYSDBA"
SQL> ALTER USER schema ACCOUNT LOCK;

The method for changing passwords varies by schema. Refer to Section 6.4, "Changing OracleAS Metadata Repository Schema Passwords" to determine the proper way to change a password.

6.3 Viewing OracleAS Metadata Repository Schema Passwords

If a Metadata Repository is registered with Oracle Internet Directory, some schema passwords are stored in the directory and you can view them using Oracle Internet Directory tools.

You can view the passwords for the following schemas in Oracle Internet Directory:

You can view the passwords using the following procedures:

• Viewing OracleAS Metadata Repository Schema Passwords using Oracle Directory Manager

• Viewing OracleAS Metadata Repository Schema Passwords using ldapsearch

ORACLE_HOME/bin/ldapsearch -p oid_port -h oid_hostname -D "cn=orcladmin"
-w orcladmin_password -b "orclresourcename=schema_name,
 orclreferencename=metadata_rep_global_db_name, cn=ias infrastructure databases,
 cn=ias, cn=products, cn=oraclecontext" -s base "objectclass=*"
 orclpasswordattribute

orclpasswordattribute=password

ORACLE_HOME/bin/ldapsearch -p 13060 -h myhost -D "cn=orcladmin"
-w mypassword -b "orclresourcename=ORASSO, 
orclreferencename=orcl.mycompany.com, cn=ias infrastructure databases,
cn=ias, cn=products, cn=oraclecontext" -s base "objectclass=*"
orclpasswordattribute

OrclResourceName=ORASSO,orclReferenceName=orcl.mycompany.com
cn=IAS Infrastructure Databases,cn=IAS,cn=Products,cn=OracleContext
orclpasswordattribute=Og23NI78

6.4 Changing OracleAS Metadata Repository Schema Passwords

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

Table 6-2 lists the appropriate method for changing each Metadata Repository schema.

ORACLE_HOME/portal/conf/ptlconfig -dad dad_name -site [-pw PORTAL_schema_password]

SQL> ALTER USER schema identified by new_password;

SQL> ALTER USER SCOTT IDENTIFIED BY abc123;

6.5 Changing the Character Set of OracleAS Metadata Repository

You can change the character set of the OracleAS Metadata Repository by following the instructions for changing the character set in the database documentation.

Then, take the following steps to configure the middle-tier and infrastructure to work with OracleAS 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 the Application Server Control Console, 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, click 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 OracleAS Metadata Repository.

   7. Click OK.

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

2. Reconfigure the Oracle Ultra Search index as follows:

   1. Connect to OracleAS Metadata Repository as WKSYS and invoke the following SQL script to reconfigure the default cache character set and index preference:

      (UNIX) ORACLE_HOME/ultrasearch/admin/wk0prefcheck.sql
      (Windows) ORACLE_HOME\ultrasearch\admin\wk0prefcheck.sql
      
      

   2. Connect to OracleAS Metadata Repository as the default user (WKTEST) and invoke the following SQL script:

      (UNIX) ORACLE_HOME/ultrasearch/admin/wk0idxcheck.sql
      (Windows) ORACLE_HOME\ultrasearch\admin\wk0idxcheck.sql
      
      

      The script asks you to enter the instance name (WK_INST). Enter y when prompted to proceed with the change.

      This script reconfigures the instance (in this case, the default instance). It also truncates the Oracle Text index used by Oracle Ultra Search and you must force a recrawl to rebuild the index.

   3. Repeat step b for all Oracle Ultra Search instances that were created before you changed the database character set. Invoke the script as the instance owner, and then force a recrawl of all data sources, if necessary.

3. If you installed OracleAS Portal, you must make sure that it is configured with the same languages as the OracleAS Infrastructure (which includes OracleAS Metadata Repository) to avoid problems with set language requests sent to OracleAS Single Sign-On. To configure additional languages for OracleAS Portal, you run the ptlang tool.

   
   

   See: The section "Configuring Language Support" in the Oracle Application Server Portal Configuration Guide for information on the ptlang tool

   
   

6.6 Renaming and Relocating OracleAS Metadata Repository Datafiles

When you install OracleAS 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 file system 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 Appendix E for a list of 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/orcl/oca.dbf to /new_directory/oca.dbf

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

Before you start the procedure:

• Make sure you have a complete cold backup of OracleAS Metadata Repository. See Part V, "Backup and Recovery" for more information.

• Connect to OracleAS 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/orcl/oca.dbf                78643200
   /infra_home/oradata/orcl/dcm.dbf                96993280
   
   

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

3. Stop the Infrastructure that contains OracleAS Metadata Repository, then start an OracleAS Metadata Repository instance and mount the database without opening it, as follows:

   1. Stop the Application Server Control Console and OPMN-managed processes:

      • On UNIX systems:

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

      • On Windows systems:

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

   2. Leave the Metadata Repository listener running.

   3. Stop the OracleAS Metadata Repository instance (make sure the ORACLE_HOME environment variable is set):

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

   4. Start an OracleAS 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:

   • On UNIX systems:

     mv /infra_home/oradata/orcl/oca.dbf /new_directory/oca.dbf
     mv /infra_home/oradata/orcl/dcm.dbf /new_directory/dcm.dbf
     
     

   • On Windows systems:

     rename C:\infra_home\oradata\orcl\oca.dbf D:\new_directory\oca.dbf
     rename C:\infra_home\oradata\orcl\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/orcl/oca.dbf',
                              '/infra_home/oradata/orcl/dcm.dbf'
         TO                   '/new_directory/oca.dbf',
                              '/new_directory/dcm.dbf';
   
   

   The new files must already exist; this statement does not create the files. 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 OracleAS Metadata Repository, then perform a normal startup of the Infrastructure:

   1. Leave the OracleAS Metadata Repository listener running.

   2. Shut down OracleAS Metadata Repository:

      SQL> SHUTDOWN
      
      

   3. Start OracleAS Metadata Repository:

      SQL> STARTUP
      
      

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

      • On UNIX systems:

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

      • On Windows systems:

        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 OracleAS Metadata Repository. After making any structural changes to a database, always perform an immediate and complete backup.

   
   

   See Also: Part V, "Backup and Recovery"