Oracle® Application Server 10g Upgrading to 10g (9.0.4)
10g (9.0.4) for UNIX Part No. B10429-01 |
|
![]() |
![]() |
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"
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.
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.
This section provides examples of configurations that are supported, and not supported, based on application of the compatibility rules.
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 1 Release | Identity ManagementFoot 2 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 |
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.
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.
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
Table 2-2 Transition from A to E to G to HFoot 1
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 |
Table 2-3 Transition from A to E to F to HFoot 1
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 |
Table 2-4 Transition from A to B to F to HFoot 1
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 |
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"
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.3, "Infrastructure Schemas Upgraded by Scripts"
Section 2.2.1.4, "Manual 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 |
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"
|
The OracleAS Upgrade Assistant upgrades the following middle-tier component configurations.
All upgrade processing performed by the OracleAS Upgrade Assistant is described in Appendix A, "Component Upgrade Process Reference", in the following sections:
Section A.1.1, "The Oracle Process Manager and Notification Server (OPMN) Upgrade Process"
Section A.1.2, "The Instance Configuration Data Upgrade Process"
Section A.1.3, "The Oracle Application Server Containers for J2EE (OC4J) Upgrade Process"
Section A.1.5, "The Oracle Application Server Web Cache Upgrade Process"
Section A.1.7, "The Oracle Enterprise Manager Upgrade Process"
Section A.1.8, "The Oracle Application Server Web Services UDDI Registry Upgrade Process"
Section A.1.10, "The OracleAS Portal Middle Tier Upgrade Process"
Section A.1.11, "The Oracle Application Server Wireless Upgrade Process"
Section A.1.12, "The Oracle Application Server Forms Services Upgrade Process"
Section A.1.13, "The Oracle Application Server Discoverer Upgrade Process"
Section A.1.14, "The Oracle Application Server Reports Services Upgrade Process"
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:
Section A.2.2, "The Metadata Repository Container Schema Upgrade Process"
Section A.2.4, "The Oracle Application Server Certificate Authority Upgrade Process "
Section A.2.5, "The Oracle Ultra Search Schema Upgrade Process"
Section A.2.7, "The Oracle Application Server Syndication Server Schema Upgrade Process"
Section A.2.8, "The Oracle Application Server Web Services UDDI Registry Schema Upgrade Process"
Section A.2.10, "The Oracle Application Server Wireless Schema Upgrade Process"
Manual tasks and their location in this guide are listed below:
Section 3.8.1, "Completing the Oracle HTTP Server Upgrade"
Section 3.8.2, "Completing the Oracle Application Server Containers for J2EE (OC4J) Upgrade"
Section 3.8.3, "Completing the OracleAS Web Cache Upgrade"
Section 3.8.4, "Completing the OracleAS Portal Middle Tier Upgrade"
Section 3.8.5, "Completing the Oracle Application Server Discoverer Viewer Upgrade"
Section 3.8.6, "Completing the Oracle Application Server Reports Services Upgrade"
Section 3.8.7, "Completing the Oracle Application Server Wireless Upgrade"
Section 3.8.8, "Completing the Oracle Application Server Forms Services Upgrade"
Section 3.8.9, "Upgrading the tnsnames.ora File"
Section 3.9, "Upgrading OracleAS InterConnect" (no automated upgrade exists for this component)
Section 4.5.8, "Completing the OracleAS Portal Repository Upgrade"
Section 5.4.1, "Completing the Oracle Internet Directory Upgrade"
Section 5.4.2, "Completing the Oracle Application Server Single Sign-On Upgrade"
Section 5.4.3, "Completing the Oracle Application Server Wireless Upgrade"
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?
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 1 | 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 |
Table 2-7 Infrastructure Upgrade Duration Estimates
Operation | Metadata Repository | Identity Management | Full InfrastructureFoot 1 |
---|---|---|---|
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 2 | 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 |
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:
The Release 2 (9.0.2) system is functioning at full capacity, with clients connecting through both middle tiers.
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.
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.
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.
The second middle tier is upgraded to 10g (9.0.4). Clients can now connect through both middle tiers.
The Infrastructure is stopped in preparation for upgrade. Applications that are dependent on the Infrastructure are unavailable now.
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". |
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:
Directories for specific components. See Table B-2, "Files Containing Upgrade Data (Sorted by Path)".
The entire Oracle home. You can use the Oracle Application Server Backup and Recovery tool and documentation to do this.
See Also: Oracle Application Server 10g Administrator's Guide |