|
Oracle® Application Server Upgrade and Compatibility Guide
10g Release 2 (10.1.2) for Microsoft Windows Part No. B14096-05 |
|
 Previous |
 Next |
|
Oracle® Application Server Upgrade and Compatibility Guide
10g Release 2 (10.1.2) for Microsoft Windows Part No. B14096-05 |
|
|
Previous |
Next |
This chapter explains how to upgrade the Oracle Application Server Metadata Repository. The major steps in upgrading the OracleAS Metadata Repository are described in the following sections:
Task 1: Upgrade the Database That Hosts the OracleAS Metadata Repository
Task 2: Back Up the OracleAS Metadata Repository Before Upgrade
Task 3: Review Special Considerations for Specific Component Schemas
Task 4: Run the Metadata Repository Upgrade Assistant (MRUA)
Task 5: Complete the OracleAS Metadata Repository Upgrade for OracleAS Portal and OracleAS Wireless
Task 6: Start the Middle Tiers That Use the OracleAS Metadata Repository
Before you can upgrade the OracleAS Metadata Repository, you must be sure the database that hosts the repository is upgraded to a version supported by 10g Release 2 (10.1.2).
The following sections describe in detail the process of upgrading your OracleAS Metadata Repository database:
Summary of the OracleAS Metadata Repository Database Requirements
Using OracleMetaLink to Obtain the Latest Oracle Application Server Software Requirements
Determining Your OracleAS Metadata Repository Database Upgrade Path
Upgrading an OracleAS Metadata Repository Creation Assistant Database
Relocating the Database Datafiles, Control Files, and Log Files
Database Upgrade Considerations When Using Oracle Ultra Search
The database that hosts the OracleAS Metadata Repository must be one of the following supported versions:
Oracle Database 10g (10.1.0.4.2)
This is the version of the database that Oracle Universal Installer creates and configures when you install a new 10g Release 2 (10.1.2) OracleAS Metadata Repository using the Identity Management and OracleAS Metadata Repository installation type or the OracleAS Metadata Repository installation type.
Similarly, this is the version of the database that results when you use Oracle Universal Installer to upgrade a seed database in a colocated Infrastructure or non-colocated Infrastructure Oracle home.
If you used the OracleAS Metadata Repository Creation Assistant to install the OracleAS Metadata Repository in an existing database, you must upgrade your database to this version and apply patch 4015165.
The Oracle Application Server 10g Release 2 (10.1.2.0.2) software requirements included in this guide were accurate at the time this manual was released to manufacturing. For the most up-to-date information about software requirements, including the database versions required for Oracle Application Server 10g Release 2 (10.1.2.0.2), refer to OracleMetaLink:
http://metalink.oracle.com/
After logging into OracleMetaLink, click Certify and Availability. From the resulting Web page, you can view the latest certifications by product, platform, and product availability.
The upgrade path you choose for your OracleAS Metadata Repository database depends upon whether your OracleAS Metadata Repository database is a seed database or an OracleAS Metadata Repository Creation Assistant database.
After you determine whether your database is a seed database or an OracleAS Metadata Repository Creation Assistant database, you can begin to determine an upgrade path:
If your database is a seed database, then you can use Oracle Universal Installer and the standard 10g Release 2 (10.1.2) installation procedure to upgrade your database automatically. Oracle Universal Installer upgrades your database to Oracle Database 10g (10.1.0.4.2).
Refer to Section 7.1.4, "Upgrading a Seed Database with Oracle Universal Installer" for detailed instructions.
If your database is an OracleAS Metadata Repository Creation Assistant database, you must first determine the current version of the database and upgrade the database, if necessary.
Refer to Section 7.1.5, "Upgrading an OracleAS Metadata Repository Creation Assistant Database" for details about determining your OracleAS Metadata Repository Creation Assistant database upgrade path.
Figure 7-1 summarizes the supported starting points for upgrading your seed database or OracleAS Metadata Repository Creation Assistant database.
Figure 7-1 Summary of Determining Your Database Upgrade Path
|
See Also: Section 7.1.2, "Using OracleMetaLink to Obtain the Latest Oracle Application Server Software Requirements" for information about obtaining the very latest information on the OracleAS Metadata Repository database requirements |
If the OracleAS Metadata Repository resides in a seed database, which was created using the Release 2 (9.0.2) or 10g (9.0.4) application server installation procedure, you can use the Oracle Universal Installer and the 10g Release 2 (10.1.2) installation procedure to upgrade your OracleAS Metadata Repository database.
This method of upgrading your database is the easiest method, since Oracle Universal Installer does the database upgrade for you.
|
Note: When you use Oracle Universal Installer to upgrade your OracleAS Metadata Repository database, the installer invokes the Database Upgrade Assistant (DBUA).DBUA can take a significant amount of time to upgrade the database. For more information on how long it takes to upgrade your database, see Section 3.3, "Planning for System Downtime" and plan accordingly. |
Refer to the following sections for more information on using Oracle Universal Installer to upgrade your OracleAS Metadata Repository database:
Overview of Using Oracle Universal Installer to Upgrade a Seed Database
Upgrading a 10g (9.0.4) OracleAS Metadata Repository Seed Database in a Non-Colocated Infrastructure
Figure 7-2 provides a graphical representation of the first few screens of the 10g Release 2 (10.1.2) installation procedure. It shows how you can select the appropriate Installation Type to install 10g Release 2 (10.1.2) and upgrade your existing OracleAS Metadata Repository.
As shown in the illustration, if you have already upgraded OracleAS Identity Management in a colocated Infrastructure, then the database that hosts the OracleAS Metadata Repository has already been upgraded to a supported version.
On the other hand, if your OracleAS Metadata Repository resides in a non-colocated Infrastructure, refer to Section 7.1.4, "Upgrading a Seed Database with Oracle Universal Installer" for more information.
Figure 7-2 Using Oracle Universal Installer to Upgrade the OracleAS Metadata Repository Database
When you use the 10g Release 2 (10.1.2) installation procedure to upgrade your OracleAS Metadata Repository database in a non-colocated Infrastructure, you perform the following tasks using the standard Oracle Universal Installer installation screens.
If your OracleAS Metadata Repository resides in a colocated Infrastructure, the database is upgraded automatically during the OracleAS Identity Management upgrade by Oracle Universal Installer.
If you are using Oracle Ultra Search, refer to Section 7.1.8, "Database Upgrade Considerations When Using Oracle Ultra Search" before upgrading the database.
Stop all the middle tiers that are using the services of the OracleAS Identity Management installation.
Make sure that the OracleAS Metadata Repository database and database listener are up and running.
Log in to the computer on which source instance is installed, as the same operating system user that performed the 10g (9.0.4) installation.
|
Note: The account you log in to install or upgrade the OracleAS Metadata Repository must be listed as a member of the Administrators group. |
Make sure the Oracle Internet Directory server is up and running.
To verify that Oracle Internet Directory is running, enter one of the following commands.
If you are running Oracle Internet Directory on a non-secure port:
SOURCE_ORACLE_HOME\bin\ldapbind -p Non-SSL_port
If you are running Oracle Internet Directory on a secure port:
SOURCE_ORACLE_HOME\bin\ldapbind -p SSL_port -U 1
These commands should return a "bind successful" message.
Set the required environment variables, as defined in the section "Environment Variables" in the "Requirements" chapter of the Oracle Application Server Installation Guide.
In particular, be sure to set following variables so they do not reference any Oracle home directories:
In addition, be sure the following environment variables are not set:
Mount the CD-ROM and start the installer.
|
See Also: Oracle Application Server Installation Guide for detailed instructions about starting Oracle Universal Installer on your platform |
Refer to Table 7-1 for information on the options you should select on each screen.
After the End of Installation screen appears, exit Oracle Universal Installer and then verify that Oracle Internet Directory and Oracle Application Server Single Sign-On are functioning and accessible in the new 10g Release 2 (10.1.2) Oracle home.
|
See Also: Oracle Application Server Administrator's Guide, Chapter 1, "Accessing the Single Sign-On Server" |
Note that you must run MRUA to upgrade the OracleAS Metadata Repository component schemas after the database is upgraded to a supported database version.
|
See Also: Section 5.5.1, "Upgrading OracleAS Identity Management in a Colocated Infrastructure" for a description of the Oracle Universal Installer screens that appear when you upgrade the OracleAS Metadata Repository database in a colocated OracleAS Infrastructure Oracle homeSection 1.1, "Reviewing Your Current Oracle Application Server Installations" for information about colocated and non-colocated OracleAS Infrastructure Oracle homes |
Table 7-1 Summary of the Oracle Universal Installer Screens During the OracleAS Metadata Repository Upgrade in a Non-Colocated Oracle Home
| Screen | Description and Recommended Options to Select |
|---|---|
|
Welcome |
Welcomes you to Oracle Universal Installer and the Oracle Application Server 10g Release 2 (10.1.2) installation procedure. |
|
Specify File Locations |
Enter a name and path for the new Oracle home. This new Oracle home will be the destination Oracle home for your Oracle Application Server 10g Release 2 (10.1.2) upgrade. |
|
Select a Product to Install |
Select OracleAS Infrastructure 10g. If multiple languages are used in the OracleAS Infrastructure you are upgrading, then click Product Languages. |
|
Language Selection |
The screen appears only if you clicked Product Languages on the Select a Product to Install screen. If multiple languages are used in the OracleAS Infrastructure you are upgrading, select those languages. If you are not sure which languages were installed, but want languages other than English, click the double arrow button (>>) to select all languages. |
|
Select Installation Type |
Select Metadata Repository. Note: It is very important that you select the same installation type that is used in the Oracle home you are upgrading. |
|
Upgrade Existing Infrastructure |
This screen appears when Oracle Universal Installer detects an existing Oracle Application Server installation of the same type as the one you selected on the Select Installation Type screen. Select the option to upgrade an existing OracleAS Infrastructure, and then select the Oracle home you want to upgrade from the drop-down list. (If there is only one Infrastructure of the selected type on the computer, then the drop-down list is inactive.) Note that Oracle Universal Installer detects only the Oracle homes that match the installation type you selected on the Select Installation Type screen. |
|
Specify Infrastructure Database Connection |
Enter |
|
Warning dialog box |
This dialog box warns you that all the clients of the OracleAS Metadata Repository database must now be stopped. Oracle Universal Installer will stop any clients within the current Oracle home automaticallyFoot 1 . However, you must manually stop any database or OracleAS Metadata Repository clients that reside in another Oracle home. Clients of the OracleAS Metadata Repository include:
Within each middle tier that uses this OracleAS Metadata Repository, you must be sure to stop all components, including Oracle HTTP Server and OracleAS Web Cache. For more information, see the chapter "Starting and Stopping " in the Oracle Application Server Administrator's Guide. |
|
Database Listener Warning Dialog Box |
If a database listener is running on the host, a warning dialog box displays. Review the dialog box determine whether or not you need to stop the listener manually. For more information, see Section 5.3.3, "Stopping the Database Listener When Prompted During the OracleAS Identity Management Upgrade". |
|
Summary |
Use this screen to confirm the choices you've made. Click Install to begin upgrading to the new 10g Release 2 (10.1.2) Oracle home. |
|
The Configuration Assistants |
After the initial software is installed, a set of configuration assistants automatically set up the components in the new 10g Release 2 (10.1.2) Oracle home. Use this screen to follow the progress of each assistant and to identify any problems during this phase of the installation. Notes:
|
|
End of Installation |
When the installation and upgrade is complete, this screen provides important details about the 10g Release 2 (10.1.2) Oracle home, such as the URL for the Application Server Control Console and the location of the After you review the information on this screen, you can exit Oracle Universal Installer and proceed to the post-upgrade tasks. |
shutdownprocesses.log file, which is located in the cfgtoollogs directory in the destination Oracle home.If you used OracleAS Metadata Repository Creation Assistant to install the OracleAS Metadata Repository, you must verify the version of the database that hosts the repository.
As shown in Figure 7-1, your goal is to upgrade your database to a version that can support the 10g Release 2 (10.1.2) OracleAS Metadata Repository.
|
See Also: Section 7.1.2, "Using OracleMetaLink to Obtain the Latest Oracle Application Server Software Requirements" for information about obtaining the very latest information on the OracleAS Metadata Repository database requirements |
Refer to the following sections for more information:
If You Installed the OracleAS Metadata Repository in an Oracle9i Database
If You Installed the OracleAS Metadata Repository in an Oracle 10g Database
If you installed your OracleAS Metadata Repository in an Oracle9i Database, you must be sure your database is Oracle9i Release 2 (9.2.0.6) or higher. Refer to the following sections for more information.
If You Installed the OracleAS Metadata Repository in an Oracle9i (9.0.1.x) Database
Install Oracle9i Release 2 (9.2.0.1) into a new Oracle home
Apply the Oracle9i Release 2 (9.2.0.6) patchset to the Oracle9i Release 2 (9.2.0.1) Oracle home; be sure to carefully follow the instructions in the Oracle9i Release 2 (9.2.0.6) patchset notes.
You can download the patchset from OracleMetaLink (http://metalink.oracle.com). Download patchset number 3948480.
Use the Database Upgrade Assistant (DBUA) in the Oracle9i Release 2 (9.2.0.6) Oracle home.
|
See Also: Oracle9i Database Migration in the Oracle9i Database documentation library for information about using DBUA and upgrading specific database components to Oracle9i Release 2 (9.2.0.6) |
Apply patch 4015165 to the newly upgraded Oracle9i Release 2 (9.2.0.6) database.
The patch is available from OracleMetaLink (http://metalink.oracle.com)
See section Section 7.1.5.2, "Special Instructions When Applying the Oracle9i Release 2 (9.2.0.6) Database Patchset" for more information before upgrading the OracleAS Metadata Repository.
|
Note: The Database Upgrade Assistant (DBUA) can take a significant amount of time to upgrade the database. For more information how long it takes to upgrade your database, see Section 3.3, "Planning for System Downtime". |
If you installed the OracleAS Metadata Repository in an Oracle9i Release 2 (9.2.0.x) database
Apply the Oracle9i Release 2 (9.2.0.6) patchset to the Oracle9i Release 2 (9.2.0.x) Oracle home; be sure to carefully follow the instructions in the Oracle9i Release 2 (9.2.0.6) patchset notes.
You can download the patch set from OracleMetaLink (http://metalink.oracle.com). Download patchset number 3948480.
Apply patch 4015165 to the newly upgraded Oracle9i Release 2 (9.2.0.6) database.
The patch is available from OracleMetaLink (http://metalink.oracle.com)
See the section Section 7.1.5.2, "Special Instructions When Applying the Oracle9i Release 2 (9.2.0.6) Database Patchset" for more information before upgrading the OracleAS Metadata Repository.
|
Note: If you are using Oracle Ultra Search, refer to Section 7.1.8, "Database Upgrade Considerations When Using Oracle Ultra Search" before you begin upgrading your database to Oracle9i Database. |
If you installed the OracleAS Metadata Repository in an Oracle9i Release 2 (9.2.0.6) database
Apply patch 4015165 to the Oracle9i Release 2 (9.2.0.6) database.
The patch is available from OracleMetaLink (http://metalink.oracle.com)
See the section Section 7.1.5.2, "Special Instructions When Applying the Oracle9i Release 2 (9.2.0.6) Database Patchset" for more information before upgrading the OracleAS Metadata Repository.
When you upgrade your database to Oracle9i Release 2 (9.2.0.6), make sure that you carefully follow the instructions in the README file for the Oracle9i Release 2 (9.2.0.6) patchset.
In particular, perform the following tasks after you run the Database Upgrade Assistant (DBUA):
Run the catpatch.sql script (step 6 in the README file).
Run utlrp.sql (step 10 in the README file for the patch set).
To check that you have run the catpatch.sql script, you can run the following command in SQL*Plus:
C:\> sqlplus "sys/password as sysdba"
SQL> select comp_name, version, status from dba_registry
where comp_id = 'CATPROC';
You should get the following results:
COMP_NAME VERSION STATUS ----------------------------- ----------- -------- Oracle9i Packages and Types 9.2.0.6.0 Valid
|
Note: Be sure that thecatpatch.sql script has been run against your database. Even if you have patched your database Oracle home to Oracle9i Release 2 (9.2.0.6), when you create a new database using the Database Configuration Assistant (DBCA), the new database might require the catpatch.sql script.
|
If you used the OracleAS Metadata Repository Creation Assistant to install the OracleAS Metadata Repository in an Oracle Database 10g database, you must upgrade the database to Oracle Database 10g (10.1.0.4.2) before you can use Metadata Repository Upgrade Assistant (MRUA) to upgrade the component schemas in the OracleAS Metadata Repository to 10g Release 2 (10.1.2.0.2).
|
Note: The Oracle Database 10g (10.1.0.4.2) patch is available only on the Oracle Database 10g (10.1.0.4.2) CD in the Oracle Application Server 10g Release 2 (10.1.2.0.2) CD pack. |
By default, after you upgrade your database, the datafiles, control files, and log files associated with the database remain in their original location. For example, if you used Oracle Universal Installer to upgrade a OracleAS Metadata Repository seed database, the datafiles for the OracleAS Metadata Repository database remain in the source Oracle home.
As a result, Oracle recommends that you relocate these files as a safeguard against inadvertently deleting them (for example, by deleting or decommissioning the entire source Oracle home directory tree). In addition, there may be performance benefits to moving the database files outside of the source Oracle home.
|
See Also: "Renaming and Relocating Datafiles" and "Creating Additional Copies, Renaming, and Relocating Control Files" in the Oracle Database Administrator's Guide |
The Oracle Enterprise Manager 10g Database Control provides a Web-based console you can use to manage Oracle Database 10g. When your OracleAS Metadata Repository is installed in an Oracle Database 10g instance, you can use the Database Control to manage your OracleAS Metadata Repository database.
|
See Also: "Managing the OracleAS Metadata Repository Database with Database Control" in the Oracle Application Server Administrator's Guide |
However, after you use Oracle Universal Installer to upgrade your OracleAS Metadata Repository database to Oracle Database 10g, the Database Control is not configured automatically. Instead, if you want to use the Database Control to manage your upgraded OracleAS Metadata Repository database, you must configure the Database Control manually using the Enterprise Manager Configuration Assistant (EMCA).
|
See Also: "Configuring the Database Control with EMCA" in Oracle Enterprise Manager Advanced Configuration |
If you have installed and configured Oracle Ultra Search, there are several issues you must consider before you upgrade your OracleAS Metadata Repository database.
Oracle Ultra Search is distributed both with the Oracle Database and with Oracle Application Server Release 2 (9.0.2) and 10g (9.0.4). The version installed with the Oracle database is different than the version installed with Release 2 (9.0.2) and 10g (9.0.4).
As a result, if you upgrade your database version, incompatibilities can result that will affect some key features of Oracle Ultra Search and, in specific upgrade configurations, some Oracle Ultra Search files can be overwritten in the database Oracle home.
In general, it is important to note the database version to which you are upgrading:
If you are upgrading an OracleAS Metadata Repository database to Oracle9i Release 2 (9.2.0.6), you do not want Oracle Ultra Search to be upgraded as part of the database upgrade. Instead, your goal is to keep using the current 10g (9.0.4) version of Oracle Ultra Search so it is compatible with Oracle Application Server.
If, however, you are upgrading your database to Oracle Database 10g, then you want Oracle Ultra Search to be upgraded during the database upgrade. After the upgrade of the database to Oracle Database 10g, you can then run the Metadata Repository Upgrade Assistant to complete the Oracle Ultra Search upgrade.
The following sections describe how to workaround these issues:
Configuring Oracle Ultra Search When Upgrading a Oracle9i Release 2 (9.2.0.4) Database
Repairing Oracle Ultra Search After Upgrading an Oracle9i Release 2 (9.2.0.x) Database
If you have installed and configured Oracle Ultra Search, you must upgrade your middle tiers before you upgrade the OracleAS Metadata Repository database.
For example, if you are upgrading OracleAS Identity Management in a colocated Infrastructure, you must upgrade the middle tiers before you upgrade OracleAS Identity Management. This is because the OracleAS Identity Management upgrade process in a colocated Infrastructure automatically upgrades the database.
If you do not upgrade the middle tiers first, compatibility problems will result between the Oracle Ultra Search files installed in the middle tiers and the Oracle Ultra Search files installed in the upgraded database.
If you have installed the OracleAS Metadata Repository in a Oracle9i Release 2 (9.2.0.4) database using the OracleAS Metadata Repository Creation Assistant, you must perform the following procedure to prevent the Oracle9i Database patchset from overwriting Oracle Ultra Search files.
This procedure is necessary only if you are applying an Oracle9i Database patchset to an Oracle9i Release 2 (9.2.0.4) database that hosts the OracleAS Metadata Repository. If you are upgrading from Oracle9i (9.0.1.3) or Oracle9i (9.0.1.5), this procedure is not necessary because that database upgrade results in a new Oracle home.
Before you apply the Oracle9i Database patchset:
Log in to the computer that hosts the OracleAS Metadata Repository database and change directory to the database Oracle home.
Rename the ultrasearch directory in the OracleAS Metadata Repository database Oracle home as follows:
Old name:
ORACLE_HOME\ultrasearch
New name:
ORACLE_HOME\ultrasearch_904
Rename the ultrasearch directory that was backed up automatically when you ran the OracleAS Metadata Repository Creation Assistant to initially create the repository in the existing database.
The name of the backup directory is in the following format:
ORACLE_HOME\ultrasearch_datestamp
Rename this directory by removing the underscore and datestamp as follows:
ORACLE_HOME\ultrasearch
Upgrade the database by applying the Oracle9i Release 2 (9.2.0.x) patchset.
Rename the ultrasearch directory to ultrasearch_920x, because this is the directory created by the Oracle9i Database patchset, and the Oracle Ultra Search files installed by the patchset are not usable in this configuration.
Rename the ultrasearch_904 directory to ultrasearch because this directory contains is the original 10g (9.0.4) files that are compatible with this version of Oracle Application Server.
Verify that the Oracle Ultra Search version is correct, by using the following SQL on the OracleAS Metadata Repository database:
select wk_util.get_version from dual;
This command should return '9.0.4' as the current version of Oracle Ultra Search.
If you applied an Oracle9i Release 2 (9.2.0.x) patchset to your OracleAS Metadata Repository Creation Assistant database without first configuring Oracle Ultra Search as described in Section 7.1.8.2, "Configuring Oracle Ultra Search When Upgrading a Oracle9i Release 2 (9.2.0.4) Database", then you can repair the Oracle Ultra Search software using the following procedure:
Rename the ultrasearch directory in the OracleAS Metadata Repository database Oracle home as follows:
Old name:
ORACLE_HOME\ultrasearch
New name:
ORACLE_HOME\ultrasearch_904_920x
The new ultrasearch_904_920x directory contains the Oracle Ultra Search files that are unusable with this version of Oracle Application Server.
Create a new version of the ultrasearch directory that contains Oracle Ultra Search files that are compatible with this version of Oracle Application Server.
You can create a new ultrasearch directory in the OracleAS Metadata Repository database Oracle home by copying the ultrasearch directory from the original 10g (9.0.4) OracleAS Metadata Repository Creation Assistant CD-ROM.
When you upgrade the OracleAS Metadata Repository database, the database upgrade procedure also upgrades some components of Oracle Ultra Search.
As a result, if you are using Oracle Ultra Search, upgrade the component schemas with the Metadata Repository Upgrade Assistant as soon as possible after you upgrade the OracleAS Metadata Repository database version.
MRUA completes the Oracle Ultra Search upgrade process by upgrading the Oracle Ultra Search schema and running required Oracle Ultra Search SQL scripts against the OracleAS Metadata Repository.
Before you begin upgrading your OracleAS Metadata Repository installation, perform a backup of the OracleAS Metadata Repository Oracle home, and perform a backup of the database that hosts the OracleAS Metadata Repository schemas.
The following sections describe special instructions to consider before using MRUA to upgrade the OracleAS Portal, OracleBI Discoverer, OracleAS Wireless, and Oracle Ultra Search schemas in the OracleAS Metadata Repository:
Special Instructions Before Upgrading the OracleAS Portal Schemas
About Upgrading the Oracle Business Intelligence Discoverer Schema
Preparing to Upgrade the Oracle Ultra Search Component Schema
The following instructions describe required tasks you must perform before upgrading the OracleAS Portal schemas in the OracleAS Metadata Repository:
Downloading and Installing the OracleAS Portal 10g (9.0.4) Repository Upgrade Software
Downloading and Installing the Oracle9iAS Single Sign-On 9.0.2.5 Patch
If you are upgrading a Release 2 (9.0.2) OracleAS Metadata Repository and you are using OracleAS Portal, then you must perform the following task before running MRUA.
Note that you must also perform this procedure before you upgrade an Oracle9iAS Release 2 (9.0.2) Portal repository in a customer database.
This procedure installs a required patch in the Oracle home of the database that contains the OracleAS Portal schemas:
Log in to the computer where your OracleAS Portal repository or OracleAS Metadata Repository is installed.
Be sure to log in as the same user who installed the repository.
Determine the version of the database where the OracleAS Metadata Repository or OracleAS Portal repository being upgraded resides.
Using your Web browser, log in to OracleMetaLink (http://metalink.oracle.com) and locate the patch specific to your database version:
|
Note: The two patches contain the same software but are bundled using different versions of the Oracle Universal Installer. Attempting to install the wrong one will result in version related errors in the installer. The latest version of these patches should always be used. |
Download the ZIP file that contains the patch into a temporary directory on your computer and extract its contents. The file contains the following:
Disk1 - a directory containing the scripts used to run the Oracle AS Portal repository upgrade
readme.html - A readme file
Examine the readme.html file for any changes that could affect the remaining procedures.
Set the ORACLE_HOME environment variable to the database Oracle home for the OracleAS Metadata Repository or OracleAS Portal repository.
Run the Oracle Universal Installer to copy the Portal upgrade scripts to the Oracle home using this command:
%ORACLE_HOME%\oui\bin\setup.exe
Table 7-2 describes the options you should select on each screen of the Oracle Universal Installer.
The installation procedure creates the following directory in the Oracle home:
ORACLE_HOME\portal\upg\plsql
It contains the programming code originally required to upgrade your repository from version 9.0.2 to version 10g (9.0.4). These files will automatically be used as part of the repository upgrade to version 10.1.2.
Table 7-2 Summary the Oracle Universal Installer Screens When Installing the OracleAS Portal 10g (9.0.4) Repository Upgrade Patch
| Screen | Description and Recommended Options to Select |
|---|---|
|
Welcome |
Welcomes you to Oracle Universal Installer. |
|
Specify File Locations |
In the Source field, specify the complete path to the For example, if you unzipped the downloaded file into your
In the Destination fields, enter the name and path to the database Oracle home that hosts your OracleAS Portal repository. |
|
Summary |
Use this screen to confirm the choices you've made. Click Install to begin installing the patch. |
|
End of Installation |
This screen appears when the installation is complete. Click Exit to quit Oracle Universal Installer. |
If you are using OracleAS Portal and you plan to keep using a 9.0.2 OracleAS Identity Management installation after you upgrade your OracleAS Metadata Repository, then you must perform the following steps in order to allow for interoperability between OracleAS Portal and 9.0.2 OracleAS Single Sign-On.
Note that this procedure also applies to situations where you have installed the OracleAS Portal repository in a customer database, outside of an OracleAS Metadata Repository.
This procedure does not apply if you have already upgraded the OracleAS Single Sign-On schema to 9.0.2.5 or if you are upgrading a 10g (9.0.4) OracleAS Portal repository or 10g (9.0.4) OracleAS Metadata Repository.
To apply the OracleAS Single Sign-On 9.0.2.5 patch:
Log in to the computer where your Oracle9iAS Release 2 (9.0.2) Metadata Repository containing your OracleAS Single Sign-On schema is located.
Be sure to log in as the same user who installed the Release 2 (9.0.2) Metadata Repository.
Log in to OracleMetaLink and locate Patch 2995671:
http://metalink.oracle.com
Download the ZIP file that contains the patch into a temporary directory on your computer and extract its contents. The file contains the following:
docs - a directory containing documentation for installing and applying the patch
util - a directory containing the files required to install and apply the patch
readme.txt - A readme file that describes the patch and its contents
Use the instructions in the following HTML file to install and apply the patch:
patch_directory\docs\sso_patch_902.html
For example, if you unpacked the patch ZIP file into the D:\downloads\sso_patch\ directory, the documentation would be located at:
D:\downloads\sso_patch\docs\sso_patch_902.html
The patch is applied to the Oracle9iAS Single Sign-On Server schema in the Release 2 (9.0.2) OracleAS Metadata Repository.
If you are upgrading OracleAS Portal 10g (9.0.4) and you have applied the OracleAS Single Sign-On 9.0.2.5 patch, then you must apply a patch to convert the external application identifiers in the OracleAS Portal schema. Refer to Table 7-3 for the appropriate patch number.
Table 7-3 Required Patches to Convert External Application Identifiers After Applying the Oracle Application Server Single Sign-On 9.0.2.5 Patch
| OracleAS Portal Version | Patch Number |
|---|---|
|
9.0.4 |
|
|
9.0.4.1 |
|
Note: The conversion of external application identifiers is generally performed automatically if you are upgrading directly from OracleAS Portal Release 2 (9.0.2). However, there may be some environments where automatic conversion during upgrade from OracleAS Portal Release 2 (9.0.2) is not possible. If this happens then the pre-check will fail and you will see an error in the upgrade log that indicates that the upgrade was unable to generate an SSO ID. In this case you must apply a patch to convert the external application identifiers and rerun the upgrade. Refer to Table 5-5 in Section 5.6.5.4, "Converting External Application IDs" for the correct patch number. |
After you use MRUA to upgrade the OracleAS Metadata Repository, you will be able to use Oracle Business Intelligence Discoverer schema (DISCOVERER5) only with a 10g Release 2 (10.1.2) Portlet Provider.
|
See Also: Oracle Application Server Portal User's Guide for more information about portlet providers |
Specifically, the upgraded 10g Release 2 (10.1.2) OracleBI Discoverer schema cannot be used with a Release 2 (9.0.2) or 10g (9.0.4) Portlet Provider. If you later need to use the OracleAS Metadata Repository with a previous version of the Portlet Provider, the only solution is to restore a backup of the OracleAS Metadata Repository database that was created before you ran MRUA.
The following sections provide information you should review before upgrading the OracleAS Wireless schema in the OracleAS Metadata Repository:
MRUA upgrades the OracleAS Wireless schema from 10g (9.0.4) to 10g Release 2 (10.1.2), but it does not upgrade the OracleAS Wireless schema from Release 2 (9.0.2).
As a result, if you are upgrading from 10g (9.0.4), then MRUA upgrades the OracleAS Wireless schema successfully and no workarounds or special steps are required. Similarly, or if you are upgrading from Release 2 (9.0.2) and you did not configure OracleAS Wireless, then MRUA installs the Wireless schema with no issues.
However, if you are upgrading from Release 2 (9.0.2) and you configured OracleAS Wireless in the Release 2 (9.0.2) middle tier, then you must follow the instructions for upgrading a Wireless middle tier as described in Section 4.10.2, "Special Instructions When Upgrading an OracleAS Wireless Release 2 (9.0.2) Middle Tier" before using MRUA to upgrade the OracleAS Metadata Repository.
This is because during the middle tier installation and upgrade to 10g Release 2 (10.1.2), the OracleAS Wireless Configuration Assistant upgrades the OracleAS Wireless schema to 10g (9.0.4). You can then use MRUA to upgrade the schema from 10g (9.0.4) to 10g Release 2 (10.1.2).
Note that if you have installed and configured OracleAS Wireless for Release 2 (9.0.2) and you did not install and configure at least one 10g Release 2 (10.1.2) OracleAS Wireless middle tier against the OracleAS Metadata Repository, the following error appears in the MRUA log files:
Invalid upgrade path. Please install AS10G (904) or 10.l.2 wireless mid tier against this infrastructure before running the MR upgrade.
|
See Also: Oracle Application Server Installation Guide for information about installing and configuring OracleAS Wireless as part of a Portal and Wireless installation |
When you upgrade the OracleAS Wireless schema in the OracleAS Metadata Repository, MRUA does not upgrade any wireless device definitions stored in the OracleAS Metadata Repository.
To obtain the most recent wireless device updates, as well as instructions for how to add them to your repository, navigate to the following URL on the Oracle Technology Network (OTN):
http://www.oracle.com/technology/products/iaswe/devices/index.html
If you are using Oracle Ultra Search, log in to the Oracle Ultra Search administration tool and stop and disable all crawler synchronization schedules in every Oracle Ultra Search instance before you run MRUA.
After you run MRUA, you can enable all crawler synchronization schedules.
|
See Also: Oracle Ultra Search Administrator's Guide |
After you have upgraded the middle tiers that depend upon this OracleAS Metadata Repository and after you have upgraded the database to a supported version, you can then use MRUA to upgrade the application server component schemas in the OracleAS Metadata Repository.
|
Note: The OracleAS Metadata Repository contains schemas for all the Oracle Application Server components. However, only a subset of those component schemas must be updated by MRUA. Other schemas, such as the OracleAS Identity Management component schemas, are upgraded during the OracleAS Identity Management upgrade. Still others, do not require any upgrade from previous versions. |
The following sections describe how to use MRUA to upgrade your component schemas:
Section 7.4.1, "Applying Required Release 2 (9.0.2) Patchsets"
Section 7.4.2, "Verifying That the Oracle Internet Directory and Database Processes Are Running"
Section 7.4.3, "Stopping All Middle Tier Instances That Use the OracleAS Metadata Repository"
Section 7.4.5, "Running the Metadata Repository Upgrade Assistant (MRUA)"
Section 7.4.6, "Example Execution Times for the Metadata Repository Upgrade Assistant"
Section 7.4.8, "Reviewing the OracleAS Portal Repository Upgrade Log Files"
Section 7.4.9, "Using a SQL Query to Verify the Success of the OracleAS Metadata Repository Upgrade"
If you are upgrading from Oracle Application Server Release 2 (9.0.2), be sure you have installed the latest patchsets.
Note that this section does not apply if you are upgrading from 10g (9.0.4).
The upgrade procedures in this manual have been tested using the latest patchsets available from OracleMetaLink. As a result, before you upgrade from Oracle Application Server Release 2 (9.0.2), apply the latest Oracle Application Server 9.0.2 patchsets to both the middle tiers and to the OracleAS Infrastructure components that the middle tiers rely upon.
The OracleMetaLink Web site is at the following URL:
http://metalink.oracle.com/
At the time this document was published the most recent Oracle9iAS patchset release was the Oracle9iAS 9.0.2.3 patchset (3038037). To locate this patchset, search for patch number 3038037 on OracleMetaLink.
|
Note: After applying Oracle9iAS 9.0.2.3 patchset (3038037), verify that the patchset was applied successfully before proceeding with the 10g Release 2 (10.1.2) upgrade. For example, verify that the Application Server Control, your deployed applications, and the components you use are functioning properly after you apply the patchset. |
Before you use MRUA, you must be sure that the following processes are up and running:
The database that hosts the OracleAS Metadata Repository
The database listener for the OracleAS Metadata Repository database
The Oracle Internet Directory instance where the OracleAS Metadata Repository database is registered
Log in to the Application Server Control Console to verify that the necessary processes are running and that the required components are configured properly. For example, you can use the Application Server Control Console to verify that the Farm page displays correctly and that the Oracle Internet Directory and OracleAS Single Sign-On components are up and running.
From the Application Server Home page in the Application Server Control Console click Ports to view a list of the ports currently in use by the application server instance, and to verify that the components are configured properly.
|
See Also: "Introduction to Administration Tools" in the Oracle Application Server Administrator's Guide for more information about using the Application Server Control Console |
Before you use MRUA, you must stop all processes associated with each middle tier that uses the OracleAS Metadata Repository.
Note that at this point in the upgrade process, as a prerequisite for running MRUA, all the middle tier instances should have been upgraded to 10g Release 2 (10.1.2).
There are two ways to view all the Oracle Application Server instances that use the OracleAS Metadata Repository:
Display the Farm page in the Application Server Control Console.
|
See Also: "Introduction to Administration Tools" in the Oracle Application Server Administrator's Guide for more information about the Application Server Control Console Farm page |
Use the following Distributed Configuration Management command in the Oracle home of any middle-tier or OracleAS Identity Management instance that belongs to the farm:
ORACLE_HOME/dcm/bin/dcmctl listinstances
|
See Also: Distributed Configuration Management Administrator's Guide for more information aboutdcmctl commands
|
To stop all the processes in a 10g Release 2 (10.1.2) middle tier, use the Services Control panel to stop the ProcessControl service and the Application Server Control.
Before you run MRUA, use the following procedure to make sure that none of the database objects that are required by Oracle Application Server are invalid:
Connect to the OracleAS Metadata Repository database.
For example:
METADATA_REPOSITORY_ORACLE_HOME\bin\sqlplus "connect / as sysdba"
When prompted, enter the SYS password.
Issue the following SQL command:
SELECT owner, object_type, object_name FROM all_objects WHERE status='INVALID';
The query should not return any database objects that have an Oracle Application Server component schema (such as PORTAL, WIRELESS, and so on) in the 'owner' column.
If you find any invalid objects, run the utlrp.sql script from the SQL*Plus command line to recompile the invalid objects:
@?/rdbms/admin/utlrp.sql
After you have upgraded the OracleAS Metadata Repository database, backed up the database, and stopped the dependent middle-tier installations, you can use MRUA to upgrade the component schemas in the OracleAS Metadata Repository, which now reside in the upgraded database.
|
Note: Be sure to log in to the computer where the OracleAS Metadata Repository is running as the same user who installed the Release 2 (9.0.2) or 10g (9.0.4) OracleAS Metadata Repository. MRUA must be run on the computer that hosts the OracleAS Metadata Repository that you are about to upgrade. |
To run MRUA:
Mount the Metadata Repository Upgrade Assistant and Utilities CD–ROM.
The MRUA and Utilities CD–ROM is part of the Oracle Application Server CD–ROM Pack that you receive when you order the Oracle Application Server software.
Start MRUA by entering the following command, with the following required arguments, which are described in Table 7-4:
CD_DRIVE_LETTER:\mrua\mrua.bat -oracle_home metadata_repository_oracle_home -oid_host Oracle_Internet_Directory_host -oid_ssl_port Oracle_Internet_Directory_SSL_port
Table 7-4 Summary of the Required MRUA Command Line Arguments
| Argument | Description |
|---|---|
|
-oracle_home |
The destination 10g Release 2 (10.1.2) OracleAS Metadata Repository home directory. |
|
-oid_host |
The name of the computer that hosts the Oracle Internet Directory where the OracleAS Metadata Repository is registered. |
|
-oid_ssl_port |
The secure port for the Oracle Internet Directory. For the purposes of upgrading the OracleAS Metadata Repository, you must use a secure connection to the Oracle Internet Directory. |
When you are prompted, enter the password for the database SYS user account.
MRUA needs the SYS password so it can access and modify the component schemas in the database.
When you are prompted, enter the Oracle Internet Directory cn=orcladmin administrator password.
MRUA needs the Oracle Internet Directory password to connect to the Oracle Internet Directory in which the OracleAS Metadata Repository is registered.
After you provide the required passwords, MRUA checks to be sure the Oracle Internet Directory is running and does one of the following:
If Oracle Internet Directory is down or unavailable, MRUA displays an error message and exits.
If Oracle Internet Directory is up and running, MRUA connects to the directory service and obtains additional information required to upgrade the component schemas.
If multiple instances of the OracleAS Metadata Repository are registered with the directory, MRUA prompts you to select the OracleAS Metadata Repository you want to upgrade.
You can upgrade only one OracleAS Metadata Repository at a time. You must select the OracleAS Metadata Repository on your local machine that corresponds to the value of the -oracle_home parameter.
If you are prompted to select a OracleAS Metadata Repository, select the OracleAS Metadata Repository you want to upgrade.
MRUA starts the upgrade process. As each step in the upgrade is executed, information messages appear on the screen to show the progress of the upgrade.
Example 7-1 shows an example of a typical MRUA upgrade session.
Review the output of the MRUA command; if MRUA reports any errors, see Section C.10, "Error Messages Generated By the Metadata Repository Upgrade Assistant".
|
Note: In many cases, MRUA will report that the Oracle Application Server Certificate Authority (OCA) and Oracle Ultra Search component schemas have already been upgraded. This is to be expected because in some cases, the OCA schema is updated automatically by the OracleAS Identity Management and the Oracle Ultra Search schema is updated during the database upgrade. |
Example 7-1 Sample Output from an MRUA Session
mrua.bat -oracle_home D:\oracle10g -oid_host dserv1.acme.com -oid_ssl_port 3130 Executing mrua.pl Running on Windows OracleAS Metadata Repository Upgrade Assistant 10.1.2.0.2 Enter the password for SYS: Enter the password for cn=orcladmin: Upgrading the OracleAS Metadata Repository to release 10.1.2.0.2 Calling upgrade plugin for MRUA Component upgraded successfully MRUA Calling upgrade plugin for UDDI Component upgraded successfully UDDI Calling upgrade plugin for WCS Component upgraded successfully WCS Calling upgrade plugin for OCA Component has already been upgraded OCA Calling upgrade plugin for ULTRASEARCH Component has already been upgraded ULTRASEARCH Calling upgrade plugin for WIRELESS Component upgraded successfully WIRELESS Calling upgrade plugin for WORKFLOW Component upgraded successfully WORKFLOW Calling upgrade plugin for PORTAL Component upgraded successfully PORTAL Calling upgrade plugin for DISCOVERER Component upgraded successfully DISCOVERER Calling upgrade plugin for B2B Component upgraded successfully B2B Calling upgrade plugin for ORABPEL Component upgraded successfully ORABPEL Calling upgrade plugin for BAM Component upgraded successfully BAM Calling upgrade plugin for MRC Component upgraded successfully MRC SUCCESS: All OracleAS plug-ins report successful upgrade Finished mrua.pl
The time required to run MRUA will vary, depending upon your hardware and the amount of data in your OracleAS Metadata Repository. However, testing of MRUA has shown the following typical execution times on the following hardware and software platforms:
1 hour, 40 minutes on a Sun UltraSPARC 60, dual CPU, running Solaris 2.9
45 minutes on a 2.4GHz Pentium 4, running Windows 2000 Service Pack 4
When you run MRUA, the utility generates a set of log files that you can use to troubleshoot, verify, or analyze the OracleAS Metadata Repository upgrade process. For more information, see the following sections:
If the MRUA output indicates that one or more of the component upgrades failed, review the MRUA log files, or any component log files referenced from the MRUA log files.
If the OracleAS Portal upgrade fails, then see Section 7.4.8, "Reviewing the OracleAS Portal Repository Upgrade Log Files" for information on how to proceed.
Otherwise, refer to Appendix C, "Upgrade and Compatibility Error Messages" for information about specific component error messages you might find in the log files.
If, by reviewing the log files and Appendix C, you are able to identify a solution to the upgrade failure, you can implement your solution and then re-run MRUA. When you re-run MRUA, any components that were upgraded successfully during the previous run will not be affected. However, MRUA will attempt to upgrade any components that were not upgraded successfully during a previous run of the utility.
Contact Oracle Support for any errors that are not documented or that cannot be resolved by following documented actions. Note that some errors that occur will require the repository to be restored from backup, the problem to be resolved, and another upgrade to be run.
The log files are located in the following directory in the Oracle home of the OracleAS Metadata Repository you are upgrading:
METADATA_REPOSITORY_ORACLE_HOME\upgrade\logs
MRUA generates three log files that are of particular interest when you are troubleshooting upgrade issues. The name of the log file includes the exact time the MRUA session was run. This makes it easy to identify a log file for a particular MRUA session.
For example, the three log files generated when you run MRUA at 12:36 PM on September 16, 2004 would appear as follows in the logs directory:
mrua2004-09-16_12-36-36PM.log mrua2004-09-16_12-36-36PM.err mrua2004-09-16_12-36-36PM.out
Table 7-5 shows the three log file types and the content you can expect to find in each one.
Table 7-5 Summary of the Log Files Generated by MRUA
| MRUA Log File | Description |
|---|---|
mrua<timestamp>.log |
The log file is a good place to start if you are troubleshooting a particular problem with the OracleAS Metadata Repository upgrade. This file contains a high-level summary of all the actions performed by MRUA; as a result, it can help you isolate a specific component that was not upgraded successfully. |
mrua<timestamp>.err |
The error file contains any errors or stack traces generated during the upgrade process. These errors should contain information that help you diagnose and address specific upgrade errors. |
mrua<timestamp>.out |
The output file is the largest of the three MRUA log files and it contains the most comprehensive data about the MRUA session. Use this log file to determine exactly when a particular problem occurred to and see the output generated by the MRUA subcomponents. |
This section provides information about the OracleAS Portal upgrade log files. If the OracleAS Portal upgrade fails, carefully review this section in its entirety before attempting to troubleshoot the upgrade failure.
Note that if the OracleAS Portal components were upgraded to 10g Release 2 (10.1.2) successfully, then there is no need to examine the log files.
The OracleAS Portal upgrade is made up of two underlying paths:
9.0.2 to 9.0.4 (which uses software downloaded from Metalink for Patch 2778342)
9.0.4 to 10.1.2 (which uses software included in the Metadata Repository Upgrade Assistant and Utilities CD–ROM)
Each of these two paths generates its own set of log files and temporary directories. When upgrading all the way from Release 2 (9.0.2) to 10g Release 2 (10.1.2) in a single step, log files for both paths are created.
When upgrading OracleAS Portal by running MRUA, the log files are generated into a single directory:
ORACLE_HOME\upgrade\temp\portal
When upgrading OracleAS Portal manually, as described in Section 8.5.2, "Upgrading the OracleAS Portal Repository in a Customer Database", the files are located in the directory where the upgrade was run. In all cases, any already existing log files in the relevant directory will be renamed to include a time stamp, so that they are not overwritten.
Table 7-6 Summary of the Repository Upgrade Log Files Generated by OracleAS Portal
| Log File | Description |
|---|---|
|
The log file generated by the 10g (9.0.4) to 10g Release 2 (10.1.2) OracleAS Portal upgrade. This file will always be generated if the starting version is 10g (9.0.4), as long as the checks performed at the beginning of the upgrade succeed. It will also be generated when the starting version is Release 2 (9.0.2), as long as the Release 2 (9.0.2) to 10g (9.0.4) portion of the upgrade succeeds. If this file exists and has an "Upgrade completed successfully" message at the end, the upgrade was successful, regardless of the starting version. |
|
|
The log file generated for the checks performed before the 10g (9.0.4) to 10g Release 2 (10.1.2) upgrade. This file is generated before the script begins making modifications to the repository, or when a manual upgrade from 10g (9.0.4) is run in -precheck mode. This file will always be generated if the starting version is 10g (9.0.4). It will not be generated if the starting version is Release 2 (9.0.2); |
|
|
The log file generated by the Release 2 (9.0.2) to 10g (9.0.4) OracleAS Portal upgrade. This file will always be generated if the starting version is Release 2 (9.0.2), as long as the checks performed at the beginning of the upgrade succeed. It will not be generated if the starting version is 10g (9.0.4) or if there are errors in |
|
|
The log file generated for the checks performed before the Release 2 (9.0.2) to 10g (9.0.4) upgrade begins making modifications to the repository, or when a manual upgrade fromRelease 2 (9.0.2) is run in -precheck mode. This file will always be generated if the starting version is Release 2 (9.0.2). It will not be generated if the starting version is 10g (9.0.4); |
At the end of each one of these log files, there is either a success message or a summary of all the errors that occur earlier in the file. These summary messages include references to line numbers. You can go to those lines earlier in the log file to see the errors in their context.
|
Caution: Any portals running after an upgrade that was not clean are not supported by Oracle. |
Look up any errors found in the precheck or upgrade log files using Section C.7, "Error Messages When Upgrading Oracle Application Server Portal" as a reference. Resolve any errors and warnings that have documented actions. Any errors that occur after the precheck phase require the repository to be restored from backup, the problem resolved and another upgrade run. Contact Oracle Support for any errors that are not documented or that cannot be resolved by following documented actions. When undocumented errors are found, do not attempt to run the upgrade again, run any further steps, alter any files, modify the OracleAS Portal schema, or access the OracleAS Portal instance in your browser.
The following is an example of the end of the log file after a successful upgrade (note the "Upgrade completed successfully" message and the lack of error messages):
>>> Running upg/common/popinv.pl ### Upgrade completed successfully >>> Running tmp/popinv.sql Portal SQL script started at Thu Apr 22 20:56:23 2004 Connected. Updating patch inventory. Upgrade Ended at Thu Apr 22 20:56:24 2004
Besides the MRUA log files, you can optionally query the database to verify the success of the OracleAS Metadata Repository upgrade. Specifically, you can use a SQL command to view the status of each component schema that MRUA upgrades.
|
Note: The OracleAS Metadata Repository contains schemas for all the Oracle Application Server components. However, only a subset of those component schemas must be updated by MRUA. Other schemas, such as the OracleAS Identity Management schemas, are upgraded during the Oracle Application Server installation. Still others, do not require any upgrade from previous versions. |
To see the current status of each component schema in the repository that is upgraded by MRUA:
Connect to the OracleAS Metadata Repository database.
For example:
METADATA_REPOSITORY_ORACLE_HOME\bin\sqlplus "connect / as sysdba"
When prompted, enter the SYS password.
Enter the following SQL command to verify the status of the component schemas:
SELECT comp_id,version,status FROM APP_REGISTRY;
Refer to the following example and tables for an explanation of the output of the query:
Example 7-2 shows an example of the output displayed from the component schema SQL query.
Table 7-7 describes the possible values in the COMP_ID column of the SQL query results.
Table 7-8 describes the possible values in the STATUS column of the SQL query results.
Example 7-2 Sample Output of the Component Schema SQL Query
prompt> SELECT comp_id,version,status FROM APP_REGISTRY; COMP_ID VERSION STATUS ------------------------------ ------------------------------ ----------- WIRELESS 10.1.2.0.2 VALID PORTAL 10.1.2.0.2 VALID WCS 10.1.2.0.2 VALID DISCOVERER 10.1.2.0.2 VALID MRUA 10.1.2.0.2 VALID B2B 10.1.2.0.2 VALID WORKFLOW 10.1.2.0.2 VALID OCA 10.1.2.0.2 VALID UDDI 10.1.2.0.2 VALID MRC 10.1.2.0.2 VALID ORABPEL 10.1.2.0.2 VALID BAM 10.1.2.0.2 VALID 11 rows selected.
Table 7-7 Component IDs in the OracleAS Metadata Repository
| Component ID | Description |
|---|---|
|
Oracle Application Server Wireless |
|
|
Oracle Application Server Portal |
|
|
Oracle Application Server Web Clipping |
|
|
Oracle Application Server Business Intelligence Discoverer |
|
|
Oracle Application Server Metadata Repository Upgrade Assistant |
|
|
Oracle Application Server Integration B2B |
|
|
Oracle Workflow |
|
|
Oracle Application Server Certificate Authority |
|
|
Oracle Application Server UDDI Registry |
|
|
Oracle Application Server Metadata Repository Container |
|
|
ORABPEL |
Oracle Business Process Execution Language (BPEL) Process Manager |
|
BAM |
Oracle BPEL Process Analytics |
Table 7-8 Component Status Indicators in the OracleAS Metadata Repository
| Status | Description |
|---|---|
|
LOADING |
MRUA has begun creating the component database objects, but not all the component objects are created and loaded into the database. |
|
LOADED |
MRUA has created all the component database objects and loaded them into the database. MRUA can now begin upgrading the component schemas. |
|
UPGRADING |
MRUA has begun upgrading the schemas for this component, but the upgrade is not complete. |
|
UPGRADED |
MRUA has finished upgrading the schemas for this component. |
|
VALID |
The component schemas have been upgraded and are valid. This is the expected status after a successful upgrade to Oracle Application Server 10g Release 2 (10.1.2). |
|
INVALID |
The component schemas have been upgraded, but the database component schemas are invalid. This state can be caused by a non-recoverable error or invalid data. See Section 7.4.7 for information about reviewing the MRUA log files. |
The following sections describe the tasks to perform after running MRUA to upgrade your OracleAS Metadata Repository component schemas:
The following sections describe how to complete the upgrade of the OracleAS Portal schema:
Starting all Middle Tiers That Use The Upgraded Portal Instance
Reconfiguring OracleAS Portal to Work with Delegated Administration Services
If your starting version was Oracle9iAS Portal 9.0.2.x, follow the steps in this section to reconfigure OracleAS Portal for Oracle Internet Directory.
This reconfiguration is necessary because some Oracle Internet Directory privileges have changed between Release 2 (9.0.2) and 10g (10.1.2). For example, the subscription for Oracle Directory Integration and Provisioning event notifications has changed and Oracle Delegated Administration Services URLs have changed.
When you run the ptlconfig command, as described in the following procedure, values such as these, which are cached in the Portal schema, get updated accordingly:
Change directory to the following location in the destination middle tier Oracle home:
DESTINATION_ORACLE_HOME\portal\conf
Run the following command:
ptlconfig -dad portal_DAD -oid
In this command, portal_DAD is the DAD of the OracleAS Portal repository that you just upgraded.
|
See Also: Oracle Application Server Portal Configuration Guide, for more information about theptlconfig tool
|
After the script has executed successfully, start each middle tier that is using the upgraded Portal instance by performing these steps:
Start OPMN and its managed processes by starting the Process Manager service in the Services control panel.
Start the Application Server Control service in the Services control panel.
By default, the portlet repository is upgraded in-place in the OracleAS Portal schema. The existing pages, templates, items, and so on, in the portlet repository are upgraded, and the new portlets are added into the repository. Since the old settings are preserved, the pages look very similar to the way they did before the upgrade was run.
|
Note: If your starting version is Oracle9iAS Portal 9.0.2 and you had rendered the Portlet Repository as grouped by Provider names, then after the upgrade, the folders in the repository will be grouped by category, because the Group by Provider Name option has been deprecated since OracleAS 10g (9.0.4).To create a similar organization, assign the portlet names to categories representing the Provider names. |
If you want the repository to have the appearance of a newly installed instance, a script is available to re-create the upgraded portlet repository. The script removes the existing portlet repository and re-creates it. Use the script only if you do not wish to preserve customizations, settings, styles, banners, and so on in the portlet repository.
To re-create the portlet repository, follow these steps after starting the middle tiers as described in Section 7.5.1.2, "Starting all Middle Tiers That Use The Upgraded Portal Instance":
Perform a backup of the database, since the script overwrites the repository and is not reversible.
Navigate to the following directory on the OracleAS Metadata Repository Upgrade Assistant and Utilities CD–ROM, which contains the prrplc.sql script:
MRUA_CDROM_ROOT\portal\admin\plsql\upg\common
Log in to the OracleAS Metadata Repository database as Portal schema user from SQL*Plus.
If there were no errors in the OracleAS Portal Repository upgrade, you can access your upgraded Portal. Open a browser and navigate to the following URL:
http://host.domain:port/pls/portal_DAD
For example:
http://portalhost42.acme.com:7777/pls/portal
Missing Oracle Text indexes are created during the OracleAS Portal upgrade process, but they are not populated, as this can be very time consuming. The new indexes are populated once the upgrade is complete, when the next synchronization job is scheduled.
If you need to shut down the database after the upgrade (to back up) and the Oracle Text index synchronization job has started, consider the impact of the following shutdown commands on the synchronization process:
Shutdown Immediate or Abort
The indexing job stops immediately and is rolled back.
Shutdown Normal
Entire indexing job finishes before the database shuts down.
Shutdown Transactional
Synchronization of the current index is allowed to finish before the database shuts down. If one or more indexes still need to be synchronized, synchronization of the next index is not started.
In releases of OracleAS Portal prior to 10g Release 2 (10.1.2), if the Infrastructure and Application Server middle tier were separated onto different hosts or protocols, the user and group Lists of Values (LOVs) required configuration to accommodate the JavaScript Origin Server Security policy. The resultant JavaScript errors were due to the OracleAS Portal and Delegated Administration Services (DAS) residing in different domains.
There were two options provided for resolution of this issue:
Setting up of a common-domain by running the script secjsdom.sql
Deploying DAS on the middle tier.
In OracleAS Portal 10g Release 2 (10.1.2), the implementation of the LOVs has been modified to support a callback method, removing the cross-domain issue and the need for the configuration steps above. However, this callback mechanism requires a corresponding patch to the DAS environment to support the use of LOVs across domains.
Support for the callback method has been included in DAS versions 9.0.4.1 and later. Conversely, if you are using DAS version 9.0.2.3 you can apply patch 3278638 to enable callback support.
If you have installed the appropriate DAS version in your environment, and have not previously implemented the configuration options mentioned above, then no subsequent configuration steps are required in OracleAS Portal to support the LOVs on a separate host. However, if you used the configuration options mentioned above, it is required to remove these steps. This can be done as follows:
If a common domain was defined, reset it by executing the secjsdom.sql script as follows:
From your operating system command prompt, go to the following directory:
DESTINATION_MIDTIER_ORACLE_HOME\portal\admin\plsql\wwc
Using SQL*Plus, connect to the OracleAS Portal Repository as the schema owner and run the following commands:
@secjsdom '' commit;
If OracleAS Portal has been configured to use a locally deployed DAS servlet, reconfigure it to point to the Infrastructure tier by running the secdaslc.sql script as follows:
From the operating system prompt, go to the following directory:
DESTINATION_MIDTIER_ORACLE_HOME\portal\admin\plsql\wwc
Using SQL*Plus, connect to the OracleAS Portal Repository as the schema owner and run the following commands:
@secdaslc N commit;
If you have customized the login portlet, you must update it to work in this release. In prior releases, user credentials were posted to OracleAS Portal's wwptl_login.login_url procedure. In this release, the user credentials must be passed to OracleAS Single Sign-On's wwsso_app_admin.ls_login procedure instead. Follow the steps outlined in OracleMetaLink note 290445.1 to update your customized login portlet to use wwsso_app_admin.ls_login.
|
Note: You do not have to perform any additional steps at this time if you followed the instructions provided in the patch documentation after applying Oracle Application Server 10g (9.0.4) Patch Set 1 (9.0.4.1), or any of the following one-off patches: |
To generate performance reports for OracleAS Portal, you must use a set of SQL scripts. These scripts are used to load OracleAS Portal log files into a database table and create reports based on that information. The scripts are located in the following directory:
ORACLE_HOME\portal\admin\plsql\perf
If you are already using the performance reporting scripts, then after upgrading to OracleAS Portal 10.1.2.0.2, you must run the new copy of the following file:
ORACLE_HOME\portal\admin\plsql\perf\install\update.sql
This is to accommodate the new URL format for Repository requests and to enable collection of new data. If this is not done, then the scripts will not work.
For details about how you can use the scripts to monitor OracleAS Portal performance, refer to the following file in the scripts subdirectory:
ORACLE_HOME\portal\admin\plsql\perf\scripts\README.html
After you upgrade the OracleAS Metadata Repository and restart your middle-tier installations, Oracle Sensor EdgeServer Processes will not be created automatically. Instead, you must create these processes manually after you run the OracleAS Upgrade Assistant and after you have upgraded the OracleAS Metadata Repository to 10g Release 2 (10.1.2).
|
See Also: "Managing the OracleAS Wireless Server" in the Oracle Application Server Wireless Administrator's Guide for information about using the Application Server Control Console to create Oracle Sensor EdgeServer Processes |
After you complete the OracleAS Metadata Repository upgrade process, you can start the middle tiers associated with the OracleAS Metadata Repository. For each middle tier, perform the following steps:
Start OPMN and its managed processes by starting the Process Manager service in the Services control panel.
Start the Application Server Control service in the Services control panel.
