| Oracle® Application Server Administrator's Guide 10g Release 2 (10.1.2) B13995-08 |
|
 Previous |
 Next |
| Oracle® Application Server Administrator's Guide 10g Release 2 (10.1.2) B13995-08 |
|
Previous |
Next |
This chapter describes copying a 9.0.4.x or 10.1.2.0.x production environment that includes a middle-tier instance, Identity Management with a Metadata Repository, and a product Metadata Repository for OracleAS Portal and OracleBI Discoverer metadata to a test environment. The Identity Management and the product metadata can share the same Metadata Repository, or they each use a dedicated Metadata Repository. You use this procedure for the purpose of:
Periodically taking a snapshot of the production environment
Testing an upgrade to 10.1.2.0.2
Testing to apply a patchset
If you need to only create additional middle-tier nodes, perform the procedures in Chapter 10 instead.
This chapter contains the following topics:
In this configuration, you have an existing production environment that includes a middle-tier instance, an Identity Management installation with a Metadata Repository, a product Metadata Repository for OracleAS Portal and OracleBI Discoverer metadata, and customer database. You would like to create a copy of this production environment on the test environment.
For this configuration, you create a test environment by installing and subsequently moving production data for the Identity Management and product Metadata Repository. You then install a test middle-tier instance and deploy applications to this instance. You use the existing customer database, importing the OracleBI Discoverer data.
Figure 11-1 shows this configuration.
Figure 11-1 Creating a Test Environment from a Production Environment and Copying Metadata
This use case assumes the following configuration:
The production environment includes a middle-tier instance, an Identity Management installation with a Metadata Repository, and an additional Metadata Repository for (OracleAS Portal and OracleBI Discoverer) product metadata. This procedure also applies to configurations in which both Identity Management and product metadata share the same Metadata Repository.
The production environment accesses a customer database that contains OracleBI Discoverer End User Layers (EULs).
The production environment is configured with release 9.0.4.x or 10.1.2.0.x.
The new test environment has not been created.
This procedure contains the following tasks:
Task 4: Copy Data from Production Identity Management to the Test Environment
Task 5: Copy Data from the Production Product Metadata Repository to the Test Environment
In the procedures, INFRA_HOME references the Oracle home of OracleAS Infrastructure, and MIDTIER_HOME references the Oracle home of Oracle Application Server.
|
See Also: Oracle Identity Management User Reference for more information about the Oracle Internet Directory management tools mentioned in this procedure, includingldapaddmt, ldapmodify, ldapsearch, ldifwrite, bulkload, and bulkdelete |
|
Note: To run the Oracle Internet Directory management tools on Windows operating systems, you need one of the following UNIX emulation utilities:
|
|
Note: Before running any of the Oracle Internet Directory management tools mentioned throughout this procedure, you must set theNLS_LANG environment variable before running the directory command.
To determine the character set, run the following query from SQL*Plus as the SQL> SELECT userenv('language') from dual;
The output looks similar to the following: USERENV('LANGUAGE')
----------------------------------------------------
AMERICAN_AMERICA.WE8MSWIN1252
To set the setenv NLS_LANG AMERICAN_AMERICA.WE8MSWIN1252 |
Prerequisite Export Steps
To obtain information and export data from the production environment prior to setting up the test environment:
Collect the information needed to access the production environment:
Operating system login credentials to computer on which the Metadata Repositories reside
Operating system login credentials and Oracle home location of the middle-tier computer and location of the Oracle home
Oracle Internet Directory connection information, including the host name, port, and administration DN and password
ODS schema password. Use the following command from the Identity Management Metadata Repository repository, not the product Metadata Repository:
PRODUCTION_INFRA_HOME/bin/ldapsearch -h production_oid_host -p production_oid_port -D cn=orcladmin -w production_orcladmin_passwd -b "orclreferencename=metadata_rep_global_db_name, cn=IAS Infrastructure Databases, cn=ias, cn=products, cn=oracleContext" -s base "orclresourcename=ods" orclpasswordattribute
In the syntax:
production_oid_host is the host of the production directory server.
production_oid_port is the LDAP port of the production directory server.
production_orcladmin_password is the password of the superuser DN (cn=orcladmin).
metadata_rep_global_db_name is the service name of the production directory Metadata Repository.
PORTAL schema password. Use the following command:
PRODUCTION_INFRA_HOME/bin/ldapsearch -h production_oid_host -p production_oid_port -D cn=orcladmin -w production_orcladmin_passwd -b "orclreferencename=metadata_rep_global_db_name, cn=IAS Infrastructure Databases, cn=ias, cn=products, cn=oracleContext" -s one "orclresourcename=portal" orclpasswordattribute
ORASSO schema password. Use the following command:
PRODUCTION_INFRA_HOME/bin/ldapsearch -h production_oid_host -p production_oid_port -D cn=orcladmin -w production_orcladmin_passwd -b "orclreferencename=metadata_rep_global_db_name, cn=IAS Infrastructure Databases, cn=ias, cn=products, cn=oracleContext" -s one "orclresourcename=orasso" orclpasswordattribute
Export data from the production Oracle Internet Directory:
Query the production directory server to find the default realm:
PRODUCTION_INFRA_HOME/bin/ldapsearch -h production_oid_host -p production_oid_port -D cn=orcladmin -w production_orcladmin_passwd -b "cn=common, cn=products, cn=oracleContext" -s base "objectclass=*" orcldefaultSubscriber
The response returns the orcldefaultSubscriber in LDIF format:
cn=Common,cn=Products,cn=OracleContext orcldefaultsubscriber=dc=us,dc=company,dc=com
You will need this information later when you install the test Identity Management.
Query the production directory server to determine the configured user search bases and group search bases:
PRODUCTION_INFRA_HOME/bin/ldapsearch -L -h production_oid_host -p production_oid_port -D cn=orcladmin -w production_orcladmin_passwd -b "cn=common, cn=products, cn=OracleContext, orcldefaultsubscriber" -s base "objectclass=*" orclCommonUserSearchBase orclCommonGroupSearchBase orclCommonNicknameattribute > /tmp/OracleContext.ldif
In the syntax, orcldefaultsubscriber is the orcldefaultsubscriber value returned in Step 2a of this procedure.
The response looks similar to the following:
dn: cn=Common,cn=Products,cn=OracleContext,dc=us,dc=company,dc=com orclcommonusersearchbase: cn=users,dc=us,dc=company,dc=com orclcommongroupsearchbase: cn=Groups,dc=us,dc=company,dc=com orclcommonnicknameattribute: uid
Export all users from the production directory server:
PRODUCTION_INFRA_HOME/bin/ldifwrite -c production_oid_net_service_name -b "orclcommonusersearchbase" -f /tmp/user.ldif
In the syntax:
production_oid_net_service_name specifies the net service name for the production directory, as defined in the tnsnames.ora file.
orclcommonusersearchbase is the orclcommonusersearchbase subtree written out in LDIF format, such as cn=users,dc=us, dc=company,dc=com.
When prompted for the directory password, enter the password of the ODS user. This password defaults to the password assigned for administrator ias_admin during installation. You should run the ldifwrite command once for each user search base value (orclcommonusersearchbase) from the Oracle Context settings query.
Export all groups from the production directory server:
PRODUCTION_INFRA_HOME/bin/ldifwrite -c production_oid_net_service_name -b "orclcommongroupsearchbase" -f /tmp/group.ldif
In the syntax, orclcommongroupsearchbase is the orclcommongroupsearchbase subtree written out in LDIF format, such as cn=Groups,dc=us, dc=company,dc=com.
When prompted for the directory password, enter the password of the ODS user. This password defaults to the password assigned for administrator ias_admin during installation. You should run the ldifwrite command once for each group search base value (orclcommongroupsearchbase) from the Oracle Context settings query.
Save the Delegated Administration Services administrative groups subtree from the production directory server:
PRODUCTION_INFRA_HOME/bin/ldifwrite -c production_oid_net_service_name -b "cn=groups, cn=OracleContext, orcldefaultsubscriber" -f /tmp/dasAdminGroups.ldif
In the syntax, orcldefaultsubscriber is the orcldefaultsubscriber value returned in Step 2a of this procedure.
Copy the password policy configuration entry, and append the entry with the following ldapsearch commands:
PRODUCTION_INFRA_HOME/bin/ldapsearch -L -h production_oid_host -p production_oid_port -D cn=orcladmin -w production_orcladmin_passwd -b "cn=PwdPolicyEntry, cn=common, cn=products, cn=OracleContext" -s base "objectclass=*" >> /tmp/pwdPolicy.ldif
PRODUCTION_INFRA_HOME/bin/ldapsearch -L -h production_oid_host -p production_oid_port -D cn=orcladmin -w production_orcladmin_passwd -b "cn=PwdPolicyEntry, cn=common, cn=products, cn=OracleContext, orcldefaultsubscriber" -s base "objectclass=*" >> /tmp/pwdPolicy.ldif
Prepare the product Metadata Repository in the production environment for export:
List the schemas to be exported:
It is necessary to identify all of the schemas that need to be exported, including the PORTAL and related schemas, the DISCOVERER5 schema, and any schemas used for database providers or OracleAS Portal Portlet Builder components.
To list all the schemas, run the following query from SQL*Plus in the PORTAL schema:
SET LINESIZE 132 SELECT USERNAME, DEFAULT_TABLESPACE, TEMPORARY_TABLESPACE FROM DBA_USERS WHERE USERNAME IN (user, user||'_PUBLIC', user||'_DEMO', user||'_APP', 'DISCOVERER5') OR USERNAME IN (SELECT DISTINCT OWNER FROM WWAPP_APPLICATION$ WHERE NAME != 'WWV_SYSTEM') ORDER BY USERNAME;
The response looks similar to the following output:
USERNAME DEFAULT_TABLESPACE TEMPORARY_TABLESPACE --------------------------------------------------------------------------- ARUN USERS TEMP DISCOVERER5 DISCO_PTM5_META DISCO_PTM5_TEMP PORTAL PORTAL PORTAL_TMP PORTAL_APP PORTAL PORTAL_TMP PORTAL_DEMO PORTAL PORTAL_TMP PORTAL_PUBLIC PORTAL PORTAL_TMP SCOTT SYSTEM TEMP TESTER_DAT SYSTEM TEMP TESTER_SCH SYSTEM TEMP UPG_SCHEMA USERS TEMP UPG_SCHEMDB USERS TEMP 10 rows selected
This command will only list schemas that are directly related to database providers or Portlet Builder components registered in the OracleAS Portal. If any of these schemas additionally reference objects in other schemas, then add them to the list of schemas to be exported.
List the tablespaces used.
It is necessary to ensure that the tablespaces on the target databases match the ones used in the source. To list the tablespaces used in the source database, run the following query from SQL*Plus as the PORTAL user:
SQL> SELECT DISTINCT TABLESPACE_NAME FROM DBA_SEGMENTS WHERE OWNER IN (schema_list) UNION SELECT DISTINCT DEFAULT_TABLESPACE FROM DBA_USERS WHERE USERNAME IN (schema_list) / SELECT DISTINCT TEMPORARY_TABLESPACE FROM DBA_USERS WHERE USERNAME IN (schema_list) /
where schema_list contains the schemas generated from Step 3a of this procedure.
The query and response looks similar to the following output:
SQL> SELECT DISTINCT TABLESPACE_NAME FROM DBA_SEGMENTS WHERE OWNER IN
2 ('ARUN','PORTAL','DISCOVERER5','PORTAL_APP','PORTAL_DEMO','PORTAL_PUBLIC','SCOTT',
3 'TESTER_DAT','TESTER_SCH','UPG_SCHEMA','UPG_SCHEMDB','FLIGHTS','PROV9022')
4 UNION
5 SELECT DISTINCT DEFAULT_TABLESPACE FROM DBA_USERS WHERE USERNAME IN
6 ('ARUN','PORTAL', 'DISCOVERER5','PORTAL_APP','PORTAL_DEMO','PORTAL_PUBLIC','SCOTT',
7 'TESTER_DAT','TESTER_SCH','UPG_SCHEMA','UPG_SCHEMDB','FLIGHTS','PROV9022');
TABLESPACE_NAME
------------------------------
INDX
DISCO_PTM5_CACHE
DISCO_PTM5_META
PORTAL
PORTAL_DOC
PORTAL_IDX
PORTAL_LOG
SYSTEM
USERS
7 rows selected.
SQL> SELECT DISTINCT TEMPORARY_TABLESPACE FROM DBA_USERS WHERE USERNAME IN ('ARUN','PORTAL','PORTAL_APP','PORTAL_DEMO','PORTAL_PUBLIC','SCOTT','TESTER_DAT','TESTER_SCH','UPG_SCHEMA','UPG_SCHEMDB','FLIGHTS','PROV9022');
TEMPORARY_TABLESPACE
------------------------------
DISCO_PTM5_TEMP
PORTAL_TMP
TEMP
List schemas that have snapshots created in them.
It is necessary to identify the schemas that have snapshots created in them, run the following query from SQL*Plus as the SYS user:
SQL> SELECT OWNER, NAME FROM DBA_SNAPSHOTS WHERE OWNER IN (schema_list);
where schema_list contains the schemas generated from Step 3a of this procedure.
The query and response looks similar to the following output:
SQL> SELECT OWNER, NAME FROM DBA_SNAPSHOTS
2 WHERE OWNER IN ('ARUN','DISCOVERER5','PORTAL','PORTAL_APP','PORTAL_DEMO','PORTAL_PUBLIC','SCOTT','TESTER_DAT','TESTER_SCH','UPG_SCHEMA','UPG_SCHEMDB');
OWNER NAME
------------------------------ ------------------------------
PORTAL_DEMO EMP_SNAPSHOT
SCOTT EMP_SNAPSHOT
Determine the character set of the production database with the following query from SQL*Plus as the SYS user:
SQL> SELECT userenv('language') from dual;
The output looks similar to the following:
USERENV('LANGUAGE')
----------------------------------------------------
AMERICAN_AMERICA.WE8MSWIN1252
Set the NLS_LANG environment variable before performing the database export:
setenv NLS_LANG AMERICAN_AMERICA.WE8MSWIN1252
Prior to exporting data, run the CATEXP.SQL script from the PRODUCTION_INFRA_HOME/rdbms/admin directory with SYSDBA privileges:
SQL> CONNECT SYS/password AS SYSDBA
@catexp.sql
This script creates the data dictionary and public synonyms for many of its views.
Export data from the product Metadata Repository in the production environment:
Stop all processes managed by OPMN:
PRODUCTION_INFRA_HOME/opmn/bin/opmnctl stopall
Run the Export utility:
The actual export is done with the database exp command as follows, with the example showing just the four core OracleAS Portal schemas. Include any other schemas identified in the SELECT statement from Step 3a of this procedure as well.
PRODUCTION_INFRA_HOME/bin/exp 'sys/password@instance AS SYSDBA' file=/tmp/portal_exp.dmp grants=y statistics=none log=/tmp/portal_exp.log owner=portal,portal_app,portal_demo,portal_public
For UNIX operating systems, you must precede the quotation marks with an escape character, such as the backslash (\).
Start all the processes managed by OPMN:
PRODUCTION_INFRA_HOME/opmn/bin/opmnctl startall
Export OracleAS Single Sign-On External Applications data from the production Identity Management.
This step exports any external applications and password store data. Extract the OracleAS Single Sign-On data with the ssomig utility as follows:
PRODUCTION_INFRA_HOME/sso/bin/ssomig -s orasso -p orasso_password -c production_sso_net_service_name -log_d /tmp -export -log_f ssomig.log -d ssomig.dmp
The response looks similar to the following output:
SSO Migration Tool: Release 10.1.2.0.2 - Production on Fri Feb 25 16:15:19 2005 Copyright (c) 2002-2005 Oracle. All rights reserved. Verifying SSO schema information... Data export started at Fri Feb 25 16:15:22 2005 Log Directory : /tmp Log File Name : /tmp/ssomig.log Export File Name : /tmp/ssomig.dmp SSO Schema Name : orasso SSO Schema Password : ****** Connect String : asdbupg Copying data...Done Exporting data...Done Creating configuration file...Done Exported Dump File: /tmp/ssomig.dmp Configuration File: /tmp/ssoconf.log Data Export Complete
If your production environment includes OracleBI Discoverer, export EUL data:
For each EUL in the customer database, create a copy using the following command from the production environment:
PRODUCTION_MIDTIER_HOME/bin/eulapi - connect old_eul_owner/password@database_service_name -export /tmp/file1.eex -all -log /tmp/exp.log
If you intend to copy data to another customer database in the test environment, use the service name of the test database for database_service_name.
|
Note: Theeulapi utility does not exist on Windows in releases 9.0.4.x and 10.1.2.0.x. For environments supporting these releases, download the patches for this utility. The related Automated Release Updates (ARU) number for 9.0.4.x is ARU 7462620 and 10.1.2.0.x is ARU 7462623.
You can download these patches from OracleMetalink: |
Task 1: Install Test Identity Management
Install and set up the test Identity Management and its associated Metadata Repository. You can install these OracleAS Infrastructure components on the same computer or on separate computers.
To install the test Identity Management:
Identify the character set in use on the database of the production Identity Management.
Run the following query from SQL*Plus as the SYS user:
SQL> SELECT userenv('language') from dual;
The output looks similar to the following:
USERENV('LANGUAGE')
----------------------------------------------------
AMERICAN_AMERICA.WE8MSWIN1252
List the ports used on the production database (optional) in order to use the same port numbers on the copy.
Install Oracle Application Server using Oracle Universal Installer.
From the Select a Product to Install screen, select OracleAS Infrastructure.
From the Select Installation Type screen, select the appropriate option for how you want the Identity Management pieces installed:
To install test Identity Management and its associated Metadata Repository on the same computer, select Identity Management and OracleAS Metadata Repository.
To install test Identity Management and its associated Metadata Repository on separate computers, first select the OracleAS Metadata Repository option for one of the computers, and then select the OracleAS Identity Management option for the other computer.
When you are prompted with the Specify Namespace in Internet Directory screen, enter the value of the orcldefaultsubscriber obtained from the query of the production Oracle Internet Directory server in Step 2a of "Prerequisite Export Steps".
Create the database using the same character set as the production instance that you are copying to avoid any character set conversion issues. You do not have to specify the same port numbers, but it can help simplify the configuration.
Perform a backup of the test Identity Management configuration files and Metadata Repository with the OracleAS Backup and Recovery Tool. See Chapter 20.
Task 2: Set Up Test Product Metadata Repository
To install and set up the test product Metadata Repository:
Identify the character set in use on the production database, as described in Step 3d of "Prerequisite Export Steps".
Optionally, list the ports used on the production database in order to use the same port numbers on the copy.
Install OracleAS Infrastructure and Metadata Repository.
Install Oracle Application Server using Oracle Universal Installer.
From the Select a Product to Install screen, select OracleAS Infrastructure.
From the Select Installation Type screen, select Metadata Repository.
Create the database using the same character set as the production instance that you are copying to avoid any character set conversion issues. Also, specify the same ports to use, if you want more fidelity. This should not affect the upgrade testing though, even if using different port numbers in the copy.
Perform a backup of the Metadata Repository database installed with the infrastructure to make is easier to do import iterations in case of upgrade errors. See Chapter 20.
Task 3: Install the Test Middle Tier
To install the test middle-tier instances and configure them to use the test Identity Management according to what you want to test:
Install Oracle Application Server using Oracle Universal Installer.
From the Select a Product to Install screen, choose the Portal and Wireless middle for environments with OracleAS Portal or the Business Intelligence and Forms for environments with OracleBI Discoverer.
Apply any required patches to bring the test system up to the same patch-level release as the production system.
For patches associated with a release, use the Oracle Universal Installer on the production system to determine applied patches. For patches not associated with a release, use the following command to determine applied patches:
ORACLE_HOME/OPatch/opatch lsinventory -detail
Perform a backup of the test middle tier, product Metadata Repository, Identity Management configuration files, and Identity Management Metadata Repository with the OracleAS Backup and Recovery Tool. See Chapter 20.
For 10.1.2.0.x environments in which both the production and test environments are running on the same operating system, you can either perform a middle-tier installation or clone the production middle-tier instance. To clone the production middle-tier instance, perform tasks in procedure Section 10.4, "Cloning Oracle Application Server Instances".
Task 4: Copy Data from Production Identity Management to the Test Environment
To copy Identity Management data to the test environment:
Prior to importing users and groups to the test directory server, use the bulkdelete command to remove the existing default users, groups containers, and Delegated Administration Services administrative groups subtree from the test directory server.
Run the following ldapsearch commands to obtain the values:
TEST_INFRA_HOME/bin/ldapsearch -h test_oid_host -p test_oid_port -b "cn=users, orcldefaultsubscriber" -s base "objectclass=*"
TEST_INFRA_HOME/bin/ldapsearch -h test_oid_host -p test_oid_port -b "cn=groups, orcldefaultsubscriber" -s base "objectclass=*"
TEST_INFRA_HOME/bin/ldapsearch -h test_oid_host -p test_oid_port -b "cn=groups, cn-OracleContext,orcldefaultsubscriber" -s base "objectclass=*"
In the syntax, orcldefaultsubscriber is the orcldefaultsubscriber value returned from Step 2a of "Prerequisite Export Steps".
Stop the directory server with the following command:
TEST_INFRA_HOME/opmn/bin/opmnctl stopproc ias-component=OID
Run the following bulkdelete commands:
TEST_INFRA_HOME/ldap/bin/bulkdelete.sh -connect test_oid_net_service_name -base "cn=users, orcldefaultsubscriber"
TEST_INFRA_HOME/ldap/bin/bulkdelete.sh -connect test_oid_net_service_name -base "cn=groups, orcldefaultsubscriber"
TEST_INFRA_HOME/ldap/bin/bulkdelete.sh -connect test_oid_net_service_name -base "cn=groups, cn=OracleContext, orcldefaultsubscriber"
In the syntax, test_oid_net_service_name specifies the net service name for the test directory, as defined in the tnsnames.ora file.
You will be prompted to provide the password to the ODS schema to complete these commands.
Run the same ldapsearch commands in Step 1a of this procedure to ensure the values are removed.
Use the bulkload utility to load users from the user.ldif file you created in Step 2c of "Prerequisite Export Steps":
Start the directory server with the following command:
TEST_INFRA_HOME/opmn/bin/opmnctl startproc ias-component=OID
To run the bulkload utility, set the directory server mode to read/modify:
From Oracle Directory Manager, navigate to the server entry (the main node under the Oracle Internet Directory Servers), and change the Server Mode attribute from Read/Write to Read/Modify from the drop-down list.
If you prefer to use the LDAP command line utilities, use the ldapmodify command:
ldapmodify -h test_oid_host -p test_oid_port -D cn=orcladmin -w test_orcladmin_pwd -v -f rm.ldif
where rm.ldif is a file you create, with the following contents:
dn: changetype: modify replace: orclservermode orclservermode: rm
After changing the server mode, you need to stop the Oracle Internet Directory processes:
TEST_INFRA_HOME/opmn/bin/opmnctl stopproc ias-component=OID
If the production Identity Management has been upgraded from release 9.0.2.x to 9.0.4.x, remove the entries starting with orclactivestartdate from the user.ldif file. If these entries are not removed, the bulkload utility will fail.
Load users into the test Oracle Internet Directory by using the bulkload utility to load the LDIF file generated from the production system. You created this file in Step 2c of "Prerequisite Export Steps". When invoking the bulkload utility, be sure to specify the absolute path of the LDIF file, even if it is in the current directory.
TEST_INFRA_HOME/ldap/bin/bulkload.sh -connect test_oid_net_service_name -check –generate -restore -load –append /tmp/user.ldif
When invoking the bulkload utility, be sure to specify the absolute path of the LDIF file, even if it is in the current directory.
The response looks similar to the following output:
Verifying node "orcl" ----------------------------- This tool can only be executed if you know database user password for OiD on orcl Enter OiD password ::
Provide the password for the schema used by Oracle Internet Directory. This defaults to the password assigned for the ias_admin administrator during installation.
This command loads all the users, provided there is no error reported in the check mode on the exported LDIF file.
Start the directory server with the following command:
TEST_INFRA_HOME/opmn/bin/opmnctl startproc ias-component=OID
Move the pwdPolicy.ldif file you created in Step 2f of "Prerequisite Export Steps" to the test environment and stop the directory server with the following commands:
TEST_INFRA_HOME/bin/ldapaddmt -h test_oid_host -p test_oid_port -D cn=orcladmin -w test_orcladmin_passwd -v -f /tmp/pwdPolicy.ldif TEST_INFRA_HOME/opmn/bin/opmnctl stopproc ias-component=OID
Ensure the password policy in the default subscriber matches that of the production environment. Perform the same ldapsearch command you performed in Step 2f of "Prerequisite Export Steps" in the test environment.
Use the bulkload utility to load groups from the group.ldif file you created in Step 2d of "Prerequisite Export Steps".
TEST_INFRA_HOME/ldap/bin/bulkload.sh -connect test_oid_net_service_name -check -generate -restore -load –append /tmp/group.ldif
When invoking the bulkload utility, be sure to specify the absolute path of the LDIF file, even if it is in the current directory.
This command loads all the groups, provided there is no error reported in the check mode on the exported LDIF file.
Load the administrative groups subtree saved from production in Step 2e of "Prerequisite Export Steps" into the test environment.
TEST_INFRA_HOME/ldap/bin/bulkload.sh -connect test_oid_net_service_name -check -generate -restore -load -append /tmp/dasAdminGroups.ldif
Perform the same ldifwrite command you performed in Step 2e of "Prerequisite Export Steps" in the test environment to ensure the value has been correctly updated.
Start the test directory server and other Identity Management components:
cd TEST_INFRA_HOME/opmn/bin
opmnctl startall
opmnctl: starting opmn and all managed processes...
After performing the bulkload commands, restore the server mode of the directory server to the normal setting:
ldapmodify -h test_oid_host -p test_oid_port -D cn=orcladmin -w test_orcladmin_pwd -v -f rw.ldif
where rw.ldif is a file you create, with the following contents:
dn: changetype: modify replace: orclservermode orclservermode: rw
If you use Oracle Directory Manager instead, change the Server Mode attribute of the server entry back to Read/Write
On the test directory server, configure Oracle Context parameters:
In Step 2b of "Prerequisite Export Steps", you created an /tmp/OracleContext.ldif file containing the configured user and group search bases. Edit this file as follows:
- Use the respective output values for value returned in Step 2b.
- OrclCommonUserSearchBase might contain only one value.
dn: value Changetype: modify replace: orclCommonUserSearchBase OrclCommonUserSearchBase: value1 OrclCommonUserSearchBase: value2 - replace: orclCommonGroupSearchBase OrclCommonGroupSearchBase: value1 OrclCommonGroupSearchBase: value2 - replace: orclCommonNickNameattribute orclCommonNickNameattribute: value
Configure the user and group search base on the test directory server:
TEST_INFRA_HOME/bin/ldapmodify –D cn=orcladmin –w orcladmin_password -h test_oid_host -p test_oid_port -v -f /tmp/OracleContext.ldif
Perform the same ldapsearch command you performed in Step 2b of "Prerequisite Export Steps" in the test environment to ensure the value has been correctly updated.
Change the value of the orclcommonnicknameattribute:
Run the ldapsearch command to see the test nickname attribute:
TEST_INFRA_HOME/bin/ldapsearch -h test_oid_host -p test_oid_port -D cn=orcladmin -w test_orcladmin_passwd -b cn=common, cn=products, cn=OracleContext, orcldefaultsubscriber" -s base "objectclass=*" orclcommonnicknameattribute
The response returns the orclcommonnicknameattribute value:
orclcommonnicknameattribute: uid
Compare this value with the production nickname attribute, obtained in Step 2b of "Prerequisite Export Steps".
For instances which have been upgraded from 9.0.2.x to 9.0.4.x, the production nickname attribute may not be set to orclcommonnicknameattribute=cn. For these instances, you need to update the test directory server with this value.
You can navigate to that entry from Oracle Directory Manager and change its value.
If you prefer to use the LDAP command line utilities, use the ldapmodify command:
ldapmodify -h test_oid_host -p test_oid_port -D cn=orcladmin -w test_orcladmin_pwd -f nickname.ldif
where nickname.ldif is a file you create, with the following contents:
dn: cn=Common,cn=Products,cn=OracleContext,dc=us,dc=company,dc=com changetype: modify replace: orclcommonnicknameattribute orclcommonnicknameattribute: cn
Perform Step 8a of this procedure to ensure the value of orclcommonnicknameattribute has been correctly updated.
Import OracleAS Single Sign-On External Applications data.
This step imports any external applications and password store data that was exported in Step 5 of procedure "Prerequisite Export Steps". Extract the OracleAS Single Sign-On data with the ssomig utility in -import mode as follows:
TEST_INFRA_HOME/sso/bin/ssomig -import -overwrite -s orasso -p orasso_pwd -c test_sso_net_service_name -d exp_dumpfile_name -log_d dumpfile_dir –discoforce
Ensure the exp_dumpfile_name is filename of the dump file and is in the directory dumpfile_dir directory. The dumpfile_dir directory will also contain the ssoconf.log file, which was generated when you ran the ssomig utility in –export mode.
You obtain the password for the ORASSO schema (orasso_pwd) from Oracle Internet Directory as follows:
TEST_INFRA_HOME/bin/ldapsearch -h test_oid_host -p test_oid_port -D cn=orcladmin -w test_orcladmin_pwd -b "orclreferencename=test_oid_service_name,cn=IAS Infrastructure Databases,cn=ias,cn=products,cn=oraclecontext" -s sub "(orclresourcename=orasso)" orclpasswordattribute
The response for ssomig looks similar to the following output:
SSO Migration Tool: Release 10.1.2.0.2 - Production on Sun Feb 27 12:10:27 2005 Copyright (c) 2002-2005 Oracle. All rights reserved. Verifying SSO schema information... Data import started at Sun Feb 27 12:10:28 2005 Log Directory : /tmp Log File Name : /tmp/ssomig.log Import File Name : ssomig.dmp SSO Schema Name : orasso SSO Schema Password : ****** Connect String : orcl Mode : overwrite Loading data into the SSO schema...Done Data import completed.
Perform a backup of the test Identity Management configuration files and Metadata Repository with the OracleAS Backup and Recovery Tool. See Chapter 20.
Task 5: Copy Data from the Production Product Metadata Repository to the Test Environment
To copy data from the product Metadata Repository in the production environment to the test environment:
Drop the OracleAS Portal schemas from the product Metadata Repository in the test environment:
Take note of the schema passwords currently assigned to the schemas to be dropped. You will be re-creating these schemas later and you should provide the same password when you create them.
You can query the currently assigned passwords from the newly installed test Oracle Internet Directory:
TEST_INFRA_HOME/bin/ldapsearch -p test_oid_port -h test_oid_host -D cn=orcladmin -w test_orcladmin_password -b "orclReferenceName=portal_service_name,cn=IAS Infrastructure Databases,cn=IAS,cn=Products,cn=OracleContext" -s sub "(|(orclResourceName=PORTAL*)(orclResourceName=DISCOVERER5))" orclpasswordattribute
Take note of the passwords listed for the following schemas: DISCOVERER5, PORTAL, PORTAL_PUBLIC, PORTAL_APP, and PORTAL_DEMO.
The response looks similar to the following output:
OrclResourceName=PORTAL,orclReferenceName=portal.us.company.com,cn=IAS Infrastructure Databases,cn=IAS,cn=Products,cn=OracleContextorclpasswordattribute=DTFDKD58 OrclResourceName=PORTAL_PUBLIC,orclReferenceName=portal.us.company.com,cn=IAS Infrastructure Databases,cn=IAS,cn=Products,cn=OracleContextorclpasswordattribute=X9g57NMP OrclResourceName=PORTAL_DEMO,orclReferenceName=portal.us.company.com,cn=IAS Infrastructure Databases,cn=IAS,cn=Products,cn=OracleContextorclpasswordattribute=ZyKR9805 OrclResourceName=PORTAL_APP,orclReferenceName=portal.us.company.com,cn=IAS Infrastructure Databases,cn=IAS,cn=Products,cn=OracleContextorclpasswordattribute=IGqvwL9c OrclResourceName=DISCOVERER5,orclReferenceName=portal.us.company.com,cn=IAS Infrastructure Databases,cn=IAS,cn=Products,cn=OracleContextorclpasswordattribute=Alu23B8w
You need to stop all SQL*Plus connections to the PORTAL schema before dropping it, or else the attempt to drop it will throw an ORA-01940: cannot drop a user that is currently connected.
Drop the OracleAS Portal-related schemas from the test product Metadata Repository just installed.
From SQL*Plus as the SYS user, drop the OracleAS Portal schemas from the product Metadata Repository:
SQL> DROP USER portal_public cascade; User dropped. SQL> DROP USER portal_app cascade; User dropped. SQL> DROP USER portal_demo cascade; User dropped. SQL> DROP USER portal cascade; User dropped. SQL> DROP USER discoverer5 cascade; User dropped.
Prepare the product Metadata Repository in the test environment for import:
Create or alter tablespaces in the test database.
Check that the required tablespaces exist in the test database. The tablespaces in the test database must at least include all the ones listed from the production instance. To list all the tablespaces on the target, run the following from SQL*Plus as the SYS user:
SQL> SET PAGESIZE 65 SELECT TABLESPACE_NAME FROM DBA_TABLESPACES ORDER BY TABLESPACE_NAME;
The response looks similar to the following output
TABLESPACE_NAME ------------------------------ B2B_DT B2B_IDX B2B_LOB B2B_RT DCM DISCO_PTM5_CACHE DISCO_PTM5_META DSGATEWAY_TAB IAS_META OCATS OLTS_ATTRSTORE OLTS_BATTRSTORE OLTS_CT_STORE OLTS_DEFAULT OLTS_SVRMGSTORE PORTAL PORTAL_DOC PORTAL_IDX PORTAL_LOG SYSAUX SYSTEM TEMP UDDISYS_TS UNDOTBS1 USERS WCRSYS_TS 26 rows selected.
Comparing this example to the list of tablespaces obtained from the production instance, we see that we need to create the INDX (permanent), PORTAL_TMP (temporary) and DISCO_PTM5_TEMP (temporary) tablespaces.
To create a new tablespace, use the CREATE TABLESPACE or CREATE TEMPORARY TABLESPACE commands in SQL*Plus, in the SYS schema. For example:
SQL> CREATE TABLESPACE INDX 2 DATAFILE '/u01/app/oracle/product/oradata/orcl/indx.dbf' SIZE 20M AUTOEXTEND ON 3 DEFAULT STORAGE (INITIAL 1M NEXT 2M MINEXTENTS 2); Tablespace created. SQL> CREATE TEMPORARY TABLESPACE PORTAL_TMP 2 TEMPFILE '/u01/app/oracle/product/oradata/orcl/portal_tmp.dbf' SIZE 20M 3 AUTOEXTEND ON; Tablespace created. SQL> CREATE TEMPORARY TABLESPACE DISCO_PTM5_TEMP 2 TEMPFILE '/u01/app/oracle/product/oradata/asdb/disco_ptm5_temp.dbf' SIZE 20M 3 AUTOEXTEND ON; Tablespace created.
For any tablespaces that already exist in the target database, it is recommended that they be set to autoextend or they must be sized large enough to hold the imported PORTAL schemas. You can use the following script to enable autoextend on all datafiles:
SET DEFINE OFF SET HEAD OFF SET LINES 4000 SPOOL DATAFILES.SQL SELECT 'ALTER DATABASE DATAFILE '''||FILE_NAME||''' AUTOEXTEND ON;' FROM DBA_DATA_FILES ; SPOOL OFF
At this point, you can edit out any extraneous lines captured in the spool file DATAFILES.SQL, and then run it in the SYS schema to alter the data files:
@DATAFILES.SQL
From the production middle-tier instance, run SQL*Plus connect to the test Metadata Repository from SQL*Plus as the SYS user with SYSDBA privileges, and re-create the PORTAL schema by running the wbisys.sql script from the PRODUCTION_MIDTIER_HOME/portal/admin/plsql/wwv directory.
SQL> CONNECT SYS/password AS SYSDBA@test_metadata_repository_net_service_name SQL> @wdbisys.sql PORTAL portal_default_tablespace portal_temporary_tablespace wdbisys.log
In the syntax, test_metadata_repository_net_service_name specifies the net service name for the product Metadata Repository in the test environment, as defined in the tnsnames.ora file.
The response looks similar to the following output:
SQL> @wdbisys.sql PORTAL PORTAL PORTAL_TMP wdbisys.log B E G I N S Y S I N S T A L L ...start: Saturday 26 February , 2005 12:01:23 I. CREATE USER PORTAL and GRANT PRIVS old 1: create user &&1 identified by &&1 new 1: create user PORTAL identified by PORTAL User created. … PL/SQL procedure successfully completed. ...end of SYS install Disconnected from Oracle Database 10g Enterprise Edition Release 10.1.0.3.1 - Production With the Partitioning, OLAP and Data Mining options
Change the PORTAL password from SQL*Plus as the SYS user:
SQL> ALTER USER PORTAL IDENTIFIED BY password_from_test_oid;
This command creates the PORTAL schema and grants all of the necessary privileges.
For example:
SQL> ALTER USER PORTAL IDENTIFIED BY DTFDKD58; User altered
Create the PORTAL_PUBLIC schema.
Change to the PRODUCTION_MIDTIER_HOME/portal/admin/plsql/wws directory and run the following script from SQL*Plus as the SYS user:
SQL> CONNECT SYS/password AS SYSDBA@test_metadata_repository_net_service_name @cruser.sql PORTAL PORTAL portal_default_tablespace portal_temporary_tablespace
The response looks similar to the following output:
SQL> @cruser.sql PORTAL PORTAL PORTAL PORTAL_TMP
old 1: select ('&&1'||'_public') t1 from dual
new 1: select ('PORTAL'||'_public') t1 from dual
...
User altered.
No errors.
Disconnected from Oracle Database 10g Enterprise Edition Release 10.1.0.3.1 - Production
With the Partitioning, OLAP and Data Mining options
SQL*Plus: Release 10.1.0.3.0 - Production on Tue Mar 1 08:28:17 2005�
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.1.0.3.1 - Production
With the Partitioning, OLAP and Data Mining options
SQL> ALTER USER PORTAL_PUBLIC IDENTIFIED BY password_from_oid;
User altered.
Change the PORTAL_PUBLIC password from SQL*Plus as the SYS user:
For example:
SQL> ALTER USER PORTAL_PUBLIC IDENTIFIED BY X9g57NMP;
User altered.
Create the auxiliary schemas from SQL*Plus as the SYS user.
Check the list of schemas that will be imported from Step 3a of "Prerequisite Export Steps". If the schemas already exist in the test database, then drop them. Before dropping any schemas, ensure that those schemas are not in use by other applications. To create the new schemas, use the following syntax:
SQL> GRANT CONNECT, RESOURCE TOschemaIDENTIFIED BYpassword; ALTER USER username DEFAULT TABLESPACE default_tablespace TEMPORARY TABLESPACE temporary_tablespace;
You must create a schema for each schema in the list from Step 3a. Use the ALTER USER command to adjust any user properties as necessary. For instance, the default and temporary tablespaces should be set to the ones specified by the results from the query in Step 3a.
When creating the PORTAL_APP, PORTAL_DEMO, or DISCOVERER5 schemas, use the passwords you extracted from Oracle Internet Directory.
Following is an example for the standard schemas:
GRANT CONNECT,RESOURCE TO portal_app IDENTIFIED BY IGqvwL9c; ALTER USER portal_app default tablespace PORTAL temporary tablespace PORTAL_TMP; GRANT CONNECT,RESOURCE TO portal_demo IDENTIFIED BY ZyKR9805; ALTER USER portal_demo default tablespace PORTAL temporary tablespace PORTAL_TMP; GRANT CONNECT,RESOURCE TO discoverer5 IDENTIFIED BY AHb10z3b; ALTER USER discoverer5 default tablespace PORTAL temporary tablespace PORTAL_TMP;
If Step 3c "Prerequisite Export Steps" returned any schemas that had snapshots in them, grant privilege to define snapshots to those schemas from SQL*Plus as the SYS user:
SQL> GRANT CREATE SNAPSHOT TO schema;
where schema contains the schemas returned by performing Step 3c. If the schemas returned are PORTAL_DEMO and SCOTT, then you would issue the following SQL commands:
SQL> GRANT CREATE SNAPSHOT TO PORTAL_DEMO; SQL> GRANT CREATE SNAPSHOT TO SCOTT;
For a Standard Edition database only, prepare the database for import:
From SQL*Plus, initialize the portal login trigger for import as the PORTAL user:
cd TEST_INFRA_HOME/portal/admin/plsql/wwhost sqlplus portal/password@portal_net_service_name SQL> @insttrig.sql PORTAL
Ensure the character set of the product Metadata Repository in the production environment matches the character set of the product Metadata Repository in the production environment.
The product Metadata Repository in the test environment must match the character set of the data in the import dump produced in the production environment.
Set the NLS_LANG environment variable on the test Metadata Repository to match the character set established in Step 3d of "Prerequisite Export Steps" in production environment:
setenv NLS_LANG AMERICAN_AMERICA.WE8MSWIN1252
Run the catexp.sql script from the TEST_INFRA_HOME/rdbms/admin directory with SYSDBA privileges:
SQL> CONNECT SYS/password AS SYSDBA
@catexp.sql
This script creates the data dictionary and public synonyms for many of its views.
Import schemas into the product Metadata Repository in the test environment:
Run the Import utility.
Make sure that the database version that you are importing into is the same or a later version than the database you exported from. The actual import is done with the database imp command as follows, with the example showing just the four core OracleAS Portal schemas. Include any other schemas identified in the SELECT statement from Step 3a of "Prerequisite Export Steps".
TEST_INFRA_HOME/bin/imp 'sys/password@instance AS SYSDBA' file=/tmp/portal_exp.dmp grants=y log=/tmp/portal_imp.log fromuser=portal,portal_app,portal_demo,portal_public touser=portal,portal_app,portal_demo,portal_public
For UNIX operating systems, you must precede the quotation marks with an escape character, such as the backslash.
Enter the list of schemas as a comma-separated list.
You can ignore the following errors in the import log:
IMP-00015: following statement failed because the object already exists: IMP-00041: Warning: object created with compilation warnings. IMP-00061: Warning: Object type "SYS"."ODCIPARTINFO" already exists with a different identifier IMP-00092: Java object "SCOTT"."DeleteDbc" already exists, cannot be created
If you get other errors, such as missing tablespaces or missing schemas, you need to restore your database from your offline backup and repeat the import step after resolving the issue. Resolve this issue as indicated by the error message. For example, if a referenced schema was missing, then include that schema in the export and re-export the set of schemas from the production server. The schema needs to be created in the test system prior to import, as described in Step 3f of this procedure. This may typically happen for schemas that are not automatically identified by the SELECT statement in Step 3a of "Prerequisite Export Steps".
Resolve any job conflict errors in the import log.
The following example shows an example of a job conflict in the import log:
IMP-00017: following statement failed with ORACLE error 1:
"BEGIN DBMS_JOB.ISUBMIT(JOB=>15,WHAT=>'begin execute immediate"
"''begin wwctx_sso.cleanup_sessions( p_hours_old => 168 ); e"
"nd;'' ; exception when others then null;
end;',NEXT_DATE=>"
"TO_DATE('2005-03-23:14:11:08','YYYY-MM-DD:HH24:MI:SS'),INTERVAL=>'SYSDATE +"
" 24/24',NO_PARSE=>TRUE); END;"
IMP-00003: ORACLE error 1 encountered
ORA-00001: unique constraint (SYS.I_JOB_JOB) violated
ORA-06512: at "SYS.DBMS_JOB", line 97
ORA-06512: at line 1
If such an error is seen during the import, then run the following from SQL*Plus as the SYS user and look for conflicting jobs:
SQL> SELECT * FROM dba_jobs;
After identifying conflicts, revert to the backup created in Step 4 of "Task 2: Set Up Test Product Metadata Repository".
For each conflict identified in the previous step (Step 3b), re-create the failing jobs, and update the imported program to reference the new ID of the re-created job.
Using that backup, resolve the conflicts, and rerun all the steps of Task 5: Copy Data from the Production Product Metadata Repository to the Test Environment.
Give jobs back to the PORTAL user by running the following command from SQL*Plus as the SYS user:
SQL> UPDATE dba_jobs SET log_user='PORTAL', priv_user='PORTAL' where schema_user='PORTAL'; SQL> commit;
Resolve other errors in the import log. Table 11-1 lists some of the common errors and their workarounds.
Table 11-1 Errors in the Import Log When Copying Data to a Test Environment
| Error in Import Log | Workaround |
|---|---|
IMP-00017: following statement failed with ORACLE error 604: "ALTER TABLE "WWPRO_ADAPTER_KEY$" ENABLE CONSTRAINT "WWSEC_ADAPTER_KEY$_CK1"" |
As the SQL> SELECT OWNER FROM dba_tables WHERE table_name = 'WWPRO_ADAPTER_KEY$' ------------------------------ ORASSO PORTAL SQL> ALTER TABLE orasso.wwpro_adapter_key$ DISABLE constraint wwsec_adapter_key$_ck1; Table altered. SQL> ALTER TABLE portal.wwpro_adapter_key$ DISABLE constraint wwsec_adapter_key$_ck1; Table altered. |
IMP-00017: following statement failed with ORACLE error 604: "ALTER TABLE "WWPRO_ADAPTER_KEY$" ENABLE CONSTRAINT "WWSEC_ADAPTER_KEY$_CK1"" IMP-00003: ORACLE error 2298 encountered ORA-02298: cannot validate (PORTAL.WWSTO_SESS_FK1) - parent keys not found |
As the SQL> DELETE from wwsto_session_data$ / DELETE from wwsto_session_session$ / commit; SQL> ALTER TABLE portal.wwsto_session_session$ ENABLE constraint wwsto_sess_fk1; Table altered. |
IMP-00003: ORACLE error 30510 encountered |
As the SQL> CREATE TRIGGER logoff_trigger before logoff on schema begin -- Call wwsec_oid.unbind to close open OID connections if any. wwsec_oid.unbind; exception when others then -- Ignore all the errors encountered while unbinding. null; end logoff_trigger; / |
IMP-00017: following statement failed with ORACLE error 921: "ALTER TABLE "WWSRC_PREFERENCE$" ADD " IMP-00003: ORACLE error 921 encountered ORA-00921: unexpected end of SQL command |
Then, as the SQL> ALTER TABLE "WWSRC_PREFERENCE$" add constraint wwsrc_preference_pk
primary key (subscriber_id, id)
using index wwsrc_preference_idx1
/ begin
DBMS_RLS.ADD_POLICY ('', 'WWSRC_PREFERENCE$', 'WEBDB_VPD_POLICY',
'', 'webdb_vpd_sec', 'select, insert, update, delete', TRUE,
static_policy=>true);
end ;
/
|
Compile all the invalid objects from the imported schemas.
Run the following script from SQL*Plus as the SYS user from the TEST_INFRA_HOME/rdbms/admin directory:
@utlrp.sql
If the following query in the PORTAL schema returns more than PORTAL_PUBLIC:
SQL> SELECT DISTINCT DB_USER FROM WWSEC_PERSON$;
Then, execute the following commands from SQL*Plus as the PORTAL user:
SET HEAD OFF SET LINES 4000 SET SQLPROMPT '--' SET SQLNUMBER off SET LINESIZE 132 SPOOL DBUSERS.SQL SELECT DISTINCT 'ALTER USER '||DB_USER ||' GRANT CONNECT THROUGH PORTAL;' FROM WWSEC_PERSON$; SPOOL OFF
Run DBUSERS.SQL in the target portal instance to grant connect through privilege� to database users associated with portal users. In most cases, this will simply be PORTAL_PUBLIC, which already has the necessary grant.
Drop the temporary login trigger.
This step is only necessary if the test server is a Standard Edition database and you performed Step 2h of this procedure; this step is not needed for an Enterprise Edition database.
Run the following script from SQL*Plus as the PORTAL user from the TEST_INFRA_HOME/portal/admin/plsql/wwhost:
@droptrig.sql PORTAL
Re-create and re-index the intermedia OracleAS Portal table.
Run the following scripts from SQL*Plus as the PORTAL user from the MIDTIER_HOME/portal/admin/plsql/wws directory:
@inctxgrn.sql @ctxcrind.sql
Update the OracleAS Portal instance from the Portal Dependency Settings file (iasconfig.xml) file by running the ptlconfig script from the TEST_MIDTIER_HOME/portal/conf directory:
ptlconfig -dad dad_name
In the syntax, dad_name is Database Access Descriptor (DAD) name. The default name set at installation is portal. Substitute the DAD name if it is not set to portal.
Perform a backup of the test product Metadata Repository, Identity Management configuration files, and Identity Management Metadata Repository with the OracleAS Backup and Recovery Tool. See Chapter 20.
Task 6: Deploy Applications to the Test Middle Tier
Deploy J2EE application EAR files to the test middle tier. You can use one of the following mechanisms:
Deploy J2EE application EAR files to the test middle tier. You can use one of the following mechanisms:
Use the DCM deployApplication command
Navigate to the OC4J Home page -> Applications tab in Oracle Enterprise Manager 10g Application Server Control Console, and click Deploy EAR file.
|
See Also:
|
Copy the configuration settings from the production environment to the test environment for all OracleAS Portal and OracleBI Discoverer applications.
For OracleBI Discoverer, you need to copy the following files to the production environment:
configuration.xml and configuration.xsd files
(10.1.2.0.x on Unix) ORACLE_HOME/discoverer/config (9.0.4.x on Unix) ORACLE_HOME/j2ee/OC4J_BI_FORMS/applications/discoverer/web/WEB-INF (10.1.2.0.x on Windows) ORACLE_HOME\discoverer\config (9.0.4.x on Windows) ORACLE_HOME\j2ee\OC4J_BI_FORMS\applications\discoverer\web\WEB-INF
(10.1.2.0.x on Unix) ORACLE_HOME/j2ee/OC4J_BI_Forms/applications/discoverer/discoverer/WEB-INF (9.0.4.x on Unix) ORACLE_HOME\j2ee\OC4J_BI_FORMS\applications\discoverer\web\WEB-INF (10.1.2.0.x on Windows) ORACLE_HOME\j2ee\OC4J_BI_Forms\applications\discoverer\discoverer\WEB-INF (9.0.4.x on Windows) ORACLE_HOME\j2ee\OC4J_BI_FORMS\applications\discoverer\web\WEB-INF
(10.1.2.0.x on UNIX) ORACLE_HOME/discoverer (10.1.2.0.x on Windows) ORACLE_HOME\discoverer
prefs.txt is not available in 9.0.4.x environments.
(10.1.2.0.x and 9.0.4.x on UNIX) ORACLE_HOME/discoverer (10.1.2.0.x and 9.0.4.x on Windows) ORACLE_HOME\discoverer
You cannot copy this file across different operating systems. If this migration is happening between little-endian to big-endian operating systems, then run the convertreg.pl script:
perl convertreg.pl test_reg_key.dc_file production_reg_key.dc_file
You can use the PERL that installs with Oracle Application Server. You can find convertreg.pl in the following directory:
(UNIX) ORACLE_HOME/discovere/util (Windows) ORACLE_HOME\discoverer\util
Windows and Linux are examples of little-endian operating systems and Solaris and HP-UX are examples of big-endian operating systems. Do not use this utility when moving from little-endian to little-endian operating systems or big-endian to big-endian operating systems. For these migrations, omit this step (in which case the destination system will have a default set of user preferences).
|
Note: Theconvertreg.pl script does not exist on Windows in releases 9.0.4.x. For environments supporting this release, download the patch for this utility. The related Automated Release Updates (ARU) number is ARU 7462620.
You can download this patches from OracleMetalink: |
If OracleAS Portal is pointing to a J2EE application provider, then if desired, deploy these applications to the test middle tier and configure OracleAS Portal to point to the test middle tier.
Perform a backup of the test middle tier configuration files, product Metadata Repository, Identity Management configuration files, and Identity Management Metadata Repository with the OracleAS Backup and Recovery Tool. See Chapter 20.
Task 7: Copy OracleBI Discoverer Data
To copy the OracleBI Discoverer data:
Create a new database schema containing an empty EUL:
TEST_MIDTIER_HOME/bin/eulapi -connect dba/password@database_service_name -create_eul [-apps_mode] -default_tablespace default_tablespace_name -temporary_tablespace temp_tablespace_name -user new_eul_schema -password new_eul_schema_password -log /tmp/createeul.log
Use the –apps_mode flag if you are creating a copy of an Oracle Applications mode EUL.
If you intend to copy data to another customer database in the test environment, use the service name of the test database for database_service_name.
Import the copied contents into the new EUL schema:
TEST_MIDTIER_HOME/bin/eulapi -connect new_eul_owner/password@database_service_name -import /tmp/file1.eex -log /tmp/imp.log
The mapping of source EUL schemas to new EUL schemas should be noted in order to support the migration of Discoverer connections as detailed in the next section.
|
Note: Theeulapi utility does not exist on Windows in releases 9.0.4.x and 10.1.2.0.x. For environments supporting these releases, download the patches for this utility. The related Automated Release Updates (ARU) number for 9.0.4.x is ARU 7462620 and 10.1.2.0.x is ARU 7462623.
You can download these patches from OracleMetalink: |
Task 8: Clean Up the Test Environment
To cleanup the test environment prior to using it:
If your OracleAS Single Sign-On migration data includes OracleBI Discoverer connection data, perform the following to update the connection data:
Connect to the test Identity Management database as ORASSO and run the following SQL:
SQL> UPDATE ORASSO_DS.WWSSO_PSEX_USER_INFO$
SET FVAL2 = '&NewEulName'
WHERE FNAME2 = 'eul' and FVAL2 = '&OldEulName' and
FNAME5 = 'database' and FVAL5 = '&DbConnectString';
Where:
&NewEULName is the name of the new EUL that was created after copying the EUL
&OldEulName is the name of the production EUL
&DbConnectString is the net service name or the connect descriptor for the database where the EUL resides and that was used when creating the Discoverer Connection pointing to this EUL
|
Note: When you deploy OracleBI Discoverer in non-OracleAS Single Sign-On mode, users create private connections, which are stored in the PSTORE. However, OracleBI Discoverer needs to store a cookie on the browser for identifying the browser that created the connections. These cookies will not be available to the test server and users will not be able to get to their non-OracleAS Single Sign-On private connections stored in PSTORE. However, users can re-create these connections and all existing workbooks will be preserved. |
To copy the OLAP connections, connect to the Identity Management database as ORASSO and run the following SQL:
SQL> UPDATE ORASSO_DS.WWSSO_PSEX_USER_INFO$ SET FVAL4 = '&New_Db_Details'
WHERE user_prefs LIKE '%olap_zone=true%' AND
FNAME4 = 'database' and FVAL4 = '&Old_Db_Details';
Where:
&New_Db_Details is in the format:
computer:listener_port:database_SID
For example, testserver.us.company.com:1521:testdb
&Old_Db_Details is in the format:
computer:listener_port:database_SID
For example, prodserver.us.company.com:1521:proddb
Clean up OracleAS Single Sign-On data:
After the OracleAS Single Sign-On import, partner applications registered with the production system are also imported to the test environment. This includes the partner registrations with the production host name. You should remove all of these.
Log into the OracleAS Single Sign-On system by accessing the following URL:
http://test_infra.domain.com:port/pls/orasso
Click SSO Server Administration.
Click Administer Partner Applications.
Scan the list of links by holding the mouse over the partner application name, and delete all the entries that pertain to the production host. Corresponding entries should now exist for the test host.
Change the registration of Discoverer Portlet Provider on the test OracleAS Portal instance.
Modify the registration of the Discoverer Portlet Provider in the OracleAS Portal instance and change the URL for the provider from:
http://production_host:production_OHS_port/discoverer/portletprovider
To:
http://test_host:production_OHS_port/discoverer/portletprovider
Log in to OracleAS Portal as the administrator (for example, PORTAL).
Click the Administer tab.
Click the Portlets sub-tab.
In the Remote Providers portlet, enter the Discoverer Portlet Provider name in the Name field. Click Edit.
Click the Connection tab.
In the URL field, update the port to the new port number. Click Apply.
Modify all Web providers to use the new URL.
Once you establish the test environment, use it for testing upgrades or applying patchsets.
After creating the test environment, consider transforming it to a highly available installation.
|
See Also:
|
