G Moving Oracle Portal 11g from a Test to a Production Environment

This chapter describes the process of moving Oracle Portal 11g from a source environment that includes a middle-tier instance, Identity Management with a Metadata Repository, and a product Metadata Repository, to a target environment. You can use this procedure for the following purposes:

Copy your test environment to a production environment, or vice versa.
Clone a similar environment from your production to test to be able to test patches, and do stress testing.

G.1 Introduction

You can move Oracle Portal and its configuration from a source environment to a different (target) location while preserving its configuration. In this chapter, "test" is assumed to be the source environment, and "production" is assumed to be the target environment. This scenario assumes that you have installed Oracle Portal 11g in a test environment and you want to copy it to a production environment.

The following sections describe the process of moving from a test to production environment:

Preparing the Source Environment
Moving from Test to Production Environment
Validating the Production Environment

Note:

This chapter does not describe the procedure to migrate Oracle Internet Directory (OID) users or groups and Single Sign-On (SSO).

G.2 Preparing the Source Environment

At the source, you must have an archive of Portal's configuration. This archive will then be used to create a cloned instance of Portal at the target environment.

G.2.1 Prerequisites

Before moving the source environment, ensure you meet the following prerequisites:

You must have a source (test) environment and a target (production) environment.
Source and target systems must be identical in terms of product version, JDK version, database version, and the system configurations of both the machines.

Note:

Your target environment will be a mirror image of your source environment. The target Portal instance behaves the same as the source Portal instance. For instance, the target instance can be deinstalled or patched using Oracle Universal Installer. It can also be used as the source later and move it to a different target.

G.2.2 Preparing the source environment to be cloned

To prepare the source environment to be cloned, perform the following steps:

Add the following paths to the PATH environment variable. Also set the Java temporary directory using T2P_JAVA_OPTIONS as follows:
```
export PATH=SOURCE_MW_HOME/oracle_common/bin:$JAVA_HOME:$PATH

export T2P_JAVA_OPTIONS="-Djava.io.tmpdir=/refresh/temp"
```
Copy the Portal Fusion Middleware home by executing the copyBinary.sh script, which copies the WebLogic Server home and the Oracle homes contained within a Middleware home. The copyBinary.sh script is located in the SOURCE_MW_HOME/oracle_common/bin folder.

For example, to clone a Middleware home that is located at /work/mwhome/, use the following command:
```
copyBinary.sh -javaHome /work/mwhome/jrockit_160_29_D1.2.0-10 -archiveLoc /work/clone/mw_source_copy.jar -sourceMWHomeLoc /work/mwhome -invPtrLoc /oraInventory/oraInst.loc
```

Create a TAR file with the Oracle home (but not the Oracle base) directory. For example:

tar cvf /tmp/cloning_tool.tar SOURCE_MW_HOME/oracle_common/bin SOURCE_MW_HOME/oracle_common/jlib

Create a database dump (.dmp) file to export the database schema to the target environment. For example:
```
SOURCE_DB_HOME/bin -> exp \'sys/welcome1@db9635 AS SYSDBA\' file=/work/clone/portal_exp.dmp grants=y
statistics=none log=/work/clone/portal_exp.log owner=<Prefix>_PORTAL,<Prefix>_PORTAL_APP,<Prefix>_PORTAL_PUBLIC
```
Note:

If there are multiple schemas of the same type, use the schema with the prefix that corresponds to the prefix used in the source instance. You can obtain the schema prefix used by the source instance, by accessing the Portal Data Source Configuration page in the WebLogic Administration Console of the source instance.

G.3 Moving from Test to Production Environment

After you create an archive of the source environment's configuration, you must use the archive to create the clone of Portal on the target environment.

G.3.1 Preparing to move the data from the source environment

Before you move data from the source environment, perform the following tasks:

On the target machine, install the same version of Oracle Database (including the same patch sets or fixes as applied in the source machine) and use the same schema prefix as in the source machine.
Copy the following files from the source machine to the target machine:
- cloning_tool.tar
- mw_source_copy.jar
- portal_exp.dmp
Extract the content of the cloning_tool.tar to the root directory of the target machine by using the following command:
```
tar -xvf cloning_tool.tar
```

G.3.2 Moving data to the target environment

To move data to the target environment, perform the following steps:

Ensure that the tablespaces on the target databases match the ones used in the source.

To list the tablespaces used, run the following query from SQL*Plus as the <Prefix>_PORTAL user:

SELECT DISTINCT TABLESPACE_NAME FROM DBA_SEGMENTS WHERE OWNER IN '<Prefix>_PORTAL','<Prefix>_PORTAL_APP','<Prefix>_PORTAL_PUBLIC') UNION SELECT DISTINCT DEFAULT_TABLESPACE FROM DBA_USERS WHERE USERNAME IN ('<Prefix>_PORTAL','<Prefix>_PORTAL_APP','<Prefix>_PORTAL_PUBLIC');

The response looks similar to the following output:

TABLESPACE_NAME
------------------------------
<Prefix>_PORTAL
<Prefix>_PORTAL_DOC
<Prefix>_PORTAL_IDX
<Prefix>_PORTAL_LOG

To list temporary tablespace, run the following query:

SELECT DISTINCT TEMPORARY_TABLESPACE FROM DBA_USERS WHERE USERNAME IN ('<Prefix>_PORTAL','<Prefix>_PORTAL_APP','<Prefix>_PORTAL_PUBLIC');

The response looks similar to the following output:

TEMPORARY_TABLESPACE
------------------------------
IAS_TEMP

Verify the *.*dbf files in the target machine. To list these files, run the following query:

select FILE_NAME, TABLESPACE_NAME, AUTOEXTENSIBLE, MAXBYTES, INCREMENT_BY from DBA_DATA_FILES where
TABLESPACE_NAME in ('<Prefix>_PORTAL','<Prefix>_PORTAL_DOC','<Prefix>_PORTAL_IDX','<Prefix>_PORTAL_LOG','<Prefix>_IAS_TEMP');

The response looks similar to the following output:

FILE_NAME       TABLESPACE_NAME     AUT        MAXBYTES INCREMENT_BY
---------------------------------------------------------------------------
              /work/db9635/oradata/db9635/STG12LIN_portaldoc.dbf
<Prefix>_PORTAL_DOC            YES 3.4359E+10          480
              /work/db9635/oradata/db9635/STG12LIN_portalidx.dbf
<Prefix>_PORTAL_IDX            YES 3.4359E+10          480
              /work/db9635/oradata/db9635/STG12LIN_portallog.dbf
<Prefix>_PORTAL_LOG            YES 3.4359E+10          480
              /work/db9635/oradata/db9635/STG12LIN_portal.dbf
<Prefix>_PORTAL                YES 3.4359E+10          480

SQL> DROP USER STG12LIN_<Prefix>_PORTAL cascade;
SQL> DROP USER STG12LIN_<Prefix>_PORTAL_APP cascade;
SQL> DROP USER STG12LIN_<Prefix>_PORTAL_PUBLIC cascade;

Create a file oraInst.loc in the TARGET_MW_HOME/oraInventory folder. This file specifies the location of the Oracle Inventory directory. Run pasteBinary.sh as shown in the following example:
```
./pasteBinary.sh -javaHome /work/mwhome/jrockit_160_29_D1.2.0-10 -archiveLoc /work/clone_source/mw_source_copy.jar
-targetMWHomeLoc /scratch/aime1/Demo -invPtrLoc   /scratch/aime1/oraInventory/oraInst.loc
```
Note:

Before creating the oraInst.loc file, ensure that the -Djava.io.tmpdir folder does not exist.
Connect to the database of the target machine as the SYS user with SYSDBA privileges, by running SQL*Plus, and re-create the <Prefix>_PORTAL schema by running the wbisys.sql script from the TARGET_PORTAL_HOME/portal/admin/plsql/wwv directory.
```
sqlplus SYS/password AS SYSDBA@db3823
@wdbisys.sql <Prefix>_PORTAL <Prefix>_PORTAL <Prefix>_IAS_TEMP wdbisys.log password
```
For more information about connecting to Oracle database, see Oracle® Database 2 Day Developer's Guide at:

http://docs.oracle.com/cd/E11882_01/appdev.112/e10766/tdddg_connecting.htm#TDDDG99998
Create the <Prefix>_PORTAL_PUBLIC schema.

Change to the TARGET_PORTAL_HOME/portal/admin/plsql/wws directory and run the following script from SQL*Plus as the SYS user.:
```
SQL> CONNECT SYS/password AS SYSDBA@db3823
@cruser.sql <Prefix>_PORTAL password <Prefix>_PORTAL <Prefix>_IAS_TEMP '' <Prefix>_PORTAL_DOC password
```
Change the <Prefix>_PORTAL_PUBLIC password from SQL*Plus as the SYS user:
```
ALTER USER <Prefix>_PORTAL_PUBLIC IDENTIFIED BY password;
```
This command creates the <Prefix>_PORTAL schema and grants all of the necessary privileges.

Create the auxiliary schemas from SQL*Plus as the SYS user.

create user <Prefix>_PORTAL_APP identified by password;
SQL> GRANT CONNECT,RESOURCE TO <Prefix>_PORTAL_APP IDENTIFIED BY password;
ALTER USER <Prefix>_PORTAL_APP default tablespace <Prefix>_PORTAL temporary tablespace <Prefix>_IAS_TEMP;

You must create a schema for each schema that you have exported. Use the ALTER USER command to adjust any user properties as necessary.

Run the catexp.sql script from TARGET_DB_HOME/rdbms/admin directory with SYSDBA privileges:
```
sqlplus SYS/password AS SYSDBA@db3823
@catexp.sql
```
Import schemas into the product Metadata Repository in the target environment:
1. Run the import utility
  
  Make sure that the database version that you are importing into is the same version of the database you exported from. The actual import is done with the database imp command as follows:
```
TARGET_DB_HOME/bin/   imp \'sys/password@db3823 AS SYSDBA\'
file=/scratch/aime1/Clone_source/portal_exp.dmp grants=y log=/scratch/aime1/Clone_source/portal_imp.log
fromuser=<Prefix>_PORTAL,<Prefix>_PORTAL_APP,<Prefix>_PORTAL_PUBLIC touser=<Prefix>_PORTAL,<Prefix>_PORTAL_APP,<Prefix>_PORTAL_PUBLIC
```
2. Compile all the invalid objects from the imported schemas.
  
  Run the following script from SQL*Plus as the SYS user from the TARGET_DB_HOME/rdbms/admin directory:
```
@utlrp.sql
```
  Note:
  
  To ensure that all invalid objects are compiled properly, the best practice is to run the utlrp.sql script more than once due to object dependency.
3. Run the following query in the <Prefix>_PORTAL schema to see if it returns more than <Prefix>_PORTAL_PUBLIC:
```
SELECT DISTINCT DB_USER FROM <Prefix>_PORTAL.WWSEC_PERSON$;
```
4. Drop the temporary login trigger.
```
@droptrig.sql <Prefix>_PORTAL
```
5. Re-create and re-index the intermediate OracleAS Portal table.
  
  Run the following scripts from SQL*Plus as the <Prefix>_PORTAL user from the TARGET_PORTAL_HOME/portal/admin/plsql/wws directory:
```
@inctxgrn.sql
@ctxcrind.sql
```
6. Give jobs back to the <Prefix>_PORTAL user by running the following command from SQL*Plus as the SYS user:
```
SQL> UPDATE dba_jobs set LOG_USER='<Prefix_PORTAL>', PRIV_USER='<Prefix_PORTAL>' where schema_user='<Prefix_PORTAL>';
SQL> commit;
```
Log into the Configuration wizard from the target Middleware home and configure Portal. For detailed steps for configuring Oracle Portal, see "Configuring Oracle Portal, Forms, Reports and Discoverer" in Oracle Fusion Middleware Installation Guide for Oracle Portal, Forms, Reports and Discoverer.

G.4 Validating the Production Environment

To validate the environment after cloning, check the following URLs in a browser:

Component	URL
Oracle Portal	http://host:port/portal/pls/portal
Administration Server Console	http://host:port/console
Enterprise Manager	http://host:port/em