3 Backup Strategies and System Availability During an Upgrade

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

Backup Strategies Before Upgrade
System Availability During Upgrade
Planning for System Downtime

3.1 Backup Strategies Before Upgrade

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:

Backup Strategies for Middle Tier Upgrades
Backup Strategies for OracleAS Metadata Repository Upgrades
Backup Strategies for Identity Management Upgrades

3.1.1 Backup Strategies for Middle Tier Upgrades

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.

3.1.2 Backup Strategies for OracleAS Metadata Repository Upgrades

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).

3.1.2.1 Backing Up the Database Before Upgrading the Database Version

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.

3.1.2.2 Backing Up the Database Before Running MRUA

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.

3.1.3 Backup Strategies for Identity Management Upgrades

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.

3.1.4 Backup Strategies After Upgrading Your Oracle Application Server Instances

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.

3.2 System Availability During Upgrade

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

Description of "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.

3.3 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 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 minutes^Foot 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

^Footnote 1The first 10g Release 2 (10.1.2) 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 3-2 Infrastructure Upgrade Duration Estimates

Operation	Metadata Repository	Identity Management	Colocated Infrastructure^Foot 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 hours^Foot 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

^Footnote 1The 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 2Note that if the OracleAS Metadata Repository is being used only to support middle tiers that are part of a database-based Oracle Application Server Farm, the J2EE and Web Cache middle tiers that use the OracleAS Metadata Repository can continue operating during the OracleAS Metadata Repository upgrade.