| Oracle Application Server 10g Administrator's Guide 10g (9.0.4) Part Number B10376-01 |
|
This chapter provides information on managing an OracleAS Metadata Repository.
It contains the following topics:
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.
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 |
A Metadata Repository is required by the following installations:
You can obtain a Metadata Repository in either of the following ways:
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:
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.
You can use Oracle Enterprise Manager, refer to Section 2.5, "Managing the OracleAS Metadata Repository Database".
No. The Metadata Repository is not intended for deploying applications.
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:
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.
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 |
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.
No. You should never delete any of the schemas that come with the Metadata Repository.
Yes.
Yes. Oracle Application Server offers several high availability options for the Metadata Repository, including:
Yes. This is part of the Oracle-recommended backup and recovery strategy.
Oracle provides a backup and recovery strategy for your entire Oracle Application Server environment, including the Metadata Repository.
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.
| Schema | Method for Changing Password |
|---|---|
|
|
If the Metadata Repository is registered with Oracle Internet Directory, you must change the password in two places:
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. |
|
|
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". |
|
|
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:
|
|
|
This schema requires special steps. Refer to Oracle Application Server Certificate Authority Administrator's Guide for advanced topics in administration. |
|
|
This schema requires special steps. Refer to Oracle Internet Directory Administrator's Guide for information on resetting the default password for the database. |
|
|
This schema requires special steps. Refer to Oracle Application Server Certificate Authority Administrator's Guide for advanced topics in administration. |
|
|
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 |
|
|
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". |
|
|
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". |
|
|
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
Refer to Oracle Application Server Portal Configuration Guide. |
|
|
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 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 |
|
|
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". |
|
|
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". |
|
|
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". |
|
|
Use SQL*Plus to change the password directly in the database. Refer to Section 6.2.2, "Changing Schema Passwords Using SQL*Plus". |
|
|
Use SQL*Plus to change the password directly in the database. Refer to Section 6.2.2, "Changing Schema Passwords Using SQL*Plus". |
|
|
Use SQL*Plus to change the password directly in the database. Refer to Section 6.2.2, "Changing Schema Passwords Using SQL*Plus". |
|
|
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". |
|
|
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". |
|
|
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". |
|
|
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". |
|
|
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". |
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:
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 USERschemaidentified bynew_password;
For example, to change the SCOTT schema password to "abc123":
SQL> ALTER USER SCOTT IDENTIFIED BY abc123;
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.
ORACLE_HOME/bin/oidadmin
orcladmin user.
orclReferenceName for the Metadata Repository.
OrclResourceName entry for the schema whose password you want to change.
orclpasswordattribute field.
To configure the middle-tier and infrastructure to work with the metadata repository after its character set has been changed:
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.
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.
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".
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 following example shows how to relocate two datafiles in two different tablespaces, as follows:
oca.dbf datafile in the OCATS tablespace from /infra_home/oradata/asdb/oca.dbf to /new_directory/oca.dbf
dcm.dbf datafile in the DCM schema from /infra_home/oradata/asdb/dcm.dbf to /new_directory/dcm.dbf
Before you start the procedure:
ALTER DATABASE system privilege to relocate datafiles.
The procedure is as follows:
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
ORACLE_HOME/bin/emctl stop iasconsoleORACLE_HOME/opmn/bin/opmnctl stopall
ORACLE_HOME/bin/sqlplus /nolog
SQL> connect SYS as SYSDBA
SQL> SHUTDOWN
SQL> STARTUP MOUNT
(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 |
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.
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
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:
Therefore, it is important to follow these rules if you create a tablespace in preparation for importing a tablespace from a Metadata Repository:
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;
SEGMENT SPACE MANAGEMENT AUTO.
|
|
![]() Copyright © 2002, 2003 Oracle Corporation. All Rights Reserved. |
|