Oracle® Application Server Upgrade and Compatibility Guide
10g Release 2 (10.1.2) for UNIX Part No. B14090-05 |
|
Previous |
Next |
This chapter provides guidelines for planning an upgrade. It consists of the following sections:
Before you start the upgrade process, you should have a clear understanding of the backup requirements. These requirements vary somewhat, depending upon whether you are upgrading a middle tier, an OracleAS Metadata Repository, or OracleAS Identity Management.
The following sections provide more information:
When you upgrade a middle tier installation, you install Oracle Application Server 10g Release 2 (10.1.2) into a new Oracle home directory and use the OracleAS Upgrade Assistant to copy your configuration data from the source Oracle home to the new, destination Oracle home. The upgrade process alters only the 10g Release 2 (10.1.2) destination Oracle home; the source instance is always left unchanged. As a result, there is no need to implement additional or new backup strategies for the source Oracle home, other than those you already use to protect your application server data.
Note: There is a scenario where installing a new 10g Release 2 (10.1.2) middle tier will alter the schemas in the OracleAS Metadata Repository. In that scenario, you should back up the OracleAS Metadata Repository database before upgrading the middle tier to 10g Release 2 (10.1.2).For more information, see Section 4.10.2, "Special Instructions When Upgrading an OracleAS Wireless Release 2 (9.0.2) Middle Tier". |
On the other hand, you may want to create a backup of the new 10g Release 2 (10.1.2), destination Oracle home before you run the OracleAS Upgrade Assistant. This backup will allow you to restore to a pre-upgrade (that is, newly installed) state. Restoring from backups is 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 Appendix B, "Files Reference".
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 Administrator's Guide for instructions on using the Backup and Recovery Tool, which is designed to help you back up and recover your Oracle Application Server installations |
In most cases, when you upgrade a OracleAS Metadata Repository, you must first upgrade the database that hosts the repository to database version supported by 10g Release 2 (10.1.2).
As with any database upgrade, standard procedure dictates that you back up your source OracleAS Metadata Repository before you upgrade the database version. For more information, see the Oracle Database documentation for your platform and database version.
After the database is upgraded, you must then run the Metadata Repository Upgrade Assistant (MRUA) to upgrade the component schemas so they are compatible with your 10g Release 2 (10.1.2) middle tier instances. This upgrade of the schemas is performed "in place," which means that MRUA alters the application server component schemas that exist in the database. It does not create a new copy of the schemas or the data they contain. The changes made by MRUA are irreversible.
As a result, before you run MRUA, you should perform a backup of the database that contains the schemas. This backup will allow you to restore your database to its original state before you run MRUA.
See Also: Oracle Application Server Administrator's Guide for information about the Oracle Application Server Backup and Recovery Tool, which is designed to help you back up and recover your Oracle Application Server installationsOracle Database Backup and Recovery Basics in the Oracle Database 10g documentation library for information and guidelines for backing up your Oracle database |
The OracleAS Identity Management upgrade involves upgrading the configuration and data files in the Oracle home of the OracleAS Identity Management installation, as well as upgrading the OracleAS Identity Management schemas stored in the OracleAS Metadata Repository database.
Consider the following backup strategies when upgrading your OracleAS Identity Management installations:
When you upgrade OracleAS Identity Management, you use the Oracle Universal Installer and the Oracle Application Server 10g Release 2 (10.1.2) installation procedure. The installation procedure automatically installs a new 10g Release 2 (10.1.2) destination Oracle home and copies configuration data from the source Oracle home to the destination Oracle home.
As a result, the source Oracle home is not modified by the OracleAS Identity Management upgrade process and no additional or new backup strategies are required, other than those you already use to protect your application server data.
The installation procedure also upgrades the OracleAS Identity Management schemas in the OracleAS Metadata Repository. These schemas include the Oracle Internet Directory and OracleAS Single Sign-On schemas.
The upgrade of the OracleAS Identity Management schemas is performed "in place," which means that the procedure alters the OracleAS Identity Management schemas that exist in the database. It does not create a new copy of the schemas or the data they contain. The schemas changes made by the OracleAS Identity Management upgrade are irreversible.
As a result, you should back up the OracleAS Metadata Repository database that contains the OracleAS Identity Management schemas before you upgrade.
After you have completed and verified the upgrade of your Oracle Application Server environment, consider backing up your Oracle Application Server installations so you can easily restore your environment to the newly upgraded state.
In particular, consider backing up the newly upgraded OracleAS Metadata Repository database immediately after the upgrade process. After this initial post-upgrade backup, you can begin your regularly scheduled database backup routine. The initial backup after the upgrade will ensure that you can restore your environment to the newly upgraded 10g Release 2 (10.1.2) state without repeating the upgrade process.
In addition, after you have moved your development or deployment activities to the newly upgraded Oracle Application Server installations, be sure to modify your regular backup routine to include the new Oracle Application Server Oracle homes.
To increase system availability during the upgrade process, you should carefully review Chapter 2, "Understanding Version Compatibility" and then plan your upgrade so you can:
Avoid implementing any unsupported configurations.
Reduce as much as possible the amount of time spent using transitional configurations.
As an example of how you can plan for system availability, this section outlines the steps involved in the upgrade process when two Oracle Application Server 10g (9.0.4) middle tier instances use a single 10g (9.0.4) Infrastructure instance.
The colocated Infrastructure in this example consists of both an OracleAS Metadata Repository and OracleAS Identity Management. As shown in Figure 3-1, full system downtime occurs only in step 6 of the process (if the system relies on an Infrastructure). Step 6 involves stopping the OracleAS Infrastructure so it can be upgraded.
For simplicity's sake, only two middle tiers are shown in the figure; however, in practice, there may be many more. The more middle tiers in service, the lower the system capacity loss in downtime during upgrade. For example, 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. If a load balancer is in use, users need not be aware of middle tier downtime.
Figure 3-1 Example of System Availability During the Upgrade Process
The progression of system states during the upgrade process is detailed as follows:
The 10g (9.0.4) 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 Release 2 (10.1.2). When the upgrade is complete and the middle tier is restarted, clients can then connect through both middle tiers.
This step in the process represents a transitional configuration.
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 Release 2 (10.1.2). After the second middle tier is upgraded and started, clients can then connect through both middle tiers.
This step in the process represents a transitional configuration.
The middle tiers are stopped in preparation for the Infrastructure upgrade. Applications that are dependent on the Infrastructure are unavailable now.
The Infrastructure is upgraded to 10g Release 2 (10.1.2). After the OracleAS Metadata Repository and OracleAS Identity Management are upgraded and all instances are started, clients can connect to the fully upgraded system.
This step in the process represents a final configuration.
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 and to troubleshooting the upgrade?
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.
For more information, see Table 3-1, "Middle Tier Upgrade Duration Estimates" and Table 3-2, "Infrastructure Upgrade Duration Estimates"
Table 3-1 Middle Tier Upgrade Duration Estimates
Operation | J2EE & Web Cache | Portal & Wireless |
---|---|---|
10g Release 2 (10.1.2) middle tier installation:A 10g Release 2 (10.1.2) middle tier must be installed on the same computer as the Release 2 (9.0.2), Release 2 (9.0.3), or 10g (9.0.4) middle tier. |
30 minutes |
60 minutesFoot 1 |
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 |
Post-upgrade: This includes starting the upgraded instance and performing basic verification tests. |
20 minutes |
30 minutes |
Total |
1 hour, 10 minutes |
2 hours |
Table 3-2 Infrastructure Upgrade Duration Estimates
Operation | Metadata Repository | Identity Management | Colocated InfrastructureFoot 1 |
---|---|---|---|
Database backup: The database should be backed up with the user's preferred procedure. |
1 hour |
Not applicable. |
Not applicable |
Oracle home backup: The Infrastructure Oracle home should be backed up. |
Not applicable. |
1 hour |
1 hour |
Database upgrade: If the Metadata Repository was created with OracleAS Metadata Repository Creation Assistant and the database is not a supported version, you must upgrade the database manually to a supported version. |
Not applicable |
Not applicable |
Not applicable |
Installation and upgrade with Oracle Universal Installer Depending upon the installation type you are upgrading, the Oracle Universal Installer installs new OracleAS Identity Management components and, if the Oracle home contains an OracleAS Metadata Repository, automatically upgrades the OracleAS Metadata Repository database to the supported version. |
3 hoursFoot 2 |
30 minutes |
3 hours, 30 minutes |
Database backup before running MRUA |
1 hour |
Not applicable |
1 hour |
OracleAS Metadata Repository upgrade with MRUA: Component schemas in the Metadata Repository are upgraded. |
1 hour |
Not applicable |
1 hour |
Identity Management post-upgrade: Perform all post-upgrade tasks. |
Not Applicable. |
1 hour |
1 hours |
Total: |
6 hours |
2 hours, 30 minutes |
7 hours, 30 minutes |