Release 2 (9.0.2) for Sun SPARC Solaris
Part Number A96157-03
 Home |
 Contents |
 Index |
| Oracle9i Application Server Migrating from Oracle9iAS Release 1 (1.0.2.2.x) to Release 2 (9.0.2) Release 2 (9.0.2) for Sun SPARC Solaris Part Number A96157-03 |
|
This chapter explains how to change the necessary configuration files, application deployment files, and metadata schema in order to migrate Management components. It contains these major sections:
Migrating Oracle Enterprise Manager
Migrating Oracle9iAS Single Sign-On
Migrating Oracle Internet Directory
This section explains how to upgrade an Oracle Enterprise Manager Release 2.x repository to a Release 9i repository. Existing pre-9i repositories are not upgraded automatically during installation. To upgrade, you must run the Oracle Enterprise Manager Configuration Assistant manually after the installation. Before upgrading, you need to create a new 9i repository.
The Oracle Enterprise Manager Configuration Assistant takes an existing Release 2.x repository and upgrades it directly to a Release 9i repository.
This section outlines the steps you must perform before you migrate Oracle Enterprise Manager.
Before you attempt to perform an upgrade, you must first stop all Management Servers and Oracle Enterprise Manager applications that are using this repository. If any Management Server is currently using this repository, upgrading the repository causes a server error.
If you are using an Oracle Enterprise Manager version prior to Release 2.2, or if you are using any separately ordered management pack, see the Oracle Enterprise Manager Configuration Guide for important information about migrating your Enterprise Manager Repository.
Before you attempt to upgrade the repository, you must first back up the database or repository schema using the standard export mechanism. The EXPORT utility is a base utility shipped with the Oracle database server.
If there is a failure during a repository upgrade, the repository will no longer be usable. The failed repository would no longer appear in the list of repositories that could be upgraded.
To upgrade the repository, perform the steps in the following sections.
(Windows NT) Start the Enterprise Manager Configuration Assistant from the Windows Start Menu, or
Start the Enterprise Manager Configuration Assistant from the command line using the command:
emca
(UNIX): Start the Enterprise Manager Configuration Assistant from the command line using the command:
emca
|
Note:
You must have write access to the |
The Configuration Operation page appears.
The Select Database for Repository page appears.
The "Select Repository" page appears. If you are selecting a repository to upgrade, the Select Repository page shows only Release 2.0, 2.1, and 2.2 repositories. The Enterprise Manager Configuration Assistant does not display Release 9.0.1 repositories in this situation (they are already at the current version and do not need to be upgraded). The page shows the following information about the repository:
Username: The username of the repository.
Version: The version of the repository.
Type: The type of repository. Type can be either "Enterprise" or "Standalone". An Enterprise repository is used by the Oracle Enterprise Manager connected to a Management Server. A Standalone repository is required by certain applications when you use Oracle Enterprise Manager not connected to a Management Server.
The Repository Login Information page appears.
In order to perform a repository upgrade, you must log on to the repository database as the repository owner (the user so designated during repository creation). The repository user name is carried forward from the previous page, but you must enter the password.
The Upgrade Repository Summary page appears.
All of the information you supplied is summarized on this page. Click Finish to perform the repository upgrade, or click Back to return to previous pages if you need to change any of the information.
The Configuration Assistant Progress window appears, showing the processing performed and the processing steps that comprise the operation being performed. Each processing step is shown by a line of text.
You can cancel the requested operation before it completes by clicking the Cancel button. However, if you cancel the operation, the repository will become unusable.
The Cancel button changes to a Close button when processing completes, whether it is successful or not.
When all of the steps have been completed without error, the "Processing completed." message appears.
During the Configuration Assistant upgrade operation, the Oracle Management Service will be created (if it does not already exist) only if the repository being upgraded is the one actually being used by the local Management Server.
To drop the repository and deconfigure the local Management Server (if it uses that repository), perform the following steps:
If any Management Server is currently using this repository, deleting the repository causes a server error.
Note:
The Welcome page appears.
The Configuration Operation page appears.
The Select Database for Repository page appears.
The Select Repository page appears, showing the following information about the repository:
Username: The username of the repository.
Version: The version of the repository.
Type: The type of repository. Type can be either "Enterprise" or "Standalone". An Enterprise repository is used by the Oracle Enterprise Manager connected to a Management Server. A Standalone repository is required by certain applications when you use Oracle Enterprise Manager not connected to a Management Server.
The Repository Drop Options page appears. Here, you can choose to drop the repository user and all its schema objects or only the repository objects.
omsconfig.properties file, and you are not dropping that repository, the Configuration Assistant will not change the Management Server configuration.
The Drop Repository Summary page appears, providing a summary of all the information supplied during the drop repository operation.
The Configuration Assistant Progress window appears, showing the processing performed and the processing steps that comprise the operation being performed. Each processing step is shown by a line of text.
The Cancel button changes to a Close button when processing is completed whether it is successful or not.
When all of the steps have been completed without error, the "Processing completed." message appears.
You can cancel the requested operation before it completes by clicking the Cancel button.
Once configured, the Management Server provides distributed control between clients and managed nodes. A central engine for notification, it processes all system management tasks and administers the distribution of these tasks across the enterprise.
|
See Also:
Oracle9i Application Server Administrator's Guide in the Oracle9iAS Documentation Library. |
This section describes the process of migrating standalone Oracle9iAS Release 1 (1.0.2.2.x) applications to enable them for Single Sign-On in Oracle9iAS Release 2 (9.0.2).
In Release 2, most applications are integrated with mod_sso (the Single Sign-On module for Oracle HTTP Server) and the OC4J security infrastructure.
After this process is complete, Release 1 applications can use the security infrastructure provided in Release 2.
This section explains how to migrate Oracle Internet Directory (OID) Release 9.0.2.1.0 from the following Oracle Internet Directory releases:
Throughout these instructions, ORACLE_HOME_1 represents the Oracle home of the existing Oracle Internet Directory and ORACLE_HOME_2 represents the Oracle home of the newly installed Oracle Internet Directory 9.0.2.1.0. The migration and upgrade process is described below:
The following conditions and procedures are important in planning and executing a successful upgrade.
Before you begin the upgrade, you must perform these steps:
Oracle Corporation strongly recommends that you back up the database in ORACLE_HOME_1 before proceeding, thereby retaining existing schema information and data.
Note:
The following table outlines the steps for upgrading OID in a single node environment.
If you are upgrading from Oracle Internet Directory 3.0.1.x only, proceed to "Upgrading from 3.0.1.* to 9.0.1.2.0".
/bin/odma. Follow the wizard to migrate the existing 8.1.7.* database in ORACLE_HOME_1, on which the old 2.1.1.* OID is running. Make sure the correct SID is specified and that you choose to migrate the database listener. For more information on Oracle Data Migration Assistant, please refer to the 9i (9.0.1.0.0) Database Migration Documentation.
Ensure that the database is brought up in ORACLE_HOME_2. To apply the 9.0.1.2.0 database patch set, please follow the instructions in the "Post Install Actions section" in ORACLE_HOME_2/rdbms/notes/patch_note.htm.
In ORACLE_HOME_2, do the following:
/bin/oidca.
The Welcome screen appears.
The Database Migration screen appears.
The Upgrade in Progress window appears.
The Root Oracle context and the Directory Integration Platform-related information are upgraded.
The User Data Migration screen appears.
The upgrade is complete.
The OID is running, listening to the specified non-SSL and SSL ports.
In ORACLE_HOME_2, do the following:
/bin/oidca.
The Welcome screen appears.
The OID database is migrated from ORACLE_HOME_1 to ORACLE_HOME_2.
/network/admin/tnsnames.ora to ORACLE_HOME_2/network/admin/tnsnames.ora.
/network/admin/listerner.ora to ORACLE_HOME_2/network/admin/listener.ora.
/rdbms/notes/patch_note.htm.
The Upgrade in Progress window appears.
The Root Oracle context and the Directory Integration Platform-related information are upgraded.
The User Data Migration screen appears.
The upgrade is complete.
The OID server is running, listening to the specified non-SSL and SSL ports.
Upgrading a multi-node OID system in a replication environment requires special attention. This section discusses the two ways to upgrade a multi-node OID system.
This method avoids a complete shutdown of the replicated network. An upgrade on one node can take place, while the other nodes remain available. Note the following:
/ldap/admin/delasrjobs.sql. This script deletes Oracle9i Replication jobs on other master sites that push changes to the MDS. Deleting these jobs temporarily removes the current node from the replication environment so that no changes can be applied to it. Other nodes, however, remain operational and continue replicating changes.
/ldap/admin/delasrjobs.sql. The ASR jobs deleted will be restored. Changes in the upgraded node will be pushed to the rest of the network and vice versa. The upgraded node is now back in the replicated network.
As discussed previously, the upgrade is not complete until all nodes are upgraded.
When an existing Directory Replication Group (DRG) is being upgraded, some of the changes made on the newly upgraded OID 9.0.2.1.0 will not replicate to nodes of the older version that have not been upgraded. These changes will eventually be replicated successfully when the consumer node is upgraded to 9.0.2.1.0.
If possible, apply the following restrictions to the DRG during upgrade:
To do this, you can temporarily disable the pushing of changes by a particular node by bringing up the replication server in a special mode (-o FALSE). To start the replication server in this mode, execute the following:
$OH/bin/oidctl connect=connect string server=oidrepld instance=1 flags="-p port -h host -o FALSE " start
Note that any the changes made on an older node can be successfully replicated to any newer v.9.0.2.1.0 node.
Backward compatibility issues can be avoided by upgrading all the nodes at one time. However, this method requires a complete shutdown of the replication network, which leads to downtime. If downtime is acceptable, this method is preferable.
This method requires all the nodes to become Read-Only, and an eventual shutdown of all the OID processes on all the nodes. This replicated network becomes unavailable during the upgrade process.
After the upgrade, perform the following tasks:
On all the nodes in the DRG, please make sure that the JOB_QUEUE_PROCESSES parameter in the init.ora file of the database is set to the following value:
You must do this if you are performing a single-node upgrade. In a multi-node environment, this only needs to be done on the Master Definition Site (MDS). Skip this section if you have performed user data migration in OIDCA.
The password format in OID 9.0.2.1.0 is base-64. The older passwords stored in hexadecimal must be converted. To perform the conversion, follow these steps:
ldapsearch to output all the encrypted user passwords to a file. In this case, ORACLE_HOME_2/ldap/install/pwdin.ldif is used as the output file.
ORACLE_HOME_2/bin/ldapsearch -L -h OID host name -p OID Non-SSL port -D OID Super User DN-w OID Super User Password -b "" -s sub "objectclass=*" dn userpassword > $OH/ldap/install/pwdin.ldif
/ldap/install/pwdin.ldif and output it to ORACLE_HOME_2/ldap/install/pwdout.ldif.
ORACLE_HOME_2/bin/passwordconvert -m hex2base64 -f modify ORACLE_HOME_ 2/ldap/install/pwdin.ldif ORACLE_HOME_2/ldap/install/pwdout.ldif
ORACLE_HOME_2/bin/ldapmodify -h OID host name -p OID Non-SSL port -D OID Super User DN-w OID Super User Password> -f ORACLE_HOME_ 2/ldap/install/pwdout.ldif
You can use Oracle Directory Manager (ODM) to perform the Oracle Context configuration.
The following information needs to be added in the Root Oracle Context under the DN "cn=Common, cn=Products, <Root Oracle Context DN>". By default, the Root Oracle Context DN is "cn=OracleContext". The following attribute values are needed:
orclSubscriberSearchBase - Identifies the base node in the DIT when searching for subscribers.
orclSubscriberNickNameAttribute - Identifies the nickname attribute to be used when searching for a subscriber under the subscriber search base.
orclDefaultSubscriber - Identifies the root of your organization. It should be the same value as the one specified in "Upgrading from 3.0.1.* to 9.0.1.2.0".
The following information must be added in the subscriber-specific Oracle Context under the DN "cn=Common, cn=Products, cn=oracleContext, <Subscriber DN>".
orclCommonUserSearchBase - Identifies the base node under the subscriber when searching for users. During upgrade, this attribute value is set as the subscriber DN.
If this attribute is not set, then the password policy under the Root Oracle Context will be applied.
Note:
orclCommonNickNameAttribute - Identifies the base node under the subscriber when searching for groups.
orclCommonGroupSearchBase - Identifies the node in the DIT under which all the groups are placed.
If a password policy exists in the older version of OID (which would be located under the DN cn=pwdpolicyentry, cn=oracle internet directory), this policy will be applied to both the Root Oracle Context and the default Subscriber Oracle Context. The original DN containing the policy, cn=pwdpolicyentry, cn=oracle internet directory will be removed in the earlier version.
Otherwise, the default password policy is set up as part of the Subscriber Oracle Context creation. By default, the password policy for the default subscriber is set to the following values:
(You can find the above attribute values in the entry cn=PwdPolicyEntry, cn=Common,cn=Products,cn=oracleContext,subscriber DN)
The password policy under Root Oracle Context applies to all entities under the root DSE. However, it does not apply to entities under the Root Oracle Context.
If the upgraded OID is integrating with other Oracle9iAS Release 2 (9.0.2) components, appropriate access control policies (ACPs) will need to be set up to grant necessary privileges to the components.
After the upgrade, the OID target in targets.xml must be updated manually to specify the correct ORACLE_SID, and the ods and emd administrator user passwords.
During the upgrade, the Directory Integration Platform (DIP) server is not brought up. In order to use the Directory Integration Platform, you need to explicitly register and start the DIP server.
An upgrade procedure using database import/export is also available. It offers a more flexible way of migrating OID from version to version. Database migration is not required.
|
 Copyright © 2002, 2003 Oracle Corporation. All Rights Reserved. |
|