| Oracle® Collaboration Suite Administrator's Guide 10g Release 1 (10.1.2) for Windows or UNIX Part Number B25490-05 |
|
|
View PDF |
| Oracle® Collaboration Suite Administrator's Guide 10g Release 1 (10.1.2) for Windows or UNIX Part Number B25490-05 |
|
|
View PDF |
This chapter describes a number of procedures used for making various changes to your Oracle Collaboration Suite Infrastructure services. This chapter includes the following topics:
Changing the Oracle Internet Directory or HTTP (SSO) Ports on Identity Management
Changing Oracle Internet Directory from Dual Mode to SSL Mode
Changing the OracleAS Metadata Repository Used by an Applications Tier
All Oracle Collaboration Suite Applications tier instances use services that reside on the Infrastructure, such as Identity Management Services and the OracleAS Metadata Repository. If you have a single Infrastructure instance, all of your Oracle Collaboration Suite Applications tier instances will automatically be associated with that instance during installation. If you have multiple Infrastructure instances, or if you have upgraded from a previous version of Oracle Collaboration Suite, some Applications tier services may require manual association as part of the setup process. These procedures are described in detail in the Oracle Collaboration Suite Installation Guide for Solaris Operating System and Oracle Collaboration Suite Installation Guide for Microsoft Windows.
After installation, you may want to change the Infrastructure Services used by a Applications tier instance. For example, you may want to use an Identity Management Service on a different host. Or, you may want to use a different OracleAS Metadata Repository.
Changing the association between one or more Infrastructure Services and one or more Applications tier instances is called 're-association'.
You can perform Infrastructure re-association using the Infrastructure Page on the Oracle Collaboration Suite Control Console, shown in figure Figure 12-1. Notice that the page allows you to change the Identity Management or the OracleAS Metadata Repository used by an Applications tier instance.
Figure 12-1 Oracle Collaboration Suite Control Console Infrastructure Page
You must perform re-association when you change any of the following:
The HTTP Server (SSO) port number on an Identity Management installation
The Oracle Internet Directory non-SSL or SSL port number
The Oracle Internet Directory Mode (Dual-mode or SSL)
The host that Identity Management or the OracleAS Metadata Repository resides on
If you are creating a new Infrastructure instance, you must first perform manual tasks in order to create and prepare the new Infrastructure service. This chapter provides the following supported procedures for changing Infrastructure services:
Changing the Oracle Internet Directory or HTTP (SSO) Ports on Identity Management
Use this procedure if you need to change the Oracle Internet Directory or HTTP listener ports on an Identity Management installation. In addition to changing the port numbers, you must update Applications tier instances with the new port information, which requires changing Infrastructure services.
Changing Oracle Internet Directory from Dual Mode to SSL Mode
Use this procedure if you would like to change the Oracle Internet Directory mode from non-SSL to SSL. In addition to changing the mode, you must update Applications tier instances with the new mode, which requires changing Infrastructure services.
Moving Identity Management to a New Host
Use this procedure if you would like to move your Identity Management installation, and its associated OracleAS Metadata Repository, to a new host. After you perform the move, you must update Applications tier instances with the new host information for Identity Management, which requires re-association.
Changing the OracleAS Metadata Repository Used by an Applications Tier
Use this procedure if you would like to move the OracleAS Metadata Repository used for product metadata by Applications tier instances to a new host.
If you would like to change the Oracle Internet Directory non-SSL or SSL port on an Identity Management installation, refer to "Changing Oracle Internet Directory Ports".
If you would like to change the Oracle HTTP Server non-SSL or SSL listen port on an Identity Management installation, which effectively changes the SSO port, refer to "Changing the HTTP Server Port on Identity Management".
When you install Identity Management, you are asked to choose a mode for Oracle Internet Directory. The default mode is dual mode, which allows some components to access Oracle Internet Directory using non-SSL connections. During the installation, you can choose SSL mode, which specifies that all components must use SSL when connecting to the directory.
If you did not choose SSL mode during the installation, and would like to change to SSL mode after installation, you can follow the procedure in this section. It includes changing the mode of the Oracle Internet Directory, and updating Applications tier instances to use the new mode.
Before You Begin
Before beginning this procedure, you should shut down all Applications tiers using this instance of Oracle Internet Directory. Be sure to leave the Oracle Collaboration Suite Control (emctl) process running on all Applications tiers.
You can shut down the tiers using Oracle Collaboration Suite Control by navigating to each Applications tier home page and clicking Stop All.
Task 1: Change the Oracle Internet Directory Mode
Perform this task on the Infrastructure instance that hosts Oracle Internet Directory.
Create a file named mod.ldif that contains the following lines:
dn:cn=configset0,cn=osdldapd,cn=subconfigsubentry changetype:modify replace:orclsslenable orclsslenable:1
Run the following command:
ldapmodify -D cn=orcladmin -w orcladmin_passwd -p oid_port -v -f mod.ldif
oid_port is the non-SSL Oracle Internet Directory port. This is listed as OIDport in ORACLE_HOME/config/ias.properties.
Stop the entire instance that hosts Oracle Internet Directory:
emctl stop iasconsole opmnctl stopall
Edit the ldap.ora file:
(UNIX) ORACLE_HOME/ldap/admin/ldap.ora (Windows) ORACLE_HOME\ldap\admin\ldap.ora
Modify the following line to remove the non-SSL port number:
DIRECTORY_SERVERS=(myhost.myco.com::sslport)
Save and close the file.
(UNIX) ORACLE_HOME/config/ias.properties (Windows) ORACLE_HOME\config\ias.properties
Change the SSLOnly parameter as follows:
SSLOnly=true
Save and close the file.
Start the entire instance that hosts Oracle Internet Directory:
opmnctl startall emctl start iasconsole
Reconfigure SSO to communicate to Oracle Internet Directory in SSL mode:
Obtain the ORASSO schema password:
ldapsearch -p oid_port -U 1 -h hostname -D "cn=orcladmin" -w orcladmin_password -b "orclresourcename=orasso, orclreferencename=global_db_name, cn=ias infrastructure databases, cn=ias, cn=products, cn=oraclecontext" -s base "objectclass=*" orclpasswordattribute
oid_port is the non-SSL Oracle Internet Directory port. This is listed as OIDport in ORACLE_HOME/config/ias.properties.
global_db_name is the name of the entry for the OracleAS Metadata Repository in the tnsnames.ora file: ORACLE_HOME/network/admin/tnsnames.ora. For example: asdb.myco.com.
This command prints the ORASSO password in a line like the following:
orclpasswordattribute=LAetjdQ5
Change to the following directory:
(UNIX) cd ORACLE_HOME/sso/admin/plsql/sso (Windows) cd ORACLE_HOME\sso\admin\plsql/sso
Run the following command:
sqlplus orasso/orasso_password @ssooconf.sql
Where orasso_password is the ORASSO schema password you obtained in the previous step.
The following prompts appear. Press return for attributes you did not change, and enter a new value for attributes that you changed.
Enter value for new_oid_host:
Press return.
Enter value for new_oid_port:
Enter the Oracle Internet Directory SSL port number and press return.
Enter value for new_sso_server_password:
Press Return.
Enter value for new_ldapusessl:
Enter Y in this field, then press return. A message appears indicating that the value new_ldapusessl has been updated.
Restart the instance that hosts Oracle Internet Directory.
opmnctl stopall opmnctl startall
Task 2: Change Applications Tier Instances to Use SSL Mode
In each Applications tier instance, run the Change Identity Management wizard and restart the instance:
Using the Application Server Control Console, navigate to the Instance Home Page for the Applications tier instance.
Click Infrastructure.
On the Infrastructure Page, in the Identity Management section, click Change.
On the Internet Directory page:
Host: Enter the fully-qualified name of the Oracle Internet Directory host.
Port: Enter the SSL Oracle Internet Directory port number.
Use only SSL connections with Internet Directory: Check this box.
Click Next.
On the Login page:
User Name: Enter cn=orcladmin, or the distinguished name of a user in the iASAdmins group.
Password: Enter the password for the user.
Click Next.
On the Validation page, you will receive informational messages regarding the validation of this operation. If you receive any error message, follow the instructions for investigating them. Otherwise, if the operation is valid, click Finish.
Edit ORACLE_HOME/ldap/admin/ldap.ora in the Applications tier Oracle home to remove the non-SSL port number. Change the following line from:
DIRECTORY_SERVERS = (replica_host:replica_oid_port:replica_ssl_oid_port)
to the following:
DIRECTORY_SERVERS = (replica_host::replica_ssl_oid_port)
When the operation is finished, you must perform an opmnctl refresh, and then restart the components in the Applications tier instance.
Enter the following command from the Applications tier (after setting ORACLE_HOME to the Applications tier home):
ORACLE_HOME/opmn/bin/opmnctl reload
Navigate to the Application Server Home Page
Click Start All.
|
Note: Now that you have disabled the non-SSL Oracle Internet Directory port, you must provide the "-U 1" option when using LDAP command-line utilities (such asldapsearch, ldapmodify, and ldapaddmt) to connect to the SSL port. |
This section provides a procedure for moving Identity Management to a new host. This procedure involves creating a replica (or copy) of the original Identity Management instance on a different host, along with its own new OracleAS Metadata Repository, and then reassociating Applications tier instance to use the new Identity Management instance.
|
Note: You cannot simply change an Applications tier instance from one Identity Management to another. The new Identity Management must be a replica of the original, created using the instructions in this procedure. |
The following are sample uses for this procedure:
You have an existing Identity Management and associated OracleAS Metadata Repository that is used by one or more Applications tier instances. Your organization intends to replace the current Identity Management host with a new system. You can use this procedure to create a replica of the Identity Management, along with its own OracleAS Metadata Repository, and change your Applications tier instances to use the new Identity Management. You can then retire the original host.
You would like to create a failover environment for your Identity Management. You can use this procedure to create a replica of the current Identity Management, along with its own OracleAS Metadata Repository. You can keep the replica running so it stays in sync with the original Identity Management. You can perform regular exports of data in the original OracleAS Metadata Repository and save them. In the event that you lose the original Identity Management, you can import the data to the new OracleAS Metadata Repository, and change your Applications tier instances to use the new Identity Management. Refer to "Strategy for Performing Failover with this Procedure" for more information.
For both the original and new installations, the Identity Management and OracleAS Metadata Repository can exist in the same Oracle home, or in separate Oracle homes (same or different host). If they are in separate Oracle homes, perform the operations on each in their own Oracle home.
For both the original and new installations, the Identity Management components (SSO, Oracle Internet Directory, DAS, and DIP) may exist in the same Oracle home, or may exist in separate Oracle homes (same or different host). If they exist in separate Oracle homes, perform the operations on each in their own Oracle home.
The OracleAS Metadata Repository used by Applications tier instances for product metadata is not affected by this procedure.
If the Applications tier instances use product metadata in the same OracleAS Metadata Repository that the original Identity Management instance uses, they will continue to use that OracleAS Metadata Repository after they have been reassociated to use the new Identity Management instance. If you want, you can change them to use a different OracleAS Metadata Repository after you have finished moving Identity Management. Refer to "Changing the OracleAS Metadata Repository Used by an Applications Tier".
If the Applications tier instances use a separate OracleAS Metadata Repository for product metadata, they will continue to use that OracleAS Metadata Repository after they have changed to the new Identity Management.
This procedure does not take OracleAS Certificate Authority into consideration.
|
See Also: Oracle Application Server Certificate Authority Administrator's Guide for information on updating OracleAS Certificate Authority when changing Identity Management services |
The following is an overview of the procedure for moving Identity Management to a new host:
You have an original Identity Management (also called the Master) used by one or more Applications tier instances. The Identity Management has a OracleAS Metadata Repository. You install and setup a new Identity Management (also called the Replica). This Identity Management has its own OracleAS Metadata Repository. The Oracle Internet Directory in the new Identity Management is an LDAP-based Replica of the original Oracle Internet Directory. Replication takes place constantly from the original Oracle Internet Directory to the new Oracle Internet Directory.
Figure 12-2 shows a sample of this setup.
Figure 12-2 Original Host (Master) and New Host (Replica)
You perform the following steps to change to the new Identity Management. The steps are shown in Figure 12-3.
Step 1: Migrate SSO and DIP data from the original OracleAS Metadata Repository (Master) to the new OracleAS Metadata Repository (Replica)
Step 2: Change the Applications tier instances to use the new OracleAS Metadata Repository.
Step 3: Stop the LDAP-based replication.
Figure 12-3 Changing from Original to New Identity Management
To move Identity Management to a new host, complete the following tasks:
Task 1: Install and Set Up the New Identity Management and OracleAS Metadata Repository
Task 2: Migrate OracleAS Single Sign-On and Directory Integration and Provisioning Data
Task 3: Change Applications Tier Instances to the New Identity Management
Task 1: Install and Set Up the New Identity Management and OracleAS Metadata Repository
In this task, you install and set up the new Identity Management and its associated OracleAS Metadata Repository. The new Identity Management is an LDAP-based replica of the original Identity Management.
Read "About LDAP-based Replicas" to learn about LDAP-based Replicas and how they are used for this procedure.
Follow the procedure in "Installing and Setting Up an LDAP-Based Replica" to install and set up the new Identity Management and OracleAS Metadata Repository.
Stop all Applications tier instances that use Oracle Internet Directory (normally, this means all Applications tier instances). Using the Oracle Collaboration Suite Control, navigate to the Instance Home Page for each Applications tier instance and click Stop All. Be sure to leave Oracle Collaboration Suite Control running.
Task 2: Migrate OracleAS Single Sign-On and Directory Integration and Provisioning Data
In this task, you migrate the OracleAS Single Sign-On and Directory Integration and Provisioning Data from the original OracleAS Metadata Repository to the new OracleAS Metadata Repository. The source for the migration is the original OracleAS Metadata Repository (Master) and the target for the migration is the new OracleAS Metadata Repository (Replica).
This procedure contains the following tasks:
Migrate the Directory Integration and Provisioning Data
|
Note: Make sure theORACLE_HOME and ORACLE_SID environment variables are set before you begin. This applies to all platforms. |
Migrate the OracleAS Single Sign-On Data
To migrate the OracleAS Single Sign-On data:
Obtain the ORASSO schema password on the master:
MASTER_HOME/bin/ldapsearch -p master_oid_port -h master_host -D "cn=orcladmin" -w master_orcladmin_passwd -b "orclresourcename=orasso, orclreferencename=master_global_db_name, cn=ias infrastructure databases, cn=ias, cn=products, cn=oraclecontext" -s base "objectclass=*" orclpasswordattribute
This command prints the ORASSO password in a line like the following:
orclpasswordattribute=LAetjdQ5
Export the OracleAS Single Sign-On data from the master, ensuring that the ORACLE_HOME environment variable is set before you run this command:
MASTER_HOME/sso/bin/ssomig -export -s orasso -p master_orasso_passwd -c master_db_name -log_d $MASTER_HOME/sso/log
master_orasso_passwd is the ORASSO password obtained in the previous step.
Copy the ssomig.dmp and ssoconf.log files from the master to the replica, preserving the exact full path for each file:
cp MASTER_HOME/sso/log/ssomig.dmp REPLICA_HOME/sso/log/ssomig.dmp cp MASTER_HOME/sso/log/ssoconf.log REPLICA_HOME/sso/log/ssoconf.log
Obtain the ORASSO schema password on the replica:
REPLICA_HOME/bin/ldapsearch -p replica_oid_port -h replica_host -D "cn=orcladmin" -w replica_orcladmin_password -b "orclresourcename=orasso, orclreferencename=replica_global_db_name, cn=ias infrastructure databases, cn=ias, cn=products, cn=oraclecontext" -s base "objectclass=*" orclpasswordattribute
Import the OracleAS Single Sign-On data to the replica:
REPLICA_HOME/sso/bin/ssomig -import -overwrite -s orasso -p replica_orasso_passwd -c replica_db_name -log_d $REPLICA_HOME/sso/log -discoforce
replica_orasso_passwd is the ORASSO password obtained in the previous step.
Validation step: Verify that the export and import of OracleAS Single Sign-On succeeded.
Verify that the OracleAS Single Sign-On migration tool reported success. You can also check the following log files for errors:
MASTER_HOME/sso/log/ssomig.log REPLICA_HOME/sso/log/ssomig.log
|
See Also: Oracle Application Server Single Sign-On Administrator's Guide for information on interpreting messages in the log files |
Migrate the Directory Integration and Provisioning Data
To migrate your Directory Integration and Provisioning Data:
|
See Also: Directory Integration and Provisioning Data documentation in the Oracle Internet Directory Administrator's Guide for running the following commands using the HTTPS port in environments in which the Oracle Internet Directory HTTP port is disabled |
Stop the Directory Integration and Provisioning Data server on the master:
MASTER_HOME/bin/oidctl server=odisrv instance=1 stop
Migrate the Directory Integration and Provisioning Data:
MASTER_HOME/bin/dipassistant reassociate -src_ldap_host master_host -src_ldap_port master_oid_port -dst_ldap_host replica_host -dst_ldap_port replica_oid_port -src_ldap_passwd master_orcladmin_passwd -dst_ldap_passwd replica_orcladmin_passwd
This command prints log messages to:
MASTER_HOME/ldap/odi/log/reassociate.log
Stop the Directory Integration and Provisioning Data server on the replica:
REPLICA_HOME/bin/oidctl server=odisrv instance=1 stop
Register the Directory Integration and Provisioning Data server on the replica:
REPLICA_HOME/bin/odisrvreg -D "cn=orcladmin" -w replica_orcladmin_passwd -h replica_host -p replica_oid_port
Start the Directory Integration and Provisioning Data server on the replica:
REPLICA_HOME/bin/oidctl server=odisrv instance=1 flags="port=replica_oid_port" start
Task 3: Change Applications Tier Instances to the New Identity Management
In each Applications tier instance, run the Change Identity Management wizard and restart the instance:
Using the Application Server Control Console, navigate to the Instance Home Page for the Applications tier instance.
Click Infrastructure.
On the Infrastructure Page, in the Identity Management section, click Change.
Follow the steps in the wizard for supplying the new Identity Management information.
Check ORACLE_HOME/ldap/admin/ldap.ora in the Applications tier Oracle home to ensure it now reflects the new Oracle Internet Directory information. Search for the following line:
DIRECTORY_SERVERS = (replica_host:replica_oid_port:replica_ssl_oid_port)
Make sure this line reflects the new information. If it does not, edit it to show the new host and port values.
When the wizard is finished, you must perform an opmnctl reload. Enter the following command from the Applications tier (after setting ORACLE_HOME to the Applications tier home):
ORACLE_HOME/opmn/bin/opmnctl reload
Navigate to the Application Server Home Page and start the Applications tier instance by clicking Start All.
If you have a problem changing the Applications tier instances to the new host, check to make sure replication is running and try again.
Task 4: Stop Replication
Stop the replication between the original Identity Management and the new Identity Management (replica) by running the following command in the new Identity Management Oracle home:
oidctl connect=tns_name server=oidrepld instance=1 flags="-p oid_port" stop
tns_name is the the tnsname of the replica database.
oid_port is the non-SSL Oracle Internet Directory port in the new Identity Management. (This is referred to as replica_oid_port.)
As mentioned in "Sample Uses for this Procedure", you can modify this procedure to perform failover for Identity Management. This enables you to shift to the new Identity Management in case the original becomes unavailable or is lost in some manner.
To perform failover:
Install and set up the new Identity Management as described in Task 1: Install and Set Up the New Identity Management and OracleAS Metadata Repository.
Export SSO and DIP data on a regular basis from the original OracleAS Metadata Repository. You do not need to import the data into the new OracleAS Metadata Repository. You only need to export the data and copy the files to the new OracleAS Metadata Repository Host. Refer to "Task 2: Migrate OracleAS Single Sign-On and Directory Integration and Provisioning Data".
If you lose the original Identity Management:
Stop replication. Refer to Task 4: Stop Replication.
Import your most recent copy of the SSO and DIP data into the new Identity Management repository. Refer to "Task 2: Migrate OracleAS Single Sign-On and Directory Integration and Provisioning Data".
Change the Applications tier instances to use the new Identity Management. Refer to Task 3: Change Applications Tier Instances to the New Identity Management.
This section provides a procedure for changing the OracleAS Metadata Repository used by a Applications tier instance (re-association). This procedure involves making a copy of the original OracleAS Metadata Repository on a different host, and then reassociating the Applications tier instance with the new OracleAS Metadata Repository.
|
Note: You cannot simply change an Applications tier instance from one OracleAS Metadata Repository to another. The new OracleAS Metadata Repository must be a copy of the original, created using the instructions in this procedure. |
The following are sample uses for this procedure:
You have an existing OracleAS Metadata Repository that is used by one or more Applications tier instances. Your organization intends to replace the current OracleAS Metadata Repository host with a new system. You can use this procedure to copy the OracleAS Metadata Repository to the new host and change your Applications tier instances to use the new OracleAS Metadata Repository. You can then retire the original host.
You would like to move a OracleAS Metadata Repository from a host in your test environment, to a host in your Production Environment. You can use this procedure to copy the OracleAS Metadata Repository from the test to production host, and change your test Applications tier instances to use the new OracleAS Metadata Repository.
The Applications tier instances must use Identity Management
That Identity Management must not use the original OracleAS Metadata Repository for its Identity Management schemas; it must use a separate OracleAS Metadata Repository
The original OracleAS Metadata Repository:
Must be used for product metadata and DCM management only (it cannot be used by Identity Management)
Must be registered with Oracle Internet Directory
The new OracleAS Metadata Repository:
Must not be registered with Oracle Internet Directory initially. During the procedure, you will register it with the same Oracle Internet Directory as the original OracleAS Metadata Repository.
Must be created with the same Oracle home, datafile location, SID, and global database name as the original OracleAS Metadata Repository. You will eventually change the global database name to a unique name.
This procedure does not take OracleAS Certificate Authority into consideration.
|
See Also: Oracle Application Server Certificate Authority Administrator's Guide for information on updating OracleAS Certificate Authority when changing OracleAS Metadata Repository services |
If the OracleAS Metadata Repository is used for OracleAS Clusters, the cluster members will not be accessible until all members of the cluster have been reassociated with the new OracleAS Metadata Repository.
The following is an overview of the procedure for changing the OracleAS Metadata Repository used by a Applications tier:
You have an original OracleAS Metadata Repository. It is used by one or more Applications tier instances for product metadata. The Applications tier instances use Identity Management, and the OracleAS Metadata Repository is registered with Oracle Internet Directory in that Identity Management.
Figure 12-4 shows a sample original OracleAS Metadata Repository (asdb1.myco.com).
Figure 12-4 Original OracleAS Metadata Repository
The following table shows sample attributes for the original OracleAS Metadata Repository:
| Attribute | Original OracleAS Metadata Repository | New OracleAS Metadata Repository |
|---|---|---|
| Oracle home | /private/oraHome |
N/A |
| Datafile location | /private/oraHome/oradata |
N/A |
| SID | asdb1 |
N/A |
| Global db name | asdb1.myco.com |
N/A |
| Registered with Oracle Internet Directory? | Yes | N/A |
You create a copy of the original OracleAS Metadata Repository by installing a new OracleAS Metadata Repository, backing up the original OracleAS Metadata Repository, and restoring to the new OracleAS Metadata Repository.
Figure 12-5 shows sample original and new Metadata Repositories.
Figure 12-5 Original OracleAS Metadata Repository and New OracleAS Metadata Repository
The following table shows sample attributes for the original and new Metadata Repositories:
| Attribute | Original OracleAS Metadata Repository | New OracleAS Metadata Repository |
|---|---|---|
| Oracle home | /private/oraHome |
/private/oraHome |
| Datafile location | /private/oraHome/oradata |
/private/oraHome/oradata |
| SID | asdb1 |
asdb1 |
| Global db name | asdb1.myco.com |
asdb1.myco.com |
| Registered with Oracle Internet Directory? | Yes | No |
You perform the following steps to change to the new OracleAS Metadata Repository. The steps are shown in Figure 12-6.
Step 1: Change the global db name of the new OracleAS Metadata Repository to a unique name (in this sample, asdb2.myco.com).
Step 2: Register the new OracleAS Metadata Repository with the same Oracle Internet Directory as the old OracleAS Metadata Repository.
Step 3: Change the Applications tier instances to use the new OracleAS Metadata Repository.
Figure 12-6 Changing from the Original to the New OracleAS Metadata Repository
| Attribute | Original OracleAS Metadata Repository | New OracleAS Metadata Repository |
|---|---|---|
| Oracle home | /private/oraHome |
/private/oraHome |
| Datafile location | /private/oraHome/oradata |
/private/oraHome/oradata |
| SID | asdb1 |
asdb1 |
| Global db name | asdb1.myco.com |
asdb2.myco.com |
| Registered with Oracle Internet Directory? | Yes | Yes |
If you are using the scenario where you no longer require the original OracleAS Metadata Repository, you can discard the original OracleAS Metadata Repository.
This procedure for changing the OracleAS Metadata Repository associated with a Applications tier contains the following tasks:
Task 3: Restore the Backup to the New OracleAS Metadata Repository
Task 4: Configure Ultra Search Metadata in the New OracleAS Metadata Repository
Task 5: Change the Global DB Name for the New OracleAS Metadata Repository
Task 6: Register the New OracleAS Metadata Repository with Oracle Internet Directory
Task 7: Change Applications tier Instances to the New OracleAS Metadata Repository
Before You Begin
If your Applications tier instances use OracleAS Portal and Oracle Ultra Search, you will need to supply the WKSYS schema password later in this procedure in Task 4: Configure Ultra Search Metadata in the New OracleAS Metadata Repository. You should obtain this password now from the old OracleAS Metadata Repository.
Task 1: Install the New OracleAS Metadata Repository
Install the new OracleAS Metadata Repository as follows:
Make sure to install the OracleAS Metadata Repository into an Oracle home that has the same path as the old OracleAS Metadata Repository Oracle home
Use Oracle Universal Installer to install the OracleAS Metadata Repository
Choose to install an Infrastructure
Choose to install a OracleAS Metadata Repository only
Do not register the OracleAS Metadata Repository with Oracle Internet Directory
Specify the same SID and global db name as the old OracleAS Metadata Repository
Specify the same datafile location as the old OracleAS Metadata Repository
Task 2: Back Up the Original OracleAS Metadata Repository
In this task, you create a backup of the original OracleAS Metadata Repository. This task provides the steps for doing this using RMAN, however, if you are an experienced DBA, you can back up the OracleAS Metadata Repository according to your standard practices.
Perform all of the steps in this task on the original OracleAS Metadata Repository host.
Create directories to store backup files and log files. For example:
mkdir -p BACKUP_DIR/log_files mkdir -p BACKUP_DIR/db_files
Make sure the original OracleAS Metadata Repository is up and running.
Make sure you have set the ORACLE_HOME and ORACLE_SID environment variables you run the SQL*Plus command.
Obtain the DBID of the original OracleAS Metadata Repository using SQL*Plus:
SQL> SELECT DBID FROM v$database;
Make note of this value; you will use it later in the procedure.
Create a file that contains the following lines. On UNIX, name the file BACKUP_DIR/cold_backup.rcv; on Windows, BACKUP_DIR\cold_backup.rcv. Substitute the full path for BACKUP_DIR.
On UNIX:
shutdown immediate; startup mount; configure controlfile autobackup on; configure controlfile autobackup format for device type disk to 'BACKUP_DIR/db_files/%F'; run { allocate channel dev1 device type disk format 'BACKUP_DIR/db_files/%U'; backup database plus archivelog; release channel dev1; }
On Windows:
shutdown immediate; startup mount; configure controlfile autobackup on; configure controlfile autobackup format for device type disk to 'BACKUP_DIR\db_files\%F'; run { allocate channel dev1 device type disk format 'BACKUP_DIR\db_files\%U'; backup database plus archivelog; release channel dev1; }
Run RMAN to back up the OracleAS Metadata Repository (the following is a single command; type it all on one line):
On UNIX:
ORACLE_HOME/bin/rman target cmdfile=BACKUP_DIR/cold_backup.rcv > BACKUP_DIR/log_files/backup.log
On Windows:
ORACLE_HOME\bin\rman target [sys]/[syspwd] cmdfile=BACKUP_DIR\cold_backup.rcv > BACKUP_DIR\log_files\backup.log
On Windows, you must supploy the SYS username and password when invoking RMAN.
Copy the backup directories to the new host. You do not need to use the same path for BACKUP_DIR on the new host.
BACKUP_DIR/log_files BACKUP_DIR/db_files
Task 3: Restore the Backup to the New OracleAS Metadata Repository
In this task you restore the backup to the new OracleAS Metadata Repository.
Perform all of the steps in this task on the new OracleAS Metadata Repository host.
Make sure the new OracleAS Metadata Repository is down:
sqlplus "sys/SYS_PASSWORD as sysdba"
SQL> shutdown immediate;
Regenerate the password file:
On UNIX:
prompt> mv ORACLE_HOME/dbs/orapwORACLE_SID ORACLE_HOME/dbs/orapwORACLE_SID.old prompt> ORACLE_HOME/bin/orapwd file=ORACLE_HOME/dbs/orapwORACLE_SID password=new_password
On Windows:
prompt> mv ORACLE_HOME\database\PWDORACLE_SID.ora ORACLE_HOME\database\PWDORACLE_SID.ora.old prompt> ORACLE_HOME\bin\orapwd file=ORACLE_HOME\database\PWDORACLE_SID.ora password=new_password
new_password is the new SYS password. You can use the old SYS password, or set it to a new password.
Start the new OracleAS Metadata Repository but do not mount it:
SQL> startup nomount;
Create a file that contains the following lines. On UNIX, name the file BACKUP_DIR/restore.rcv; on Windows, name it named BACKUP_DIR\restore.rcv. In the file, substitute the full path for BACKUP_DIR and the DBID obtained in the previous task.
On UNIX:
set dbid=DBID; connect target /; set controlfile autobackup format for device type disk to 'BACKUP_DIR/db_files/%F'; restore controlfile from autobackup; startup mount force; run { allocate channel dev1 device type disk format 'BACKUP_DIR/db_files/%U'; restore database; release channel dev1; alter database open resetlogs; }
On Windows:
set dbid=DBID; connect target /; set controlfile autobackup format for device type disk to 'BACKUP_DIR\db_files\%F'; restore controlfile from autobackup; startup mount force; run { allocate channel dev1 device type disk format 'BACKUP_DIR\db_files\%U'; restore database; release channel dev1; alter database open resetlogs; }
Run RMAN to restore the OracleAS Metadata Repository:
On UNIX:
prompt> ORACLE_HOME/bin/rman cmdfile=BACKUP_DIR/restore.rcv > BACKUP_DIR/log_files/restore.log
On Windows:
prompt> ORACLE_HOME\bin\rman cmdfile=BACKUP_DIR\restore.rcv > BACKUP_DIR\log_files\restore.log
After you restore using RMAN, determine if the TEMP tablespace has a datafile by connecting to the database as a use with SYSDBA privileges and running the following command in SQL*Plus:
SQL> select file_name from dba_temp_files where tablespace_name like 'TEMP';
If the preceding command does not return any files, add a datafile:
SQL> alter tablespace "TEMP" add tempfile 'ORACLE_HOME/oradata/ \ db_name/temp01.dbf' size 5120K autoextend on next 8k maxsize unlimited;
Where db_name is the first portion of the new global db name.
Note that the above command creates a file called temp01.dbf and adds it to the TEMP tablespace. If the temp01.dbf file already exists in the directory, add a "reuse" clause to the command:
On UNIX:
SQL> alter tablespace "TEMP" add tempfile 'ORACLE_HOME/oradata/ \ db_name/temp01.dbf' size 5120K reuse autoextend on next 8k maxsize unlimited;
On Windows:
SQL> alter tablespace "TEMP" add tempfile 'ORACLE_HOME\oradata\ \ db_name\temp01.dbf' size 5120K reuse autoextend on next 8k maxsize unlimited;
Task 4: Configure Ultra Search Metadata in the New OracleAS Metadata Repository
Perform this task on the new OracleAS Metadata Repository.
Make sure the ORACLE_HOME and ORACLE_SID environment variables are set.
Run the following commands:
On UNIX:
cd ORACLE_HOME/ultrasearch/admin sqlplus "sys/SYS_PASSWORD as sysdba" SQL> @wk0config.sql WKSYSPW JDBC_CONNSTR LAUNCH_ANYWHERE ""
On Windows:
cd ORACLE_HOME\ultrasearch\admin sqlplus "sys/SYS_PASSWORD as sysdba" SQL> @wk0config.sql WKSYSPW JDBC_CONNSTR LAUNCH_ANYWHERE ""
Where:
WKSYSPW is the password of the WKSYS schema that you obtained at the beginning of this procedure.
JDBC_CONNSTR is the JDBC connection string host:port:SID, for example: myhost:1521:testdb.
LAUNCH_ANYWHERE is TRUE if the OracleAS Metadata Repository is in Real Application Cluster mode, otherwise FALSE. For this procedure, you should set it to FALSE.
Task 5: Change the Global DB Name for the New OracleAS Metadata Repository
In this task, you change the global db name of the new OracleAS Metadata Repository to a new, unique name so you can register it with Oracle Internet Directory.
|
See Also: You can find more information on changing the global db name in article 137483.1 athttp://metalink.oracle.com |
Perform all of the steps in this task on the new OracleAS Metadata Repository host.
Run the following commands to set up the database:
sqlplus "sys/SYS_PASSWORD as sysdba"
SQL> alter system switch logfile;
SQL> alter database backup controlfile to trace resetlogs;
Check the spfile using SQL*Plus:
SQL> select value from v$parameter where name='spfile';
If the previous command returns no rows, you can skip this step.
If the previous command returns output like the following:
VALUE ---------------------------------- ?/dbs/spfile@.ora
run the following command to create a pfile from the spfile:
SQL> create pfile='initORACLE_SID.ora' from spfile;
Where ORACLE_SID is the SID of the original and new OracleAS Metadata Repository.
Shut down the new OracleAS Metadata Repository:
SQL> shutdown immediate;
The database must be shut down with SHUTDOWN NORMAL or SHUTDOWN IMMEDIATE. You should not use SHUTDOWN ABORT.
Rename the spfile so the pfile will be used when the database instance is restarted:
cd ORACLE_HOME/dbs mv spfileORACLE_SID.ora spfileORACLE_SID.ora.save
Edit the following file:
On UNIX:
ORACLE_HOME/dbs/initORACLE_SID.ora
On Windows:
ORACLE_HOME\database\initORACLE_SID.ora
Update the db_name to the new db name (the first portion of the new global db name). For example, if the new global db name is ocsdb1.myco.com, the value of db_name should be ocsdb1. Note that this is not necessarily (nor likely) the same value as the SID on the new OracleAS Metadata Repository.
Rename the following directory with the new db_name:
On UNIX:
ORACLE_HOME/oradata/db_name
On Windows:
ORACLE_HOME\oradata\db_name
Rename the control files so they do not exist later when the new ones are created:
On UNIX:
cd ORACLE_HOME/oradata/db_name mv control01.ctl control01.ctl.old mv control02.ctl control02.ctl.old mv control03.ctl control03.ctl.old
On Windows:
cd ORACLE_HOME\oradata\db_name move control01.ctl control01.ctl.old move control02.ctl control02.ctl.old move control03.ctl control03.ctl.old
Rename the following directory with the new db_name:
On UNIX:
ORACLE_HOME/admin/db_name
On Windows:
ORACLE_HOME\admin\db_name
Edit the following file:
On UNIX:
ORACLE_HOME/admin/db_name/pfile/initORACLE_SID.ora
On Windows:
ORACLE_HOME\admin\db_name\pfile\init.ora
Change all instances of the old db name to the new db name; do not update the SID. To do this, change the old db name in all directory paths and the db_name parameter. Do not update the instance_name parameter, because that is set to the SID.
Change to the trace file directory:
On UNIX:
cd ORACLE_HOME/admin/db_name/udump
On Windows:
cd ORACLE_HOME\admin\db_name\udump
Note that this is the default location for the trace file directory. This location can be overridden by the user_dump_dest parameter in initORACLE_SID.ora or spfileORACLE_SID.ora.
Locate the trace file; it has a name of the form oraNNNNN.trc, where NNNNN is a number. Choose the trace file with the most recent modification date.
Copy the contents of the trace file, starting from the line with "STARTUP NOMOUNT" down to the end of the file, into a new file named BACKUP_DIR/ccf.sql.
Edit BACKUP_DIR/ccf.sql as follows (an example of ccf.sql after performing the edits in this step is shown in Example 12-1.)
Update the following line with the new global db name and change "REUSE" to "SET":
Before modification:
CREATE CONTROLFILE REUSE DATABASE "OLD_GLOBAL_DB_NAME" RESETLOGS ...
After modification:
CREATE CONTROLFILE SET DATABASE "NEW_GLOBAL_DB_NAME" RESETLOGS ...
Remove the following line:
# STANDBY LOGFILE
Comment out the following lines, if they exist, with "REM", as shown:
REM RECOVER DATABASE USING BACKUP CONTROLFILE
REM VARIABLE RECNO NUMBER;
REM EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CONTROLFILE
AUTOBACKUP','ON');
REM VARIABLE RECNO NUMBER;
REM EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CONTROLFILEAUTOBACKUP FORMAT FOR DEVICE TYPE','DISK TO BACKUP_DIR/db_files/%F');
REM ALTER TABLESPACE TEMP ADD TEMPFILE 'ORACLE_HOME/TEMP01.DBF' SIZE 5242880 AUTOEXTEND ON MAXSIZE 4294950912 REUSE;
Change all comment symbols (#) to "REM".
Example 12-1 Example ccf.sql File after Edits
STARTUP NOMOUNT
CREATE CONTROLFILE set DATABASE "<NEW DATABASE>" RESETLOGS ARCHIVELOG
MAXLOGFILES 50
MAXLOGMEMBERS 5
MAXDATAFILES 100
MAXINSTANCES 1
MAXLOGHISTORY 226
LOGFILE
GROUP 1 '/private1/inst/oradata/asdb/redo01.log' SIZE 50M,
GROUP 2 '/private1/inst/oradata/asdb/redo02.log' SIZE 50M,
GROUP 3 '/private1/inst/oradata/asdb/redo03.log' SIZE 50M
DATAFILE
'/private1/inst/oradata/asdb/system01.dbf',
'/private1/inst/oradata/asdb/undotbs01.dbf',
'/private1/inst/oradata/asdb/drsys01.dbf',
'/private1/inst/oradata/asdb/dcm.dbf',
'/private1/inst/oradata/asdb/portal.dbf',
'/private1/inst/oradata/asdb/ptldoc.dbf',
'/private1/inst/oradata/asdb/ptlidx.dbf',
'/private1/inst/oradata/asdb/ptllog.dbf',
'/private1/inst/oradata/asdb/oca.dbf',
'/private1/inst/oradata/asdb/discopltc1.dbf',
'/private1/inst/oradata/asdb/discopltm1.dbf',
'/private1/inst/oradata/asdb/oss_sys01.dbf',
'/private1/inst/oradata/asdb/wcrsys01.dbf',
'/private1/inst/oradata/asdb/uddisys01.dbf',
'/private1/inst/oradata/asdb/ip_dt.dbf',
'/private1/inst/oradata/asdb/ip_rt.dbf',
'/private1/inst/oradata/asdb/ip_idx.dbf',
'/private1/inst/oradata/asdb/ip_lob.dbf',
'/private1/inst/oradata/asdb/attrs1_oid.dbf',
'/private1/inst/oradata/asdb/battrs1_oid.dbf',
'/private1/inst/oradata/asdb/gcats1_oid.dbf',
'/private1/inst/oradata/asdb/gdefault1_oid.dbf',
'/private1/inst/oradata/asdb/svrmg1_oid.dbf',
'/private1/inst/oradata/asdb/ias_meta01.dbf'
CHARACTER SET WE8MSWIN1252
;
REM Configure RMAN configuration record 1
REM VARIABLE RECNO NUMBER;
REM EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CONTROLFILE
AUTOBACKUP','ON');
REM Configure RMAN configuration record 2
REM VARIABLE RECNO NUMBER;
REM EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CONTROLFILE AUTOBACKUP
FORMAT FOR DEVICE TYPE','DISK TO /private1/inst/backup_dir/db_files/%F');
REM Recovery is required if any of the datafiles are restored backups,
REM or if the last shutdown was not normal or immediate.
REM RECOVER DATABASE USING BACKUP CONTROLFILE
REM Database can now be opened zeroing the online logs.
ALTER DATABASE OPEN RESETLOGS;
REM No tempfile entries found to add.
Determine if the TEMP tablespace has a datafile by connecting to the database as a use with SYSDBA privileges and running the following command in SQL*Plus:
SQL> select file_name from dba_temp_files where tablespace_name like 'TEMP';
If the preceding command does not return any files, add a datafile:
On UNIX:
SQL> alter tablespace "TEMP" add tempfile 'ORACLE_HOME/oradata/ \ db_name/temp01.dbf' size 5120K autoextend on next 8k maxsize unlimited;
On Windows:
SQL> alter tablespace "TEMP" add tempfile 'ORACLE_HOME\oradata\ \ db_name\temp01.dbf' size 5120K autoextend on next 8k maxsize unlimited;
Where db_name is the first portion of the new global db name.
Note that this SQL command creates a file called temp01.dbf and adds it to the TEMP tablespace. If the temp01.dbf file already exists in the directory, add a "reuse" clause to the command:
On UNIX:
SQL> alter tablespace "TEMP" add tempfile 'ORACLE_HOME/oradata/ \ db_name/temp01.dbf' size 5120K reuse autoextend on next 8k maxsize unlimited;
On Windows:
SQL> alter tablespace "TEMP" add tempfile 'ORACLE_HOME\oradata\ \ db_name\temp01.dbf' size 5120K reuse autoextend on next 8k maxsize unlimited;
Run the ccf.sql script:
On UNIX:
SQL> @BACKUP_DIR/ccf.sql
On Windows:
SQL> @BACKUP_DIR\ccf.sql
Change the global db name in the database:
SQL> alter database rename global_name to NEW_GLOBAL_DB_NAME;
Update the service name and the global db name to the new global db name in the tnsnames.ora file and listener.ora file:
On UNIX:
ORACLE_HOME/network/admin/tnsnames.ora ORACLE_HOME/network/admin/listener.ora
On Windows:
ORACLE_HOME\network\admin\tnsnames.ora ORACLE_HOME\network\admin\listener.ora
Note that you should not change the SID.
Edit the following file:
On UNIX:
ORACLE_HOME/config/ias.properties
On Windows:
ORACLE_HOME\config\ias.properties
Change the InfrastructureDBCommonName parameter to the new global db name.
Task 6: Register the New OracleAS Metadata Repository with Oracle Internet Directory
In this task, you register the new OracleAS Metadata Repository with the same Oracle Internet Directory used by the original OracleAS Metadata Repository. To do this, you run Oracle Application Server Metadata Repository Creation Assistant (OracleAS Metadata Repository Creation Assistant), a wizard that guides you through the registration.
|
Note: OracleAS Metadata Repository Creation Assistant is available on the "OracleAS Metadata Repository Creation Assistant and Utilities" CD-ROM. |
To register the new OracleAS Metadata Repository with Oracle Internet Directory, start up OracleAS Metadata Repository Creation Assistant on the host where the new OracleAS Metadata Repository is installed:
runRepca -OH ORACLE_HOME -REGISTER
Where ORACLE_HOME is the new OracleAS Metadata Repository Oracle home.
The wizard will guide you through the process.
|
See Also: Oracle Application Server Installation Guide for more information on registering the OracleAS Metadata Repository with Oracle Internet Directory |
Task 7: Change Applications tier Instances to the New OracleAS Metadata Repository
On each Applications tier instance you want to change to the new OracleAS Metadata Repository, run the Change OracleAS Metadata Repository wizard and restart the instance:
Using the Application Server Control Console, navigate to the Instance Home Page for the Applications tier instance.
Make sure all components except Management are down. If not, click the Stop All button to stop them. Note that this will not stop Management.
Click Infrastructure.
On the Infrastructure Page, in the OracleAS Metadata Repository section, click Change.
Follow the steps in the wizard for supplying the new OracleAS Metadata Repository information.
When the wizard is finished, you must perform an opmnctl reload. Enter the following command from the Applications tier (after setting ORACLE_HOME to the Applications tier home):
ORACLE_HOME/opmn/bin/opmnctl reload
Navigate to the Application Server Home Page and start the Applications tier instance by clicking Start All.
Task 8: Update the Farm Name
Run the following command in the Oracle home of one of the Applications tier instances that you changed to use the new OracleAS Metadata Repository in the previous task:
ORACLE_HOME/dcm/bin/dcmctl resetFarmName new_farm_name
Where new_farm_name is the global db name of the new OracleAS Metadata Repository.
|
Note: You only need to run the command in one Applications tier instance. The command will update all other instances. |
This section describes how to install and configure an LDAP-based replica. It contains the following topics:
Oracle Internet Directory replication is the process of copying and maintaining the same data (or naming context) on multiple directory servers. Simply put, replication is a means of having two identical directories that contain the same information. One directory is called the master (or supplier). This directory contains the master copy of the naming context. The other directory is called the replica (or consumer). The master supplies replication updates to the replica, which keeps the master and replica in sync.
There are different types of replicas. This procedure uses an LDAP-based replica, which means the protocol for transferring data between the master and the replica is LDAP.
|
See Also: Oracle Internet Directory Administrator's Guide for more information on directory replication and LDAP-based replicas |
For the purposes of this procedure, the master and replica directories are part of a larger environment that includes the Identity Management installations that contain the directories, and the OracleAS Metadata Repository that support them. This is called the LDAP-based Replica Environment, and it contains the following:
Master—The Identity Management installation containing the Oracle Internet Directory that holds the master copy of the naming context. It supplies replication updates to the replica.
Master Repository—The OracleAS Metadata Repository that the master uses to store its Identity Management schemas.
Replica—The Identity Management installation containing the replicated Oracle Internet Directory.
Replica Repository—The Metadata Repository that the replica uses to store its Identity Management schemas.
Figure 12-7 illustrates the LDAP-based replica environment.
Figure 12-7 LDAP-based Replica Environment
Typically, an LDAP-based replica is used to provide high availability and improved performance for directory users. For the purposes of changing Infrastructure services, the LDAP-based Replica is used as follows:
For "Moving Identity Management to a New Host", the LDAP-based replica is created as a way of moving Identity Management from one host to another. The Master is the original Identity Management installation, and the Replica is the new Identity Management installation. In this case, replication is used to create an identical copy of the original Identity Management on a new host. You can then change your Applications tiers from the old Identity Management (Master) to the new Identity Management (Replica) and discard the Master.
The replica can also be used to move from a test to production environment. The Master is the production Identity Management, and the Replica is the test Identity Management. When you are ready to merge your test environment into your production environment, you can migrate data from your test Identity Management (Replica) to your production Identity Management (Master) and change your Applications tiers from the test Identity Management to the production Identity Management. You can then discard the test Identity Management or continue to use it for testing.
This section describes how to install and set up an LDAP-based replica environment.
You should be aware of these important items before you start the procedure:
This procedure uses a single Infrastructure Oracle home that contains Identity Management and the Metadata Repository. However, it is fine to split the Infrastructure installation so Identity Management is in one Oracle home and the Metadata Repository is in another Oracle home. You can also distribute the Identity Management components (OracleAS Single Sign-On, Oracle Internet Directory, Delegated Administration Services, Directory Integration and Provisioning) across different hosts. If you do this, perform the operations on each component in their respective Oracle homes.
The replica always uses port 389 for the non-SSL Oracle Internet Directory port, and 636 for the SSL Oracle Internet Directory port, regardless of what is reported by Oracle Universal Installer, or printed in ORACLE_HOME/install/portlist.ini. Make sure no other processes are using ports 389 and 636 on the replica host before you start the procedure.
Make sure you use the ldapsearch and ldapmodify commands that are in ORACLE_HOME/bin. (Some operating systems ship their own version of these commands—do not use those.)
These procedures use the remtool and oidpasswd commands. The messages returned by these commands are in UTF-8 encoding and are unreadable in most non-English environments. To work around this, set the NLS_LANG environment variable to american_america.character_set before running these commands. Most character sets (for example, US7ASCII) will work.
Make sure the ORACLE_HOME and ORACLE_SID environment variables are set. This applies to all platforms.
This section contains the procedure for setting up an LDAP-based replica. It contains the following tasks:
Task 1: Obtain the Master and Master Repository
Most likely, you already have your Master and Master Repository. The Master and Master Repository are the installations you would like to move to a new host, and the LDAP-based replica will be the relocated installations.
If you are starting from scratch, you can install a Master and Master Repository as follows:
Install Oracle Collaboration Suite using Oracle Universal Installer.
Choose the Infrastructure Installation.
Choose to install Identity Management and OracleAS Metadata Repository.
Choose to configure the following components: Oracle Internet Directory, OracleAS Single Sign-On, Delegated Administration Services, and Directory Integration and Provisioning.
Task 2: Install Applications Tier Instances (Optional)
Most likely, you already have Applications tier instances using the Master for Identity Management services. This is fine, and, if desired, you can install and configure additional instances to use the Master now, or at the end of this procedure after you have configured the replica, or both.
These Applications tier instances can use the Master Repository for their product metadata, or they can use a different repository.
Task 3: Install and Configure the Replica
You can install and configure the Replica using Oracle Universal Installer. Be sure to install the Replica on a different host than the Master.
|
See Also: Oracle Collaboration Suite Installation Guide for Solaris Operating System or Oracle Collaboration Suite Installation Guide for Microsoft Windows for information on installing an Oracle Internet Directory replica |
When the installation has finished, replication is configured and all components are up and running. You can return to the main procedure.
As part of the re-association process, Applications tier applications which are affected may need to be configured to use the Collaboration Suite Database instance on a different Infrastructure. The procedure for setup and reconfiguration varies for each type of Oracle Collaboration Suite application.
This section includes the following topic:
For Oracle Collaboration Suite, Oracle Calendar uses the Collaboration Suite Database component to store some of its data. Which Collaboration Suite Database is used by Calendar is determined when Calendar is first deployed. The re-association process described in this section allows you to change the Collaboration Suite Database component that Calendar uses from one physical instance to another. There will not be any data loss and the Calendar will work as it did with the original Collaboration Suite Database.
You must meet the following requirements before Calendar can be re-associated to the new Collaboration Suite Database:
The version of the target Collaboration Suite Database must be the same or greater than the original Collaboration Suite Database
The target Collaboration Suite Database must be registered to the same Infrastructure as Calendar.
To reassociate Calendar to a different Infrastructure instance, follow the procedure described in "Changing the OracleAS Metadata Repository Used by an Applications Tier".
To reassociate Calendar with a new Infrastructure instance, you invoke a java class on the Calendar Applications tier installation.
The java jar file is found in $ORACLE_HOME/ocal/jlib/ocal_clnt.jar
The java class is oracle.calendar.server.configuration.InitStorage
Usage: InitStorage -oh oraclehome -reassociate -sourcedatabase <source dbname> -sysp <sys password>-targetdatabase <target dbname> -D binddn -w bindpassword -oh <ORACLE_HOME path> -reassociate -sourcedatabase <Source DB Global Name> -targetdatabase <Target DB Global Name> -sysp <SYS password on source database> -D <OID Credentials> -w <OID credentials password>
In the following example, Example 12-2, the original Collaboration Suite Database is asdb.host1.domain.com and the target Collaboration Suite Database is asdb.host2.domain.com. The Oracle Internet Directory login is cn=orcladmin and the Oracle Internet Directory password is welcome1.
Example 12-2 Reassociating Calendar with a new Collaboration Suite Database
$ORACLE_HOME/jre/java -classpath $ORACLE_HOME/ocal/jlib/ocal_clnt.jar:$ORACLE_HOME/ldap/jlib/ldapjclnt10.jar:$ORACLE_HOME/jlib/ojmisc.jar:$ORACLE_HOME/jdbc/lib/classes12.jar:$ORACLE_HOME/jdbc/lib/nls_charset12.jar:$ORACLE_HOME/rdbms/jlib/aqapi.jar oracle.calendar.server.configuration.InitStorage -oh $ORACLE_HOME -reassociate -sourcedatabase asdb.host1.domain.com -sysp welcome1 -targetdatabase asdb.host2.domain.com -D cn=orcladmin -w welcome1
