| Oracle® Database Upgrade Guide 11g Release 1 (11.1) Part Number B28300-01 |
|
|
View PDF |
| Oracle® Database Upgrade Guide 11g Release 1 (11.1) Part Number B28300-01 |
|
|
View PDF |
This chapter describes the steps to complete before upgrading a database to Oracle Database 11g Release 1 (11.1). This chapter covers in detail Steps 1 through 3 of the upgrade process that were outlined in "Overview of the Database Upgrade Process".
This chapter covers the following topics:
See Also:
Oracle Database Net Services Administrator's Guide for information about upgrade considerations for Oracle Net ServicesNote:
Some aspects of upgrading are operating system-specific. See your operating system-specific Oracle documentation for additional information about preparing to upgrade.Complete the following tasks to prepare to upgrade:
Before you plan the upgrade process, become familiar with the features of Oracle Database 11g Release 1 (11.1). Oracle Database New Features Guide is a good starting point for learning the differences between Oracle Database releases. Also, check specific guides in the Oracle Database 11g Release 1 (11.1) documentation set to find information about new features for a certain component; for example, see Oracle Real Application Clusters Administration and Deployment Guide for changes in Oracle Real Application Clusters.
Note:
Oracle Database training classes are an excellent way to learn how to take full advantage of the features and functions available with Oracle Database. Connect to the following web page for more information:The path that you must take to upgrade to Oracle Database 11g Release 1 (11.1) depends on the release number of your current database. It might not be possible to upgrade directly from your current version of Oracle Database to the latest version. Depending on your current release, you might be required to upgrade through one or more intermediate releases to upgrade to Oracle Database 11g Release 1 (11.1).
For example, if the current database is running release 8.1.6, then follow these steps:
Upgrade release 8.1.6 to release 8.1.7.4 using the instructions in Oracle8i Migration Release 3 (8.1.7).
Upgrade release 8.1.7.4 to 9.2.0.8 using the instructions in Oracle9i Database Migration Release 2 (9.2).
Upgrade release 9.2.0.8 to Oracle Database 11g Release 1 (11.1) using the instructions in this guide.
Table 2-1 contains the required upgrade path for each release of Oracle Database. Use the upgrade path and the specified documentation to upgrade your database.
Table 2-1 Upgrade Paths
| Current Release | Upgrade Path |
|---|---|
|
7.3.3 and lower 7.3.4 8.0.3 8.0.4 8.0.5 8.0.6 8.1.5 8.1.6 8.1.7.4 9.0.1.4 |
Direct upgrade is not supported. Upgrade to an intermediate Oracle Database release before you can upgrade to Oracle Database 11g Release 1 (11.1), as follows:
When upgrading to an intermediate Oracle Database release, follow the instructions in the intermediate release's documentation. Then, upgrade the intermediate release database to Oracle Database 11g Release 1 (11.1) using the instructions in Chapter 3, "Upgrading to the New Release". |
|
9.2.0.4 10.1.0.2 10.2.0.1 |
Direct upgrade to Oracle Database 11g Release 1 (11.1) is supported from 9.2.0.4 or higher, 10.1.0.2 or higher, and 10.2.0.1 or higher. Note that Oracle Clusterware release 10.2.0.x must be at release 10.2.0.3 (or higher), before you attempt to upgrade it to Oracle Clusterware 11g release 1 (11.1). See "Upgrading an Oracle Real Application Clusters (Oracle RAC) Database". For release 9.2.0.3 you must first upgrade to an intermediate Oracle Database release, as follows: 9.2.0.3 (or lower) -> 9.2.0.8 -> 11.1 To upgrade to Oracle Database 11g Release 1 (11.1), follow the instructions in Chapter 3, "Upgrading to the New Release". |
Note:
See Supported Releases for Downgrading in Chapter 7 for information related to downgrading your database.The following sections describe the upgrade methods you can use to upgrade your database to Oracle Database 11g Release 1 (11.1):
Database Upgrade Assistant (DBUA) interactively steps you through the upgrade process and configures the database for Oracle Database 11g Release 1 (11.1). DBUA automates the upgrade process by performing all of the tasks normally performed manually. DBUA makes appropriate recommendations for configuration options such as tablespaces and redo logs. You can then act on these recommendations.
DBUA provides support for Oracle Real Application Clusters (Oracle RAC) and Automatic Storage Management (ASM).
In an Oracle RAC environment, DBUA upgrades all the database and configuration files on all nodes in the cluster.
A manual upgrade consists of running SQL scripts and utilities from a command line to upgrade a database to Oracle Database 11g Release 1 (11.1).
While a manual upgrade gives you finer control over the upgrade process, it is more susceptible to error if any of the upgrade or pre-upgrade steps are either not followed or are performed out of order.
When manually upgrading a database, perform the following pre-upgrade steps:
Analyze the database using the Pre-Upgrade Information Tool. The Upgrade Information Tool is a SQL script that ships with Oracle Database 11g Release 1 (11.1), and must be run in the environment of the database being upgraded.
The Upgrade Information Tool displays warnings about possible upgrade issues with the database. It also displays information about required initialization parameters for Oracle Database 11g Release 1 (11.1).
Prepare the new Oracle home.
Perform a backup of the database.
Depending on the release of the database being upgraded, you might be required to perform additional pre-upgrade steps (adjust the parameter file for the upgrade, remove obsolete initialization parameters and adjust initialization parameters that might cause upgrade problems).
Review the upgrade spool log file and use the Post-Upgrade Status Tool. The Post-Upgrade Status Tool is a SQL script that ships with Oracle Database 11g Release 1 (11.1), and should be run in the environment of the new release.
See Also:
"Upgrade a Database Manually"Unlike DBUA or a manual upgrade, the Export/Import utilities physically copy data from your current database to a new database. You can use either the Oracle Data Pump Export and Import utilities, available as of Oracle Database 10g Release 1 (10.1), or the original Export and Import utilities to perform a full or partial export from your database, followed by a full or partial import into a new Oracle Database 11g Release 1 (11.1) database. Export/Import can copy a subset of the data in a database, leaving the original database unchanged.
When upgrading from Oracle Database 10g Release 1 (10.1) or higher, Data Pump Export and Import are recommended for higher performance.
The Export utility of the current database copies specified parts of the database into an export dump file. Then, the Import utility of Oracle Database 11g Release 1 (11.1) loads the exported data into a new database. However, the new Oracle Database 11g Release 1 (11.1) database must already exist before it can be loaded from the export dump file.
When importing data from an earlier release, the Oracle Database 11g Release 1 (11.1) Import utility makes appropriate changes to data definitions as it reads export dump files from earlier releases.
The following sections highlight aspects of Export/Import that might help you to decide whether to use Export/Import to upgrade your database.
The Export/Import upgrade method does not change the current database, which enables the database to remain available throughout the upgrade process. However, if a consistent snapshot of the database is required (for data integrity or other purposes), then the database must run in restricted mode or must otherwise be protected from changes during the export procedure. Because the current database can remain available, you can, for example, keep an existing production database running while the new Oracle Database 11g Release 1 (11.1) database is being built at the same time by Export/Import. During the upgrade, to maintain complete database consistency, changes to the data in the database cannot be permitted without the same changes to the data in the new Oracle Database 11g Release 1 (11.1) database.
Most importantly, the Export/Import operation results in a completely new database. Although the current database ultimately contains a copy of the specified data, the upgraded database might perform differently from the original database. For example, although Export/Import creates an identical copy of the database, other factors, such as disk placement of data and unset tuning parameters, might cause unexpected performance problems.
Upgrading using Export/Import offers the following benefits:
Defragments the data - you can compress the imported data to improve performance.
Restructures the database - you can create new tablespaces or modify existing tables, tablespaces, or partitions to be populated by imported data.
Facilitates side-by-side testing of the old and new versions of Oracle Database because an entirely new database is created.
Enables the copying of specified database objects or users - you can import only the objects, users, and other items that you wish. This is useful for establishing a test environment for the new software on only a subset of the production data. Data Pump Export / Import provides very flexible data subsetting capabilities.
Serves as a backup archive - you can use a full database export as an archive of the current database.
Allows the new database to be established on an Operating System or hardware platform that is different from that supporting the database being upgraded.Network-based Data Pump Import allows the new Oracle database to be directly loaded across the network from the old database being upgraded. Thus, no intervening dump files are required.
Upgrading an entire database by using Export/Import can take a long time, especially compared to using DBUA or performing a manual upgrade. Therefore, you might be required to schedule the upgrade during non-peak hours or make provisions for propagating to the new database any changes that are made to the current database during the upgrade.
You must choose an Oracle home directory for Oracle Database 11g Release 1 (11.1) that is separate from the Oracle home directory of your current release. You cannot install the new software into the same Oracle home directory as your current release, unless you are installing an Oracle 11g patchset release. For a patchset release, you can use the same Oracle Database 11g Release 1 (11.1) Oracle home.
Using separate installation directories enables you to keep your existing software installed along with the new software. This method enables you to test the upgrade process on a test database before replacing your production environment entirely.
You need a series of carefully designed tests to validate all stages of the upgrade process. Executed rigorously and completed successfully, these tests ensure that the process of upgrading the production database is well understood, predictable, and successful. Perform as much testing as possible before upgrading the production database. Do not underestimate the importance of a test program.
Whether you use Real Application Testing features like Database Replay or SQL Performance Analyzer or perform testing manually, your test plan must include the following types of tests:
Upgrade testing entails planning and testing the upgrade path from your current software to Oracle Database 11g Release 1 (11.1), whether you use DBUA, perform a manual upgrade, or use Export/Import or other data-copying methods. Regardless of the upgrade method you choose, you must establish, test, and validate an upgrade plan.
Minimal testing entails moving all or part of an application from the current database to the new database and running the application without enabling any new database features. Minimal testing might not reveal problems that would appear in an actual production environment. But minimal testing immediately reveals any application startup or invocation problems.
Functional testing is a set of tests in which new and existing features and functions of the system are tested after the upgrade. Functional testing includes all database, networking, and application components. The objective of functional testing is to verify that each component of the system functions as it did before upgrading and to verify that new functions are working properly.
Integration testing examines the interactions among components of the system. Consider the following factors when you plan your integration testing:
Pro*C/C++ applications running against a new Oracle Database 11g Release 1 (11.1) instance should be tested to ensure that there are no problems with the new software.
Graphical user interfaces should be tested with other components.
Subtle changes in Oracle Database 11g Release 1 (11.1), such as data types, data in the data dictionary (additional rows in the data dictionary, object type changes, and so on) can have an effect all the way up to the front-end application, even if the application is not directly connected to a new Oracle Database 11g Release 1 (11.1) instance.
If the connection between two components involves Net8 or Oracle Net Services, then those connections should also be tested and stress tested.
Performance testing of the new database compares the performance of various SQL statements in the new database with the performance of those same statements in the current database. Before upgrading, you should understand the performance profile of the application under the current database. Specifically, you should understand the calls the application makes to the database server.
This section describes the following types of performance testing:
Note:
Automatic Workload Repository is not supported for Oracle Database9i Release 2 (9.2). If you are upgrading from Oracle Database9i Release 2 (9.2), then use the SQL trace facility and profile your application with TKPROF.See Also:
Oracle Database Performance Tuning Guide for more information on Automatic Workload RepositoryBeginning with Oracle Database 11g Release 1 (11.1), you can use the new Database Replay feature to perform real-world testing of a database upgrade on your site's production workload before actually upgrading the production database. This feature captures the actual database workload on the production system and replays it on the test system. It also provides analysis and reporting to highlight potential problems—for example, errors encountered, divergence in performance, and so forth. In addition, all the regular performance monitoring and reporting tools such as ADDM, AWR, and ASH reports (in addition to the replay report) are at your disposal to remedy any problems.
Note:
You can change the stored procedure logic in the database but the stored PL/SQL procedures that implement the application logic must maintain the same interfaces as prior to the upgrade. If an upgrade affects the stored procedures of an application, then the workload might not be replayable. By using the Database Replay tool in this way, you have good diagnostics to see if the new application logic in the server is performing as expected after the upgrade.See Also:
Oracle Database Performance Tuning Guide for complete information about how to capture and replay workloadsBeginning with Oracle Database 11g Release 1 (11.1), you can use the SQL Performance Analyzer to forecast the impact of system changes on a SQL workload. SQL Performance Analyzer allows you to evaluate the impact of a change such as database upgrade by identifying the SQL statements impacted by the upgrade and measuring their performance divergence. This enables you to assess the overall effect of the upgrade on SQL performance and makes it possible to avoid any negative outcome before users can be impacted.
See Also:
Oracle Database Performance Tuning Guide for complete information and examples using the SQL Performance Analyzer to perform what-if analysis on potential database changesSQL plan management prevents performance regressions resulting from sudden changes to the execution plan of a SQL statement by providing components for capturing, selecting, and evolving SQL plan information. SQL plan management is a preventative mechanism that records and evaluates the execution plans of SQL statements over time, and builds SQL plan baselines composed of a set of existing plans known to be efficient. The SQL plan baselines are then used to preserve performance of corresponding SQL statements, regardless of changes occurring in the system.
Volume and load stress testing tests the entire upgraded database under high volume and loads. Volume describes the amount of data being manipulated. Load describes the level of concurrent demand on the system. The objective of volume and load testing is to emulate how a production system might behave under various volumes and loads.
Volume and load stress testing is crucial, but is commonly overlooked. Oracle has found that customers often do not conduct any kind of volume or load stress testing. Instead, customers often rely on benchmarks that do not characterize business applications. Benchmarks of the application should be conducted to uncover problems relating to functions, performance, and integration, but they cannot replace volume and load stress testing.
Load testing involves running an application load against the new version of the database to ensure that the application does not encounter problems such as new errors or performance issues under load conditions likely to be encountered in production. Many times, problems manifest under certain load conditions and are normally not seen in functional testing. Database Replay feature is ideal for such load testing as it allows you to capture system workload from a production environment and replay it in identical fashion on the test system.
The ultimate success of your upgrade depends heavily on the design and execution of an appropriate backup strategy. To develop a backup strategy, consider the following questions:
How long can the production database remain inoperable before business consequences become intolerable?
What backup strategy should be used to meet your availability requirements?
Are backups archived in a safe, offsite location?
How quickly can backups be restored (including backups in offsite storage)?
Have recovery procedures been tested successfully?
Your backup strategy should answer all of these questions and include procedures for successfully backing up and recovering your database.
See Also:
Oracle Database Backup and Recovery User's Guide for information on database backupsCreate a test environment that does not interfere with the current production database. Your test environment depends on the upgrade method you have chosen:
If you plan to use DBUA or perform a manual upgrade, then create a test version (typically a subset) of the current production database to test the upgrade.
If you plan to use Export/Import, then export and import small test pieces of the current production database.
Practice upgrading the database using the test environment. The best upgrade test, if possible, is performed on an exact copy of the database to be upgraded, rather than on a downsized copy or test data.
Caution:
Do not upgrade the actual production database until after you successfully upgrade a test subset of this database and test it with applications, as described in the next step.Make sure you upgrade any OCI and precompiler applications that you plan to use with your new Oracle database. Then, you can test these applications on a sample database before upgrading your current production database. See "Upgrading Precompiler and OCI Applications" for more information.
Perform the planned tests on the current database and on the test database that you upgraded to Oracle Database 11g Release 1 (11.1). Compare the results, noting anomalies. Repeat the test upgrade as many times as necessary.
Test the newly upgraded test database with existing applications to verify that they operate properly with a new Oracle database. You also might test enhanced functions by adding available Oracle Database features. However, first make sure that the applications operate in the same manner as they did in the current database.
See Also:
Chapter 6, "Upgrading Your Applications" for more information on using applications with Oracle Database
