Skip Headers

Oracle® Application Server 10g Upgrading to 10g (9.0.4)
10g (9.0.4) for UNIX
Part No. B10429-01
  Go To Documentation Library
Home
Go To Table Of Contents
Contents
Go To Index
Index

Previous Next  

2 Planning an Upgrade

This chapter provides guidelines for planning an upgrade. It consists of the following sections:

Section 2.1, "Oracle Application Server Compatibility"

Section 2.2, "Determining an Upgrade Strategy"

2.1 Oracle Application Server Compatibility

As discussed in Chapter 1, a distributed Oracle Application Server configuration comprises one or more middle tiers and an Infrastructure. The Infrastructure comprises Identity Management and the Metadata Repository, each of which can be Release 2 (9.0.2) or 10g (9.0.4).

The upgrade process provides for compatibility between these units. Section 1.3, "The Infrastructure Upgrade Process" discusses supported hybrid configurations, in which the Infrastructure combines Metadata Repository and Identity Management units of 10g (9.0.4) and Release 2 (9.0.2). The implication is, of course, that certain combinations of units are not supported.

This section identifies salient compatibility rules and, based on these, presents a sampling of supported and unsupported configurations. Understanding these, and the possible transition states between them, will help you plan a successful Oracle Application Server upgrade.

2.1.1 Compatibility Rules

Oracle Application Server compatibility is based on the following rules:

  • A 10g (9.0.4) middle tier interoperates with a 10g (9.0.4) Metadata Repository.

  • A 10g (9.0.4) middle tier interoperates with a 10g (9.0.4) Identity Management.

  • A 10g (9.0.4) middle tier interoperates with a Release 2 (9.0.2) Metadata Repository.

  • A 10g (9.0.4) middle tier interoperates with a Release 2 (9.0.2) Identity Management.

  • All version rules are platform independent: two or more of the version units may reside on multiple operating systems without impact on their compatibility relationship.

  • A 10g (9.0.4) Metadata Repository does not interoperate with a Release 2 (9.0.2) or Release 2 (9.0.3) middle tier.

  • Clusters only host instances of the same release.

2.1.2 Oracle Application Server Configuration Examples

This section provides examples of configurations that are supported, and not supported, based on application of the compatibility rules.

2.1.2.1 Single Middle Tier and Single Infrastructure

Table 2-1 lists configurations that combine middle tier and Infrastructure units of different releases, and indicates whether they are supported.

Table 2-1 Single Middle Tier and Single Infrastructure Compatibility

Configuration Middle Tier Release Metadata RepositoryFoot  Release Identity ManagementFoot  Release Supported?
A 9.0.2 or 9.0.3 9.0.2 9.0.2 Yes
B 9.0.2 or 9.0.3 9.0.2 9.0.4 Yes
C 9.0.2 or 9.0.3 9.0.4 9.0.2 No
D 9.0.2 or 9.0.3 9.0.4 9.0.4 No
E 9.0.4 9.0.2 9.0.2 Yes
F 9.0.4 9.0.2 9.0.4 Yes
G 9.0.4 9.0.4 9.0.2 Yes
H 9.0.4 9.0.4 9.0.4 Yes

Footnote Excludes Oracle Internet Directory and Oracle Application Server Single Sign-On schemas. Consists of schemas for: Integration Platform, Oracle Certificate and Authentication, Oracle Ultra Search, Oracle Application Server Syndication Server, Oracle Application Server Web Services, Oracle Application Server Portal, Oracle Application Server Wireless, and Web Clipping.
Footnote Identity Management comprises Oracle Internet Directory and Oracle Application Server Single Sign-On binaries and schemas.

2.1.2.2 Multiple Middle Tiers and Single Infrastructure

Compatibility in multiple middle tiers and a single Infrastructure is very similar to the single middle tier and single Infrastructure case. The fact that a 10g (9.0.4) Metadata Repository does not operate with a Release 2 (9.0.2) or Release 2 (9.0.3) middle tier is the determining factor in compatibility; it is the most likely reason for incompatibility in this configuration.

2.1.2.3 Multi-Platform Installations

A unit’s operating system does not affect its compatibility relationships with units on other platforms. Any of the distributed configurations will run on a variety of platforms. For example, a 10g (9.0.4) middle tier on a Linux system may access Release 2 (9.0.2) Identity Management and a Metadata Repository on a Windows system. A 10g (9.0.4) middle tier on a Windows system may access a 10g (9.0.4) Identity Management and a Release 2 (9.0.2) Metadata Repository on a Solaris system, and so on.

2.1.3 Transitions Between Configurations

This section identifies possible transitions between configurations during upgrade. Figure 2-1 depicts the transitions. Table 2-2, Table 2-3, and Table 2-4 list the releases and the order in which the upgrade must be performed.

Figure 2-1 Supported Transitions Between Configurations

Description of asmas031.gif follows
Description of the illustration asmas031.gif

Table 2-2 Transition from A to E to G to HFoot 

Configuration Middle Tier Release Metadata Repository Release Identity Management Release
A 9.0.2 or 9.0.3 9.0.2 9.0.2
E 9.0.4 9.0.2 9.0.2
G 9.0.4 9.0.4 9.0.2
H 9.0.4 9.0.4 9.0.4

Footnote The upgrade must be performed in this order: Middle tier, Metadata Repository, Identity Management.

Table 2-3 Transition from A to E to F to HFoot 

Configuration Middle Tier Release Identity Management Release Metadata Repository Release
A 9.0.2 or 9.0.3 9.0.2 9.0.2
E 9.0.4 9.0.2 9.0.2
F 9.0.4 9.0.4 9.0.2
H 9.0.4 9.0.4 9.0.4

Footnote The upgrade must be performed in this order: Middle tier, Identity Management, Metadata Repository.

Table 2-4 Transition from A to B to F to HFoot 

Configuration Identity Management Release Middle Tier Release Metadata Repository Release
A 9.0.2 9.0.2 or 9.0.3 9.0.2
B 9.0.4 9.0.2 or 9.0.3 9.0.2
F 9.0.4 9.0.4 9.0.2
H 9.0.4 9.0.4 9.0.4

Footnote The upgrade must be performed in this order: Identity Management, Middle tier, Metadata Repository.

2.2 Determining an Upgrade Strategy

This section provides information that will help you determine how to approach the Oracle Application Server upgrade. It contains these topics:

Section 2.2.1, "Upgrade Process Overview"

Section 2.2.2, "Planning for System Downtime"

Section 2.2.3, "System Availability During Upgrade"

Section 2.2.4, "Creating Backups"

2.2.1 Upgrade Process Overview

This section describes the upgrade process in entirety and identifies the parts of the upgrade that are automated by the Upgrade Assistant or a script, and those that are manual. It contains these topics:

Section 2.2.1.1, "Upgrade Tasks"

Section 2.2.1.2, "Middle-Tier Components Upgraded by the Oracle Application Server Upgrade Assistant"

Section 2.2.1.3, "Infrastructure Schemas Upgraded by Scripts"

Section 2.2.1.4, "Manual Upgrade Tasks"

2.2.1.1 Upgrade Tasks

Table 2-5, "Oracle Application Server Upgrade Tasks", is a task list for the entire upgrade process. Some steps do not apply all configurations; for example,Step 6 and Steps 8 through 11 are not applicable to configurations that do not use an Infrastructure.

Table 2-5 Oracle Application Server Upgrade Tasks

Step Task Instructions
1 Install the Oracle Application Server 10g (9.0.4) middle tier, which must use the same Metadata Repository and Oracle Internet Directory as the Release 2 (9.0.2) middle tier being upgraded. Oracle Application Server 10g Installation Guide
2 Stop the source middle tier instance. Section 3.1.2, "Stopping Oracle Application Server Instances"
3 Ensure that the Infrastructure is running and accessible. Section 3.5.2, "Starting the Infrastructure" on page 3-10
4 Execute the OracleAS Upgrade Assistant. Section 3.5, "Using the OracleAS Upgrade Assistant"
5 Perform the manual steps required to complete the middle tier upgrade. Section 3.8, "Completing the Upgrade"
6 Repeat Steps 1, 2, 3, 4 and 5 for each middle tier associated with the same Infrastructure. Oracle Application Server 10g Installation Guide

Section 3.1.2, "Stopping Oracle Application Server Instances"

Section 3.5.2, "Starting the Infrastructure" on page 3-10

Section 3.5, "Using the OracleAS Upgrade Assistant"

Section 3.8, "Completing the Upgrade"

7 Apply the patch to upgrade the database to Release 9.0.1.5. Section 4.2, "Preparing to Upgrade the Metadata Repository"
8 Install or upgrade the Oracle Application Server 10g (9.0.4) Infrastructure. Section 5.1, "Upgrading Identity Management"
9 Execute the scripts to upgrade the Infrastructure database schemas for the Metadata Repository Container, Integration Platform, Oracle Certificate and Authentication, Syndication Server, Web Clipping, Oracle Ultra Search, and Oracle Application Server Web Services. Section 4.4, "Executing Metadata Repository Upgrade Scripts"
10 Upgrade the Portal repository. Section 4.5, "Upgrading the OracleAS Portal Repository"
11 Perform the manual tasks (if applicable) to complete the upgrade of Oracle Application Server Single Sign-On and Oracle Internet Directory, which occurred during Infrastructure installation. Section 5.4, "Performing Infrastructure Post-Upgrade Tasks"
12 Execute the scripts to upgrade schemas in customer databases, if applicable. Section 4.6, "Upgrading Schemas in Customer Databases "
13 Modify middle tier components to adopt 10g (9.0.4) Infrastructure functionality. Section 4.7, "Activating 10g (9.0.4) Functionality for UDDI Applications"

2.2.1.3 Infrastructure Schemas Upgraded by Scripts

Some components have schemas in the Infrastructure database that contain product metadata and user data. These are upgraded by the installer, or by a script provided on the Repository Creation Assistant CD or on MetaLink. There may also be manual processes associated with these upgrades.

All processing by the schema upgrade scripts on the Repository Creation Assistant CD or is described in Appendix A, "Component Upgrade Process Reference", in the following sections:

2.2.2 Planning for System Downtime

This section contains information that will help you answer the following questions as you plan the Oracle Application Server upgrade:

  • How much downtime should be allocated to upgrade? to troubleshooting?

  • What parts of the system are subject to downtime?

  • When will the downtime occur?

2.2.2.1 How Long Will the Upgrade Take?

The duration of upgrade preparation tasks and upgrade processing is of concern when considering downtime. This section provides estimates of the duration of the upgrade of a basic configuration. The estimates do not account for troubleshooting time; they are based on an error-free upgrade.

Table 2-6 Middle Tier Upgrade Duration Estimates

Operation J2EE & Web Cache Portal & Wireless Business Intelligence & Forms

Total

1 hour, 45 minutes

2 hours, 35 minutes

3 hours, 25 minutes
10g (9.0.4) middle tier installation:A 10g (9.0.4) middle tier must be installed on the same computer as the Release 2 (9.0.2) or Release 2 (9.0.3) middle tier. 30 minutes 60 minutesFoot  90 minutesFootref 1
Pre-upgrade: The source and destination instances must be stopped. Backing up the instances is optional and is not included in these estimates. 20 minutes 20 minutes 20 minutes
OracleAS Upgrade Assistant execution: Execution time depends on source configuration; for example, the number and size of J2EE applications deployed may affect the duration significantly. This estimate assumes a basic configuration. 20 minutes 30 minutes 40 minutes
Post-upgrade: This includes starting the upgraded instance and performing basic verification tests. 20 minutes 30 minutes 40 minutes

Footnote The first 10g (9.0.4) instance that configures Oracle Application Server Wireless against a Release 2 (9.0.2) Metadata Repository upgrades the schema in that repository. This may increase the length of this operation significantly. If Oracle Application Server Wireless is running on multiple middle tiers, Oracle Application Server Wireless must be stopped on all of those middle tiers before performing this operation. See Appendix A, "The Oracle Application Server Wireless Upgrade Process" for more information.

Table 2-7 Infrastructure Upgrade Duration Estimates

Operation Metadata Repository Identity Management Full InfrastructureFoot 

Total:

5 hours, 35 minutes

5 hours, 10 minutes

8 hours, 40 minutes
Database backup: The database should be backed up with the user’s preferred procedure (for example, ufsdump). 1 hour Not applicable. Not applicable.
Oracle home backup: The Infrastructure Oracle home should be backed up. Not applicable. 1 hour 1 hour
Database patch: If the database containing the Metadata Repository is version 9.0.1.3, it must be patched to version 9.0.1.5. 2 hours 2 hours 2 hours
Metadata Repository Container upgrade: The Metadata Repository Container upgrade script is executed from the Repository Configuration Assistant CD-ROM. Foot  5 minutes 5 minutes 5 minutes
Component schema and OracleAS Portal upgrade:Component schemas in the Metadata Repository and OracleAS Portal are upgraded via scripts. 2 hours Not applicable 3 hours
Metadata Repository Container post-upgrade: The middle tier components relying on upgraded schemas are re-started. 30 minutes Not applicable 30 minutes
Installer preparation: The Release 2 (9.0.2) Infrastructure software must be in the correct state (instance stopped, database started, database listener stopped, Oracle Internet Directory started, etc.) Not applicable 20 minutes 20 minutes
Installation: The Oracle Universal Installer is executed in upgrade mode, installing the 10g (9.0.4) Infrastructure into a new Oracle home and executing all post-installation configuration tools. Not applicable 45 minutes 45 minutes
Identity Management post-upgrade: Post-upgrade tasks, such as Oracle Application Server Single Sign-On DAD upgrade, as required Not applicable 1 hour 1 hour

Footnote The upgrade duration of the Metadata Repository and Identity Management may be shorter than that of the sum of the durations required to upgrade each piece individually, since common tasks need only be executed once.
Footnote Although this estimate is based on execution of all scripts, it is not mandatory that all components in the Metadata Repository are upgraded; thus, the fewer components upgraded, the shorter the duration of this operation.

2.2.3 System Availability During Upgrade

This section outlines the steps involved in the upgrade process when two middle tier instances use a single Infrastructure instance. The upgrade process was designed for high availability. As shown in Figure 2–2, full system downtime occurs only in step 6 of the process (if the system relies on an Infrastructure).

The progression of system states during the upgrade process is detailed below:

  1. The Release 2 (9.0.2) system is functioning at full capacity, with clients connecting through both middle tiers.

  2. The first middle tier is stopped, in preparation for upgrade. Clients can no longer connect through the first middle tier, but continue to connect through the second middle tier.

  3. The first middle tier is upgraded to 10g (9.0.4). (See Section 1.2, "The Middle Tier Upgrade Process".) Clients can now lconnect through both middle tiers.

  4. The second middle tier is stopped, in preparation for upgrade. Clients can no longer connect through the second middle tier, but continue to connect through the first middle tier.

  5. The second middle tier is upgraded to 10g (9.0.4). Clients can now connect through both middle tiers.

  6. The Infrastructure is stopped in preparation for upgrade. Applications that are dependent on the Infrastructure are unavailable now.

  7. The Infrastructure is upgraded to 10g (9.0.4). (See Section 1.3, "The Infrastructure Upgrade Process".) Clients can now connect to the fully upgraded system.


Notes:

Only two middle tiers are shown in the figure for simplicity’s sake, but in practice there may be many more. The more middle tiers in service, the lower the system capacity loss in downtime during upgrade. If there are two middle tiers, 50% capacity is lost when one is stopped for upgrade. If there are four middle tiers, only 25% capacity is lost when one is stopped for upgrade.

In the figure, "Clients" may refer to a load balancer. Users need not be aware of middle tier downtime.

For middle tiers running Oracle Application Server Wireless, there are exceptions to this upgrade process. Appendix A, "Upgrade of Oracle Application Server Wireless Middle Tiers and Wireless Schema".


Figure 2-2 System Availability During Upgrade

Description of asmas029.gif follows
Description of the illustration asmas029.gif

2.2.4 Creating Backups

The upgrade process only alters 10g (9.0.4) installations; the source instances are always left unchanged. You may want to create a backup of a 10g (9.0.4) Oracle home so that it can be restored to a pre-upgrade (that is, newly installed) state. Restoring from backups may be an efficient alternative to reinstalling the entire instance, in the event that upgrade results are unsatisfactory. A useful backup might include: