|
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 middle tier of your Oracle Application Server installation. It includes instructions on how to prepare your system for a successful upgrade, and how to start and use the Oracle Application Server Upgrade Assistant.
This chapter also details any post-upgrade tasks you must perform on individual components after the OracleAS Upgrade Assistant has finished processing.
|
See Also: Section 1.5, "Typical Upgrade Scenarios" for a general overview of the middle tier upgrade process. |
The chapter is divided into the following major sections:
Task 1: Install a New 10g Release 2 (10.1.2) Middle Tier In Preparation for Upgrade
Task 6: Start the Upgraded Middle Tier and Perform Final Upgrade Tasks
Special Considerations When Upgrading OracleAS Clusters, OracleAS Wireless, or Oracle Workflow
|
Note: Only the 10g Release 2 (10.1.2) Oracle home is changed in the upgrade process. This makes it possible to revert to using the source Oracle home. |
For each middle tier, you perform the following upgrade tasks:
If you are upgrading middle tier that is part of an OracleAS Cluster, or if you are upgrading OracleAS Wireless or Oracle Workflow, review Section 4.10, "Special Considerations When Upgrading OracleAS Clusters, OracleAS Wireless, or Oracle Workflow".
Install a new Oracle Application Server 10g Release 2 (10.1.2) Oracle home on the same host as the original middle-tier.
Use the OracleAS Upgrade Assistant, which is installed in the upgrade directory of the 10g Release 2 (10.1.2) middle tier Oracle home, to copy your custom applications and configuration data to the new Oracle home.
Perform any required post-upgrade tasks for specific Oracle Application Server components that you have used or configured.
Start and verify the newly upgraded middle tier.
Optionally, decommission the original Release 2 (9.0.2), Release 2 (9.0.3), or 10g (9.0.4) Oracle home.
The first step in upgrading an Oracle Application Server middle tier is to install a new 10g Release 2 (10.1.2) middle tier, which will serve as the destination Oracle home.
The following sections provide information on the tasks you need to perform when installing a new 10g Release 2 (10.1.2) Middle Tier in preparation for upgrade:
If you are using a Release 2 (9.0.2) Oracle Internet Directory, use the procedure in Section 2.6.5, "Updating an Entry in the Release 2 (9.0.2) Oracle Internet Directory Before Installing the 10g Release 2 (10.1.2) Middle Tier".
This step is required in order for the 10g Release 2 (10.1.2) middle tier to operate with the Release 2 (9.0.2) Oracle Internet Directory.
Before you upgrade your Release 2 (9.0.2) middle tiers, make sure that the mod_osso Oracle HTTP Server module is configured properly. The mod_osso module provides authentication to OracleAS OracleAS Single Sign-On applications.
Specifically, you must verify that mod_osso is configured to use the OracleAS Web Cache port. By default, when you install Release 2 (9.0.2), mod_osso is configured to use the Oracle HTTP Server listen port.
To reconfigure mod_osso, use the Release 2 (9.0.2) ossoreg.jar utility to re-register the Release 2 (9.0.2) OracleAS Single Sign-On software so it uses the OracleAS Web Cache port.
For information about using the ossoreg.jar utility, see "Reregistering the Oracle HTTP Server with the Single Sign-On Server" in the Oracle9iAS Single Sign-On Release Notes. You can find the Release 2 (9.0.2) release notes in the platform-specific Release 2 (9.0.2) documentation libraries available on the Oracle Technology Network:
http://www.oracle.com/technology/documentation/ias.html
When you run the Release 2 (9.0.2) ossoreg.jar utility replace all the port designations with the OracleAS Web Cache port, which can be found in the portlist.ini file in the Release 2 (9.0.2) Oracle home:
ORACLE_HOME\install\portlist.ini
When you view the contents of the portlist.ini file, the first entry is the Oracle HTTP Server port against which the OracleAS Single Sign-On server is registered by default. The next port listed in the file is the OracleAS Web Cache port. Use this OracleAS Web Cache port when you run the ossoreg.jar utility.
The middle-tier upgrade procedures have been tested using the latest patchsets available from OracleMetaLink.
As a result, before you install 10g Release 2 (10.1.2) in preparation for an upgrade from Oracle Application Server Release 2 (9.0.2), apply the latest Oracle Application Server 9.0.2 patchsets to the source middle tier that you are upgrading and to the OracleAS Infrastructure components that the middle tier relies 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.
The first step in upgrading a middle tier is to install Oracle Application Server 10g Release 2 (10.1.2) middle tier.
To save time later and to avoid potential problems when upgrading to the new Oracle home, review the following checklist before you install the new 10g Release 2 (10.1.2) destination Oracle home:
Refer to the Oracle Application Server Installation Guide specific to your platform for complete instructions on installing the 10g Release 2 (10.1.2) middle tier.
Install the 10g Release 2 (10.1.2) middle tier on the same computer as the source middle tier
Use the same operating system user that installed the source middle tier
Install the 10g Release 2 (10.1.2) middle tier in a separate Oracle home from the source middle tier
During the installation, select an installation type that is compatible with source middle tier
If the source middle tier users any OracleAS Infrastructure components, be sure that the 10g Release 2 (10.1.2) middle tier users the same OracleAS Metadata Repository and OracleAS Identity Management as the source middle tier.
If you are upgrading a middle tier that is part of an OracleAS Cluster, if you are upgrading an OracleAS Wireless Release 2 (9.0.2) middle tier, or if you are upgrading Oracle Workflow, then refer to the following section before you install Oracle Application Server 10g Release 2 (10.1.2):
Be aware that only components that are configured in the destination Oracle home will be functional after the middle tier upgrade has completed.
If you are upgrading OracleAS Portal, note that the OracleAS Portal component will not be functional in the Oracle Application Server 10g Release 2 (10.1.2) instance until after you run the OracleAS Upgrade Assistant. As a result, OracleAS Portal can be accessed only by the source middle tiers until after the middle tier upgrade is complete.
The following sections provide information about tasks you must perform before you begin upgrading your middle tier application server instances:
When you run the OracleAS Upgrade Assistant, it will stop all the processes in the source Oracle home and the destination Oracle home, except for the Enterprise Manager Web site in a Release 2 (9.0.2) or Release 2 (9.0.3) source Oracle home.
For several reasons, the OracleAS Upgrade Assistant cannot stop the Enterprise Manager Web site automatically. Instead, you must use the following procedure to stop the Enterprise Manager Web site manually:
If you have multiple Release 2 (9.0.2) or Release 2 (9.0.3) instances on the same host, do the following:
Determine which instance hosts the active Enterprise Manager Web site.
The active Enterprise Manager Web site is stored in the following entry in the Windows registry:
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\em_loc
Stop the active Enterprise Manager Web site as follows:
ACTIVE_EM_ORACLE_HOME\bin\emctl stop
Enterprise Manager prompts you for the ias_admin management password.
If the instance you want to upgrade contains the active Enterprise Manager Web site, switch the active Oracle Enterprise Manager to another Release 2 (9.0.2) or Release 2 (9.0.3) instance using the following command:
ACTIVE_EM_ORACLE_HOME\bin\emctl switch home
This command displays a dialog where you can select another Oracle9iAS instance that contains the active Oracle Enterprise Manager.
If the instance you want to upgrade is the only Release 2 (9.0.2) or Release 2 (9.0.3) instance on the host, stop the Enterprise Manager Web site as follows:
SOURCE_ORACLE_HOME\bin\emctl stop
If you are upgrading a large number of applications or a large number of OC4J instances, it might be helpful to increase the memory for the extract phase of the OC4J upgrade. The extract phase of the upgrade process starts a new Java process; that is, it has a new Java Virtual Machine (JVM). You can configure the minimum and maximum memory for the JVM. To do this, you configure the JavaVM property in the following configuration file:
DESTINATION_ORACLE_HOME\upgrade\Oc4jPlugin.cfg
Example 4-1 shows the JavaVM property and the arguments you can adjust.
Example 4-1 JavaVM Property in Oc4jPlugin.cfg File
<JavaVM> <JVMproperties property="-Xms256m"/> <JVMproperties property="-Xmx512m"/> </JavaVM>
The default values of 256MB minimum and 512MB maximum are shown in Example 4-1; however, 1024MB is a plausible upper limit for upgrading several OC4J instances and many large applications.
Before you upgrade any middle tier that uses an Infrastructure, the Infrastructure must be started and accessible. If the Infrastructure is stopped, certain upgrade processes will fail (for example, Oracle Application Server Containers for J2EE, OracleAS Portal, and Oracle Application Server Wireless).
The following sections provide instructions for using OracleAS Upgrade Assistant to upgrade your Oracle Application Server instances to 10g Release 2 (10.1.2):
Optionally Specifying Logging Behaviors for the OracleAS Upgrade Assistant
Performing an Upgrade with the OracleAS Upgrade Assistant (Graphical User Interface (GUI) Version)
Performing an Upgrade with the OracleAS Upgrade Assistant (Command-line Version)
The OracleAS Upgrade Assistant provides a set of log files that you can use to troubleshoot any problems you might run into while upgrading your Oracle Application Server middle tiers.
Optionally, you can customize the default logging behavior of the OracleAS Upgrade Assistant by setting properties in the following configuration file:
DESTINATION_ORACLE_HOME\upgrade\iasua.properties
The logging properties and their uses are:
log.level — Use this property to specify the level of logging for the OracleAS Upgrade Assistant and all component plug-ins. For example, log.level=NOTIFICATION would set the logging level for all components upgraded by the OracleAS Upgrade Assistant to NOTIFICATION. (The default value is NOTIFICATION.)
<plug-in name>.log.level — Use this property to specify the level of logging for a specific component plug-in, used to override the log.level property for a given component upgrade. For example, OC4J.log.level=TRACE would set the logging level for the Oracle Application Server Containers for J2EE upgrade to TRACE, even if the log level for the OracleAS Upgrade Assistant was set to NOTIFICATION. (The default value is NOTIFICATION.)
log.append — Use this property to specify whether to append log entries to the existing log file or create a new log file. For example, log.append=TRUE would append log entries to the existing log file. (The default value is TRUE.)
|
Note: Property names are case sensitive. Property values are case insensitive. |
Table 4-1 Logging Properties for the OracleAS Upgrade Assistant
| Property Name | Description | Valid Values |
|---|---|---|
|
log.level |
Level of logging for the OracleAS Upgrade Assistant and all component plug-ins |
NOTIFICATION (default value) ERROR TRACE DEBUG |
|
<plug-in name>.log.level |
Level of logging for a specific component plug-in, used to override the log.level property for a given component upgrade Possible values of <plug-in name> are OPMN, InstanceConfig, OHS, OC4J, WebCache, modplsql, EM, UDDI, UltraSearch, Portal, Wireless, and Net |
NOTIFICATION (default value) ERROR TRACE DEBUG |
|
log.append |
Specifies whether to append log entries to the existing log file or create a new log file |
TRUE (default value) FALSE |
This section provides step-by step instructions for using the OracleAS Upgrade Assistant GUI version to perform an upgrade:
Log in to the user account that was used to install the source Oracle home.
Start the OracleAS Upgrade Assistant with the command:
DESTINATION_ORACLE_HOME\upgrade\iasua.bat
The Welcome screen appears.
Click Next.
The Oracle Homes screen appears. The Source Oracle Home drop-down list contains the names of Release 2 (9.0.2), Release 2 (9.0.3), and 10g (9.0.4) Oracle homes that are found in the inventory of Oracle products on the current computer and that were installed using an installation type that is compatible with the installation type of the destination Oracle home.
The destination Oracle home is the 10g Release 2 (10.1.2) Oracle home in which the OracleAS Upgrade Assistant is running.
Select the source Oracle home that you want to upgrade from the drop-down list; then, click Next.
The OracleAS Upgrade Assistant performs many of the required pre-upgrade tasks automatically before it begins the upgrade process.
However, in some situations, the Upgrade Assistant displays a dialog box, which provides you with a list of the pre-upgrade requirements that are not performed automatically. These requirements must be met in order for the OracleAS Upgrade Assistant to successfully continue.
Specifically, there are two scenarios that cause this dialog box to appear:
If you are upgrading an Oracle Application Server Release 2 (9.0.2) or Release 2 (9.0.3) middle tier instance, this dialog box prompts you to be sure the Oracle Enterprise Manager Web site has been stopped.
If you are upgrading a middle-tier instance that requires an OracleAS Infrastructure component, this dialog box prompts you to be sure that the required Infrastructure components are up and running.
Ensure that all requirements are fulfilled, and click Yes.
The Examining Components dialog box appears. The OracleAS Upgrade Assistant examines each component in the source Oracle home to determine whether it needs to be upgraded.
The Status column for each component contains one of the examination status values shown in Table 4-2.
Table 4-2 OracleAS Upgrade Assistant Component Examination Status
| Status | Meaning |
|---|---|
|
in progress... |
The OracleAS Upgrade Assistant is examining the component's upgrade items. |
|
pending... |
The component will be examined when the OracleAS Upgrade Assistant finishes examining the current component. |
|
succeeded |
The component was examined successfully. |
|
failed |
There was a failure during the examination of the component. The OracleAS Upgrade Assistant cannot upgrade the component. |
If one or more components failed, the OracleAS Upgrade Assistant displays an Examination Failure Warning dialog box.
If the upgrade cannot continue without you addressing the failed examination, a dialog box tells you to fix the problem and restart the OracleAS Upgrade Assistant later.
If the examination uncovers a problem that affects only a subset of the components you are upgrading, OracleAS Upgrade Assistant displays a dialog box that identifies the component that failed. At this point, click Help for more information about what to do next.
If all component examinations succeed, the Summary screen appears.
Scroll to view the components, clicking the plus symbol (+) to expand a component's upgrade items. Review the components; then, click Finish.
|
Note: The Summary screen is the last screen before upgrade processing begins. Before you click Finish, verify that the choices on previous screens are correct and the upgrade items listed are ready to upgrade. |
The Upgrading screen appears.
The Status column for each component contains one of the status values shown in Table 4-3.
Table 4-3 OracleAS Upgrade Assistant Upgrading Status
| Status | Meaning |
|---|---|
|
in progress... |
The OracleAS Upgrade Assistant is upgrading the component's upgrade items. |
|
pending... |
The component will be upgraded when the OracleAS Upgrade Assistant finishes upgrading the current component. |
|
succeeded |
The component was upgraded successfully. |
|
failed |
The OracleAS Upgrade Assistant could not upgrade the component. |
If the upgrade completes successfully, then the Upgrade Succeeded screen appears.
If the upgrade fails, the Upgrade Failed screen appears.
Do one of the following.
Click OK to close the Upgrade Failure screen and remedy the conditions that prevented the components from being upgraded. Start the OracleAS Upgrade Assistant again.
|
See Also: Section 4.5.1, "Resolving OracleAS Upgrade Assistant Errors" and Section 4.5.2, "Restarting the OracleAS Upgrade Assistant" for instructions on how to resolve the errors and restart the OracleAS Upgrade Assistant. |
Click OK to close the Upgrade Succeeded screen.
The Upgrade Succeeded screen specifies the location of the upgrade log file and lists the post-upgrade tasks to be performed for various components.
This section explains how to start and use the OracleAS Upgrade Assistant command-line version to perform an upgrade.
|
Note: The OracleAS Upgrade Assistant examines components differently in the command-line version and the GUI version.If the examination of a component fails in the command line version, then the upgrade is not performed. If the examination of a component fails in the GUI version, the following choices are provided: retry, continue with an incomplete upgrade, specify another Oracle home, or cancel the upgrade. |
Start the OracleAS Upgrade Assistant with the command:
DESTINATION_ORACLE_HOME\upgrade\iasua.bat -sourcehome SOURCE_ORACLE_HOME
Table 4-4 Summary of the OracleAS Upgrade Assistant Command-Line Arguments
Example 4-2 shows a sample of the output you should see from the iasua.bat command. If the middle tier you are upgrading relies on an OracleAS Infrastructure, the prompt reminds you to start the Infrastructure; if the middle tier is a Release 2 (9.0.2) or Release 2 (9.0.3) installation, the prompt reminds you to stop the Enterprise Manager Web site process, which OracleAS Upgrade Assistant cannot stop automatically.
Ensure that all the listed requirements are met; then, enter yes in answer to the prompt.
Messages similar to those in Example 4-3 appear on the screen. (The messages vary according to components found in the Oracle home).
If any error messages appear after Step 2, correct the errors as explained in Section 4.5.1, "Resolving OracleAS Upgrade Assistant Errors". Then restart the Upgrade Assistant and perform the upgrade process again.
Example 4-2 Sample Output from the Command-Line OracleAS Upgrade Assistant
prompt> iasua.bat -sourcehome D:\private\oracle\appserver1 Validating Oracle homes Validating component plug-ins Initializing component plug-ins Pre-upgrade requirements: Start the Infrastructure Associated with the source and destination Oracle home. Verify that each of the pre-upgrade requirements above have been met. Have the pre-upgrade requirements been met?[No]Yes
Example 4-3 Additional Sample Output from the Command-Line OracleAS Upgrade Assistant
Examining component "Oracle Process Manager and Notification Server (OPMN)" Examining component "Instance Configuration" Examining component "Oracle Application Server Containers for J2EE (OC4J)" Examining component "Oracle HTTP Server" Examining component "OracleAS Web Cache" Examining component "Oracle mod_plsql" Examining component "Oracle Enterprise Manager" Upgrading component "Oracle Process Manager and Notification Server (OPMN)" Upgrading component "Instance Configuration" Upgrading component "Oracle Application Server Containers for J2EE (OC4J)" Upgrading component "Oracle HTTP Server" Upgrading component "OracleAS Web Cache" Upgrading component "Oracle mod_plsql" Upgrading component "Oracle Enterprise Manager" The command completed successfully
The following sections describe how you can troubleshoot any problems that occur during the middle tier upgrade:
If errors occur at either stage of the upgrade process, you must correct the conditions that caused them before you try the upgrade again. The following sections provide some guidance in resolving OracleAS Upgrade Assistant errors:
Under certain conditions, the OracleAS Upgrade Assistant cannot perform an upgrade. Among these are that the starting configuration is unsupported, processes are running in the Oracle homes, the Infrastructure services are unavailable, or there is insufficient memory for a large-scale OC4J application upgrade.
This section identifies each condition and its cause(s), and explains how to resolve it.
If the source Oracle home does not appear as expected in the drop-down list on the Oracle Homes, suspect one of these conditions: wrong installation type, Oracle homes are on different computers, or the Oracle home is not identified in the inventory of Oracle products. The solution for each of these is detailed below.
Wrong Installation Type The source Oracle home will not appear if the installation type of the source middle tier is not compatible with the installation type of the destination middle tier instance. If this is the case, you must do one of the following:
Expand the installation type, as described in Section 1.6.3, "A Note About Expanding or Changing an Installation Type".
Reinstall the destination middle tier using an installation type that is compatible with the source middle tier.
Oracle Homes on Different Computers Another case in which the source middle tier will not appear as a selection is that the source middle tier instance is installed on a different computer from the destination middle tier instance. If this is the case, you must install the destination middle tier instance on the same computer as the source instance to be upgraded.
Oracle Home Not Identified in the Oracle Inventory The OracleAS Upgrade Assistant locates Oracle Application Server Oracle homes on your system by analyzing the contents of the Oracle inventory.
Every time you install an Oracle software product on a host computer, Oracle Universal Installer saves information about the software installation on your hard disk. The directories and files that contain this software configuration information are referred to as the Oracle Universal Installer inventory.In some cases, a particular installation may not appear in the inventory. It could be that the inventory directory was deleted or damaged, or it could be that multiple inventories are installed on the computer.
|
See Also: Oracle Universal Installer Concepts for information about the Oracle Universal Installer inventory.Oracle Universal Installer Concepts is available as part of the Oracle Database 10g (10.1.0.2) documentation library available on OTN: http://www.oracle.com/technology/documentation/database10g.html |
If the upgrade fails during the OPMN, OC4J or Oracle HTTP Server upgrade, it is probably because OPMN is still running in one or both instances (source and destination). You must stop OPMN before starting the OracleAS Upgrade Assistant.
If the upgrade fails during the examination phase, it is probably because the Infrastructure is unavailable. The OracleAS Upgrade Assistant needs the Infrastructure services for certain operations, so the Infrastructure must be started before you start the OracleAS Upgrade Assistant.
You can use the OracleAS Upgrade Assistant log file to determine the cause of examination and upgrade failures.
The OracleAS Upgrade Assistant log file is located at:
DESTINATION_ORACLE_HOME\upgrade\log\iasua.log
|
Note: By default, the OracleAS Upgrade Assistant appends logging data to the existing log file. To modify this default behavior so that each session of OracleAS Upgrade Assistant overwrites the existing log file, see Section 4.4.1, "Optionally Specifying Logging Behaviors for the OracleAS Upgrade Assistant". |
To determine the cause of an examination failure:
Note the name of the failed component in the OracleAS Upgrade Assistant dialog or command-line output.
Open the following OracleAS Upgrade Assistant log file:
DESTINATION_ORACLE_HOME\upgrade\log\iasua.log
Search for the message Starting to examine component_name.
Refer to Appendix C, "Upgrade and Compatibility Error Messages" for information about specific error messages in the Upgrade log files.
To determine the cause of an upgrade failure:
Note the name of the failed component in the OracleAS Upgrade Assistant dialog or command-line output.
Open the Upgrade log file:
DESTINATION_ORACLE_HOME\upgrade\log\iasua.log
Search for the message Starting to upgrade component_name.
Refer to Appendix C, "Upgrade and Compatibility Error Messages" for information about specific error messages in the Upgrade log files.
The following sections discuss reasons for which an Oracle Application Server Containers for J2EE upgrade may fail and ways you can address the issues:
If a configuration does not perform as expected after an upgrade, it might be because configuration changes were made to OC4J application files by means other than the Application Server Control Console. Only the changes made by the Application Server Control Console will be included in the OC4J upgrade performed by the OracleAS Upgrade Assistant. Manually edited files may not be in the scope of the managed configuration, and the edits may not be preserved in an upgrade.
OC4J deployment enforces J2EE compliance rules, so the OracleAS Upgrade Assistant may not upgrade applications that are not fully J2EE compliant. The OracleAS Upgrade Assistant simply reads the files in the source Oracle home and attempts to deploy them to the destination Oracle home; if deployment fails, it could be because an application is not J2EE compliant. If the OracleAS Upgrade Assistant cannot deploy an application for any reason, it logs the exception in the following log file:
DESTINATION_ORACLE_HOME\upgrade\log\iasua.log
The exception may not be explicitly described as a J2EE compliance issue, but that may be the reason for the failure. Knowledge of the J2EE and EJB specifications, and the EJB features used in applications will be helpful in preventing and troubleshooting deployment failures. Note that 10g Release 2 (10.1.2) supports a higher version of the EJB specification than Release 2 (9.0.2) or Release 2 (9.0.3).
While the development of J2EE applications is standardized and portable, the XML configuration files are not. Multiple XML files may need to be configured for an OC4J application to be deployed, and the required configuration varies according to the services the application uses. For example, if the application uses a database, the DataSource object in the data-sources.xml file must be configured.
It is a good idea to review all applications for overall J2EE compliance before upgrading them, since there are cases in which an application is deployable, but delivers unpredictable or undesirable server behavior. For example, ensure that each application has a unique context root defined in application.xml.
The dcmctl utility provides a J2EE compliance validation command. It takes one input, the name of an EAR file, and then lists non-compliant characteristics of that file. The syntax is:
DESTINATION_ORACLE_HOME\dcm\bin\dcmctl validateEarFile -f full_path_and_filename_for_ear_file
You must provide the full path to the EAR file.
If you connect to the Internet using a proxy server, you must configure proxy settings so that the validation routine can access DTDs (for example, on the Sun Microsystems site).
For more information, see Section 4.5.1.3.4, "Configuring Proxy Settings for the validateEarFile Command".
If you do not use a proxy server to connect to an external network, use the -noproxy flag with the command. For example:
DESTINATION_ORACLE_HOME\dcm\bin\dcmctl validateEarFile -f full_path_and_filename_for_ear_file -noproxy
See Example 4-4 and Example 4-5 to review sample output from the validateEarFile command.
Example 4-4 validateEarFile Command and Output for J2EE-Compliant Application
dcmctl validateEarFile -v -f simple.ear No J2EE XML/DTD validation errors were found
Example 4-5 validateEarFile Command and Output for non-J2EE-Compliant Application
dcmctl validateEarFile -v -f petstore.ear
Warning: J2EE/DTD validation errors were found
ADMN-906001 {0} Base Exception:
oracle.ias.sysmgmt.deployment.j2ee.exception.J2eeDeploymentException:
Cannot get xml document by parsing /var/tmp/jar50152.tmp: Invalid element
'servlet' in content of 'web-app', expected elements '[servlet-mapping,
session-config, mime-mapping, welcome-file-list,error-page, taglib,
resource-ref, security-constraint, login-config, security-role, env-entry,
ejb-ref]'.
To configure the proxy settings for the validateEarFile command, you define an environment variable called ORACLE_DCM_JVM_ARGS, which specifies a hostname and port for the proxy.
For example, on Windows 2000 systems, you can use the System control panel as follows:
Open the System control panel.
Click the Advanced tab.
Click Environment Variables to display the Environment Variables dialog box.
Click New to display the New beneath the System Variables list to display the New System Variable dialog box.
Enter ORACLE_DCM_JVM_ARGS in the Variable Name field, and enter the following in the Variable Value field:
-Dhttp.Proxyhost=hostname.domain -Dhttp.Proxyport=port
In this example, replace hostname.domain with the host name and domain for the proxy server, and replace port with the port for the proxy server.
Alternatively, you can issue this command to set the variable in a DOS Command window:
set ORACLE_DCM_JVM_ARGS=-Dhttp.Proxyhost=www-proxy.hostname.com -Dhttp.Proxyport=9999
You can restart the OracleAS Upgrade Assistant after it has partially or completely processed an Oracle home. Follow these steps:
Start the OracleAS Upgrade Assistant GUI version as described in Section 4.4.2, or the command-line version as described in Section 4.4.3.
The OracleAS Upgrade Assistant displays one of the following messages, depending on the outcome of the previous upgrade:
If the previous upgrade was unsuccessful, then the message is:
The OracleAS Upgrade Assistant has already processed this destination Oracle home directory, it didn't complete successfully.
If the previous upgrade was successful, then the message is:
The OracleAS Upgrade Assistant has already successfully processed this destination Oracle home directory.
Close the dialog (GUI version) or enter Yes (command-line version) and continue with the upgrade.
This section explains how to perform the tasks that may be necessary to make the newly upgraded 10g Release 2 (10.1.2) instance functional after the OracleAS Upgrade Assistant has finished executing.
This section contains the following topics:
Completing the Oracle Application Server Containers for J2EE (OC4J) Upgrade
Completing the Oracle Business Intelligence Discoverer Viewer Upgrade
Completing the Oracle Application Server Reports Services Upgrade
Completing the Oracle Application Server Forms Services Upgrade
After you upgrade a middle tier to Oracle Application Server 10g Release 2 (10.1.2), the upgraded instance is configured by OracleAS Upgrade Assistant to use the same ports that were used by the source instance. For this reason, after upgrade, you cannot start both the source and destination middle tier instances at the same time; otherwise, port conflicts will occur.
Refer to the following sections for important information about port assignments before and after upgrade:
Note that the portlist.ini file does not reflect the upgraded port settings; instead, it lists the port values assigned by the installer when the destination instance was initially installed. The portlist.ini file can be found in the following location in the destination Oracle home:
DESTINATION_ORACLE_HOME\install\portlist.ini
Another way to review the current port settings for the upgraded middle tier, is to use the Ports page on the Application Server Home page in the Application Server Control Console. The Ports page lists all the ports in use by the Oracle Application Server instance.
|
See Also: "Introduction to Administration Tools" in the Oracle Application Server Administrator's Guide for more information about using the Application Server Control Console |
To display the Application Server Control Console, enter the following URL in your browser:
http://appserver_host_name:app_server_control_port_number
If you do not know the Application Server Control Console port, you can locate the port number by checking the StandaloneConsoleURL entry in the following configuration file in the application server Oracle home:
DESTINATION_ORACLE_HOME\sysman\emd\targets.xml
See Also:
"Managing Ports" in the Oracle Application Server Administrator's Guide
If you are upgrading from Release 2 (9.0.2), the OracleAS Upgrade Assistant cannot reset the port for the Application Server Control Console to its original port. This is because the port used to access the console may or not be defined within the upgraded Oracle home.
However, if you are upgrading from 10g (9.0.4), the port number for the Application Server Control Console is automatically reset by the OracleAS Upgrade Assistant so it uses the original port number from the source Oracle home.
Note that after you upgrade from 10g (9.0.4) the 10g Release 2 (10.1.2) Welcome pages will continue to link to the Application Server Control Console port number assigned during the 10g Release 2 (10.1.2) installation. As a result, the link from the 10g Release 2 (10.1.2) Welcome pages to the Application Server Control Console will not work after you upgrade from 10g (9.0.4).
|
See Also: Section 4.6.1.4, "Examples of Port Assignments Before and After Upgrade" for an example of how the Application Server Control Console ports are assigned before and after a 10g Release 2 (10.1.2) upgrade."Managing Previous Versions of Oracle Application Server" in the Oracle Application Server Administrator's Guide for more information about the differences between the Enterprise Manager Web site in Release 2 (9.0.2) and Release 2 (9.0.3) and the Application Server Control Console in 10g (9.0.4) and 10g Release 2 (10.1.2). |
To illustrate how ports are initially assigned to the new 10g Release 2 (10.1.2) Oracle home and then modified by the OracleAS Upgrade Assistant, Table 4-5 lists examples of pre- and post-upgrade values for Oracle HTTP Server, Oracle Enterprise Manager 10g Application Server Control Console, and Oracle Application Server Web Cache.
Table 4-5 Sample Port Values Before and After Upgrade
| Component | Port in Source Oracle Home | Port Value in Destination Oracle Home Assigned by Installer and Recorded in portlist.ini File | Post-Upgrade Port Value |
|---|---|---|---|
|
Port: 7777 Listen: 7778 Listen: 4444 (SSL) |
Port: 7783 Listen: 7784 Listen: 4445 (SSL) |
Port: 7777 Listen: 7778 Listen: 4444 (SSL)Foot 1 |
|
|
Oracle Enterprise Manager 10g Application Server Control Console |
1810 |
1812 |
1812, if the source Oracle home is Release 2 (9.0.2) or Release 2 (9.0.3). |
|
Oracle Application Server Web Cache |
Administration: 4000 Invalidation: 4001 Statistics: 4002 |
Administration: 4003 Invalidation: 4004 Statistics: 4005 |
Administration: 4000 Invalidation: 4001 Statistics: 4002 |
After you upgrade a middle tier, use the following passwords in the destination Oracle home:
To log in to the Application Server Control Console, use the ias_admin password you defined during the installation of the destination Oracle home.
To log in to the OracleAS Web Cache Manager, use the OracleAS Web Cache Administrator password you used in the OracleAS Web Cache source Oracle home.
The following section describe post-upgrade tasks for the Oracle HTTP Server:
If you enabled SSL in the source Oracle home, verify that the component is still configured for secure communications after you have used the OracleAS Upgrade Assistant.
To verify the proper configuration of your secure Oracle HTTP Server, use the following procedure to check the required values in the opmn.xml and httpd.conf configuration files. Unless both of these files are configured as described in this procedure, you could encounter problems with your SSL configuration:
Use a text editor to open the following OPMN configuration file:
DESTINATION_ORACLE_HOME\opmn\conf\opmn.xmlLocate the following ias-component entry in the opmn.xml file:
<ias-component id="HTTP_Server">
<process-type id="HTTP_Server" module-id="OHS">
<module-data>
<category id="start-parameters">
<data id="start-mode" value="ssl-enabled"/>
</category>
</module-data>
Within the start-parameters category tag, verify that the start-mode parameter is set to ssl-enabled.
This ensures that OPMN starts Oracle HTTP Server in SSL mode.
Use a text editor to open the following Oracle HTTP Server configuration file:
DESTINATION_ORACLE_HOME\Apache\Apache\conf\httpd.conf
Locate the following entry in the httpd.conf file:
<IfDefine SSL>
LoadModule ossl_module libexec/mod_ossl.so
</IfDefine>
In particular, be sure that the LoadModule ossl_module command is surrounded by the <IfDefine SSL> tag. This ensures that Oracle HTTP Server will be started in SSL mode if and only if OPMN directs it to start in SSL mode. Without the surrounding <IfDefine SSL> tag, Oracle HTTP Server starts in SSL mode regardless of whether OPMN has been configured to do so.
In 10g Release 2 (10.1.2), the SSL configuration is controlled by OPMN so it is important that the settings in both the opmn.xml file and httpd.conf file be consistent.
The OracleAS Upgrade Assistant upgrades the standard settings for the Oracle HTTP Server. If you have configuration files or documents that are in non-standard locations or referenced in non-standard ways, you must upgrade these manually. These, and other specific cases for manual upgrade, are detailed below.
If mod_osso was configured: If mod_osso was configured, after upgrade, the osso.conf file continues to use the source Oracle home partner entry in the Single Sign-On server. If the name of the entry in use is obsolete (in that it refers in some way to the source Oracle home), rename it accordingly.
If there are configuration files in non-default locations: If httpd.conf, mod_oc4j.conf, mod_osso.conf and moddav.conf files are not in the default location, you must upgrade them manually by applying the customizations in the files in the source Oracle home to the files in the destination Oracle home.
If there are custom files and directories referenced by Oracle HTTP Server configuration files: Because the OracleAS Upgrade Assistant only upgrades the items listed in Section A.1.4.1, "OHS Upgrade Items", there could be files or directories referred to by directives such as Alias, mod_rewrite, and log directives, such as ErrorLog, that are not present after the upgrade. Ensure that all such items are upgraded manually and exist in the locations expected by the directives. If these files or directives are missing after the upgrade, the Oracle HTTP Server may not start. You can identify errors by starting the Oracle HTTP Server individually after the upgrade, and examining the following file for errors associated with these items:
DESTINATION_ORACLE_HOME\Apache\Apache\logs\error_log
If there are Dynamic Monitoring Service (DMS) configuration elements in the httpd.conf and mod_oc4j.conf files: You must relocate these configuration elements into the dms.conf file.
If Oracle Application Server Web Cache is the first listener: If OracleAS Web Cache is configured as the first listener, ensure that the Oracle HTTP Server directives listed in Table 4-6 have the same values as the corresponding OracleAS Web Cache elements. In particular, note that the Oracle HTTP Server Port directive specifies the port number of a front-end load balancer or reverse proxy. Thus, if Oracle Application Server Web Cache is used, then the Oracle HTTP Server Port directive should have the value of the port on which OracleAS Web Cache is listening.
If you have static documents in the default DocumentRoot directory that you want to upgrade: The OracleAS Upgrade Assistant locates static document files and directories for upgrade in the location specified in the DocumentRoot directive. The DocumentRoot directive defines the location for static documents and related directories. The base server has a document root location, and each virtual host has one. The OracleAS Upgrade Assistant copies files under these directories to the destination Oracle home. The default DocumentRoot directory contains demonstration programs and release notes placed there by the installer, so the OracleAS Upgrade Assistant does not upgrade this directory. You must upgrade this directory manually:
SOURCE_ORACLE_HOME\Apache\Apache\htdocs
The OracleAS Upgrade Assistant performs many of the Oracle Application Server Containers for J2EE (OC4J) upgrade tasks. However, some components of OC4J may require manual adjustments, or may have characteristics of which you should be aware before using Oracle Application Server 10g Release 2 (10.1.2).
The following sections describe some of the tasks you may need to perform to finish the OC4J upgrade:
Section 4.6.4.2, "Upgrading JAZN Library Path Entries After Upgrading From Release 2 (9.0.2)"
Section 4.6.4.3, "Reviewing the Default OC4J Instances After Upgrade"
Section 4.6.4.4, "Completing the Upgrade of User-Created OC4J Instances"
Section 4.6.4.7, "Upgrade Considerations for Enterprise Java Beans"
Section 4.6.4.8, "Upgrade Considerations for the OC4J Java Server Pages (JSP) Container"
Section 4.6.4.9, "Considering JDK 1.4 Issues: Cannot Invoke Classes Not in Packages"
Section 4.6.4.10, "Considering Modified Servlet APIs and Behavior"
Section 4.6.4.11, "Deploying Oracle Business Components for Java (BC4J) Applications After Upgrade"
During upgrade, the OC4J upgrade assistant redeploys your J2EE applications in an OC4J instance in the new 10g Release 2 (10.1.2) Oracle home. Thus, changes made to the jazn-data.xml and jazn.xml files packaged within an application's EAR file will be migrated automatically.
However, manual steps are needed for the following cases, which are not common.
In orion-application.xml, the application can specify the location of jazn-data.xml; for example:
<jazn provider="XML" location="SOURCE_ORACLE_HOME\j2ee\jazn-data.xml">
When jazn-data.xml is not packaged within the application's EAR file, then jazn-data.xml needs to be copied manually to the new 10g Release 2 (10.1.2) environment. The location of the file may need to be updated accordingly in the orion-application.xml file.
In orion-application.xml, the application can point to jazn.xml using the following syntax:
<jazn config="path_to_jazn.xml" />
When jazn.xml is not packaged within the application's EAR file, then it needs to be copied manually to the new install environment. The location of the file may need to be updated accordingly in the orion-application.xml file.
If you are upgrading OC4J instances in a Release 2 (9.0.2) Oracle home, note that in Oracle Application Server 10g (9.0.4) and 10g Release 2 (10.1.2) the jazn.jar file is split into two JAR files: jazn.jar and jazncore.jar.
For this reason, after upgrading OC4J applications that use JAZN and require dynamic compilation (for example, JSP), both JAR file names should be added to the library path entries in the application.xml file.
Ensure that the application.xml file contains both of the entries below:
<library path="DESTINATION_J2EE_HOME\jazn.jar"/> <library path="DESTINATION_J2EE_HOME\jazncore.jar"/>
In this example, replace DESTINATION_J2EE_HOME with the following directory path:
DESTINATION_ORACLE_HOME\j2ee\home
Default OC4J instances are installed automatically by the Oracle Universal Installer and are used by Oracle Application Server components.
During upgrade, the OracleAS Upgrade Assistant does not upgrade default OC4J instances. These default OC4J instances are replaced by new default instances that are installed by the 10g Release 2 (10.1.2) installation procedure in the destination Oracle home. In most cases, these default instances are designed for specific use by the Oracle Application Server components. These default instances include:
User-created OC4J instances are created or modified by the user; this category includes the home instance.
The OracleAS Upgrade Assistant upgrades most of the properties and attributes of user-created OC4J instances, including the home instance. However, not all the properties and attributes of a user-created OC4J instance are upgraded automatically.
For example, the OracleAS Upgrade Assistant adds any properties defined in oc4j.properties to the corresponding java-options section (for both start and stop parameters) in opmn.xml. However, the OracleAS Upgrade Assistant does not upgrade the process-set properties that define the number Java Virtual Machines (JVMs) defined for the instance.
The following sections describe the rules used by the OracleAS Upgrade Assistant to determine which attributes and properties in the opmn.xml file can be upgraded automatically for each user-created OC4J instance:
Upgrading java-options Other Than -D Options for OC4J Instances Defined in the OPMN.XML File
Upgrading -D java-options for OC4J Instances Defined in the OPMN.XML File
About the start-parameters and stop-parameters Sections of the OPMN.XML File
The attributes and properties of each OC4J instance you create are defined in the opmn.xml file along with other Oracle Application Server components that are managed by Oracle Process Manager and Notification Server (OPMN).
Example 4-6 shows a typical entry in the opmn.xml file that defines the home instance, which is a default OC4J instance that can be used and modified by the user.
Example 4-6 OC4J Instance Properties in the opmn.xml File
<ias-component id="OC4J">
<process-type id="home" module-id="OC4J" status="enabled">
<module-data>
<category id="start-parameters">
<data id="java-options" value="-server -Djava.security.policy=$ORACLE_HOME/j2ee/home/config/java2.policy -Djava.awt.headless=true"/>
</category>
<category id="stop-parameters">
<data id="java-options" value="-Djava.security.policy=$ORACLE_HOME/j2ee/home/config/java2.policy -Djava.awt.headless=true"/>
</category>
</module-data>
<start timeout="600" retry="2"/>
<stop timeout="120"/>
<restart timeout="720" retry="2"/>
<port id="ajp" range="3301-3400"/>
<port id="rmi" range="3201-3300"/>
<port id="jms" range="3701-3800"/>
<process-set id="default_island" numprocs="1"/>
</process-type>
</ias-component>
Note the java-options tags in Example 4-6, as well as the start-parameters and stop-parameters defined the OC4J instance.
For java-options that do not start with -D, the OracleAS Upgrade Assistant performs the following evaluations and actions for each user-created OC4J instance defined in the opmn.xml file:
The OracleAS Upgrade Assistant compares arguments defined in the java-options tag in the source Oracle home with those defined in the destination oracle Home.
If the java-options exist in the source Oracle home, but not in the destination Oracle home, the OracleAS Upgrade Assistant appends the java-options defined in the source Oracle home to the java-options tag in the destination Oracle home.
The OracleAS Upgrade Assistant does not analyze the semantics of the java-option parameter. For example, if -Xmx256m is defined in the source opmn.xml file and -Xmx512m is defined in the destination file, the resulting file will contain the following:
<data id="java-options" value="-server -Djava.security.policy=$ORACLE_HOME\j2ee\home\config\java2.policy -Djava.awt.headless=true" -Xmx512m -Xmx256m />
Note, however, that the default java-options for 10.1.2 do not include any -X options, so it is unlikely the destination java-options tag will include additional arguments when you perform the middle tier upgrade. Specifically, the default java-options for the home OC4J instance appear as follows in the opmn.xml file:
<data id="java-options" value="-server -Djava.security.policy=$ORACLE_HOME/j2ee/home/config/java2.policy -Djava.awt.headless=true"
For java-options that start with -D, the OracleAS Upgrade Assistant performs the following evaluations and actions for each user-created OC4J instance defined in the opmn.xml file:
The -D parameters of the java-options tag consist of property/value pairs. If the value is a path to a file and the path includes the source Oracle home, OracleAS Upgrade Assistant ignores the parameter.
If the value of the -D parameter is not a path to a file or if the path does not include the source Oracle home, OracleAS Upgrade Assistant compares the java-options tag the source Oracle home with the same tag in the destination Oracle home. If the property is already defined in the destination Oracle home and it has a different value, OracleAS Upgrade Assistant replaces the value with the value defined in the source Oracle home.
On the other hand, if the property is not defined in the destination Oracle home, the OracleAS Upgrade Assistant adds the -D parameter to the destination Oracle home.
When upgrading a 10g (9.0.4) Oracle home, the OracleAS Upgrade Assistant upgrades the java-options for both start-parameters and the stop-parameters sections of the opmn.xml file.
However, in Oracle Application Server Release 2 (9.0.2) there is only one java-option for each OC4J instance. In this case, the OracleAS Upgrade Assistant upgrades the single java-options tag for each instance and the parameters defined apply to both starting and stopping the OC4J instance.
If you have customized entries in the application.xml file, such as library paths, Java options, and OC4J options, you must upgrade them manually.
In Oracle Application Server 10g Release 2 (10.1.2), OC4J by default complies with the J2EE 1.3 specification. In some cases, this results in behavior that differs from that seen with previous OC4J implementations. To allow for backward compatibility, OC4J supports a CTS compliance flag that you can set to false to revert to previous OC4J behavior in the following components:
Oracle JMS
Oracle JDBC
Oracle XML parser for JAXP/XDK
The compliance behavior of OC4J is determined by the flag oracle.cts.useCtsFlags, with a default value of true. If any of the upgrade issues are critical in a particular application, you can disable CTS compliance and revert to old behavior for an OC4J instance by setting the flag value to false in an OC4J properties file, and providing the location of the properties file to OC4J.
For example, consider the following configuration file:
DESTINATION_ORACLE_HOME\j2ee\home\config\oc4j.properties
This file might contain the flag:
oracle.cts.useCtsFlags=false
Supply the name and location of a properties file to OC4J through an <oc4j-option> element in the opmn.xml file. The opmn.xml file is located in the following directory:
DESTINATION_ORACLE_HOME\opmn\conf\opmn.xml
The <oc4j-option> element should appear as in the following example:
<oc4j>
...
<oc4j-option value="-p DESTINATION_ORACLE_HOME\j2ee\home\config\oc4j.properties"/>
...
</oc4j>
This is equivalent to starting OC4J as follows in standalone mode:
java -jar oc4j.jar -p DESTINATION_ORACLE_HOME\j2ee\home\config\oc4j.properties
In the Oracle Application Server 10g Release 2 (10.1.2) implementation of Oracle JMS (OJMS), which complies with J2EE 1.3, some behavior differs from OJMS behavior in Oracle9iAS Release 1 (1.0.2.2). (There are no such upgrade considerations between Oracle9iAS releases 9.0.2 and 9.0.3.) The differences are as follows:
JMSExpiration—In the OJMS 10g Release 2 (10.1.2) J2EE 1.3-compliant implementation, the JMSExpiration header value in a dequeued message is the sum of the JMS timestamp when the message was enqueued, and the time-to-live. This value is expressed in milliseconds from midnight, January 1, 1970 to the current Greenwich Mean Time. If a message never expires, the value is 0.
In the OJMS 1.0.2.2 implementation, the JMSExpiration header value in a dequeued message is the duration until expiration of the message, in milliseconds. If a message never expires, the value is -1.
JMSPriority—In the OJMS Release 2 (9.0.4) 1.3-compliant implementation, 9 is the highest priority, 0 is the lowest priority, and 4 is the default priority.
In the OJMS 1.0.2.2 implementation, java.lang.Integer.MIN_VALUE is the highest priority, Integer.MAX_VALUE is the lowest priority, and 1 is the default priority.
Durable subscribers—In the OJMS 10g Release 2 (10.1.2) J2EE 1.3-compliant implementation, durable Topic Subscribers with the same name are not allowed under any circumstances.
In the OJMS 1.0.2.2 implementation, durable Topic Subscribers with the same name are allowed if they are subscribed to different topics.
Strongly typed JMS selectors—In accordance with the JMS 1.02b specification and J2EE 1.3 compliance requirements, the OJMS 10g Release 2 (10.1.2) implementation uses only a certain subset of SQL92 syntax for selector expression syntax, with the following mandated restrictions:
Selector expressions are strongly typed, meaning operators and operands in arithmetic comparisons must be of the same type. Automatic type conversions for the purpose of comparison, such as converting the string "1" to the integer 1, are prohibited.
String and boolean comparisons are restricted to "=", "<", and ">". Two strings are equal only if they contain the exact same sequence of characters.
The OJMS 1.0.2.2 implementation is not subject to these restrictions or to the limited subset of SQL92 syntax for selector expression syntax.
In the Oracle Application Server 10g Release 2 (10.1.2) implementation of Oracle JDBC, which complies with J2EE 1.3, some behavior differs from JDBC behavior in Oracle9iAS Release 2 (9.0.2) and prior. The differences are as follows:
Java types for NUMBER columns—In 10g Release 2 (10.1.2), the getObject() method of a result set (java.sql.ResultSet instance) returns a java.lang.Double value for a NUMBER column with precision, or a java.math.BigDecimal value for a NUMBER column without precision.
In Release 2 (9.0.2) and prior releases, getObject() returns a BigDecimal value for any NUMBER column.
Metadata for NUMBER columns—In 10g Release 2 (10.1.2), the getColumnTypeName() method of a result set metadata object (java.sql.ResultSetMetaData instance) returns "FLOAT" for a NUMBER column with precision, or "NUMBER" for a NUMBER column without precision. The getColumnType() method returns java.sql.Types.FLOAT for a NUMBER column with precision, or Types.NUMBER for a NUMBER column without precision.
In Release 2 (9.0.2) and prior releases, getColumnTypeName() returns "NUMBER" for any NUMBER column, and getColumnType() returns Types.NUMBER for any NUMBER column.
Java types for DATE and TIMESTAMP columns—In 10g Release 2 (10.1.2), the getObject() method of a result set returns a java.sql.Date value for a DATE column, and a java.sql.Timestamp value for a TIMESTAMP column.
In Release 2 (9.0.2) and prior releases, getObject() returns a java.sql.Timestamp value for a DATE column. (TIMESTAMP columns were not supported.)
Exceptions for inappropriate SQL statements—In 10g Release 2 (10.1.2), if an executeQuery() call in a statement object contains anything but a SELECT statement (such as if it instead contains an INSERT or UPDATE statement), the JDBC driver properly throws an exception. Similarly, if an executeUpdate() call contains a SELECT statement, the driver properly throws an exception. (An UPDATE, INSERT, or DELETE statement is expected.)
In Release 2 (9.0.2) and prior releases, these situations did not result in exceptions.
In the Oracle Application Server 10g Release 2 (10.1.2) implementation of the XML parser for JAXP/XDK, which complies with J2EE 1.3, some behavior differs from XML parser behavior in Oracle9iAS Release 2 (9.0.2) and prior. The differences are as follows:
getNamespaceURI() null return values—In 10g Release 2 (10.1.2), the getNamespaceURI() method returns 'null' if the namespace is not defined for an element or attribute.
In Release 2 (9.0.2) and prior releases, the getNamespaceURI() method returns '""' in these circumstances.
getLocalName() null return values—In 10g Release 2 (10.1.2), the getLocalName() method returns 'null' if the element or attribute was created using a DOM level 1 API call to createElement() or createAttribute().
In Release 2 (9.0.2) and prior releases, the getLocalName() method returns '"Transfer interrupted!"' in these circumstances.
getPrefix() null return values—In 10g Release 2 (10.1.2), the getPrefix() method returns 'null' if the element or attribute was created using a DOM level 1 API call to createElement() or createAttribute().
In Release 2 (9.0.2) and prior releases, the getPrefix() method returns '""' in these circumstances.
|
Note: ThegetNamespaceURI(), getLocalName(), and getPrefix() methods exist with the preceding changes in the XMLElement and XMLAttr classes of the oracle.xml.parser.v2 package.
|
SAX exceptions—In 10g Release 2 (10.1.2), registered error handlers throw a SAXException or SAXParseException in error conditions.
In Release 2 (9.0.2) and prior releases, error handlers throw an XMLParseException in error conditions.
I/O exceptions—In 10g Release 2 (10.1.2), an IOException is thrown as is in I/O error conditions.
In Release 2 (9.0.2) and prior releases, an IOException is wrapped in an XMLParseException.
Beginning with Oracle9iAS Release 2 (9.0.3), Oracle Application Server Containers for J2EE complies with the J2EE 1.3 specification and implements the Enterprise Java Beans (EJB) 2.0 specification in entirety. Therefore, if you are upgrading from Release 2 (9.0.2) to 10g Release 2 (10.1.2), applications using EJB features in the areas of container-managed persistence and container-managed relationships will require modification.
|
See Also: Oracle Application Server Containers for J2EE Enterprise JavaBeans Developer's Guide, Appendix C for guidance on modifying these applications. |
The following sections describes JSP settings that are affected by the upgrade:
Beginning with Oracle9iAS Release 2 (9.0.3), the OC4J JSP container by default imports the packages listed below into any JSP page, in accordance with the JSP specification. No page directive import settings are required.
javax.servlet.*
javax.servlet.http.*
javax.servlet.jsp.*
In previous releases, the following packages were also imported by default:
java.io.*
java.util.*
java.lang.reflect.*
java.beans.*
For backward compatibility, you can use the JSP extra_imports configuration parameter as a workaround. Alternatively, you can add desired imports through page directives or global includes. See the Oracle Application Server Containers for J2EE Support for JavaServer Pages Developer's Guide for information about these topics.
When upgrading to Oracle Application Server 10g Release 2 (10.1.2) and using JSP pages, use appropriate settings for the following important JSP configuration parameters.
check_page_scope
forgive_dup_dir_attr
These are set as initialization parameters for the JSP front-end servlet, either in the global-web-application.xml file or in the application orion-web.xml file. Example 4-7 shows an example of the JSP configuration parameters.Here is an example.
Example 4-7 JSP Configuration Parameters for Upgrading to 10g Release 2 (10.1.2)
<servlet>
<servlet-name>jsp</servlet-name>
<servlet-class>oracle.jsp.runtimev2.JspServlet</servlet-class>
<init-param>
<param-name>check_page_scope</param-name>
<param-value>true</param-value>
</init-param>
...
</servlet>
See the Oracle Application Server Containers for J2EE Support for JavaServer Pages Developer's Guide for more information about JSP configuration parameters.
check_page_scope (boolean; default: false): This parameter was introduced in Oracle9iAS Release 2 (9.0.3). For OC4J environments, set it to true to enable Oracle-specific page-scope checking by the JspScopeListener utility.
This parameter is not relevant for non-OC4J environments. For JServ, Oracle-specific page-scope checking is always enabled. For other environments, the Oracle-specific implementation is not used and you must use the checkPageScope custom tag for JspScopeListener page-scope functionality. See the Oracle Application Server Containers for J2EE JSP Tag Libraries and Utilities Reference for information about JspScopeListener.
forgive_dup_dir_attr (boolean; default: false): This parameter was introduced in Oracle9iAS Release 2 (9.0.3). Set it to true to avoid translation errors in a JSP 1.2 environment such as OC4J if you have duplicate settings for the same directive attribute within a single JSP translation unit (a JSP page plus anything it includes through include directives).
The JSP 1.2 specification directs that a JSP container must verify that directive attributes, with the exception of the page directive import attribute, are not set more than once each within a single JSP translation unit.
The JSP 1.1 specification did not specify such a limitation. OC4J offers the forgive_dup_dir_attr parameter for backward compatibility.
Among the migration considerations in moving to a Sun Microsystems JDK 1.4 environment, which is the environment that is shipped with Oracle Application Server 10g Release 2 (10.1.2), there is one of particular importance to servlet and JSP developers.
As stated by Sun Microsystems, "The compiler now rejects import statements that import a type from the unnamed namespace." (This was to address security concerns and ambiguities with previous JDK versions.) Essentially, this means that you cannot invoke a class (a method of a class) that is not within a package. Any attempt to do so will result in a fatal error at compilation time.
This especially affects JSP developers who invoke JavaBeans from their JSP pages, as such beans are often outside of any package (although the JSP 2.0 specification now requires beans to be within packages, in order to satisfy the new compiler requirements). Where JavaBeans outside of packages are invoked, JSP applications that were built and executed in an OC4J 9.0.3 / JDK 1.3.1 or prior environment will no longer work in an OC4J 9.0.4 / JDK 1.4 environment.
Until you update your application so that all JavaBeans and other invoked classes are within packages, you have the alternative of reverting back to a JDK 1.3.1 environment to avoid this issue.
For more information about the "classes not in packages" issue and other JDK 1.4 compatibility issues, refer to the following Web site:
http://java.sun.com/j2se/1.4/compatibility.html
In particular, click the link "Incompatibilities Between Java 2 Platform, Standard Edition, v1.4.0 and v1.3".
When upgrading to Oracle Application Server 10g Release 2 (10.1.2) and using servlets, consider the following changes in servlet APIs and behavior:
Changes relating to getRequestURI()
Changes regarding filtering of servlets that are forward or include targets
In previous Oracle9iAS releases, whenever Oracle HTTP Server received a request, it would unencode the URI before passing it to OC4J. Therefore, servlets making computations based on the response of getRequestURI() (a method on the request object) were implicitly getting a value that had been unencoded one time. As of the OC4J 9.0.4 implementation, Oracle HTTP Server will send OC4J an unaltered version of the URI, which in turn is used by OC4J as the return value of getRequestURI().
If the mod_rewrite module is being used in conjunction with mod_oc4j in communications between Oracle HTTP Server and OC4J, the rewritten URI that is sent to mod_oc4j is the same as what is sent to OC4J, and the return value of getRequestURI() will have had mod_rewrite rules applied to it.
The mod_rewrite and mod_oc4j modules are discussed in the Oracle HTTP Server Administrator's Guide. Further details about mod_rewrite are available in the Apache Server documentation.
In previous Oracle Application Server releases, if a filtered servlet forwards to or includes another servlet, the target servlet, by default, is also filtered. In Oracle Application Server 10g Release 2 (10.1.2), this is no longer the default behavior. Having the target servlet not filtered by default matches the intention of the servlet specification.
This behavior is configurable: in the OC4J 9.0.4 implementation, it is according to the oracle.j2ee.filter.on.dispatch environment flag (false by default); in future implementations, it will be according to web.xml configuration as set forth in the servlet 2.4 specification.
After you upgrade to Oracle Application Server 10g Release 2 (10.1.2), you will want to redeploy your J2EE applications using the OC4J component of your newly upgrade 10g Release 2 (10.1.2) instance.
However, before you redeploy any applications that use the capabilities of Oracle Business Components for Java (BC4J), you must repackage the application .EAR file. Specifically, you must be sure to package the 10g Release 2 (10.1.2) version of the bc4jhtml.jar file into the WEB-INF/lib directory of your application .EAR file.
|
See Also: The Oracle JDeveloper documentation and release notes |
The following sections describe procedures to consider when upgrading the middle tiers that are part of an OracleAS Web Cache Cluster:
Using Multiple Versions of OracleAS Web Cache within an OracleAS Web Cache Cluster
Synchronizing the Upgraded OracleAS Web Cache Cluster Configuration
Upgrading an OracleAS Web Cache Cluster from Release 2 (9.0.2.x) to 10g Release 2 (10.1.2)
About Linking to the Application Server Control From the OracleAS Web Cache Welcome Page
When upgrading an OracleAS Web Cache cluster, you can upgrade one cache cluster member at a time. The caches will continue to function, but because the other cluster members have a different version of the configuration, the caches will not forward requests to cache cluster members operating with a different version.
For example, if you upgrade Cache_A to the current version, but have not yet upgraded Cache_B and Cache_C, Cache_A will not forward requests to the cache cluster members Cache_B and Cache_C.
In this situation, the Operations page in Web Cache Manager indicates that the Operation Needed is Incompatible software version.
After you upgrade each cache cluster member to 10g Release 2 (10.1.2), you must perform the following additional steps to synchronize the configuration for the members of the cluster:
If the caches have not been started, for each upgraded cache, start OracleAS Web Cache and OracleAS Web Cache Manager. On the command line, enter:
opmnctl startproc ias-component=WebCache
This command starts the OracleAS Web Cache cache server process and admin server process.
In a browser, enter the URL for the OracleAS Web Cache Manager for one of the upgraded caches, and, when prompted, enter the username and password for the ias_admin or administrator user.
Note that after you upgrade an OracleAS Web Cache instance, you log into the OracleAS Web Cache Manager using the Administrator password defined when you installed and configured OracleAS Web Cache source Oracle home.
In the navigator frame, select Administration -> Operations.
The Operations page appears.
In the Operations page, click Retrieve Configuration.
Web Cache retrieves the cache-specific configuration information from the remote cache cluster members. Then, Web Cache Manager indicates that the Operation Needed is Propagate Configuration.
To propagate the configuration to all cache cluster members, select All caches and an Interval of Immediate. Then, click Propagate.
Restart the caches by selecting All caches and an Interval. Then, click Restart. (Note that you can perform this operation as you upgrade each cache, or you can perform this operation after all of the cache cluster members have been upgraded.)
A Release 2 (9.0.2) cache cannot accept invalidation messages from a 10g Release 2 (10.1.2) cache. In a configuration that uses a OracleAS Web Cache cluster with a mixture of Release 2 (9.0.2) and 10g Release 2 (10.1.2) cluster members, you must configure the Load Balancer to send invalidation messages only to the Release 2 (9.0.2.x) members.
When upgrading a cache cluster from Release 2 (9.0.2) to 10g Release 2 (10.1.2), remove cluster members one at a time from the invalidation pool for the Load Balancer prior and upgrade them. Once all the cluster members are upgraded, add them back to the invalidation pool. As an example, assume a configuration with a Load Balancer in front of a cache cluster that is comprised of four members, webche1-host, webche2-host, webche3-host, and webche4-host, all running Release 2 (9.0.2.x). To upgrade this cache cluster:
In the Load Balancer configuration, remove webche1-host from the pool that is responsible for invalidation.
Upgrade webche1-host from Release 2 (9.0.2) to 10g Release 2 (10.1.2).
In the Load Balancer configuration, remove webche2-host from the pool that is responsible for invalidation.
Upgrade webche2-host from Release 2 (9.0.2) to 10g Release 2 (10.1.2).
In the Load Balancer configuration, remove webche3-host from the pool that is responsible for invalidation.
Upgrade webche3-host from Release 2 (9.0.2) to 10g Release 2 (10.1.2).
Upgrade webche4-host from Release 2 (9.0.2) to 10g Release 2 (10.1.2). As this is the last cache member in the Load Balancer configuration, it is not necessary to remove it from the invalidation pool.
In the Load Balancer configuration, add webche1-host, webche2-host, and webche3-host back into the pool that is responsible for invalidation.
When you install the 10g Release 2 (10.1.2) destination Oracle home, the OracleAS Web Cache Welcome page is configured to link to the 10g Release 2 (10.1.2) Application Server Control Console URL. However, during the upgrade of the middle tier, the OracleAS Upgrade Assistant configures Application Server Control so you can access it from the original port number assigned when you installed the source 10g (9.0.4) Oracle home.
As a result, after you upgrade from OracleAS Web Cache 10g (9.0.4) to 10g Release 2 (10.1.2), the link to the Oracle Enterprise Manager Application Server Control Console on the OracleAS Web Cache Welcome page does not work. To access the Application Server Control Console, use the 10g (9.0.4) Application Server Control URL.
If you configured OracleAS Web Cache for HTTPS requests, then you defined a wallet that OracleAS Web Cache must use to support the HTTPS protocol.
The OracleAS Upgrade Assistant automatically upgrades your destination Oracle home with the location of the OracleAS Web Cache wallet as long as the wallet is stored in the Oracle home directory.
However, in some cases, if you did not use the same case when specifying the path to the wallet, the OracleAS Upgrade Assistant incorrectly identifies the wallet as being located outside of the Oracle home. In those cases, the path to the wallet is not updated correctly in the destination Oracle home.
As a result, after you upgrade OracleAS Web Cache, verify that OracleAS Web Cache is configured to locate your wallets in the destination Oracle home and not the source Oracle home.
|
See Also: "Configuring OracleAS Web Cache for HTTPS Requests" in the Oracle Application Server Web Cache Administrator's Guide |
This section explains how to perform the manual procedures required to complete the Portal upgrade after the OracleAS Upgrade Assistant has finished processing. It discusses the following topics:
In cases where a Portal instance accessed through the middle-tier is not using the same Oracle Internet Directory that the middle-tier is registered with, some additional steps need to be carried out after upgrade of the middle tier. These steps validate that the Oracle Internet Directory details stored in the OracleAS Portal Dependency Settings File are correct. When you perform an upgrade, not all of the values are available to the upgrade tool and are simply set to a default value.
To verify the Oracle Internet Directory properties:
Open the following file in a text editor:
DESTINATION_ORACLE_HOME\portal\conf\iasconfig.xml
Review the contents of the file for entries that apply to OracleAS Portal.
In particular, note each occurrence of the PortalInstance element within the file. Example 4-8 shows the contents of a typical iasconfig.xml file.
For each PortalInstance element that refers to an Oracle Internet Directory other than the one with which the middle tier is registered, do the following:
Set the LDAPSSLPort property in the OIDDependency element to the SSL port for the Oracle Internet Directory.
Verify that the AdminDN property of the corresponding OIDComponent element is set to the Administration DN of the Oracle Internet Directory.
Verify that the AdminPassword property of the corresponding OIDComponent element is correctly set to the password of the Oracle Internet Directory.
Save your changes and close the iasconfig.xml file.
Encrypt all manually entered password properties using the following command:
DESTINATION_ORACLE_HOME\portal\conf\ptlconfig -encrypt
Refer to the Oracle Application Server Portal Configuration Guide for more information about the iasconfig.xml and the ptlconfig tool.
Example 4-8 Sample Contents of the OracleAS Portal iasconfig.xml File
<IASInstance Name="midtier.abc.company.com" Host="abc.company.com">
<WebCacheComponent AdminPort="4000" ListenPort="80"
InvalidationPort="4001" InvalidationUsername="invalidator"
InvalidationPassword="@BdS/zVGJHrElbOMohqLzurxsPR1au77peA=="
SSLEnabled="false"/>
<EMComponent ConsoleHTTPPort="1811" SSLEnabled="false"/>
</IASInstance>
<IASInstance Name="infra.xyz.company.com" Host="xyz.company.com">
<OIDComponent AdminPassword="welcome1"
AdminDN="cn=orcladmin" SSLEnabled="false" LDAPPort="389"/>
</IASInstance>
<PortalInstance DADLocation="/pls/portal30" SchemaUsername="portal30"
SchemaPassword="welcome1"
connectString="dbserver.company.com:1521:orcl">
<WebCacheDependency ContainerType="IASInstance"
Name="midtier.abc.company.com"/>
<OIDDependency ContainerType="IASInstance" LDAPSSLPort="4339"
Name="infra.xyz.company.com"/>
<EMDependency ContainerType="IASInstance"
Name="midtier.abc.company.com"/>
</PortalInstance>
Any new deployment property files added in the source Oracle home will be copied to the destination Oracle home. However, any property file that is modified from its original installation time values will not be copied. Any changes in those files must be manually applied to the destination Oracle home.
The location of the property file will vary among web providers, and can be located using the service identifier of the web provider. The service identifier identifies a provider within an application. The deployment property files are named according to the following convention:
SOURCE_ORACLE_HOME\j2ee\OC4J_Portal\applications\application_name\ web_application_name\WEB-INF\deployment\service_identifier.properties
For example, the deployment properties for the JPDK sample web provider, whose identifier is sample, reside in:
SOURCE_ORACLE_HOME\j2ee\OC4J_Portal\applications\jpdk\jpdk\WEB-INF\ deployment\sample.properties
To migrate modified deployment properties from the source to the destination Oracle home:
Identify all customized property files (files in which new properties were added or whose default property values were changed) in the source Oracle home.
Copy the customized properties from these property files in the source Oracle home to the corresponding files in the destination Oracle home.
If you are upgrading from Oracle9iAS Discoverer version 9.0.2.52 or earlier, you must upgrade the End User Layer schema before you can use Oracle Business Intelligence Discoverer 9.0.4 in 10g Release 2 (10.1.2).
See Section 8.5.1, "Upgrading the Oracle Business Intelligence Discoverer End User Layer Schema", for instructions.
The following sections describe the post-upgrade tasks to perform after you upgrade OracleAS Reports Services:
Enabling Management of OracleAS Reports Services from the Application Server Control Console
Registering Standalone Reports Servers with OPMN and Oracle Enterprise Manager
Upgrading User-Defined OC4J Instances With OracleAS Reports Services Deployments
The OracleAS Upgrade Assistant performs most of the Oracle Application Server Reports Services upgrade. However, it does not process the following:
The .bat script files in the following source Oracle home location:
SOURCE_ORACLE_HOME\reports\samples\scripts\rw*.bat SOURCE_ORACLE_HOME\reports\samples\scripts\reports.bat
The template file in the following source Oracle home location:
SOURCE_ORACLE_HOME\reports\conf\rwserver.template
The jdbcpds.conf configuration file in the following source Oracle home location:
SOURCE_ORACLE_HOME\reports\conf\jdbcpds.conf
If you have customized any of these files, you must apply the customizations to the corresponding files in the destination Oracle home.
In addition, to preserve the cache files and the cache directory from source Oracle home, copy the reports server cache directory from the source Oracle home to the destination Oracle home.
After you upgrade OracleAS Reports Services in the middle tier, make the following changes to the targets.xml configuration file to manage the upgraded OracleAS Reports Services server from the Application Server Control Console. These changes are necessary in order for the EM integration to work with the upgraded OracleAS Reports Services in-process server:
Use a text editor to open the following configuration file in the destination Oracle home:
DESTINATION_ORACLE_HOME\sysman\emd\targets.xml
Locate the following entry in the targets.xml file for the Reports in-process server:
TYPE="oracle_repserv" and DISPLAY_NAME="Reports Server: new_server_name
Note that new_server_name will be in the following format:
rep_hostname_newOracleHome
In this example, hostname is the name of host computer without the domain name and newOracleHome is the destination Oracle home.
For the oracle_repserv entry, replace all occurrences of new_server_name with the original server name that was used in the source Oracle home before you performed the middle-tier upgrade.
Example 4-9 uses boldface type to identify the typical occurrences of new server name in the oracle_repserv entry in the targets.xml file.
Note that the original server name can be found in the following OracleAS Reports Services configuration file:
DESTINATION_ORACLE_HOME\reports\conf\rwservlet.properties
Use the Services control panel to restart the Application Server Control service for the changes to take effect.
Example 4-9 Sample OracleAS Reports Services Content in the targets.xml File
<Target TYPE="oracle_repserv"
NAME="appserv1.acme.com_Reports_Server: new_server_name"
DISPLAY_NAME="Reports Server: new_server_name"
VERSION="1.0"
ON_HOST="appserv1.acme.com">
<Property NAME="IASInternalName" VALUE="new_server_name"/>
<Property NAME="Password" VALUE="77c1ed41793a5ce6" ENCRYPTED="TRUE"/>
<Property NAME="Server" VALUE="new_server_name"/>
<Property NAME="Servlet"
VALUE="http://appserv1.acme.com:port/reports/rwservlet"/>
...
...
</Target>
The OracleAS Upgrade Assistant does not upgrade OracleAS Reports Services standalone servers. As a result, if you are using any standalone OracleAS Reports Services servers, you must manually register those servers with Oracle Process Manager and Notification Server (OPMN) and with Oracle Enterprise Manager 10g Application Server Control.
Registering the standalone servers with OPMN and Application Server Control involves updating the opmn.xml and targets.xml configuration files. Oracle Application Server provides a script you can use to automatically perform the updates.
To register your OracleAS Reports Services standalone servers, run the following command once for each standalone server you want to register:
DESTINATION_ORACLE_HOME\bin\addNewServerTarget.bat standalone-server-name
In this example, replace standalone-server-name with the name of the OracleAS Reports Services standalone server you want to register with OPMN and Oracle Enterprise Manager.
The OracleAS Upgrade Assistant upgrades your Release 2 (9.0.2) or 10g (9.0.4) Business Intelligence & Forms configuration to an Oracle Application Server 10g Release 2 (10.1.2) Business Intelligence & Forms configuration. The OracleAS Upgrade Assistant is not aware of OC4J instances outside of these configurations that may contain deployed reports, or of customizations made to those instances in order to enable the deployed reports to run.
Therefore, if you are using OC4J instances other than the standard Business Intelligence and Forms OC4J instance, you must apply any manual deployment steps that you performed on those instances to the equivalent instances in Oracle Application Server 10g Release 2 (10.1.2).
This section applies only if you are upgrading from the Release 2 (9.0.2) or 10g (9.0.4) Business Intelligence & Forms installation type to the 10g Release 2 (10.1.2.0.2) Forms and Reports Services installation type.
After upgrading to the 10g Release 2 (10.1.2.0.2) Forms and Reports Services installation type, perform the following steps to make all Reports Servers (in-process and standalone servers) unsecure and enable them to work properly:
Modify the server_name.conf file, as follows:
Locate and open the server_name.conf configuration file:
DESTINATION_ORACLE_HOME\reports\conf\server_name.conf
Locate the following element in the file:
<security id="rwSec" class="oracle.reports.server.RWSecurity"> <!--property name="securityUserid" value="portal_db_username/portal_db_ password@%portal_db_tnsname" confidential="yes" encrypted="no"/--> <property name="oidEntity" value="reports_oid_entity"/> </security>
Comment the security element as shown in the following example.
Be sure to remove any existing comment characters (<!-- and -->) within the security element:
<!--security id="rwSec" class="oracle.reports.server.RWSecurity"> <property name="securityUserid" value="portal_db_username/portal_db_ password@%portal_db_tnsname" confidential="yes" encrypted="no"/> <property name="oidEntity" value="reports_oid_entity"/> </security-->
Save and close the server_name.conf file.
Modify the rwservlet.properties file:
Open the rwservlet.properties configuration file:
DESTINATION_ORACLE_HOME\reports\conf\rwservlet.properties
Locate the OID_ENTITY entry in the rwservlet.properties file.
For example:
OID_ENTITY=reportsApp.acme.com_FD502C79FB3F660CE0340003BA182918
Comment the OID_ENTITY entry as follows:
#OID_ENTITY=reportsApp.acme.com_FD502C79FB3F660CE0340003BA182918
Save and close the rwservlet.properties file.
The following sections provide information on upgrading the Oracle Application Server Wireless Middle Tier from Release 2 (9.0.2) or 10g (9.0.4) to 10g Release 2 (10.1.2):
Section 4.6.9.1, "Using the Oracle Application Server Wireless Notification Service Upgrade Script"
Section 4.6.9.3, "Configuring Site-Level Drivers in a Mixed Mode Environment"
Section 4.6.9.4, "Restoring the OracleAS Wireless Release 2 (9.0.2) Schema"
|
See Also: Oracle Application Server Wireless Developer's Guide for information on any unfamiliar concepts introduced here, and for information on configuration and development of OracleAS Wireless applications |
|
Note: New OracleAS Wireless features added for the 10g Release 2 (10.1.2) release will not be available until you upgrade the OracleAS Metadata Repository to 10g Release 2 (10.1.2). For more information, see Chapter 7, "Upgrading the OracleAS Metadata Repository". |
This section explains how to upgrade notifications created by the Oracle Application Server Wireless Release 2 (9.0.2) Notification Engine in the Oracle Application Server Wireless System Manager. The architecture and functionality of the Notification Engine are not described here.
This procedure is not necessary if you are upgrading from 10g (9.0.4).
You can upgrade notifications from Release 2 (9.0.2) to 10g Release 2 (10.1.2) with the migrateNotifications.bat script. To execute the script:
Navigate to DESTINATION_ORACLE_HOME\wireless\bin.
Set the ORACLE_HOME environment variable to the 10g Release 2 (10.1.2) Oracle home.
Issue one of the commands below:
migrateNotifications.bat -name deprecated master alert name(s) -owner owner user name
migrateNotifications.bat -oid deprecated master alert oid -owner owner user name
The script does the following:
Creates a new master alert service named old master alert name_New. (This process involves converting the message template to a valid mobile xml, if necessary.)
Creates the folder \master\notifications, if it does not exist.
Creates the master service old master alert name_MS.
Creates a mapping for the new master alert and the new master service based on the message template for the old master alert.
Creates the folder \Users Home\username\notifications, if it does not exist.
Discovers all associated 9.0.2.x AlertService objects and converts them to link objects. (The top-level authorization is flattened to link level authorization during this process.)
Transforms all subscriptions for alert services converted.
The following command upgrades all 9.0.2.x master alert services whose name starts with StockAlert (for example, StockAlertNews, StockAlertWarning, and so on). All new objects will be owned by the orcladmin user.
migrateNotifications.bat -name StockAlert% -owner orcladmin
The following command upgrades the 9.0.2.x master alert service with the name StockAlert, and assigns all new objects to the systemadmin user.
migrateNotifications.bat -name StockAlert -owner systemadmin
The following command upgrades the 9.0.2.x master alert service with the object ID 1973, and assigns all new objects to the systemadmin user.
migrateNotifications.bat -oid 1973 -owner systemadmin
You can operate an environment with Oracle9iAS Wireless Release 2 (9.0.2) and Oracle Application Server Wireless 10g Release 2 (10.1.2) middle tiers using the same Infrastructure services. However, this configuration is subject to some restrictions, as described below.
J2ME download and XHTML/XForms based applications should not be used in a mixed environment. These features are new in Oracle Application Server Wireless 10g Release 2 (10.1.2), and would cause errors when attempting to access them from any of the Oracle9iAS Wireless Release 2 (9.0.2) middle tiers. If you wish to use these features, then it is necessary to upgrade all middle tiers to Oracle Application Server Wireless 10g Release 2 (10.1.2).
The Notification Engine cannot be used in a mixed environment. Instead, you should use the Alert Engine.
Service access point (service-level address) should be created through an Oracle Application Server Wireless 10g Release 2 (10.1.2) middle tier, in order for them to be visible to both the Oracle Application Server Wireless 10g Release 2 (10.1.2) middle tiers and Oracle9iAS Wireless Release 2 (9.0.2) middle tiers.
Oracle Application Server Wireless 10g Release 2 (10.1.2) supports user name case sensitivity. However, this requires that you upgrade the Oracle Internet Directory to Oracle Application Server 10g Release 2 (10.1.2).
If you change (add, delete, or update) a 10g Release 2 (10.1.2) ASK Access point, the changes you make will not be reflected in the Release 2 (9.0.2) Enterprise Manager Web site until the Release 2 (9.0.2) Enterprise Manager Web site and the OC4J_Wireless OC4J instance is restarted.
Specifically, a driver account (for example, an e-mail account for an e-mail driver) that is removed from an instance and subsequently added to another instance that is a different release version (for example, from Release 2 (9.0.2) to 10g Release 2 (10.1.2)) may cause messages to be lost. Restarting the OC4J_Wireless OC4J instance resolves this problem.
The Notification Engine introduced in Oracle Application Server Wireless 10g Release 2 (10.1.2) replaces the Alert Engine, which was part of Oracle9iAS Wireless Release 2 (9.0.2). Although the Alert Engine is still available in Oracle Application Server Wireless 10g Release 2 (10.1.2), Oracle Corporation recommends that after all middle tiers have been upgraded to Oracle Application Server Wireless 10g Release 2 (10.1.2), you switch to the Notification Engine, as the Alert Engine may not be available in future versions of Oracle Application Server Wireless.
Upgrade scripts are available to help you with this task. See the Oracle Application Server Wireless Developer's Guide for details. The Oracle9iAS Wireless Release 2 (9.0.2) Alert APIs have been deprecated, and you must upgrade your applications to use the Oracle Application Server Wireless 10g Release 2 (10.1.2) APIs instead.
Oracle Sensor EdgeServer processes will not operate in a mixed environment of Release 2 (9.0.2), 10g (9.0.4), or 10g Release 2 (10.1.2) middle tiers. To use these features, you must upgrade all middle tiers to 10g Release 2 (10.1.2) and upgrade the OracleAS Metadata Repository to 10g Release 2 (10.1.2).
In a mixed mode environment, Oracle9iAS Wireless Release 2 (9.0.2) and Oracle Application Server Wireless 10g Release 2 (10.1.2) may have transport drivers configured to receive incoming messages. The two sets of entry points, Oracle9iAS Wireless Release 2 (9.0.2) and Oracle Application Server Wireless 10g Release 2 (10.1.2), should not be exposed to a device at the same time. A user issuing a request to the Release 2 (9.0.2) instance should not subsequently send another request, within an 3 hour period, to the entry point defined in the transport driver of the Oracle Application Server Wireless 10g Release 2 (10.1.2) instance. The same user may not receive any response for requests addressed to the latter entry point, if it is violated.
Since the driver configuration is different in Release 2 (9.0.2) and 10g Release 2 (10.1.2), when a Oracle9iAS Wireless Release 2 (9.0.2) instance is upgraded to Oracle Application Server Wireless 10g Release 2 (10.1.2), the transport drivers must be managed such that requests are processed as expected.
In 10g Release 2 (10.1.2), a site level driver can be enabled or disabled. By default, it is enabled. If a driver is disabled, it is not recognized by the routing algorithm, and therefore is not used by the messaging system. However, in Release 2 (9.0.2), all site level drivers are recognized by the routing algorithm.
If a Release 2 (9.0.2) instance has two middle tiers, after one of the middle tiers and the Infrastructure are upgraded to 10g Release 2 (10.1.2), the upgraded middle tier may enable or disable a site level driver. However, middle tiers that are not yet upgraded recognize all drivers as enabled. For this reason, it is prudent to remove, rather than disable, a driver in this type of environment.
InRelease 2 (9.0.2), the transport mechanism can route a message to only one driver, and it does not matter whether there is an instance configured for it. This means that a message will not be delivered if it is indeed routed to a driver that has no instance configured. For this reason, the best practice is to remove all drivers that do not have an instance configured in any Release 2 (9.0.2) environment, including a Release 2 (9.0.2) and 10g Release 2 (10.1.2) mixed environment.
If, after installing the Oracle Application Server Wireless 10g Release 2 (10.1.2), you decide that you do not want to use it and want to use OracleAS Wireless Release 2 (9.0.2), you can restore the 9.0.2 WIRELESS schema:
Remove all objects from the WIRELESS schema, which is now at version 9.0.4, in the 9.0.2 metadata repository.
To do this, run the wirelessrm.sql script. The Oracle home refers to the Oracle home for the 9.0.4 middle tier.
cd %ORACLE_HOME%\wireless\repository\sql sqlplus system/password@service_name @wirelessrm.sql
Restore the 9.0.2 WIRELESS schema by importing the database export file created in step 2 of the previous procedure.
imp system/password@service_name file=iasw902.dmp fromuser=wireless touser=wireless
When you upgrade to 10g Release 2 (10.1.2), 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).
Note, however, that you cannot create Oracle Sensor Edge Server processes until after you upgrade the OracleAS Metadata Repository to 10g Release 2 (10.1.2).
After you upgrade an OracleAS Wireless middle tier to 10g Release 2 (10.1.2), some of the applications provided by Oracle Application Server Wireless, such as Commerce, Location, PIM, and Examples will generate errors when accessed from your 10g Release 2 (10.1.2) middle tier. To prevent these errors from occurring, upgrade the OracleAS Metadata Repository to 10g Release 2 (10.1.2).
The OracleAS Upgrade Assistant moves most of the OracleAS Forms Services configuration data from the source to the destination Oracle home. However, there may be manual tasks remaining after the upgrade. This section explains how to perform these tasks.
Refer to the following sections for more information:
New Names for OracleAS Forms Services Files, Directories, URLs, and Environment Variables
Upgrading OracleAS Forms Services EAR File Deployed in User-defined OC4J Instances
For Oracle Application Server 10g Release 2 (10.1.2.0.2), the names of many OracleAS Forms Services files, directories, URLs, and environment variables have changed. The OracleAS Upgrade Assistant converts your OracleAS Forms Services configuration to the new names automatically.
|
See Also: Section A.1.13.6, "OracleAS Forms Services File Name, Directory Name, URL, and Variable Name Changes in 10g Release 2 (10.1.2.0.2)" for a complete list of the OracleAS Forms Services name changes. |
If the OracleAS Forms Services executable files (.fmx files) exist in a directory within the source Oracle home, then manually copy these files to a relative path in the destination Oracle home. However, if these files are not in the source Oracle Home (for example, in a separate directory referenced by the FORMS_PATH environment variable), then this manual step is not required.
In the source Oracle home, the OracleAS Forms Services EAR file (forms90app.ear) is deployed by default into the OC4J_BI_Forms OC4J instance as forms90app. If you have re-deployed this ear file in a customized configuration in the OC4J_BI_Forms OC4J instance, then the OracleAS Upgrade Assistant automatically upgrades this deployment to the destination Oracle home.
However, if you have deployed the ear in any other default OC4J instance (home, OC4J_Portal, OC4J_Wireless) or in any user-defined OC4J instances, then this configuration will not be upgraded. In that case, redeploy the OracleAS Forms Services EAR file to the corresponding OC4J instance in the destination Oracle home.
The OracleAS Forms Services 10g Release 2 (10.1.2.0.2) formsapp.ear file is located in the folowing directory:
DESTINATION_ORACLE_HOME\forms\j2ee
After the OracleAS Upgrade Assistant has finished processing, and you have completed all of the applicable manual post-upgrade tasks, you can start the upgraded middle tier instance.
The following sections provide more information:
If the middle tier instance uses an Infrastructure, ensure that the Infrastructure is running.
Follow these instructions to start the middle tier instance:
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.
Portal instances access web providers via a URL. The process of specifying this URL is referred to as provider registration. If the destination Oracle home will be accessed using a hostname and/or port number different from that of the source Oracle home, or the web providers have been deployed to a different URL path, then you need to update the URLs used to access the upgraded web providers. Web providers can be referenced by multiple portal instances; all of these must be updated.
Follow these steps to update the web provider URL:
Log on to OracleAS Portal as an administrator.
Click the Navigator link.
The Portal Navigator page appears.
Click the Providers tab.
Click Registered Providers.
A sorted list of registered providers appears.
Locate the provider to update, using the Next and Previous links if necessary.
Click the Edit Registration link for the provider to update.
The Edit Provider page appears.
Click the Connection tab.
Update the URL to reflect the new location of the provider.
Click OK or Apply to save the changes.
This section applies only to Release 2 (9.0.2) instances. It does not apply if you are upgrading a 10g (9.0.4) middle tier that contains OracleAS Portal.
The Event/Parameter Passing Samples Provider definition has changed since Release 2 (9.0.2). Consequently, if you are upgrading a Release 2 (9.0.2) middle tier, the provider must be refreshed in the OracleAS Portal repository.
Repeat these steps for each Release 2 (9.0.2) OracleAS Portal instance that references this provider.
Follow these steps to update the web provider URL:
Log on to OracleAS Portal as an administrator.
Click the Navigator link.
The Portal Navigator page appears.
Click the Providers tab.
Click Registered Providers.
A sorted list of registered providers appears.
Locate the JPDK V2 Sample Event Web Provider, using the Next and Previous links, if necessary.
Click the Refresh link for the JPDK V2 Sample Event Web Provider.
The following sections describe tasks you should perform after the middle tier upgrade to validate that the upgrade was successful:
Follow these steps to verify that the middle tier components that were upgraded are started:
In a browser, access the Application Server Control Console in the 10g Release 2 (10.1.2) middle tier Oracle home by entering the Application Server Control Console URL.
For example:
http://midtierhostname:port
Be sure you have entered the correct port number. See Section 4.6.1, "About Port Values and the portlist.ini File After Upgrade" for information about determining the Application Server Control Console port after you have upgraded the middle tier.
Enterprise Manager prompts you to log in to the Application Server Control Console.
Enter the ias_admin login credentials that you used for the destination Oracle home.
After you upgrade an Oracle Application Server instance, use the password you defined when installing the destination Oracle home to log in to the Application Server Control Console in the destination 10g Release 2 (10.1.2) instance.
Enterprise Manager displays the Farm page in your browser window. A link for the middle tier instance appears in the Standalone Instances section of the page.
Click the name of the middle tier instance in the Standalone Instances section.
The System Components page appears.
Verify that the components are running.
Verify that the configuration information for the components in use is reflected in the 10g Release 2 (10.1.2) Oracle home.
Follow these steps to verify that you can access the Oracle HTTP Server and application URLs:
Verify that you can access the Oracle HTTP Server on the same host and port that you did in the previous release by entering the URL. Ensure that you provide the correct host name and port number. For example:
http://midtierhost.mycompany.com:7777
Verify that you can access the URLs for the applications you operated in the previous release, and ensure that the applications are functioning as they did in the previous release.
As described earlier in this chapter, when you upgrade a middle tier, the source Oracle home is left untouched. In other words, the source Oracle home is still operational. However, if you decide to revert to the source middle tier after you have upgraded to 10g Release 2 (10.1.2), then refer to the following information about using OracleAS Portal:
If you decide to revert to using the source middle tier, you must reset the Portal Service Monitoring link in the Services portlet on the Portal Builder page before you can begin using the Oracle home again.
Oracle Application Server provides the monseed.sql script to automate the process of resetting the Portal Service Monitoring link.
The following instructions describe how to use the script:
Set the ORACLE_HOME environment variable to the source middle tier Oracle home.
Navigate to the following directory:
%ORACLE_HOME%\portal\admin\plsql\wwc
Using SQL*Plus, connect to the Portal schema.
If you are reverting to a Release 2 (9.0.2) Oracle home, enter the following command to run the monseed.sql script:
@monseed.sql EM_host EM_port Portal_DAD middle_tier_host middle_tier_port instance_name
For example:
@monseed.sql midtierhost.acme.com 1810 portal midtierhost.acme.com 7777 ias902mid.midtierhost.acme.com
Refer to Table 4-7 for a description of the arguments you must provide to the monseed.sql script.
If you are reverting to a 10g (9.0.4) Oracle home, then enter the following command to run the monseed.sql script:
@monseed.sql EM_protocol EM_host EM_port Portal_DAD instance_name
For example:
@monseed.sql http midtierhost.acme.com 1810 portal as904.midtierhost.acme.com
Refer to Table 4-7 for a description of the arguments you must provide to the monseed.sql script.
Table 4-7 Arguments to Use for the monseed.sql Script
If you upgrade to 10g Release 2 (10.1.2.0.2), revert to the source Oracle home, and later want to revert back to the 10g Release 2 (10.1.2.0.2) Oracle home, consider the following information about the OracleAS Portal Services Monitoring link.
In earlier releases of Oracle Application Server, including Release 2 (9.0.2), 10g (9.0.4), and 10g Release 2 (10.1.2.0.0), clicking the Portal Services Monitoring link displays the OracleAS Portal Monitoring Page in the Application Server Control Console.
Starting with 10g Release 2 (10.1.2.0.2), the behavior of this link has changed. It now displays the Farm page in the Application Server Control Console. You can then access the OracleAS Portal Monitoring Page by selecting the Application Server that is servicing the Portal that you want to monitor, and then selecting the Portal target in the System Components table.
|
See Also: "Introduction to Administration Tools" in the Oracle Application Server Administrator's Guide for more information about the Farm page in the Application Server Control Console |
As a result, if you upgrade to 10g Release 2 (10.1.2.0.2), revert to the source Oracle home, and later want to revert back to the 10g Release 2 (10.1.2.0.2) Oracle home, then you must run the monseed.sql script with a slightly different set of arguments than those described in Section 4.8.3.1, "Resetting the OracleAS Portal Service Monitoring Link In the Source Oracle Home".
Otherwise, the Portal Service Monitoring link will not function properly.
To revert back to the 10g Release 2 (10.1.2.0.2) Oracle home, perform steps 1 through 3 as described in Section 4.8.3.1, and then enter the following command to reset the Portal Services Monitoring link for 10g Release 2 (10.1.2.0.2):
monseed.sql EM_protocol EM_host EM_port
In this example:
EM_protocol is the protocol used to connect to the Application Server Control Console. The value can be http or https. Use https if the the Application Server Control security has been enabled.
EM_host is the hostname used to connect to the Application Server Control
EM_port is the port used to connect to the Application Server Control
The upgrade process leaves the source Oracle home unchanged. Depending on the type of installation you have, and your future needs, you may elect to remove the source Oracle home, or to retain it for specific reasons.
|
Note: If you retain the source Oracle home, you cannot operate it simultaneously with the destination Oracle home, because certain components have the same port values after upgraded. See Section 4.6.1, "About Port Values and the portlist.ini File After Upgrade". |
The following sections provide more information about decommissioning an upgraded source Oracle home:
If there are application files or log files in the source Oracle home that are being referenced or used by the destination Oracle home, you should move them to another location before you decommission the source Oracle home, and, in the destination Oracle home, change any references to the files to the new location.
If you continue to operate a Release 2 (9.0.2) or 10g (9.0.4) Portal repository, you should not decommission the source Oracle home if there is a possibility that you might later want to load additional languages into the Release 2 (9.0.2) or 10g (9.0.4) Portal repository. The utilities for loading languages in Oracle Application Server 10g Release 2 (10.1.2) are not compatible with OracleAS Portal in Release 2 (9.0.2) or 10g (9.0.4).
If the middle tier instance you have upgraded is a member of an OracleAS Farm, be sure to remove the source instance from the farm before you deinstall the source Oracle home.
For example, after you upgrade an instance that was using an OracleAS Infrastructure, the source instance remains in the list of instances on the Application Server Control Console Farm page.
To remove the source instance from the farm and from the Farm page, use the following command in the source Oracle home:
SOURCE_ORACLE_HOME\dcm\bin\dcmctl leavefarm
|
See Also: Distributed Configuration Management Administrator's Guide for more information about thedcmctl leavefarm command
"Introduction to Administration Tools" in the Oracle Application Server Administrator's Guide for more information about the Farm page in the Application Server Control Console |
When you are certain that the upgrade was successful, you have all of the necessary backups, and you have no plans to revert to the source Oracle home, you may elect to remove the files from the source Oracle home. Use the Oracle Universal Installer to deinstall the instance.
However, before you begin deinstalling an instance, consider the following sections:
Issue: 10g Release 2 (10.1.2) Instance Must Not Contain the Active Oracle Enterprise Manager
If a 10g Release 2 (10.1.2) Instance Becomes the Active Oracle Enterprise Manager
|
See Also: Oracle9i Application Server Installation Guide in the Release 2 (9.0.2) or (9.0.3) documentation library for instructions on deinstalling the instance. |
If you have 9.0.2 or 9.0.3 and 10g Release 2 (10.1.2) instances on the same computer, and you want to deinstall a 9.0.2 or 9.0.3 instance, perform these steps:
Apply patch 32346813352263 to your 9.0.2 or 9.0.3 instances. You can download the patch from OracleMetaLink (http://metalink.oracle.com).
See Section 4.9.4.2, "Issue: 10g Release 2 (10.1.2) Instance Must Not Contain the Active Oracle Enterprise Manager" for details on why you need this patch.
Stop all processes associated with the instance you want to deinstall.
Run the installer to deinstall the 9.0.2 or 9.0.3 instance. Make sure you run the version of Oracle Universal Installer that was used to install the Release 2 (9.0.2) or Release 2 (9.0.3) instance.
For example, for Release 2 (9.0.2) and Release 2 (9.0.3) instances, start the installer from the Start menu: Start / Programs / Oracle Installation Products / Universal Installer.
If you have multiple 9.0.2 and/or 9.0.3 instances on the same computer, these instances share an Oracle Enterprise Manager. This is the "active Oracle Enterprise Manager". When you deinstall the instance that contains the active Oracle Enterprise Manager using the installer, the installer needs to switch the active Oracle Enterprise Manager to one of the remaining instances. If there is only one remaining instance, then the installer automatically makes it the active Oracle Enterprise Manager. If more than one instance remain, the installer prompts you to select the instance to contain the active Oracle Enterprise Manager.
Unlike 9.0.2 or 9.0.3 instances, Oracle Application Server 10g Release 2 (10.1.2) instances on the same computer do not share an Oracle Enterprise Manager. Each 10g Release 2 (10.1.2) instance has its own Oracle Enterprise Manager.
Because 10g Release 2 (10.1.2) instances do not share an Oracle Enterprise Manager, you must not select a 10g Release 2 (10.1.2) instance to contain the active Oracle Enterprise Manager. You must select a 9.0.2 or 9.0.3 instance to contain the active Oracle Enterprise Manager.
If you select a 10g Release 2 (10.1.2) instance, or if the installer automatically switches the active Oracle Enterprise Manager to a remaining instance that happens to be a 10g Release 2 (10.1.2) instance, the installer overwrites files in the 10g Release 2 (10.1.2) Oracle home with files from the 9.0.2 or 9.0.3 home. This causes Oracle Enterprise Manager to stop working.
The patch described in Section 4.9.4.1, "Deinstallation of 9.0.2 or 9.0.3 Instances from a Computer that Also Contains 10g Release 2 (10.1.2) Instances" prevents the installer from automatically switching the active Oracle Enterprise Manager to a 10g Release 2 (10.1.2) instance in the case where the only remaining instances are 10g Release 2 (10.1.2) instances. It also prevents the installer from displaying 10g Release 2 (10.1.2) instances in the list where you select the instance to contain the active Oracle Enterprise Manager.
If a 10g Release 2 (10.1.2) instance becomes the active Oracle Enterprise Manager, Oracle Enterprise Manager will stop working.
To fix this, perform these steps in the 10g Release 2 (10.1.2) Oracle home:
Shut down the Oracle Enterprise Manager Application Server Control:
DESTINATION_ORACLE_HOME\bin\emctl stop iasconsole
Rename the following files. Do not delete the files, because you might need them in step 5. You can rename them with an "active" suffix (for example, iasadmin.properties.active):
DESTINATION_ORACLE_HOME\sysman\config\iasadmin.properties DESTINATION_ORACLE_HOME\sysman\emd\targets.xml DESTINATION_ORACLE_HOME\sysman\j2ee\config\jazn-data.xml DESTINATION_ORACLE_HOME\sysman\webapps\emd\WEB-INF\config\consoleConfig.xml
Copy the backup files for the files listed in the preceding step.
The backup files are in the same directory as the listed files. The names of the backup files are suffixed with a digit (for example, iasadmin.properties.1). Check the timestamp, or check the content, of the backup files to determine the most recent backup file.
Start the Oracle Enterprise Manager Application Server Control.
DESTINATION_ORACLE_HOME\bin\emctl start iasconsole
If you have remaining Release 2 (9.0.2) or Release 2 (9.0.3) instances on the computer, you need to designate one of them to contain the active Oracle Enterprise Manager.
Copy the files listed in step 2 (which you renamed with the active suffix) to the Release 2 (9.0.2) or Release 2 (9.0.3) instance Oracle home. Rename them back to the original names (that is, remove the active suffix).
Update the following key in the Registry to refer to the new active Oracle Enterprise Manager:
HKEY_LOCAL_MACHINE / SOFTWARE / ORACLE / EM_LOC
Steps for updating the key:
i. Select Start / Run. Enter regedit to start up the Registry Editor.
ii. In the left frame, expand HKEY_LOCAL_MACHINE / SOFTWARE.
iii. In the left frame, select ORACLE.
iv. In the right frame, double-click EM_LOC. Update the path to point to the new active Oracle Enterprise Manager and click OK.
When you are certain that the upgrade was successful, you have all of the necessary backups, and have no plans to revert to the source Oracle home, you may elect to remove the files from the source Oracle home. Use the Oracle Universal Installer to deinstall the instance.
|
See Also: Oracle9i Application Server Installation Guide in the 10g (9.0.4) documentation library for instructions on deinstalling the instance. |
The following special considerations apply if you are upgrading a middle tier that is part of an Oracle Application Server Cluster, or if you are upgrading an OracleAS Wireless Release 2 (9.0.2) or Oracle Workflow middle tier:
Special Instructions When Upgrading an OracleAS Wireless Release 2 (9.0.2) Middle Tier
Special Instructions When Upgrading an Oracle Application Server Cluster
Special Instructions When Upgrading Oracle Workflow Middle Tier Components
If you are using an Oracle Application Server Cluster, review the following sections before you begin upgrading the middle tiers that comprise a cluster:
Understanding the Components of Oracle Application Server Cluster
Upgrading Oracle Application Server Cluster in a Database-Based Repository
Upgrading Oracle Application Server Cluster in a File-Based Repository
Updating the mod_oc4j Configuration File for an Upgraded Cluster
|
Note: The following sections assume you are currently using Oracle Application Server Cluster and that you are familiar with the procedures for creating and managing Oracle Application Server Cluster.Section 4.10.1.1, "Understanding the Components of Oracle Application Server Cluster" is provided as a summary of OracleAS Cluster concepts; it should not replace a thorough review of the concepts described in Distributed Configuration Management Administrator's Guide. |
If you are using Oracle Application Server Cluster, then you have installed multiple Oracle Application Server middle-tier instances, and two or more of the instances belong to the same farm and to the same OracleAS Cluster.
A farm is a collection of instances that share the same Distributed Configuration Management (DCM) repository. The DCM repository can be one of the following:
A database-based repository that contains the DCM schema
The database-based repository can be an OracleAS Metadata Repository installed as part of an Oracle Application Server Infrastructure installation, or it can be an OracleAS Metadata Repository created using the Oracle Application Server Metadata Repository Creation Assistant (OracleAS Metadata Repository Creation Assistant).
In either case, the database repository contains the DCM schema, as well as schemas used by many other Oracle Application Server components.
A File-based Repository that does not require an Oracle database.
The File-based Repository contains only the DCM schema and does not contain other component schemas required for various Oracle Application Server components. As a result, it can be used only as an OracleAS Farm for multiple J2EE and Web Cache installations.
When you create a cluster in a file-based DCM repository, there is no database, but one of the instances in the cluster becomes the repository host. The file-based repository resides on the repository host.
|
See Also: "Distributed Configuration Management Overview" in the Distributed Configuration Management Administrator's Guide |
To upgrade Oracle Application Server Cluster in a database-based repository:
Log in to one of the middle tier instances that are part of the cluster and identify the names of all the middle tier instances that are currently in the cluster.
You can use the DCM command line to identify the members of the cluster, or you can use the Application Server Control Console.
To use the DCM command line:
Enter the following command to identify the name of the cluster:
SOURCE_ORACLE_HOME\dcm\bin\dcmctl listclusters
Enter the following command to list the instances in the cluster:
SOURCE_ORACLE_HOME\dcm\bin\dcmctl listinstances -cl cluster_name
To use the Application Server Control Console, navigate to the Cluster page to see a list of the instances in the cluster.
|
See Also: "About Managing Oracle Application Server Clusters" in the Application Server Control online help |
Use the instructions in the remaining sections of this chapter to upgrade each of the middle tiers in the cluster and then start each newly upgraded 10g Release 2 (10.1.2) instance.
When all the middle tiers are upgraded and running, make sure the original, source instances are stopped.
For each source middle tier, use the following commands to remove the source middle tier from the cluster and then from the database-based farm:
SOURCE_ORACLE_HOME\dcm\dcmctl leavecluster SOURCE_ORACLE_HOME\dcm\dcmctl leavefarm
Add each of the newly upgraded 10g Release 2 (10.1.2) instances to the database-based farm.
You can add each instance to the farm by using the Application Server Control Console.
|
See Also: "Adding an Instance to an Oracle Application Server Farm" in the Application Server Control online help |
After you add the 10g Release 2 (10.1.2) instances to the farm, recreate the cluster and add each of the instances to the new 10g Release 2 (10.1.2) cluster.
You can recreate the cluster and add each instance to the cluster by using the DCM command line (dcmctl) or by using the Farm page in the Application Server Control Console.
|
See Also: "Farm Creation and Maintenance Tasks" in the Distributed Configuration Management Administrator's Guide for information about using the DCM command line"About Managing Oracle Application Server Clusters" in the Application Server Control online help |
To upgrade OracleAS Cluster in a file-based repository:
Identify the file-base repository host.
The repository host is the computer you were logged in to when you created the file-based repository. The file-based repository resides on this host.
Log in to the repository host and identify the names of all the middle tier instances that are currently in the cluster.
You can use the DCM command line to identify the members of the cluster, or you can use the Application Server Control Console.
To use the DCM command line:
Enter the following command to identify the name of the cluster:
SOURCE_ORACLE_HOME\dcm\bin\dcmctl listclusters
Enter the following command to list the instances in the cluster:
SOURCE_ORACLE_HOME\dcm\bin\dcmctl listinstances -cl cluster_name
To use the Application Server Control Console, navigate to the Cluster Home page to see a list of the instances in the cluster.
|
See Also: "About Managing Oracle Application Server Clusters" in the Application Server Control online help |
In preparation for upgrading the cluster, install a new 10g Release 2 (10.1.2) J2EE and Web Cache instance in a new Oracle home on the file-based repository host.
During the installation procedure, create a new file-based repository for the 10g Release 2 (10.1.2) instance. Do not use the OracleAS Upgrade Assistant to upgrade the original source Oracle home to 10g Release 2 (10.1.2) until later in this procedure.
|
See Also: Oracle Application Server Installation Guide for information on creating a new file-based repository as part of the Oracle Application Server installation procedure. |
For each of the other cluster members—but not the instance on the repository host—do the following:
Log in to the middle tier host and install a new 10g Release 2 (10.1.2) J2EE and Web Cache instance in a new Oracle home.
During the installation, join the 10g Release 2 (10.1.2) farm you created when you installed 10g Release 2 (10.1.2) on the repository host.
Use the instructions in Section 4.4, "Task 3: Run the OracleAS Upgrade Assistant" to upgrade the instance to 10g Release 2 (10.1.2).
Log in to the file-based repository host and, using the instructions in Section 4.4, "Task 3: Run the OracleAS Upgrade Assistant", upgrade the instance on the repository host to 10g Release 2 (10.1.2).
Recreate the cluster and then add each of the instances to the new 10g Release 2 (10.1.2) cluster.
You can recreate the cluster and add each instance to the cluster by using the DCM command line (dcmctl) or by using the Farm page in the Application Server Control Console.
|
See Also: Distributed Configuration Management Administrator's Guide for information about using the DCM command line"About Managing Oracle Application Server Clusters" in the Application Server Control online help |
Perform the following additional tasks after you upgrade the cluster to preserve your request routing configuration:
Use a text editor to open the following file in one of the instances, noting the instance and cluster names in the Oc4jMount directives:
DESTINATION_ORACLE_HOME\Apache\Apache\conf\mod_oc4j.conf
Change the instance (and, if necessary) cluster names to the instance name of the upgraded instance.
Copy the Oc4jMount directives to the mod_oc4.conf file in each instance in the new cluster.
Verify that requests that match the URL patterns in the Oc4jMount directives are routed to the correct instances.
If you are upgrading one or more Release 2 (9.0.2) middle tiers that are running Oracle Application Server Wireless, you must perform the following procedure before running the OracleAS Upgrade Assistant:
Shut down all Release 2 (9.0.2) middle tiers that are running Oracle9iAS Wireless.
|
See Also: "Starting and Stopping the Application Server" in the Oracle9i Application Server Administrator's Guide in the Release 2 (9.0.2) documentation library |
Back up the WIRELESS schema in the Release 2 (9.0.2) OracleAS Metadata Repository.
This step is recommended because when you install the Oracle Application Server Wireless 10g Release 2 (10.1.2) middle tier (in the next step), the Wireless Configuration Assistant upgrades the WIRELESS schema in the Release 2 (9.0.2) OracleAS Metadata Repository to 10g (9.0.4).
Later, when you upgrade the OracleAS Metadata Repository to 10g Release 2 (10.1.2), the Metadata Repository Upgrade Assistant (MRUA) will upgrade the 10g (9.0.4) WIRELESS schema to 10g Release 2 (10.1.2).
You can back up the WIRELESS schema by using the Export database utility.
exp system/password@service_name file=iasw902.dmp owner=WIRELESS
In this example, you must provide the following values:
password - password of the SYSTEM account.
service_name - local net service name that points to the 9.0.2 metadata repository, for example, asdb.
This command creates a database export file called iasw902.dmp with the contents of the WIRELESS schema.
Continue with the middle tier upgrade process as described in the rest of this chapter.
The middle tier upgrade process includes a step where you install a 10g Release 2 (10.1.2) middle tier. When you install a 10g Release 2 (10.1.2) Portal and Wireless installation against the Release 2 (9.0.2) infrastructure, the Wireless Configuration Assistant upgrades the WIRELESS schema to 9.0.4.
If you install additional Oracle Application Server Wireless 10g Release 2 (10.1.2) middle tiers against the same OracleAS Metadata Repository, the configuration assistant detects that the schema is already upgraded and does not upgrade it again.
After you upgrade one of the Portal and Wireless middle tiers to 10g Release 2 (10.1.2), you can continue upgrading the other middle tiers, or you can restart the other middle tiers where Release 2 (9.0.2) Wireless is configured.
To upgrade Oracle Workflow, you must perform your upgrade using the following steps
Install the 10g Release 2 (10.1.2) Oracle home, as described in Section 4.2, "Task 1: Install a New 10g Release 2 (10.1.2) Middle Tier In Preparation for Upgrade".
Install Oracle Workflow Release 2.6.3.5 from the Oracle Content Management SDK CD into the new 10g Release 2 (10.1.2) middle tier Oracle home.
Use the OracleAS Upgrade Assistant to upgrade the middle tier to 10g Release 2 (10.1.2) as described in the following sections:
Run the Workflow Configuration Assistant as described in the Oracle Workflow Installation Notes for Oracle Content Management Software Development Kit, which is available on the Oracle Technology Network at the following location:
http://www.oracle.com/technology/documentation/cm_sdk.html
The Workflow Configuration Assistant performs additional upgrade tasks for the middle tier, and if necessary, upgrades the Oracle Workflow schema.
When you run the Workflow configuration Assistant, note the following:
If you already upgraded the Oracle Workflow schema, use the Configure Middletier install option.
For example, the Oracle Workflow schema might have been upgraded previously during the upgrade of another Oracle Workflow middle tier.
If you are upgrading the Oracle Workflow schema in a customer database and configuring the Oracle Workflow middle tier at the same time, use the Server and Middletier install option.
|
See Also: Section 8.5.3, "Upgrading the Oracle Workflow Schema in a Customer Database"Oracle Workflow Administrator's Guide |
