Oracle provides scripts that collect optimizer statistics for dictionary objects in Oracle Database. By running these scripts before performing the actual database upgrade, you can decrease the amount of downtime incurred during the database upgrade.
This process should be tested on a test database just like any other aspect of the upgrade. Also, some schemas referenced in these scripts might not exist if some database components have not been installed.
This appendix contains the following topics:
If you are using Oracle9i Release 2 (9.2), then you should use the DBMS_STATS.GATHER_SCHEMA_STATS procedure to gather statistics. The following sample script uses this procedure to collect statistics for system component schemas.
To run this script, connect to the database AS SYSDBA using SQL*Plus.
spool gdict
grant analyze any to sys;
exec dbms_stats.gather_schema_stats('WMSYS',options=>'GATHER', -
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -
method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('MDSYS',options=>'GATHER', -
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -
method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('CTXSYS',options=>'GATHER', -
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -
method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('XDB',options=>'GATHER', -
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -
method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('WKSYS',options=>'GATHER', -
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -
method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('LBACSYS',options=>'GATHER', -
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -
method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('ORDSYS',options=>'GATHER', -
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -
method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('ORDPLUGINS',options=>'GATHER', -
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -
method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('SI_INFORMTN_SCHEMA',-
options=>'GATHER', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -
method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('OUTLN',options=>'GATHER', -
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -
method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('DBSNMP',options=>'GATHER', -
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -
method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('SYSTEM',options=>'GATHER', -
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -
method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('SYS',options=>'GATHER', -
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -
method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
spool off
|
Note: The statistics collection might give errors if a particular component schema does not exist in the database. This can happen if a component is not installed or if it is invalid. |
This script creates the table, dictstattab, and exports the statistics for the RDBMS component schemas into it. The export returns an error if a particular component schema does not exist in the database. This can happen if a component is not installed or if it is invalid.
This script is useful when you want to import the statistics back into the database. For example, the following PL/SQL subprograms import the statistics for the SYS schema after deleting the existing statistics:
EXEC DBMS_STATS.DELETE_SCHEMA_STATS('SYS'); EXEC DBMS_STATS.IMPORT_SCHEMA_STATS('SYS','dictstattab');
To run the following script, connect to the database AS SYSDBA using SQL*Plus.
spool sdict
grant analyze any to sys;
exec dbms_stats.create_stat_table('SYS','dictstattab');
exec dbms_stats.export_schema_stats('WMSYS','dictstattab',statown => 'SYS');
exec dbms_stats.export_schema_stats('MDSYS','dictstattab',statown => 'SYS');
exec dbms_stats.export_schema_stats('CTXSYS','dictstattab',statown => 'SYS');
exec dbms_stats.export_schema_stats('XDB','dictstattab',statown => 'SYS');
exec dbms_stats.export_schema_stats('WKSYS','dictstattab',statown => 'SYS');
exec dbms_stats.export_schema_stats('LBACSYS','dictstattab',statown => 'SYS');
exec dbms_stats.export_schema_stats('ORDSYS','dictstattab',statown => 'SYS');
exec dbms_stats.export_schema_stats('ORDPLUGINS','dictstattab',statown => 'SYS');
exec dbms_stats.export_schema_stats('SI_INFORMTN_SCHEMA','dictstattab',statown => 'SYS');
exec dbms_stats.export_schema_stats('OUTLN','dictstattab',statown => 'SYS');
exec dbms_stats.export_schema_stats('DBSNMP','dictstattab',statown => 'SYS');
exec dbms_stats.export_schema_stats('SYSTEM','dictstattab',statown => 'SYS');
exec dbms_stats.export_schema_stats('SYS','dictstattab',statown => 'SYS');
spool off
Upgrading to a new release of Oracle Database is a basic part of database maintenance and administration. Oracle provides the Database Upgrade Assistant and specialized scripts and tools to assist with the upgrade process and to automate many steps. This chapter discusses important information and requirements and guides you through the process of upgrading a database to Oracle Database 11g Release 2 (11.2).
This chapter contains the following topics:
System Considerations and Requirements for Upgrading Oracle Database
Upgrading with Database Upgrade Assistant on Linux, UNIX, and Windows
Optionally Performing an In-Place Upgrade (Into the Same Oracle Home)
|
Caution: If you retain the old Oracle software, then never start the upgraded database with the old Oracle software. Only start the database with the executables in the new Oracle Database installation. |
When you upgrade to a new release of Oracle Database, typically there are new or changed system requirements. The following topics describe the various checks and considerations to perform before starting an upgrade of Oracle Database:
Relocating Existing Data Files to the New Oracle Database Environment
About Upgrading PL/SQL Packages That Are Not Installed by Default
About Upgrading Oracle ASM Installed with Oracle Grid Infrastructure
Considerations for Upgrading Oracle Clusterware and Oracle ASM Instances
About Upgrading Databases That Use Oracle Streams Downstream Capture
|
Important: To upgrade to this release, you must install the Oracle Grid Infrastructure and Oracle Database software into a new Oracle home instead of applying a patch set to the existing Oracle home. This is referred to as an out-of-place upgrade and is different from patch set releases for earlier releases of Oracle Database, where the patch set was always installed in place. |
|
Note: Oracle Grid Infrastructure does not support in-place upgrade. Only out-of-place upgrade into a new grid intrastructure home is supported. |
|
See Also:
|
Before you remove the old Oracle environment, you must relocate any data files in that environment to the new Oracle Database environment.
To relocate data files to the new Oracle Database environment
Use Database Upgrade Assistant (DBUA) and select the Move Database Files option during the upgrade.
|
See Also: "Upgrading with Database Upgrade Assistant on Linux, UNIX, and Windows" for more information Oracle Database Administrator's Guide, if you perform a manual upgrade, for information about relocating data files |
Packages that were previously installed on the database for which you are preparing to upgrade to the current release may not be upgraded automatically. You may need to separately check if the package is available in the current release and reinstall that package to ensure you have the latest version.
Oracle ASM is upgraded as part of the Oracle Grid Infrastructure upgrade. You cannot upgrade Oracle ASM before you upgrade Oracle Grid Infrastucture.
Starting with Oracle Database 11g Release 2 (11.2.0.1), Oracle Clusterware and Oracle Real Application Clusters (Oracle RAC) must be installed into a separate, new home from the existing installation. This reduces the downtime required to upgrade a node in the cluster and facilitates the provisioning of clusters within an enterprise. The reduction in planned outage time required for cluster upgrades helps in meeting availability service levels and also makes it easier to provide a standard installation across the enterprise.
The following considerations pertain to upgrading Oracle Clusterware and Oracle ASM instances:
For releases earlier than Oracle Database 11g, either all Oracle software installations were owned by the Oracle user, typically oracle, or Oracle Database software was owned by the user oracle, and Oracle Clusterware software was owned by a separate user, typically crsuser.
Starting with Oracle Database 11g, the user account that is designated as owner of the release 10g Cluster Ready Services (CRS) software must perform the Oracle Clusterware 11g upgrade. The user account that is performing this upgrade must also be the user that owns the ASM home of the earlier release (that is, previous to release 11.2). If the pre-11.2 ASM home has a different owner, then the owner account must be changed before performing the upgrade.
As of Oracle Database 11g release 2 (11.2), the Oracle Clusterware software must be upgraded to a new home location in the Oracle Grid Infrastructure home. Additionally, Oracle ASM and Oracle Clusterware (and Oracle Restart for single-instance databases) must run in the same Oracle Grid Infrastructure home. When upgrading Oracle Clusterware to release 11.2, OUI automatically calls Oracle ASM Cluster Assistant (ASMCA) to perform the upgrade into the Oracle Grid Infrastructure home.
To upgrade to Oracle Database release 11.2.0.3, you must install the Oracle Grid Infrastructure and Oracle Database software into a new Oracle home instead of into the existing Oracle home.
For a single-instance configuration, Oracle ASM and Oracle Restart run from the Oracle Grid Infrastructure home, and the cluster synchronization services daemon (CSS) runs from this same home. Thus, Oracle ASM and CSS are upgraded to Oracle Database 11g Release 2 (11.2) at the same time.
For Oracle Database release 11.1 and earlier releases, if your configuration does not include Oracle ASM, then you must shut down the CSS daemon and delete the CSS service from the system by running the localconfig command with the delete option. For example:
ORACLE_HOME/bin/localconfig delete
You must ensure that the database compatibility attribute for Oracle ASM disk groups matches the compatibility parameter that is set in init.ora.
If you do not know whether or not your configuration includes Oracle ASM, then issue the following SQL statement on the database instance:
select count(*) from v$asm_client where status = 'CONNECTED';
If this statement returns one or more rows, then the database is actively using an Oracle ASM disk group.
You can use Database Upgrade Assistant (DBUA) to upgrade an existing Oracle RAC database to the current release of Oracle Database. DBUA guides you through the upgrade process and configures your database for the new release. DBUA automates the upgrade process and makes appropriate recommendations for configuration options such as tablespaces and online redo log files.
If you are manually upgrading an Oracle RAC database, then most of the actions are to be performed on only one node of the system. Actions that must be performed on more than one node are indicated in the relevant steps.
Oracle Clusterware 11g release 2 (11.2) requires time synchronization across all nodes within a cluster when Oracle RAC is deployed.
You can use one of the following options for time synchronizaion:
Your operating system-configured network time protocol (NTP)
Oracle Cluster Time Synchronization Service
|
See Also: Oracle Grid Infrastructure Installation Guide for your operating system for information on configuring NTP and Oracle Cluster Time Synchronization Service |
If you are upgrading Oracle RAC and your databases use Oracle ASM for data file storage, then you need to consider additional restrictions and requirements.
A subset of nodes cannot be selected when upgrading from an earlier release to 11.2.0.3.
Before the new database release 11.2.0.3 software can be installed on the system, the root script for upgrading Oracle Grid Infrastructure invokes ASMCA to upgrade Oracle ASM to release 11.2.0.3.
Where Oracle Clusterware software has been upgraded to release 11.2.0.1, but where Oracle ASM is running an earlier release, then DBUA displays an error indicating that the Oracle ASM cluster has not been upgraded. In this case, the root script invokes Oracle ASM Cluster Assistant (ASMCA) to upgrade Oracle ASM to release 11.2.0.1 before installing any Oracle Database release 11.2.0.3 software on the system.
When upgrading from release 11.2.0.1 to 11.2.0.3, DBUA needs the Oracle Clusterware stack to be up. If DBUA finds that the Oracle Clusterware stack is down on the local node, then it displays an error message indicating the commands that need to be run to start up the stack on the local node.
DBUA does not permit a single-instance database (SIDB) release 11.2.0.3 to be installed on 11.2.0.1 clusters.
If DBUA detects Oracle Restart, then it presents a page asking you whether to register the database with Oracle Restart. If you choose to register with Oracle Restart, then DBUA displays a message prompting you to first upgrade Oracle Grid infrastructure to release 11.2.0.3.
|
Note: Oracle Restart was previously referred to as Oracle Single-Instance High Availability (SIHA). |
Starting with Oracle Database 11g Release 1 (11.1), you should use the SYSASM privilege to separate database management and storage management responsibilities. Also, you have the option to create separate operating system credentials for Oracle ASM and each database. This separation allows for an even greater division of database management and storage management responsibilities. For instance, if there are n databases using Oracle ASM on a given node, then you can configure n + 1 sets of operating system credentials groups whose members have SYS privileges: one OSDBA group for each database with SYSDBA privileges, and one OSASM group for the Oracle ASM instance with SYSASM privileges.
Before upgrading an Oracle ASM instance to the new Oracle Database 11g release, you must add a user and password combination to the password file that is local to a node's Oracle ASM instance using the SQL*Plus CREATE USER statement:
CREATE USER user_name IDENTIFIED BY password;
It is only necessary to add a user and password combination to the password file when upgrading the Oracle ASM instance. It is not necessary when upgrading a database to the new Oracle Database 11g release without upgrading Oracle ASM.
If the default Oracle Database 11g security settings are in place, then passwords must be at least eight characters, and passwords such as welcome and oracle are not allowed.
|
See Also:
|
Oracle Database 11g Release 1 (11.1) and later releases can read file headers created in previous releases, so you are not required to do anything to them during the upgrade. The only exception to this is if you want to transport tablespaces created previously than Oracle Database 11g Release 1 (11.1) to another platform. In this case, the file headers must be made read/write at some point before the transport. However, there are no special actions required on them during the upgrade.
The file headers of offline data files are updated later when they are brought online, and the file headers of read-only tablespaces are updated if and when they are made read/write sometime after the upgrade. You are never required to make read-only tablespaces read/write in any other circumstance.
|
See Also: Oracle Database Administrator's Guide for more information about read-only tablespaces and transporting tablespaces between databases |
To upgrade the Oracle Database software when standby databases are present in an Oracle Data Guard configuration, see Oracle Data Guard Concepts and Administration. To upgrade or downgrade Oracle Database and Oracle Enterprise Manager software in an Oracle Data Guard broker configuration, see Oracle Data Guard Broker.
During a rolling upgrade, you can run different releases of Oracle Database software on the primary and standby databases while you upgrade them, one at a time, incurring minimal downtime on the primary database by using either of the following methods:
SQL Apply and logical standby databases
Starting with Oracle Database 10g Release 1 (10.1.0.3), you can use Oracle Data Guard SQL Apply on a logical standby database to perform a rolling upgrade to the new Oracle Database 11g release. For example, you can upgrade the Oracle Database software from patch set release 10.1.0.n to the next database 10.1.0.(n+1) patch set release, or upgrade Oracle Database 10g Release 1 (10.1) to Oracle Database 11g Release 2 (11.2).
Use of physical standby database for rolling upgrades
A physical standby database can now take advantage of the rolling upgrade feature provided by a logical standby. Through the use of the new KEEP IDENTITY clause option to the SQL ALTER DATABASE RECOVER TO LOGICAL STANDBY statement, a physical standby database can be temporarily converted into a logical standby database for the rolling upgrade, and then reverted back to the original configuration of a primary database and a physical standby database when the upgrade is done.
|
See Also:
|
When you upgrade to a new release of Oracle software, the operating system requirements may have changed. If required, upgrade the operating system before upgrading Oracle Database.
|
See Also:
|
When using DBUA or when performing a manual upgrade, you cannot migrate data in a database on one operating system to a database on another operating system. For example, you cannot migrate data in an Oracle9i database on Solaris to an Oracle 11g database on Windows using DBUA.
To migrate Oracle Database software to a different operating system
Upgrade to the new Oracle Database 11g release on your current operating system platform following the instructions in this guide.
Test the upgraded database on your current operating system platform.
Use Oracle Data Guard and physical standby databases to migrate between operating systems.
|
See Also: Note 413484.1 on My Oracle Support (formerly OracleMetaLink) athttps://support.oracle.com/ for more information on Oracle Data Guard support for heterogeneous primary and standby systems in the same Oracle Data Guard configuration |
If cross-platform physical standby database is not available for the platform combination to be migrated, then you can use the Oracle Database 11g cross-platform transportable tablespace feature or the Oracle Data Pump Export and Import utilities to migrate the upgraded database to the different operating system.
|
Note: Transportable tablespaces do not support migratingSYSTEM or SYSAUX tablespaces. All non-segment user data, such as roles, triggers, views, and procedures, must be moved to the new operating system with scripts or export/import. |
If the two operating systems are in the same endianness group, then you can use the Oracle Database 11g cross-platform transportable database feature to migrate the entire database.
You can also use Oracle Streams to migrate data between operating systems. Oracle Streams has data type limitations and restrictions, such as for advanced queues and object types, and it requires additional administrative overhead.
|
See Also:
|
In an Oracle Streams replication environment, downstream captures means that a capture process runs on a database other than the source database. When you upgrad e the databases in such an environment, upgrade the database with the downstream capture process before you upgrade the source database. Upgrading the databases in this order ensures that the downstream capture database can continue to function after the source database is upgraded.
When upgrading from Oracle Database release 10.2, if you have enabled Oracle Database Vault in your current Oracle home, then you must disable Oracle Database Vault in the target Oracle home where the new release 11.2.0.3 software is installed. You must do this before upgrading the database. Enable Oracle Database Vault again once the upgrade is complete.
|
See Also: Oracle Database Vault Administrator's Guide for instructions about disabling Oracle Database Vault |
You must install the software for the new Oracle Database release before you can perform the upgrade of Oracle Database. The installation procedure for the new Oracle Database 11g Release 2 (11.2) installs the Oracle software into a new Oracle home. This is referred to as an out-of-place upgrade and is different from patch set releases for earlier releases of Oracle Database, where the patch set was always installed in place. Oracle strongly recommends that you follow the steps in this procedure to ensure minimal downtime for the upgrade process and integrity of the new binaries and software libraries.
|
Important: It is not possible to upgrade a database using DBUA when the source and target Oracle homes are owned by different users. Attempting to do so returns error PRKH-1014. Either ensure that the source and target databases have the same owner, or perform the manual steps described in "Upgrading Oracle Database Manually". |
To install the new Oracle Database software for this release
If you are upgrading an Oracle RAC database, then you must perform the following steps in the order shown:
Upgrade Oracle Clusterware first as described in "Considerations for Upgrading Oracle Clusterware and Oracle ASM Instances".
|
Note: When upgrading a non-Oracle RAC database, you must run Oracle Net Configuration Assistant (NETCA) before running DBUA. See "Configuring the Listener When Upgrading from Oracle9i". When upgrading an Oracle RAC database, as part of the Oracle Clusterware upgrade, OUI automatically runs NETCA to upgrade the network listener. Therefore, you do not need to manually run NETCA. |
Mount the Oracle Grid Infrastructure installation media.
Perform operating system prerequisite checks on each of the nodes that you intend to upgrade, to ensure that they meet the system prerequisites for Oracle Grid Infrastructure (Oracle Clusterware and Oracle ASM).
If necessary, perform patch upgrades of the earlier release of Oracle Clusterware or Oracle Cluster Ready Services software to the most recent patch version.
Ensure that you are logged in as the user that you want to own the Oracle Grid Infrastructure installation, and run the Oracle Grid Infrastructure installation. Provide information as prompted by the installer.
When prompted, open a separate terminal session, log in as root, and run root.sh.
After upgrading Oracle Clusterware, follow the instructions in your Oracle operating system-specific documentation to prepare for installation of Oracle Database software and start the Oracle Universal Installer.
Oracle recommends that you run the Pre-Upgrade Information Tool before you upgrade using DBUA, so that you can preview the types of items DBUA checks. (See "Using the Pre-Upgrade Information Tool".) You can then run DBUA independently after the installation is complete.
If you use Oracle Label Security, Oracle Database Vault, or both, then select Enterprise Edition on the Select Database Edition page, click Select Options, and enable one or both components from the components list. See Oracle Label Security Administrator's Guide and Oracle Database Vault Administrator's Guide for more information.
When installation of Oracle Database software has completed successfully, click Exit to close Oracle Universal Installer.
The software for Oracle Database 11g Release 2 (11.2) contains a full release that includes all the latest patches and updates for Oracle Database. It is not necessary to check for patch set updates before proceeding with the upgrade process for this release. However, Oracle recommends that you periodically check for patches and patch set updates as a part of database administration.
|
See Also:
|
After you have installed the software for Oracle Database 11g Release 2 (11.2) and any required patches, Oracle recommends that you analyze your database before upgrading it to the new release. This is done by running the Pre-Upgrade Information Tool from the environment of the database you are to upgrade. The Pre-Upgrade Information Tool is a SQL script included with Oracle Database 11g Release 2 (11.2) software. This is a required step if you are upgrading manually; otherwise, the catupgrd.sql script terminates with errors. Running the Pre-Upgrade Information Tool is also recommended if you are upgrading with DBUA, so that you can preview the items that DBUA checks.
These topics contain additional information about the Pre-Upgrade Information Tool:
|
See Also: Note 884522.1 "How to Download and Run Oracle's Database Pre-Upgrade Utility" available from My Oracle Support athttps://support.oracle.com, which contains the latest version of the Pre-Upgrade Information Tool. Oracle strongly recommends that you use the latest version of this script available in Note 884522.1. |
To run the Pre-Upgrade Information Tool
Log in to the system as the owner of the environment of the database being upgraded.
|
Important: The Pre-Upgrade Information Tool must be copied to and must be run from the environment of the database being upgraded. |
Start SQL*Plus.
Connect to the database instance as a user with SYSDBA privileges.
Set the system to spool results to a log file for later analysis:
SQL> SPOOL upgrade_info.log
Run the Pre-Upgrade Information Tool:
SQL> @$11g_ORACLE_HOME/rdbms/admin/utlu112i.sql
Turn off the spooling of script results to the log file:
SQL> SPOOL OFF
Check the output of the Pre-Upgrade Information Tool in upgrade_info.log.
|
Note: Oracle interMedia became Oracle Multimedia in Oracle Database 11g Release 1 (11.1). |
About the Output of the Pre-Upgrade Information Tool
The Pre-Upgrade Information Tool displays warnings about possible upgrade issues with the database. The output in Example 3-1 shows the report that is generated from running the Pre-Upgrade Information Tool after installing the software for Oracle Database 11g Release 2 (11.2). In addition to the warnings that the tool displays, you must address any errors described in the output of the Pre-Upgrade Information Tool before performing the upgrade.
For invalid objects or invalid components, Oracle recommends running the the utlrp.sql before starting the upgrade as a means to minimize the number of invalid objects and components marked with WARNING.
The following topics contain sample output of the Pre-Upgrade Information Tool and provide descriptions of each section of the output.
|
Important: If you see a warning about the presence of the release 10g |
Example 3-1 Pre-Upgrade Information Tool Sample Output
Oracle Database 11.2 Pre-Upgrade Information Tool 07-12-2011 12:51:34
Script Version: 11.2.0.3.0 Build: 001
.
**********************************************************************
Database:
**********************************************************************
--> name: O112
--> version: 11.2.0.1.0
--> compatible: 11.2.0.0.0
--> blocksize: 8192
--> platform: Linux x86 64-bit
--> timezone file: V11
.
**********************************************************************
Tablespaces: [make adjustments in the current environment]
**********************************************************************
--> SYSTEM tablespace is adequate for the upgrade.
.... minimum required size: 701 MB
--> SYSAUX tablespace is adequate for the upgrade.
.... minimum required size: 453 MB
--> UNDOTBS1 tablespace is adequate for the upgrade.
.... minimum required size: 400 MB
--> TEMP tablespace is adequate for the upgrade.
.... minimum required size: 60 MB
--> EXAMPLE tablespace is adequate for the upgrade.
.... minimum required size: 78 MB
.
**********************************************************************
Flashback: OFF
**********************************************************************
**********************************************************************
Update Parameters: [Update Oracle Database 11.2 init.ora or spfile]
Note: Pre-upgrade tool was run on a lower version 64-bit database.
**********************************************************************
--> If Target Oracle is 32-Bit, refer here for Update Parameters:
-- No update parameter changes are required.
.
--> If Target Oracle is 64-Bit, refer here for Update Parameters:
-- No update parameter changes are required.
.
**********************************************************************
Renamed Parameters: [Update Oracle Database 11.2 init.ora or spfile]
**********************************************************************
-- No renamed parameters found. No changes are required.
.
**********************************************************************
Obsolete/Deprecated Parameters: [Update Oracle Database 11.2 init.ora or spfile]
**********************************************************************
-- No obsolete parameters found. No changes are required
.
**********************************************************************
Components: [The following database components will be upgraded or installed]
**********************************************************************
--> Oracle Catalog Views [upgrade] VALID
--> Oracle Packages and Types [upgrade] VALID
--> JServer JAVA Virtual Machine [upgrade] VALID
--> Oracle XDK for Java [upgrade] VALID
--> Oracle Workspace Manager [upgrade] VALID
--> OLAP Analytic Workspace [upgrade] VALID
--> OLAP Catalog [upgrade] VALID
--> Oracle Label Security [upgrade] VALID
--> Oracle Database Vault [upgrade] VALID
... To successfully upgrade Oracle Database Vault, choose
... 'Select Options' in Oracle installer and then select
... Oracle Label Security.
--> EM Repository [upgrade] VALID
--> Oracle Text [upgrade] VALID
--> Oracle XML Database [upgrade] VALID
--> Oracle Java Packages [upgrade] VALID
--> Oracle interMedia [upgrade] VALID
--> Spatial [upgrade] VALID
--> Expression Filter [upgrade] VALID
--> Rule Manager [upgrade] VALID
--> Oracle Application Express [upgrade] VALID
... APEX will only be upgraded if the version of APEX in
... the target Oracle home is higher than the current one.
--> Oracle OLAP API [upgrade] VALID
.
**********************************************************************
Miscellaneous Warnings
**********************************************************************
WARNING: --> Database is using a timezone file older than version 14.
.... After the release migration, it is recommended that DBMS_DST package
.... be used to upgrade the 11.2.0.1.0 database timezone version
.... to the latest version which comes with the new release.
WARNING: --> Database contains schemas with objects dependent on DBMS_LDAP package.
.... Refer to the 11g Upgrade Guide for instructions to configure Network ACLs.
.... USER APEX_030200 has dependent objects.
.
**********************************************************************
Recommendations
**********************************************************************
Oracle recommends gathering dictionary statistics prior to
upgrading the database.
To gather dictionary statistics execute the following command
while connected as SYSDBA:
EXECUTE dbms_stats.gather_dictionary_stats;
**********************************************************************
Oracle recommends reviewing any defined events prior to upgrading.
To view existing non-default events execute the following commands
while connected AS SYSDBA:
Events:
SELECT (translate(value,chr(13)||chr(10),' ')) FROM sys.v$parameter2
WHERE UPPER(name) ='EVENT' AND isdefault='FALSE'
Trace Events:
SELECT (translate(value,chr(13)||chr(10),' ')) from sys.v$parameter2
WHERE UPPER(name) = '_TRACE_EVENTS' AND isdefault='FALSE'
Changes will need to be made in the init.ora or spfile.
**********************************************************************
Database Section Contents
The Database section displays global database information about the current database, such as the database name, release number (version), compatibility level, blocksize, OS platform, and time zone file. A warning is displayed if you must adjust the COMPATIBLE initialization parameter before the database is upgraded.
|
See Also: "Setting the COMPATIBLE Initialization Parameter" for information about setting theCOMPATIBLE initialization parameter |
Tablespaces Section Contents
The Tablespaces section displays a list of tablespaces in the current database. For each tablespace, the tablespace name and minimum required size is displayed. In addition, a message displays next to each tablespace confirming that the tablespace is adequate for the upgrade. If the minimum required size is not met, then you must make adjustments, which the tool recommends.
In a manual upgrade using SQL scripts and utilities, space must be added to tablespaces that do not have enough free space in the current database. These tablespace adjustments must be made before the database is upgraded. Some of these tasks are performed automatically by DBUA.
Rollback Segments Section Contents
The Rollback Segments section shows the status for rollback segments in the SYSTEM tablespace and displays a warning about any adjustments that need to be made before performing the upgrade. This section only appears if there are rollback segments.
Flashback Section Contents
The Flashback section shows whether flashback is ON or OFF, and displays warnings about pool size and cache size that must be increased. The status of undo_management is also displayed with any adjustment that must be made. You can execute an ALTER SYSTEM SET command to change the pool sizes and database cache size.
For example execute the following command to to set the java_pool_size to the recommended size as follows:
SQL> ALTER SYSTEM SET java_pool_size='nnnM' SCOPE=spfile;
The same can be done for changing the other settings.
Update Parameters Section Contents
The Update Parameters section displays a list of initialization parameters in the parameter file (init.ora or spfile) of the current database that must be adjusted before the database is upgraded. The adjustments must be made to the parameter file after it is copied to the new Oracle Database 11g release.
If you are using Oracle ASM disk groups, then you must ensure that the database compatibility attribute for the disk groups matches the compatibility parameter that is set in init.ora.
|
See Also: Appendix A, "Behavior Changes After Upgrading Oracle Database" for more information about changes to initialization parameters in this Oracle Database 11g release |
Renamed Parameters Section Contents
The Renamed Parameters section displays a list of initialization parameters in the parameter file of the current database that are renamed in the new Oracle Database 11g release. New default values are also given.
|
See Also: Appendix A, "Behavior Changes After Upgrading Oracle Database" for initialization parameters that are renamed in the new Oracle Database 11g release |
Obsolete/Deprecated Parameters Section Contents
The Obsolete/Deprecated Parameters section displays a list of initialization parameters in the parameter file of the current database that are obsolete or deprecated in the new Oracle Database 11g release. Obsolete initialization parameters must be removed from the parameter file before the database is upgraded.
|
See Also: Appendix A, "Behavior Changes After Upgrading Oracle Database" for a list of initialization parameters that are obsolete or deprecated in the new Oracle Database 11g release |
Components Section Contents
The Components section displays a list of database components in the database to be upgraded or installed when the current database is upgraded to the new Oracle Database 11g release. Software components are pre-built code libraries that provide specific database funtionality like Oracle Text, Oracle Java packages, and Oracle RAC.
Miscellaneous Warnings Section Contents
The Miscellaneous Warnings section provides warnings about specific situations that require attention before or after the upgrade. For example, if the database is using a time zone file that is a version older than what is required for the upgrade, then a warning displays with the required action.
Recommendations Section Contents
The Recommendations section provides Oracle recommendations, including the recommended SQL statements and commands, that should be performed before upgrading to the new Oracle Database 11g release.
Before upgrading to the new Oracle Database 11g release, Oracle recommends analysis of the information and warnings displayed by the Pre-Upgrade Information Tool. The following topics describe warnings and the appropriate actions to take.
Managing and Updating Access Control Lists and Network Utility Packages
Decreasing Downtime for Gathering Optimizer Statistics (Optional)
Saving Database Control Files and Data with the emdwgrd Utility
After upgrading to the new Oracle Database 11g release from Oracle9i Release 2 (9.2) or Oracle Database 10g Release 1 (10.1), the CONNECT role has only the CREATE SESSION privilege. The other privileges granted to the CONNECT role in earlier releases are revoked during the upgrade.
To identify which users and roles in your database are granted the CONNECT role
Perform the following query:
SELECT grantee FROM dba_role_privs
WHERE granted_role = 'CONNECT' and
grantee NOT IN (
'SYS', 'OUTLN', 'SYSTEM', 'CTXSYS', 'DBSNMP',
'LOGSTDBY_ADMINISTRATOR', 'ORDSYS',
'ORDPLUGINS', 'OEM_MONITOR', 'WKSYS', 'WKPROXY',
'WK_TEST', 'WKUSER', 'MDSYS', 'LBACSYS', 'DMSYS',
'WMSYS', 'EXFSYS', 'SYSMAN', 'MDDATA',
'SI_INFORMTN_SCHEMA', 'XDB', 'ODM');
If users or roles require privileges other than CREATE SESSION, then grant the specific required privileges before upgrading.
The upgrade scripts provided by Oracle adjust the privileges for the Oracle-supplied users.
The new Oracle Database 11g release includes fine-grained access control to the UTL_TCP, UTL_SMTP, UTL_MAIL, UTL_HTTP, and UTL_INADDR packages using Oracle XML DB. If you have applications that use one of these packages, then you must install Oracle XML DB if it is not currently installed.
To update ACLs and Network Utility packages
Install Oracle XML DB if it is not currently installed.
New behavior for the DBMS_LDAP PL/SQL package and the HttpUriType type requires the creation or update of access control lists (ACLs) after performing the upgrade to the new Oracle Database release 11.2.
For example, if your application depends on the DBMS_LDAP package, then the error "ORA-24247: network access denied by access control list (ACL)" may occur. The logged-in user must have the connect privilege for the host and port specified by DBMS_LDAP.init.
If Oracle XML DB is installed on the database to be upgraded, and therefore one or all of the UTL_TCP, UTL_SMTP, UTL_MAIL, UTL_HTTP, and UTL_INADDR packages are installed, then you may need to re-install these packages after performing the upgrade to ensure that you have the latest version of these packages for the new release.
After upgrading to the new Oracle Database 11g release, you may need to assess the dependencies of network utility packages and provide access by adding the appropriate access control lists (ACLs).
To check the status of access and add ACLs for network utility packages
Run the pre-upgrade information tool as described in "Using the Pre-Upgrade Information Tool".
Check the output from the pre-upgrade information tool (upgrade_info.log) for messages such as the following:
WARNING: --> Database contains schemas with objects dependent on network packages. .... Refer to the 11g Upgrade Guide for instructions to configure Network ACLs. .... USER WKSYS has dependent objects. .... USER SYSMAN has dependent objects. .... USER FLOWS_010600 has dependent objects. .
Query the DBA_DEPENDENCIES view to obtain more information about the dependencies. For example:
SELECT * FROM DBA_DEPENDENCIES
WHERE referenced_name IN ('UTL_TCP','UTL_SMTP','UTL_MAIL','UTL_HTTP','UTL_INADDR','DBMS_LDAP')
AND owner NOT IN ('SYS','PUBLIC','ORDPLUGINS');
Prepare post-upgrade scripts now to make the scripts available for use in the test environment. This ensures the new access controls are part of your upgrade testing.
To configure network access control lists (ACLs) in the database so that these packages can work as they did in prior releases, see the example script provided in "Configuring Fine-Grained Access to External Network Services After Upgrading Oracle Database". This script shows how to use the DBMS_NETWORK_ACL_ADMIN package to create, assign, and add privileges to the access control list.
After the upgrade, you must grant the specific required privileges. Access is based on the usage in the original database.
This information is important only if you need to downgrade to your original database release after performing the upgrade. During the upgrade to the new Oracle Database 11g release from Oracle9i Release 2 (9.2) or Oracle Database 10g Release 1 (10.1), any passwords in database links are encrypted.
To downgrade to the original release, all of the database links with encrypted passwords must be dropped before the downgrade. Consequently, the database links are nonexistent in the downgraded database.
If you anticipate a requirement to be able to downgrade to your original release, then save the information about affected database links from the SYS.LINK$ table, so that you can re-create the database links after the downgrade.
The time zone files that are supplied with Oracle Database 11g Release 2 (11.2) have been updated to reflect changes in transition rules for some time-zone regions. The changes might affect existing data of the TIMESTAMP WITH TIME ZONE data type.
The time zone behavior for Oracle Database 11g Release 2 (11.2) has changed significantly from earlier releases. You must make sure to obtain the latest time zone files before you upgrade the database. If the time zone file version of the database being upgraded is not the most recent version of the time zone file available for the new 11.2 release, then the Pre-Upgrade Information Tool displays a warning and describes how to proceed. Table 3-1 describes the warnings and summarizes how to resolve a mismatch in time zone file versions.
|
Caution: The |
Table 3-1 Choices for Fixing the Time Zone File Version
| IF the time zone version on the database being upgraded is... | THEN fix the time zone files... |
|---|---|
|
Earlier than the most current version included in the new database release and the Pre-Upgrade Information Tool displays "Database is using a time zone file older than version n." |
After completing the database upgrade. Use the |
|
Later than the version included in the new database release and the Pre-Upgrade Information Tool displays "Database is using a time zone file greater than version n." |
Before beginning the database upgrade. You must patch ( You must patch the Oracle home with the appropriate patch for the time zone file version in use. Apply the patch for each database to be upgraded. Otherwise, the upgrade script terminates without upgrading the database. |
|
See Also:
|
When upgrading to the new Oracle Database 11g release, optimizer statistics are collected for dictionary tables that lack statistics. This statistics collection process can be time consuming for databases with a large number of dictionary tables, but statistics gathering only occurs for those tables that lack statistics or are significantly changed during the upgrade.
To decrease the amount of downtime incurred when collecting statistics
Collect statistics before performing the actual database upgrade. Oracle recommends that you use the DBMS_STATS.GATHER_DICTIONARY_STATS procedure to gather these statistics. For example, you can enter the following SQL statement:
EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;
|
Note: If you are using Oracle9i Release 2 (9.2), then you should use theDBMS_STATS.GATHER_SCHEMA_STATS procedure to gather statistics. To do this, you can run the scripts provided in Appendix B in this guide. |
System Components and Schemas Used for Optimizer Statistics
Table 3-2 lists the system components and schemas that are checked for statistics collection during the upgrade.
Table 3-2 Statistics Collection for System Components and Schemas
| Component Name | Schema |
|---|---|
|
JServer JAVA Virtual Machine |
|
|
OLAP Analytic Workspace |
|
|
Oracle Database Catalog Views |
|
|
Oracle Database JAVA Packages |
|
|
Oracle Database Packages and Types |
|
|
Oracle Database Vault |
|
|
Oracle Enterprise Manager |
|
|
Oracle Expression Filter |
|
|
Oracle Multimedia |
|
|
Oracle Label Security |
|
|
Oracle OLAP API |
|
|
Oracle Spatial |
|
|
Oracle Text |
|
|
Oracle Workspace Manager |
|
|
Oracle XDK |
|
|
Oracle XML Database |
|
Any invalid SYS/SYSTEM objects found before upgrading the database are stored in the table named registry$sys_inv_objs. Any invalid non-SYS/SYSTEM objects found before upgrading the database are stored in registry$nonsys_inv_objs.
To identify any new invalid objects due to the upgrade
After the upgrade, run ORACLE_HOME/rdbms/admin/utluiobj.sql
If you plan to downgrade Oracle Enterprise Manager Database Control after upgrading to the new Oracle Database 11g release, then you must save your database control files and data before upgrading your database. Oracle provides the emdwgrd utility to use before upgrading your database to keep a copy of your database control files and data.
The emdwgrd utility resides in the ORACLE_HOME/bin directory in the new Oracle Database 11g release. The emdwgrd utility consists of emdwgrd and emdwgrd.pl for Linux and UNIX, and emdwgrd.bat and emdwgrd.pl for Windows. Before running the utility, you must install the software for the new Oracle Database 11g release, and then invoke the script from the new Oracle home. The emdwgrd utility, however, requires that you set ORACLE_HOME to the old Oracle home.
To save your database control files and data using emdwgrd
Install the software for the new Oracle Database 11g release. (This step is not required for an in-place patch set upgrade.)
Set ORACLE_HOME to your old Oracle home. (This step is not required for an in-place patch set upgrade.)
Set ORACLE_SID to the SID of the database being upgraded.
Set PATH, LD_LIBRARY_PATH, and SHLIB_PATH to point to the Oracle home from which the database is being upgraded.
Go to the Oracle home of the new Oracle Database 11g release.
Execute one of the following commands:
For a single-instance database, run the following command, where old_SID is the SID of the database being upgraded and save_directory is the path to the storage place you have chosen for your database control files and data:
emdwgrd -save -sid old_SID -path save_directory
|
Note: The script is inemdwgrd.sh on Linux and UNIX platforms. On Windows, the script is in emdwgrd.bat. |
If the database is an Oracle RAC database, remote copy is required across the cluster nodes. Define an environment variable to indicate which remote copy is configured. For example:
setenv EM_REMCP /usr/bin/scp
Then, execute the following save command:
emdwgrd -save -cluster -sid old_SID -path save_directory
If the release 10g Oracle home is on a shared device, add -shared to the previous command line.
Enter the SYS password for the database to be upgraded.
|
Note: The DBUA backup and restore process also allows you to revert to your previous Oracle Enterprise Manager Database Control environment after upgrading your database. However, all user data that is accumulated between the time of upgrade and restore operations is lost. Saving your database control files and data enables you to downgrade both your database and database control. All user data is retained even though all database control data that is accumulated between the time of upgrade and downgrade is lost. |
You must wait until all materialized views have completed refreshing before upgrading. You can query the system to determine if there are any materialized view refreshes still in progress.
To determine if there are any materialized view refreshes still in progress
Run the following query
SQL> SELECT * FROM sys.obj$ o, sys.user$ u, sys.sum$ s WHERE o.type# = 42 AND bitand(s.mflags, 8) = 8;
Before upgrading the database, you must ensure that there are no files requiring media recovery. You can query the system to get a list of files and then recover them as appropriate.
To get a list of files that require media recovery
Issue the following statement:
SQL> SELECT * FROM v$recover_file;
Files must not be in backup mode when performing the upgrade; therefore, you must wait until backups are completed. You can query the system to see a list of any files in backup mode and then take appropriate action by either waiting for the backup to complete, or by aborting any backups that are not needed.
To get a list of files in backup mode
Issue the following statement:
SQL> SELECT * FROM v$backup WHERE status != 'NOT ACTIVE';
You must resolve outstanding distributed transactions before performing the upgrade. You can do this by first querying to see any pending transactions, and then committing the transactions. You must wait until all pending distributed transactions have been committed.
To resolve outstanding distributed transactions
Issue the following statement:
SQL> SELECT * FROM dba_2pc_pending;
If the query in the previous step returns any rows, then issue the following statements:
SQL> SELECT local_tran_id FROM dba_2pc_pending;
SQL> EXECUTE dbms_transaction.purge_lost_db_entry('');
SQL> COMMIT;
If a standby database exists, then you must synchronize it with the primary database.
To check if a standby database exists and to synchronize it
Issue the following query:
SQL> SELECT SUBSTR(value,INSTR(value,'=',INSTR(UPPER(value),'SERVICE'))+1) FROM v$parameter WHERE name LIKE 'log_archive_dest%' AND UPPER(value) LIKE 'SERVICE%';
If the query in the previous step returns a row, then synchronize the standby database with the primary database.
Make sure all the logs are transported to the standby server after a final log switch in the primary.
Start the recovery of the standby database with the NODELAY option.
The database recycle bin must be empty before you begin the upgrade process. You use the PURGE statement to remove items and their associated objects from the recycle bin and release their storage space.
To empty the database recycle bin
Issue the following command:
SQL> PURGE dba_recyclebin
|
Caution: The database recycle bin must be empty during the upgrade process to avoid possible |
If you are upgrading from Oracle9i and a listener was not configured in the Oracle9i repository, then you must run Oracle Net Configuration Assistant to configure the listening protocol address and service information for the new Oracle Database 11g database, including a listener.ora file, before running DBUA. A new version of the listener is required for an Oracle Database 11g database. Previous versions of the listener are not supported for use with an Oracle Database 11g database. However, it is possible to use the new version of the listener with previous versions of Oracle Database.
If you are upgrading an Oracle RAC database, then you have the following options:
Upgrade the Oracle RAC database with DBUA, which automatically migrates the listener from your old Oracle home to the new Oracle Grid Infrastructure 11g Release 2 home.
|
Note: Beginning with Oracle Database 11g Release 2, you must administer the listener by using thelsnrctl command in the Oracle Grid infrastructure home. Do not attempt to use the lsnrctl commands from Oracle home locations for previous releases. |
If you are upgrading from Oracle9i or upgrading manually without using DBUA, then run Oracle Net Configuration Assistant before upgrading the Oracle RAC database.
This is a two-step option. You must first run Oracle Net Configuration Assistant from the old Oracle home to remove the old listener. Then you must run Oracle Net Configuration Assistant again from the Oracle home of the new Oracle Database 11g release to create a new listener.
You must remove the old listener before creating a new one. If you attempt to create a new listener from the new Oracle home first, and use the same name and port as the old listener, then Oracle Net Configuration Assistant returns an error.
|
See Also: Oracle Database Net Services Administrator's Guide for complete information about using Oracle Net Configuration Assistant |
DBUA provides a graphical user interface (GUI) to guide you through the upgrade of a database, or you can invoke it in silent mode, which does not present a user interface. The following topics guide you through the process of upgrading a database using Database Upgrade Assistant (DBUA).
Important: If you terminate the upgrade, but do not restore the database, then you cannot restart DBUA. Instead, you must continue with a manual (command line) upgrade as described in "Manually Upgrading Oracle Database".
DBUA can be used to upgrade from earlier Oracle Database 11g patch releases as well as from earlier major Oracle Database releases on both Oracle RAC databases and Oracle Database single-instance databases. The procedure to upgrade patch releases is no different from the normal upgrade procedure.
You must run the Oracle Net Configuration Assistant before running DBUA. See "Configuring the Listener When Upgrading from Oracle9i".
If you are upgrading an existing Oracle Enterprise Manager Database Control or if you are configuring a new Oracle Enterprise Manager Database Control for the new Oracle Database 11g release, then the listener must be running before upgrading Oracle Enterprise Manager. If DBUA detects that an Oracle Enterprise Manager upgrade or configuration is requested, and DBUA does not see a listener running, then it prompts you and starts the default listener in either of these cases.
If you upgrade a cluster database using DBUA, then you must make sure the CLUSTER_DATABASE initialization parameter is set to TRUE.
If the database instance is not running, then DBUA tries to start the instance with the default initialization parameter file. If that fails, then DBUA prompts you to provide the name of the correct initialization parameter file or to start the instance. If the instance is up and running, then DBUA connects to it.
If you terminate the upgrade, but do not restore the database, then you cannot restart DBUA until you start up the existing database in UPGRADE mode using the new Oracle Database 11g server. You cannot go back to the original server unless you restore your database.
For Oracle RAC, you cannot re-run DBUA once you terminate the upgrade. If you need to re-run the upgrade, then you must run DBUA from the restored backup of the database you are upgrading.
If you restore your database manually (not using DBUA), then remove the Welcome_SID.txt file, which is located in the ORACLE_HOME/cfgtoollogs/dbua/logs/ directory, before starting DBUA. The presence of this file indicates to DBUA that this is a re-run operation.
If you installed Oracle Database 11g Release 2 (11.2) and specified that you are upgrading an existing database, then DBUA starts automatically. However, if you did not specify that you are upgrading an existing database, then you can start DBUA independently after installation is complete.
While the upgrade is in process, DBUA shows the upgrade progress for each component. DBUA writes detailed trace and log files and produces a complete HTML report for later reference. To enhance security, DBUA automatically locks new user accounts in the upgraded database. DBUA then proceeds to create new configuration files (parameter and listener files) in the new Oracle home.
DBUA does not begin the upgrade until all of the pre-upgrade steps are completed.
These topics provide additional information about DBUA:
DBUA performs the following checks before the upgrade:
Invalid user accounts or roles
Invalid data types or invalid objects
Desupported character sets
Adequate resources, including rollback segments, tablespaces, and free disk space
Missing SQL scripts needed for the upgrade
Listener running (if Oracle Enterprise Manager Database Control upgrade or configuration is requested)
Oracle Database software linked with Database Vault option
|
Note: If Database Vault is enabled, then DBUA returns an error asking you to disable Database Vault before upgrading. See "About Upgrading Databases That Use Oracle Database Vault". |
During the upgrade, DBUA automatically modifies or creates new required tablespaces and invokes the appropriate upgrade scripts, as follows:
If the datafiles are auto extensible and have enough disk space to grow, then DBUA continues with the upgrade.
If the datafiles are not autoextensible, then DBUA prompts you and makes the files auto extensible.
If the tablespaces are auto extensible and the MAXSIZE initialization parameter needs adjustment, then DBUA prompts for the same and adjusts the MAXSIZE parameter.
If there is not enough disk space to grow, then DBUA prompts you to create space (by adding more datafiles). DBUA does not add new datafiles because DBUA cannot determine where to create the files.
Optionally, DBUA backs up all necessary files.
Complete the following steps to upgrade a database using the DBUA graphical user interface. These steps are performed from within the new Oracle home where the latest database software has been installed as described in "Installing the New Oracle Database Software for the Upgrade" .
|
Important: If you terminate the upgrade, but do not restore the database, then you cannot restart DBUA. Instead, you must continue with a manual (command line) upgrade as described in "Manually Upgrading Oracle Database". |
To upgrade a database using DBUA on Linux, UNIX, and Windows
Start DBUA from the Oracle home where the new database software has been installed:
On Linux or UNIX platforms, enter the following command at a system prompt in the new Oracle Database 11g Release 2 (11.2) home:
dbua
|
Note: Thedbua executable is usually located in the ORACLE_HOME/bin directory. |
On Windows operating systems, select Start > Programs > Oracle - HOME_NAME > Configuration and Migration Tools > Database Upgrade Assistant.
The DBUA Welcome screen displays.
If you need help at any screen or want to consult more documentation about DBUA, then click Help to open the online help.
Click Next.
The Select Database page appears, listing the databases available for upgrade.
Select the database you want to upgrade to Oracle Database 11g Release 2 (11.2).
You can select only one database at a time. If you do not see the database that you want, then make sure an entry with the database name exists in the oratab file in the etc directory.
If you are running DBUA from a user account that does not have SYSDBA privileges, then you must enter the user name and password credentials to enable SYSDBA privileges for the selected database.
Click Next.
DBUA analyzes the database, performing pre-upgrade checks and displaying warnings as necessary. Examples of DBUA database checks include:
Redo log files whose size is less than 4 MB. If such files are found, then DBUA gives the option to drop/create new redo log files.
Obsolete or deprecated initialization parameters.
When DBUA finishes its checks, the Upgrade Options screen displays.
The Upgrade Options screens enables you to set the following options:
Recompile invalid objects at the end of upgrade
Select Recompile invalid objects at the end of upgrade if you want DBUA to recompile all invalid PL/SQL modules after the upgrade is complete.
When you upgrade a database to Oracle Database 11g Release 2 (11.2), many of the PL/SQL modules in your database become invalid. As a result, all existing PL/SQL modules in an INVALID state must be recompiled, such as packages, procedures, types, and so on.
By default, Oracle Database recompiles invalid PL/SQL modules as they are used. The time it takes to recompile the module can result in poor performance when you begin to use your newly upgraded database.
To eliminate these performance issues, select Recompile invalid objects at the end of upgrade. When you select this option, DBUA recompiles all the invalid PL/SQL modules immediately after the upgrade is performed. This ensures that you do not experience any performance issues later, as you begin using your newly upgraded database.
|
Note: Selecting Recompile invalid objects at the end of upgrade is equivalent to running theutlrp.sql script, located in the ORACLE_HOME/rdbms/admin directory, which is used to recompile stored PL/SQL and Java code. |
The task of recompiling all the invalid PL/SQL modules in your database can take a significant amount of time and increase the time it takes to complete your database upgrade. If you have multiple CPUs, then you can reduce the time it takes to perform this task by taking advantage of parallel processing on your available CPUs. If you have multiple CPUs available, then DBUA automatically adds an additional section to the Recompile Invalid Objects screen and automatically determines the number of CPUs you have available.
Degree of Parallelism
DBUA also provides a recommended degree of parallelism, which determines how many parallel processes are used to recompile your invalid PL/SQL modules. Specifically, DBUA sets the degree of parallelism to one less than the number of CPUs you have available. For example, if you have three CPUs available for processing, then DBUA selects 2 from the Degree of Parallelism menu. You can adjust this default value by selecting a new value from the Degree of Parallelism menu.
Backup Database
Select Backup database if you want DBUA to back up your database for you.
|
Important: Oracle strongly recommends that you back up your database before starting the upgrade. If errors occur during the upgrade, then you might be required to restore the database from the backup. |
If you use DBUA to back up your database, then it makes a copy of all your database files in the directory you specify in the Backup Directory field. DBUA performs this cold backup automatically after it shuts down the database and before it begins performing the upgrade procedure. The cold backup does not compress your database files, and the backup directory must be a valid file system path. You cannot specify a raw device for the cold backup files.
In addition, DBUA creates a batch file in the specified directory. You can use this batch file to restore the database files:
On Windows operating systems, the file is called db_name_restore.bat.
On Linux or UNIX platforms, the file is called db_name_restore.sh.
If you choose not to use DBUA for your backup, then Oracle assumes you have backed up your database using your own backup procedures.
|
Note: DBUA does not back up Oracle ASM databases. You must manually back them up on your own. |
Click Next.
If you are upgrading a single-instance database or Oracle Express Edition (XE), then the Move Database Files screen appears. If you are upgrading an Oracle Real Application Clusters database, then the Move Database Files screen does not display.
Select one of the following options:
Do Not Move Database Files as Part of Upgrade
Move Database Files during Upgrade
If you choose to move database files, then you must also make one of the following selections:
File System
Your database files are moved to the host file system.
Oracle Automatic Storage Management (Oracle ASM)
Your database files are moved to Oracle ASM storage, which must currently exist on your system. If you do not have an Oracle ASM instance, then you can create one using Automatic Storage Management Configuration Assistant (ASMCA) from the Oracle Grid Infrastructure home and then restart DBUA.
|
See Also:
|
Click Next.
The Recovery and Diagnostic Locations screen displays, where you can designate a flash recovery area for your database.
Flash recovery area is an Oracle managed disk location used for storing backup and recovery related files. Oracle strongly recommends configuring a flash recovery area, because it significantly enhances speed, reliability, and manageability of the database recovery process. The location of the flash recovery area is also used by Enterprise Manager if you enable local management and daily backups on the Management Options screen.
If you selected the Move Database Files during Upgrade option in step 5, or if an Oracle Express Edition database is being upgraded to Oracle Enterprise Edition, then you must configure a flash recovery area. If a flash recovery area is currently configured, then the current settings are retained but the screen displays to allow you to override these values.
Do one of the following:
Accept the default flash recovery area location
Enter the full path to a different location in the Flash Recovery Area field
Click Browse and select a different flash recovery area location
Do one of the following:
Accept the default size for the flash recovery area
Enter a different value in the Flash Recovery Area Size field
Click the up or down arrows to adjust the flash recovery area size
Click Next.
If no other database is currently being monitored with Enterprise Manager, then the Management Options screen displays.
At the Management Options screen, you have the option of setting up your database so it can be managed with Enterprise Manager. Enterprise Manager provides Web-based management tools for managing individual database instances, as well as central management tools for managing your entire Oracle environment, including multiple databases, hosts, application servers, and other components of your network.
Before you can register the database with Oracle Enterprise Manager Grid Control, an Oracle Enterprise Manager Agent must be configured on the host computer.
To set up your database to be managed with Enterprise Manager, select Configure the Database with Enterprise Manager and then select one of the following options:
Register with Grid Control for centralized management
If you select this option, then you must also select an Oracle Management Service from the Management Service drop-down list. When you run DBUA, it checks to see if the Oracle Management Agent has been installed on the host computer. If no Oracle Management Agent is found, then the Grid Control option is not available.
When you finish installing the Oracle Database software, the database is automatically available as a managed target within Oracle Enterprise Manager Grid Control.
Configure Oracle Enterprise Manager Database Control for local management
If you are not centrally managing your Oracle environment, then you can still use Enterprise Manager to manage your database. When you install Oracle Database, you automatically install Oracle Enterprise Manager Database Control, which provides Web-based features for monitoring and administering the single-instance or cluster database you are installing.
Do the following steps if you want the SYSMAN user (the default Super Administrator and owner of the Management Repository schema) to receive E-mail notification when a metric for a specified condition reaches a critical or warning threshold:
Select Enable Alert Notifications
Enter the name of the e-mail server you want to use for notifications in the Outgoing Mail (SMTP) Server field
Enter the e-mail address of the SYSMAN user in the Recipient Email Address field
For example, Enterprise Manager can send an e-mail when a target goes down or when there are database space usage problems. E-mail notifications are enabled immediately upon installation.
Do the following steps to use the Oracle suggested backup strategy to back up your entire database with a minimum amount of configuration:
Select Enable Daily Disk Backup to Recovery Area
Enter a start time in the Backup Start Time field
Enter host credentials in the OS Username and Password fields
If you select the Enable Daily Disk Backup to Recovery Area option, then Enterprise Manager is configured to back up your database immediately after you finish upgrading Oracle Database. Enterprise Manager backs up the database to the flash recovery area. Later, you can use Enterprise Manager to customize your backup strategy further.
On Windows the user whose credentials you enter for the backup must be granted the Logon as a batch job privilege in the Local Security Policies of Windows. If the chosen user does not have this privilege, then the backup job fails.
Click Next.
The Database Credentials screen displays.
Select one of the following options:
Use Different Passwords
If you choose to use different passwords, then you must enter a password in the Password and Confirm Password columns for each account in the table.
Use the Same Password for All Accounts
If you choose to use the same password, then you must enter that password in the Password and Confirm Password fields.
|
Note: If the default Oracle Database 11g Release 2 (11.2) security settings are in place, then new passwords must be at least eight characters, and passwords such aswelcome and oracle are not allowed. See Oracle Database Security Guide for more information. |
Click Next.
The Summary screen appears.
The Summary screen shows the following information about the upgrade before it starts:
Name, version, and Oracle home of the old and new databases
Database backup location, available space, and space required
Warnings ignored
Database components to be upgraded
Initialization parameters changes
Database files location
Listener registration
|
See Also: "Setting the COMPATIBLE Initialization Parameter" for information about setting theCOMPATIBLE initialization parameter after the upgrade |
Check all of the specifications. Then do one of the following:
Click Back if anything is incorrect until you reach the screen where you can correct it.
Click Finish if everything is correct.
The Progress screen displays and DBUA begins the upgrade.
After the upgrade has completed, the following message is displayed on the Progress screen:
Upgrade is complete. Click "OK" to see the results of the upgrade.
The Upgrade Results screen displays a description of the original and upgraded databases and changes made to the initialization parameters. The screen also shows the directory where various log files are stored after the upgrade. You can examine these log files to obtain more details about the upgrade process.
|
Note: An HTML version of the Upgrade Results is also saved in the log files directory. |
Click Configure Database Passwords to display the Password Management dialog box.
The Password Management dialog box enables you to change the default password for a user after you upgrade the database. For security reasons, all users are locked except for the following users:
SYS
SYSTEM
If you have enabled Local Management with Enterprise Manager, then the SYSMAN and DBSNMP accounts are also unlocked. These accounts provide Enterprise Manager with access to the database so it can gather monitoring data and so you can perform administration tasks with Enterprise Manager.
If you have enabled Central Management with Enterprise Manager, then the DBSNMP account is unlocked, as well as the SYS and SYSTEM user accounts.
|
Note: To prevent unauthorized use of the database, Oracle recommends that you change all user passwords immediately after you upgrade your database.If the default Oracle Database 11g Release 2 (11.2) security settings are in place, then passwords must be at least eight characters, and passwords such as |
Click Restore Database if you are not satisfied with the upgrade results.
Depending on the method you used to back up your database, the Restore operation performs one of two tasks:
If you used DBUA to back up your database, then clicking Restore restores the original database and the original database settings from the backup.
If you used your own backup procedure to back up the database, then clicking Restore restores only the original database settings. To restore the database itself, you must restore the backup you created with your own backup utilities.
If you are satisfied with the upgrade results, then click Exit to quit DBUA and use your newly upgraded database.
DBUA modifies the SID_DESC entry for the upgraded database in the Oracle Database listener.ora file in one of the following ways:
A simple case: Suppose the old listener.ora has the following SID_DESC entry:
...
(SID_DESC =
(SID_NAME = ORCL)
)
...
If th e database name is SAL, the domain name is COM, and the Oracle home is /oracle/product/9.2, then the assistant adds the following entry:
...
(SID_DESC =
(GLOBAL_DBNAME = sal.com)
(ORACLE_HOME = /oracle/product/9.2)
(SID_NAME = SAL)
)
...
A more complicated case: Suppose the old listener.ora has the following SID_DESC entry:
...
(SID_DESC =
(GLOBAL_DBNAME = an_entry)
(SID_NAME = ORCL)
)
...
If an_entry does not match the GLOBAL_DBNAME of the migrated database, and if the database name is SAL, the domain name is COM, and the Oracle home is /oracle/product/9.2, then the assistant adds the following entry:
...
(SID_DESC =
(GLOBAL_DBNAME = sal.com)
(ORACLE_HOME = /oracle/product/9.2)
(SID_NAME = SAL)
)
...
This entry is the same as the entry in the simple case, but DBUA also adds the entry an_entry to the SERVICE_NAMES parameter in the initialization parameter file. Therefore, DBUA changes the SERVICE_NAMES parameter to the following:
SERVICE_NAMES = sal.com, an_entry
DBUA removes the entry of the upgraded database from the old listener.ora file.
DBUA reloads the listener.ora file in both the old and new Oracle Database environments.
>>The following steps were deleted, either because the screens no longer appear or because they have been replaced with rewritten steps covering the same screens, as per IOUG presentation by Ravi Pattabhi 3/26/07. CBF 3/30/07
Specify the attributes for the SYSAUX tablespace, which is added automatically to all new Oracle Database 11g Release 1 (11.1) databases you create.
Many of the attributes of the SYSAUX tablespace are set automatically and cannot be modified. For example, the SYSAUX tablespace is set to use Automatic Segment-Space Management. However, you can specify the location of the data file, the default size of the SYSAUX tablespace, and its autoextend attributes.
|
Note: If you specify an existing datafile for theSYSAUX tablespace, then you must select Reuse Existing File Name. Otherwise, DBUA alerts you to the fact that the file currently exists. |
Click Next.
The Recompiling Invalid Objects screen appears.
Secure your database with passwords for the Enterprise Manager accounts. You can set a single password, which is applied to each of the listed Enterprise Manager user accounts, or enhance the security of the accounts by providing unique passwords for each user.
Click Next.
The Recovery Configuration screen appears.
Specify a flash recovery area and enable archiving. When you are managing your database, it is important to configure the database so you can recover your data in the event of a system failure.
The Flash Recovery Area can be used to recover data that would otherwise be lost during a system failure. This location is also used by Enterprise Manager if you enabled local management and daily backups on the Management Options screen.
Click Next.
The Network Configuration screen appears.
At the Upgrade Operations page, do one of the following:
Select the option to upgrade only the Oracle ASM instance
Select the option to upgrade the database
If you choose to upgrade the database, and the database is using Oracle ASM, then DBUA asks if you want to upgrade the Oracle ASM instance along with the database. Oracle recommends that you upgrade the database and Oracle ASM in separate DBUA sessions, in separate Oracle homes.
Click Next.
The Selecting a Database Instance screen appears.
At the Changes in Default Behavior screen, DBUA displays some changes in the behavior of Oracle Database 11g Release 1 (11.1) from that of previous releases. In some cases the default values of some initialization parameters have changed. In other cases some new behavior/requirement has been introduced that might affect current scripts or applications.
Complete the procedures described in Chapter 4, "Post-Upgrade Tasks for Oracle Database".
Oracle recommends when upgrading to Oracle Database 11g R2 (11.2) that you perform an out-of-place mode upgrade, which installs the new software into a new Oracle home. This means that you provide a different Oracle home location for the new upgrade. However, there may be cases where you need to perform an in-place upgrade, which maintains the same Oracle home. This section provides the information on how to keep the existing Oracle home.
The considerations and options for performing in-place upgrades are provided in these topics:
Known Issue When Starting an In-Place Upgrade
When performing an in-place upgrade, which uses the same Oracle home location, an error messages appears stating that the installer detects Oracle Database software in the location that you specified.
Message: The installer has detected that the software location you have specified contains Oracle Database software release 11.2.0.1. Oracle recommends that when upgrading, you perform an out-of-place installation of the software into a new Oracle home and then upgrade the database using the new software binaries.
Cause: The installer has detected that the software location you have specified contains Oracle Database software release 11.2.0.1.
Action: Either perform an in-place upgrade as described in this section, or perform an out-of-place upgrade, into a new Oracle home, as described in "Installing the New Oracle Database Software for the Upgrade".
Performing an In-Place Upgrade for Single-Instance Oracle Database
If you must perform an in-place upgrade, then the procedure is to back up the current installation, move it to a different location, and then install the new software in the old location, as described in the following procedure.
|
WARNING: Oracle strongly recommends that you do not upgrade Oracle Database to release 11.2.0.2 or 11.2.0.3 using the existing Oracle home. This procedure is provided only if for some reason you have no alternative but to use the existing Oracle home. |
To perform an in-place upgrade for a single-instance database
Obtain the Oracle Database release 11.2.0.3 software from My Oracle Support at https://support.oracle.com/.
Back up the configuration data by backing up the following directories:
ORACLE_HOME/dbs
ORACLE_HOME/network/admin
ORACLE_HOME/owb/bin/admin
ORACLE_HOME/hostname_dbname
ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_hostname_dbname
Depending on which release you are upgrading from, in the software location for the release 11.2.0.1 or 11.2.0.2 software, detach the ORACLE_HOME with the following command:
ORACLE_HOME/oui/bin/runInstaller -detachHome ORACLE_HOME=11.2.x.x.x software location
Rename or move this ORACLE_HOME software directory to a temporary name:
mv ORACLE_HOME ORACLE_HOME.backup
Start OUI and select release 11.2.0.3. Software Only.
For Location, select the same location as used for release 11.2.0.1 or 11.2.0.2 (depending on which release you are upgrading from).
After the installation completes, restore the configuration data for the old Oracle home. Restore the backed up configuration data files (from the backups you made of /dbs and network/admin), and also restore the following directories: /hostname_dbname, /owb/bin/admin, and /oc4j/j2ee/OC4J_DBConsole_hostname_dbname. Specify the actual name for hostname_dbname where hostname is the actual hostname and dbname is the actual database name.
Run DBUA from ORACLE_HOME/bin directory and select the 11.2.0.1.0 or 11.2.0.2.0 database instance to perform the upgrade to 11.2.0.3.0.
|
See Also: |
Performing an In-Place Upgrade for an Oracle RAC Database
Performing an in-place upgrade of an Oracle RAC database is similar to the procedure described in "Performing an In-Place Upgrade for Single-Instance Oracle Database". You must back up the current Oracle home and installation, move it to a different location, and then install the new software in the old location, as described in the following steps.
|
WARNING: Oracle strongly recommends that you do not upgrade Oracle Database to release 11.2.0.2 or 11.2.0.3 using the existing Oracle home. This procedure is provided only if for some reason you have no alternative but to use the existing Oracle home. |
To perform an in-place upgrade for Oracle RAC Database instances
Back up the configuration data by backing up the following directories on all cluster nodes:
ORACLE_HOME/dbs
ORACLE_HOME/network/admin
ORACLE_HOME/owb/bin/admin
ORACLE_HOME/hostname_dbname
ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_hostname_dbname
Run the following command on each of the nodes to detach the old Oracle RAC ORACLE_HOME. For example:
ORACLE_HOME/oui/bin/runInstaller -detachHome ORACLE_HOME=11.2.0.1.0 software location
Rename this Oracle RAC ORACLE_HOME directory on all the nodes to a temporary name.
Install release 11.2.0.3 Software Only on all nodes.
On all nodes, restore into the 11.2.0.3 ORACLE_HOME software location the backed up configuration data files (from the backups you made of /dbs and network/admin), and also restore the following directories: /hostname_dbname, /owb/bin/admin, and /oc4j/j2ee/OC4J_DBConsole_hostname_dbname. Specify the actual name for hostname_dbname.
Run DBUA from the 11.2.0.3 ORACLE_HOME/bin directory on the local node and select the 11.2.0.1.0 Oracle RAC database instance to upgrade it to release 11.2.0.3.0.
Oracle recommends that you perform the out-of-place upgrade into a new Oracle home. This procedure is provided only if for some reason you must use the old Oracle home.
The following topics discuss how to perform an upgrade into an existing Oracle home on Windows platforms:
Considerations for In-Place Upgrade of Oracle Database on Windows Platforms
Performing an In-Place Upgrade of Oracle Database on Windows
|
Important:
|
On Windows, you must shut down all services that invoke or lock Oracle files. To do this, set the services to disable in Windows service manager. A reboot may be required after you disable some services in order to free their associated locked objects. On Windows platforms, ORADIM manages Windows Services (operating system processes). DBCA manages Oracle database instances and database services.
This procedure is provided only if you have no alternative but to use the old Oracle home when upgrading to the new Oracle Database 11g Release 2 (11.2) release. This is not the perferred method for upgrading Oracle Database to release 11.2. If you must perform an in-place upgrade, then you must perform the steps listed in this section. The procedure describes how to backup the current installation, move the current installation to a new location, and then install the new software into the old location.
|
WARNING: Oracle strongly recommends that you do not upgrade Oracle Database to release 11.2.0.2 or 11.2.0.3 using the existing Oracle home. This procedure is provided only if for some reason you have no alternative but to use the existing Oracle home. |
To perform an in-place upgrade on Windows
Back up the configuration data by backing up the following directories on the single node or all cluster nodes:
ORACLE_HOME/dbs
ORACLE_HOME/database
ORACLE_HOME/network/admin
ORACLE_HOME/owb/bin/admin
ORACLE_HOME/hostname_dbname
ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_hostname_dbname
Skip this step if you are upgrading a single instance database. If you are upgrading an Oracle RAC database, then installation of the software for Oracle Database 11g Release 2 (11.2) requires that you upgrade Oracle Clusterware first. See "Considerations for Upgrading Oracle Clusterware and Oracle ASM Instances"
Shut down the instances running on ORACLE_HOME:
SQL> SHUTDOWN IMMEDIATE
|
Note: On an Oracle RAC Database, you must shut down the database instances on all nodes, and stop all interfering services on all nodes in the cluster. |
On all instances, stop the Oracle services that may interfere with this Oracle home. For example:
C:\oracle\bin\oradim –shutdown
OracleService%ORACLE_SID%
where OracleService is the name of the service, and ORACLE_SID is the SID of the database instance.
Oracle services that may need to be stopped include:
the TNSListener
HTTP server
Oracle Management Server
OLAP Agent
Intelligent Agent
|
See Also: My Oracle Support athttps://support.oracle.com:
|
|
Note: The list of services to stop is not inclusive. There may be Windows-specific and vendor-specific services running that need to be stopped. |
Run the following command on each of the nodes to detach this Oracle RAC ORACLE_HOME:
ORACLE_HOME/oui/bin/setup -detachHome ORACLE_HOME=this software location
Rename this Oracle RAC ORACLE_HOME directory on all the nodes to a temporary name.
Install release 11.2.0.3 Software Only on all nodes.
If needed, use ORADIM to create a new instance:
C:\oracle\bin\oradim –NEW -SID ORACLE_SID
where ORACLE_SID is the SID of the database instance. This will enable the instance to be listed with DBUA for upgrading.
|
See Also: Oracle Database Platform Guide for Microsoft Windows for information on creating an instance with ORADIM |
On all nodes, restore into this ORACLE_HOME software location the backed up configuration data files (from the backups you made of /dbs, /database, and network/admin), and also restore the following directories: /hostname_dbname, /owb/bin/admin, and /oc4j/j2ee/OC4J_DBConsole_hostname_dbname. Specify the actual name for hostname_dbname.
Run DBUA from this ORACLE_HOME/bin directory on the local node. If you are upgrading an Oracle RAC database, then select the 11.2.0.1.0 or 11.2.0.2.0 Oracle RAC database instance to upgrade to release 11.2.0.3.0.
|
See Also: Oracle Database Platform Guide for Microsoft Windows for information on postinstallation tasks for the database |
When invoked with the -silent command line option, DBUA operates in silent mode. In silent mode, DBUA does not present a user interface. It also writes any messages (including information, errors, and warnings) to a log file in ORACLE_HOME/cfgtoollogs/dbua/SID/upgraden, where n is the number of upgrades that DBUA has performed as of this upgrade.
To upgrade a database with DBUA in silent mode
Issue the following command
dbua -silent -sid ORCL &
where the database is named ORCL in this example.
Database Upgrade Assistant (DBUA) supports command line options when run in silent mode. Table 3-3 describes the various options and the corresponding parameters that are supported by DBUA.
|
Note: If the default Oracle Database 11g Release 2 (11.2) security settings are in place, then passwords must be at least eight characters, and passwords such aswelcome and oracle are not allowed. See Oracle Database Security Guide for more information. |
Table 3-3 DBUA Command Line Options
| Option | Description |
|---|---|
|
|
Specifies that DBUA should operate in silent mode. |
|
|
Specifies the system identifier (SID) of the database to upgrade |
|
|
Specifies the Oracle Database home directory of the database to upgrade |
|
|
Specifies the Oracle Database base directory of the database to upgrade |
|
|
Specifies the default location to store Oracle trace and diagnostic files. It replaces the initialization parameter settings for background dump destination and user dump destination from earlier releases. |
|
|
Specifies a user with |
|
|
Specifies the password for SYSDBA_user. |
|
|
Autoextends database files during the upgrade. Data files revert to their original autoextend settings after the upgrade. |
|
|
Specifies a new global database name. This option applies only if you are moving data files or upgrading an Oracle XE database. |
|
|
Specifies a new system identifier (SID) of the database to upgrade. This option applies only if you are moving data files or upgrading an Oracle XE database. |
|
|
Upgrades the tim ezone file version for the database. |
|
|
Applies only if you are moving data files or upgrading an Oracle XE database. If you specify this option, then DBUA only generates a database map file in the log location and then exits. |
|
|
Applies only if you are moving data files or upgrading an Oracle XE database. If the database to upgrade has an Oracle ASM instance, then this option tells DBUA to use it for the upgrade. |
|
|
Specifies a common location to store database files. This option applies only if you are moving data files or upgrading an Oracle XE database. |
|
|
Specifies a database area for Oracle Managed Files. This option applies only if you are moving data files or upgrading an Oracle XE database. |
|
|
Specifies the full name of the map file to map database files. This option applies only if you are moving data files or upgrading an Oracle XE database. |
|
|
Specifies the recovery area for a database that is moved during upgrade. This option applies only if you are moving data files or upgrading an Oracle XE database. |
|
|
Specifies the recovery area size (MB) for a database that is moved during upgrade. This option applies only if you are moving data files or upgrading an Oracle XE database. |
|
|
Specifies the password for the Application Express Administrator. |
|
|
Disables the detailed log generation for running SQL scripts during the upgrade process. This is enabled by default. To enable log generation, do not specify this option. |
|
|
Specifies a directory to back up your database before the upgrade starts |
|
|
Creates a new |
|
|
Specifies the complete path of the data file for creating the new |
|
|
Specifies the size of the data file for creating the new |
|
|
Specifies the next extent for the data file |
|
|
Specifies the maximum size of the data file |
|
|
Specifies a comma-delimited list of SQL scripts. Specify complete path names. The scripts are executed at the end of the upgrade. |
|
|
Specifies a comma-delimited list of initialization parameter values of the form name=value |
|
|
Turns off archiving and flashback logging for the duration of the upgrade. |
|
|
When you specify |
|
|
Specifies the number of CPUs to be used for parallel recompilation. |
-emConfiguration{CENTRAL|LOCAL|ALL|NOBACKUP|NOEMAIL|NONE} |
Specifies Oracle Enterprise Manager management options:
|
|
|
Specifies the |
|
|
Specifies the |
|
|
Specifies the |
|
|
Specifies the host user name for the Oracle Enterprise Manager backup job. This option applies only if you are configuring Oracle Enterprise Manager. |
|
|
Specifies the host user password for the Oracle Enterprise Manager backup job. This option applies only if you are configuring Oracle Enterprise Manager. |
|
|
Specifies the daily backup schedule in the form hh:mm (hours and minutes). This option applies only if you are configuring Oracle Enterprise Manager. |
|
|
Specifies the outgoing mail (SMTP) server for E-mail notifications. This option applies only if you are configuring Oracle Enterprise Manager. |
|
|
Specifies the E-mail address for E-mail notifications. This option applies only if you are configuring Oracle Enterprise Manager. |
|
|
Specifies the Oracle Enterprise Manager central agent location. This option applies only if you are configuring Oracle Enterprise Manager. |
|
|
Specifies the destination directory for all recovery files. This option applies only if you are moving data files, upgrading an Oracle XE database, or configuring Oracle Enterprise Manager. |
|
|
Specifies the local SID of the cluster database if the cluster database is not registered in the Oracle Cluster Registry |
|
|
Displays help for DBUA |
You can specify all valid options from the command line using the following syntax:
dbua [ -silent ] [ -sid SID ] [-oracleHome home_name] [-oracleBase base_name] [-diagnosticDest diagnostic_destination] [-sysDBAUserName SYSDBA_user] [-sysDBAPassword SYSDBA_pwd] [-upgradeASM] [-autoextendFiles] [-newGlobalDbName db_name] [-newSid new_SID] [-generateMapFile] [-useASM] [-commonFileLocation common_files] [-omfLocation omf_area] [-databaseMapFile map_file_name] [-newRecoveryArea recover_area] [-newRecoveryAreaSize recover_size] [-apexAdminPassword apex_pwd] [-disableUpgradeScriptLogging ] [-backupLocation directory] [-sysauxTablespace -datafileName name -datafileSize size -datafileSizeNext size -datafileSizeMax size] [-postUpgradeScripts script [, script ] ... ] [-initParam parameter=value [, parameter=value ] ... ] [-disableArchiveLogMode] [-recompile_invalid_objects true | false] [-degree_of_parallelism cpu_number] [-emConfiguration {CENTRAL|LOCAL|ALL|NOBACKUP|NOEMAIL|NONE} -dbsnmpPassword password -sysmanPassword password -asmPassword password -hostUserName hostname -hostUserPassword password -backupSchedule hh:mm [-smtpServer server_name -emailAddress address] [-centralAgent location] [-localRacSid SID]] [-recoveryAreaDestination directory] [-h|-help]
There may be cases where you need to upgrade Oracle Database manually instead of using DBUA. After installing the new Oracle Database software as described in "Installing the New Oracle Database Software for the Upgrade", backing up your database, and preparing the new Oracle home, you are ready to proceed with a manual upgrade. The procedure for manually upgrading your database assumes that you have previously run the Pre-Upgrade Information Tool as described in "Using the Pre-Upgrade Information Tool".
The following topics guide you through the process of performing a manual upgrade.
After running the Pre-Upgrade Information Tool and cleanly shutting down the instance, Oracle recommends that you back up the database as described in this section. If you encounter problems with the upgrade and wish to abandon the upgrade completely, then you must restore the database from this backup. Therefore, Oracle recommends that you back up your database now as a precaution.
To perform a full backup of the database to be upgraded
Sign on to RMAN:
rman "target / nocatalog"
Issue the following RMAN commands:
RUN
{
ALLOCATE CHANNEL chan_name TYPE DISK;
BACKUP DATABASE FORMAT 'some_backup_directory%U' TAG before_upgrade;
BACKUP CURRENT CONTROLFILE FORMAT 'controlfile location and name';
}
After backing up the database to be upgraded, prepare the new Oracle home in a new location. Do this for any release of Oracle Database for which you are upgrading, whether the database is release 11.2 or earlier. Starting with Oracle Database 11g Release 2 (11.2.0.3), you install the Oracle Grid Infrastructure and Oracle Database software into a new Oracle home instead of applying a patch set to the existing Oracle home.
To prepare the new Oracle home
Copy configuration files from the Oracle home of the database being upgraded to the new Oracle Database 11g Release 2 (11.2) Oracle home:
If your parameter file resides within the old environment's Oracle home, then copy it to the new Oracle home. By default, Oracle looks for the parameter file in the ORACLE_HOME/dbs directory on Linux or UNIX platforms and in the ORACLE_HOME\database directory on Windows operating systems. The parameter file can reside anywhere you wish, but it should not reside in the old environment's Oracle home after you upgrade to Oracle Database 11g Release 2 (11.2).
|
Note: It might be necessary to create a text initialization parameter file (PFILE) from the server parameter file (SPFILE) so that you can edit the initialization parameters. |
If your parameter file resides within an Oracle ASM instance, then back up the parameter file using the following command:
CREATE pfile FROM spfile;
If you must downgrade the database and your SPFILE resided within Oracle ASM, then the parameter file must be restored before the downgrade.
If your parameter file is a text-based initialization parameter file with either an IFILE (include file) or a SPFILE (server parameter file) entry, and the file specified in the IFILE or SPFILE entry resides within the old environment's Oracle home, then copy the file specified by the IFILE or SPFILE entry to the new Oracle home. The file specified in the IFILE or SPFILE entry contains additional initialization parameters.
If you have a password file that resides within the old environment's Oracle home, then move or copy the password file to the Oracle Database 11g Release 2 (11.2) Oracle home.
The name and location of the password file are operating system-specific. On Linux or UNIX platforms, the default password file is orapwsid, located in the ORACLE_HOME/dbs directory. On Windows operating systems, the default password file is pwdsid.ora, located in the ORACLE_HOME\database directory. In both cases, sid is your Oracle instance ID.
If you are upgrading a cluster database and your initdb_name.ora file resides within the old environment's Oracle home, then move or copy the initdb_name.ora file to the new Oracle home.
|
Note: If you are upgrading a cluster database, then perform this step on all nodes in which this cluster database has instances configured. |
If you are upgrading an Oracle Enterprise Edition database, you must copy the Enterprise Manager Database Console directory from the old Oracle Home into the new Oracle Home. Note that DBUA automatically copies and upgrades the Enterprise Manager Database Console directory.
Adjust your parameter file in Oracle Database 11g Release 2 (11.2) by completing the following steps:
Remove obsolete initialization parameters and adjust deprecated initialization parameters. Certain parameters are obsolete in Oracle Database 11g Release 2 (11.2), while other parameters have become deprecated. Remove all obsolete parameters from any parameter file that starts an Oracle Database 11g Release 2 (11.2) instance. Obsolete parameters might cause errors in Oracle Database 11g Release 2 (11.2). Also, alter any parameter whose syntax has changed in the new release.
The Pre-Upgrade Information Tool displays any deprecated parameters and obsolete parameters it finds in the Deprecated Parameters and Obsolete Parameters sections, respectively.
|
See Also: Appendix A, "Behavior Changes After Upgrading Oracle Database" for a list of initialization parameters that have been deprecated or have become obsolete, and for information on initialization parameters that have changed in ways that raise compatibility issues between different releases of Oracle Database software |
Make sure the COMPATIBLE initialization parameter is properly set for Oracle Database 11g Release 2 (11.2). The Pre-Upgrade Information Tool displays a warning in the Database section if COMPATIBLE is not properly set.
Adjust the values of the initialization parameters to at least the minimum values indicated by the Pre-Upgrade Information Tool.
Make sure all path names in the parameter file are fully specified. You should not have relative path names in the parameter file.
If the parameter file contains an IFILE entry, then change the IFILE entry in the parameter file to point to the new location of the include file that you specified in Step 1. c. Then, edit the file specified in the IFILE entry in the same way that you edited the parameter file in Step a through Step d.
If you are upgrading a cluster database, then modify the initdb_name.ora file in the same way that you modified the parameter file.
Make sure you save all of the files you modified after making these adjustments.
|
Note: If you are upgrading a cluster database, then perform this step on all nodes in which this cluster database has instances configured. |
If you are upgrading a cluster database, then set the CLUSTER_DATABASE initialization parameter to false. After the upgrade, you must set this initialization parameter back to TRUE.
After installing the new Oracle Database software as described in "Installing the New Oracle Database Software for the Upgrade" and preparing the new Oracle home as described in "Preparing the New Oracle Home for a Manual Upgrade", you are ready to proceed with the manual upgrade.
To manually upgrade the database
Shut down the instance:
SQL> SHUTDOWN IMMEDIATE
If your operating system is Windows, then complete the following steps:
Stop the OracleServiceSID Oracle service of the database you are upgrading, where SID is the instance name. For example, if your SID is ORCL, then enter the following at a command prompt:
C:\> NET STOP OracleServiceORCL
Delete the Oracle service at a command prompt using ORADIM.
If your SID is ORCL, then enter the following command:
C:\> ORADIM -DELETE -SID ORCL
Create the Oracle Database 11g Release 2 (11.2) service at a command prompt using the ORADIM command of the new Oracle Database release:
C:\> ORADIM -NEW -SID SID -SYSPWD PASSWORD -MAXUSERS USERS -STARTMODE AUTO -PFILE ORACLE_HOME\DATABASE\INITSID.ORA
This syntax includes the following variables:
| Variable | Description |
|---|---|
SID | The same SID name as the SID of the database you are upgrading. |
PASSWORD | The password for the new Oracle Database 11g Release 2 (11.2) database instance. This is the password for the user connected with SYSDBA privileges. The -SYSPWD option is not required. If you do not specify it, then operating system authentication is used, and no password is required.
If the default Oracle Database 11g Release 2 (11.2) security settings are in place, then passwords must be at least eight characters, and passwords such as |
USERS | The maximum number of users who can be granted SYSDBA and SYSOPER privileges. |
ORACLE_HOME | The Oracle Database 11g Release 2 (11.2) Oracle home directory. Ensure that you specify the full path name with the -PFILE option, including the drive letter of the Oracle home directory. |
For example, if your SID is ORCL, your password (SYSPWD) is TWxy5791, the maximum number of users (MAXUSERS) is 10, and the ORACLE_HOME directory is C:\ORACLE\PRODUCT\11.2.0\DB, then enter the following command:
C:\> ORADIM -NEW -SID ORCL -SYSPWD TWxy5791 -MAXUSERS 10 -STARTMODE AUTO -PFILE C:\ORACLE\PRODUCT\11.2.0\DB\DATABASE\INITORCL.ORA
ORADIM writes a log file to the ORACLE_HOME\database directory.
If your operating system is Linux or UNIX, then perform the following checks:
Your ORACLE_SID is set correctly
The oratab file points to your Oracle Database 11g Release 2 (11.2) Oracle home
The following environment variables point to the Oracle Database 11g Release 2 (11.2) directories:
ORACLE_HOME
PATH
Any scripts that clients use to set the ORACLE_HOME value must point to the new Oracle home.
|
Note: If you are upgrading a cluster database, then perform these checks on all nodes on which this cluster database has instances configured. |
|
See Also: Oracle Database Installation Guide for your operating system-specific Oracle Database procedures for information about setting other important environment variables on your operating system |
If there is a different user and group for Grid Infrastructure and Oracle Database, then run the setasmgidwrap script, which is located in the GRID_HOME/bin directory, against the new ORACLE_HOME/bin/oracle directory with the -o option as shown in the following example:
$GRID_HOME/bin/setasmgidwrap o=ORACLE_HOME/bin/oracle
Log in to the system as the owner of the Oracle Database 11g Release 2 (11.2) Oracle home directory.
At a system prompt, change to the ORACLE_HOME/rdbms/admin directory.
Start SQL*Plus.
Connect to the database instance as a user with SYSDBA privileges.
Start the instance by issuing the following command:
SQL> STARTUP UPGRADE
|
Note: TheUPGRADE keyword enables you to open a database based on an earlier Oracle Database release. It also restricts logons to AS SYSDBA sessions, disables system triggers, and performs additional operations that prepare the environment for the upgrade. |
You might be required to use the PFILE option to specify the location of your initialization parameter file.
Once the database is started in upgrade mode, only queries on fixed views execute without errors until after the catupgrd.sql script is run. Before running catupgrd.sql, queries on any other view or the use of PL/SQL returns an error.
The following are common errors that might occur when attempting to start the new Oracle Database 11g Release 2 (11.2) database. Some of these errors are written to the alert log and not to your session. If you receive any of these errors, then issue the SHUTDOWN ABORT command to shut down the database and correct the problem.
ORA-00401: the value for parameter compatible is not supported by this release
The COMPATIBLE initialization parameter is set to a value less than 10.0.0.
ORA-39701: database must be mounted EXCLUSIVE for UPGRADE or DOWNGRADE
The CLUSTER_DATABASE initialization parameter is set to TRUE instead of FALSE.
ORA-39700: database must be opened with UPGRADE option
The STARTUP command was issued without the UPGRADE keyword.
ORA-00336: log file size xxxx blocks is less than minimum 8192 blocks
A redo log file size is less than 4 MB:
If errors appear listing obsolete initialization parameters, then make a note of the obsolete initialization parameters and continue with the upgrade. Remove the obsolete initialization parameters the next time you shut down the database.
Perform this step only if you are upgrading from Oracle9i Release 2 (9.2). Otherwise, skip to the next step.
Create a SYSAUX tablespace. In the new Oracle Database 11g release, the SYSAUX tablespace is used to consolidate data from a number of tablespaces that were separate in previous releases.
The SYSAUX tablespace must be created with the following mandatory attributes:
ONLINE
PERMANENT
READ WRITE
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO
Table 3-4 can be used to determine an optimal size for the SYSAUX tablespace. Also, the Pre-Upgrade Information Tool provides an estimate of the minimum required size for the SYSAUX tablespace under the SYSAUX Tablespace section.
Table 3-4 Guidelines for Sizing the SYSAUX Tablespace
| Factor | Small | Medium | Large |
|---|---|---|---|
|
Number of CPUs |
2 |
8 |
32 |
|
Number of concurrently active sessions |
5 |
20 |
100 |
|
Number of user objects (tables and indexes) |
500 |
5,000 |
50,000 |
|
Estimated SYSAUX size at steady state with default configuration |
500 MB |
2 GB |
5 GB |
The following SQL statement would create a 500 MB SYSAUX tablespace for the database:
SQL> CREATE TABLESPACE sysaux DATAFILE 'sysaux01.dbf'
SIZE 500M REUSE
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO
ONLINE;
Set the system to spool results to a log file for later verification of success:
SQL> SPOOL upgrade.log
SQL> @catupgrd.sql
The catupgrd.sql script determines which upgrade scripts must be run, runs them, and then shuts down the database. You must run the script in the Oracle Database 11g Release 2 (11.2) environment.
The upgrade script creates and alters certain data dictionary tables. It also upgrades or installs the following database components in the new Oracle Database 11g Release 2 (11.2) database:
Oracle Database Catalog Views
Oracle Database Packages and Types
JServer JAVA Virtual Machine
Oracle Database Java Packages
Oracle XDK
Oracle Real Application Clusters
Oracle Workspace Manager
Oracle Multimedia
Oracle XML Database
OLAP Analytic Workspace
Oracle OLAP API
OLAP Catalog
Oracle Text
Spatial
Oracle Data Mining
Oracle Label Security
Messaging Gateway
Oracle Expression Filter
Oracle Rules Manager
Oracle Enterprise Manager Repository
Oracle Database Vault
Oracle Application Express
|
Note: If you did not run the Pre-Upgrade Information Tool, thecatupgrd.sql script terminates with one of the following errors:
ORA-00942: table or view does not exist ORA-00904: "TZ_VERSION": invalid identifier ORA-01722: invalid number If you receive any of these errors, issue the |
Restart the instance to reinitialize the system parameters for normal operation.
SQL> STARTUP
This restart, following the database shutdown performed as part of the catupgrd.sql script, flushes all caches, clears buffers, and performs other housekeeping activities. These measures are an important final step to ensure the integrity and consistency of the newly upgraded Oracle Database software.
If you encountered a message listing obsolete initialization parameters when you started the database in Step 9, then remove the obsolete initialization parameters from the parameter file before restarting. If necessary, convert the SPFILE to a PFILE so you can edit the file to delete parameters. See the chapter about managing initialization parameters using a server parameter file in Oracle Database Administrator's Guide.
Run utlu112s.sql, the Post-Upgrade Status Tool, which provides a summary of the upgrade at the end of the spool log. Starting with release 11.2.0.3, ou can run utlu112s.sql any time after completing the upgrade. See "About the Post-Upgrade Status Tool" for more information.
Run utlu112s.sql to display the results of the upgrade as follows:
SQL> @utlu112s.sql
If the Post-Upgrade Status Tool returns errors or shows components that are not VALID or not the most recent release, then see "Troubleshooting the Upgrade of Oracle Database" for more information.
Run catuppst.sql to perform upgrade actions that do not require the database to be in UPGRADE mode:
SQL> @catuppst.sql
This may generate the following informational messages:
Generating apply and rollback scripts... Check the following file for errors: Apply script: .* Rollback script: .* Executing script file... Updating registry... Check the following log file for errors: Generating apply and rollback scripts... Check the following file for errors: .../cfgtoollogs/catbundle/catbundle_PSU_*.log Apply script: .../rdbms/admin/catbundle_PSU_*_APPLY.sql Rollback script: .../rdbms/admin/catbundle_PSU_*_ROLLBACK.sql Executing script file... Updating registry... Check the following log file for errors: .../cfgtoollogs/catbundle/catbundle_PSU_*.log
Run utlrp.sql to recompile any remaining stored PL/SQL and Java code.
SQL> @utlrp.sql
Verify that all expected packages and classes are valid:
SQL> SELECT count(*) FROM dba_invalid_objects; SQL> SELECT distinct object_name FROM dba_invalid_objects;
|
Note: If the pre-upgrade information tool detectedINVALID objects and populated the registry$sys_inv_objs and registry$nonsys_inv_objs tables, then execute ORACLE_HOME/rdbms/admin/utluiobj.sql to display only those objects which are newly invalid because of the upgrade process. The utluiobj.sql script only displays objects that are now INVALID but which were VALID before the upgrade. |
Exit SQL*Plus.
If you are upgrading a cluster database from releases 10.2, 11.1, or 11.2, then upgrade the database configuration in Oracle Clusterware using the following command:
$ srvctl upgrade database -d db-unique-name -o oraclehome
where db-unique-name is the database name assigned to it (not the instance name), and oraclehome is the Oracle home location in which the database is being upgraded.
Your database is now upgraded to the new Oracle Database 11g release. You are ready to complete the procedures described in Chapter 4, "Post-Upgrade Tasks for Oracle Database".
|
Note: Oracle Warehouse Builder components are not upgraded as part of thecatupgrd.sql script and, therefore, its version will not be updated during the upgrade process. |
|
Caution: If you retain the old Oracle software, then never start the upgraded database with the old software. Only start the database with the executables in the new Oracle Database installation. Also, before you remove the old Oracle environment, make sure you relocate any data files in that environment to the new Oracle Database environment. See the Oracle Database Administrator's Guide for information about relocating data files. |
The Post-Upgrade Status Tool, which is the utlu112s.sql script, displays the status of the database components in the upgraded database and the time required to complete each component upgrade. Any errors that occur during the upgrade are listed with each component and must be addressed. The utlu112s.sql script can be run any time after you run catupgrd.sql, but not after running utlrp.sql.
The Post-Upgrade Status Tool displays a report similar to the following output:
Oracle Database 11.2 Post-Upgrade Status Tool 07-12-2011 12:36:25 . Component Current Version Elapsed Time Name Status Number HH:MM:SS . Oracle Server . VALID 11.2.0.3.0 00:04:47 JServer JAVA Virtual Machine . VALID 11.2.0.3.0 00:01:05 Oracle Workspace Manager . VALID 11.2.0.3.0 00:00:18 OLAP Analytic Workspace . VALID 11.2.0.3.0 00:00:07 OLAP Catalog . VALID 11.2.0.3.0 00:00:21 Oracle OLAP API . VALID 11.2.0.3.0 00:00:12 Oracle Label Security . VALID 11.2.0.3.0 00:00:02 Oracle Enterprise Manager . VALID 11.2.0.3.0 00:00:50 Oracle XDK . VALID 11.2.0.3.0 00:00:19 Oracle Text . VALID 11.2.0.3.0 00:00:11 Oracle XML Database . VALID 11.2.0.3.0 00:01:04 Oracle Database Java Packages . VALID 11.2.0.3.0 00:00:07 Oracle Multimedia . VALID 11.2.0.3.0 00:01:25 Spatial . VALID 11.2.0.3.0 00:00:50 Oracle Expression Filter . VALID 11.2.0.3.0 00:00:04 Oracle Rules Manager . VALID 11.2.0.3.0 00:00:02 Oracle Application Express . VALID 3.2.1.00.10 Oracle Database Vault . VALID 11.2.0.3.0 00:00:02 Gathering Statistics . 00:00:36 Total Upgrade Time: 00:12:30
Oracle provides troubleshooting tips and workarounds for problems and errors that may occur during the upgrade process for Oracle Database. Also, be sure to check Oracle Database Readme.
This section contains the following topics:
Running the DBMS_DST Package After Upgrade Can Result in ORA-01822
DBUA May Mark Invalid Components with an X Before Entire Upgrade is Done
You may need to keep the old Oracle Home for a while after a successful upgrade. However, after you have tested the newly upgraded Oracle database, you will need to remove the old Oracle Home.
As the clusterware user on all nodes, enter the following SQL*Plus commands.
Detach OLD_HOME (where OLD_HOME is your pre-upgrade Oracle Home:
$OLD_HOME/oui/bin/runInstaller -detachHome -silent -local
Confirm OLD_HOME is removed from central inventory:
$OLD_HOME/OPatch/opatch lsinventory -all
Remove files in OLD_HOME manually:
/bin/rm -rf $OLD_HOME
If you run out of resources, such as disk space or memory, during the upgrade of Oracle Database, then increase the resource allocation. After increasing the resource allocation, you should perform a SHUTDOWN ABORT and restart the instance (in UPGRADE mode) before rerunning the catupgrd.sql script or restarting DBUA.
The resources that generally require increases for a new Oracle Database release are as follows:
SYSTEM and SYSAUX tablespaces
Typically you receive one of the following messages during the upgrade if your SYSTEM tablespace size is insufficient:
ORA-01650: unable to extend rollback segment string by string in tablespace string ORA-01651: unable to extend save undo segment by string for tablespace string ORA-01652: unable to extend temp segment by string in tablespace string ORA-01653: unable to extend table string.string by string in tablespace string ORA-01654: unable to extend index string.string by string in tablespace string ORA-01655: unable to extend cluster string.string by string in tablespace string
To avoid these errors, set AUTOEXTEND ON MAXSIZE UNLIMITED for the SYSTEM and SYSAUX tablespaces.
Shared memory
You might require larger shared memory pool sizes in some cases. The error message indicates which shared memory initialization parameter must be increased.
ORA-04031: unable to allocate string bytes of shared memory ("string","string","string","string")
Rollback segments/undo tablespace
If you are using rollback segments, then you must have a single large (100 MB) PUBLIC rollback segment online while the upgrade scripts are being run. Smaller public rollback segments should be taken offline during the upgrade. Typically you get the following error if your rollback segment size is insufficient:
ORA-01562: failed to extend rollback segment number string
If you are using an undo tablespace, then be sure it is at least 400 MB.
Flash Recovery Area
If you are using a Flash Recovery Area and it fills up during the upgrade, then the following error appears in the alert log, followed by suggestions for recovering from the problem:
ORA-19815: WARNING: db_recovery_file_dest_size of string bytes is 98.99% used, and has string remaining bytes available.
Identify the root cause of the problem and take appropriate actions to proceed with the upgrade. To avoid issues during the upgrade, increase the amount of space available in your Flash Recovery Area before starting the upgrade.
If you see error ORA-00723, "Initialization parameter COMPATIBLE must be explicitly set," when attempting to open a database in the new Oracle home in upgrade mode, then check that COMPATIBLE is set in the pfile or spfile.
|
See Also: "Setting the COMPATIBLE Initialization Parameter" for information about setting theCOMPATIBLE initialization parameter |
If an upgrade script or command running in SQL*Plus set the EDITION parameter, then Oracle Database cannot start properly afterwards and error SP2-1540: "Oracle Database cannot startup in an Edition session" is thrown. To avoid this problem, after running catugrd.sql or any SQL*Plus session where this parameter is changed, exit the SQL*Plus session and restart the instance in a different session.
The ORA-01408 error is a known problem with Oracle Application databases. The workaround addresses the following scenario:
SQL> Create Index system.repcat$_audit_column_f2_idx ON
2 system.repcat$_audit_column(base_sname,base_oname,base_conflict_type_id,
3 base_reference_name)
4 /
system.repcat$_audit_column(base_sname,base_oname,base_conflict_type_id,
*ERROR at line 2:
ORA-01408: such column list already indexed
The workaround is to drop the REPCAT$_AUDIT_COLUMN_IDX1 index and rerun the upgrade as described in "Rerunning the Upgrade for Oracle Database".
Running the DBMS_DST package after upgrading to Oracle Database 11g Release 2 (11.2) can result in the ORA-01882: time zone region not found error.
This error is returned if the user sets the time zone file version incorrectly, which results in the region IDs of several time zone regions being stored incorrectly in the database. For example:
ERROR at line 1: @ ORA-01882: time zone region not found @ ORA-06512: at "SYS.DBMS_DST", line 113 @ ORA-06512: at "SYS.DBMS_DST", line 1101 @ ORA-06512: at line 1
To fix this problem, update the time zone version as described in "About Warnings for TIMESTAMP WITH TIME ZONE Data Type" and rerun the upgrade as described in "Rerunning the Upgrade for Oracle Database".
The Post-Upgrade Status Tool should report VALID status for all components at the end of the upgrade. The following list shows and briefly describes other status values that you might see:
NO SCRIPT
The component upgrade script was not found in ORACLE_HOME. Check the install logs, install the component software, and then rerun catupgrd.sql.
OPTION OFF
The server option required for the component was not installed or was not linked with the server. Check the V$OPTION view as well as the install logs. Install the component or relink the server with the required option, and then rerun catupgrd.sql.
REMOVED
The component was not upgraded because it was removed from the database.
INVALID
Some objects for the component were invalid at the completion of the upgrade. If there were no errors during the component upgrade, then running utlrp.sql might change the status to VALID without rerunning the entire upgrade. Check the DBA_REGISTRY view after running utlrp.sql.
UPGRADING
The component upgrade did not complete. Resolve the problem and rerun catupgrd.sql.
DBUA may mark invalid components with an X on the Upgrade Progress window as the upgrade is progressing. An invalid component could be re-validated after a recompile is performed. Please check the final component status on the Upgrade Result page in DBUA after utlrp.sql recompiles have been run.
You can rerun the upgrade with the catupgrd.sql script as described in the following steps.
To rerun the upgrade
Shut down the database as follows:
SQL> SHUTDOWN IMMEDIATE
Restart the database in UPGRADE mode:
SQL> STARTUP UPGRADE
Set the system to spool results to a log file for later verification of success:
SQL> SPOOL upgrade.log
Rerun catupgrd.sql:
SQL> @catupgrd.sql
|
Note: You can rerun thecatupgrd.sql script as many times as necessary. The first time you run the script, there should be no error messages returned. If you rerun the script, then the ORA-00001 message is displayed. You can safely ignore this message. |
Rerun utlu112s.sql:
SQL> @utlu112s.sql
If you completed the steps in "Backing Up Oracle Database for a Manual Upgrade" to back up your database, then the easiest way to cancel the upgrade is to restore that backup as described in the following procedure.
To cancel the upgrade by restoring the previous backup
Log in to the system as the owner of the Oracle home directory of the previous release.
Sign on to RMAN:
rman "target / nocatalog"
Issue the following RMAN commands:
STARTUP NOMOUNT
RUN
{
RESTORE CONTROLFILE FROM 'save_controlfile_location';
ALTER DATABASE MOUNT;
RESTORE DATABASE FROM TAG before_upgrade
ALTER DATABASE OPEN RESETLOGS;
}
The recommended practice for upgrading Oracle ASM is to upgrade an Oracle ASM instance with the Oracle Universal Installer (OUI) executable file that is located in the Oracle Grid Infrastructure home directory. OUI automatically defaults to upgrade mode when it detects an Oracle ASM instance at an earlier release level.
Oracle ASM Configuration Assistant enables you to upgrade an existing Oracle ASM instance to the current software level and upgrade an older Oracle ASM instance to the latest Oracle Grid Infrastructure home.
You can upgrade an Oracle ASM instance to an Oracle Restart 11g release 2 (11.2) configuration. The recommended practice is to upgrade an Oracle ASM instance with Oracle Universal Installer (OUI).
You can also perform a rolling upgrade to clustered Oracle ASM instances in environments running Oracle Database 11g or later.
|
See Also:
|
Oracle Database can only be downgraded to the release from which you upgraded. For example, if you upgrade from Oracle Database 10g Release 1 (10.1.0.5) to Oracle Database 11g Release 2 (11.2), then you cannot subsequently downgrade to Oracle Database 10g Release 2 (10.2); you can only downgrade to Oracle Database 10g Release 1 (10.1.0.5).
This chapter contains the following topics:
|
See Also: Oracle Database Installation Guide for your operating system for discussions of downgrading that are operating system-specific |
You can downgrade both major releases and patchset releases, based on the original release from which the database was upgraded. Major release downgrades are supported back to Oracle Database 11g Release 1 (11.1.0.6), Oracle Database 10g Release 2 (10.2.0.2), and Oracle Database 10g Release 1 (10.1.0.5). Patchset downgrades are supported back to all prior 11.2 patch releases.
|
Note: You cannot downgrade a database that was upgraded from Oracle Database Express Edition. |
If you have Oracle Database Vault installed with your Oracle Database 11g Release 2 (11.2) database, then you can downgrade to release 11.1.0.6 and release 11.1.0.7 only.
If you have Messaging Gateway or Workspace Manager in your database, then be aware that neither of them are part of Oracle Database patchsets earlier than release 10.2.0.4. Therefore, you must separately apply all relevant patches to the release 10.2.0.3 or release 10.1.0.5 Oracle home before downgrading.
Downgrade is not supported for Oracle Enterprise Manager. However, if you save your Oracle Enterprise Manager Database Control files and data before upgrading your database, then you can restore the old version of Database Control after downgrading the database.
Check the compatibility level of your release of Oracle Database to see if the database might have incompatibilities that prevent you from downgrading. If the compatibility level of your Oracle Database 11g Release 2 (11.2) database is 11.2.0 or higher, then you cannot downgrade.
If you are downgrading to Oracle Database 11g Release 1 (11.1), then the COMPATIBLE initialization parameter must be set to 11.0.0 or lower.
If you are downgrading to Oracle Database 10g Release 2 (10.2), then the COMPATIBLE initialization parameter must be set to 10.2.0 or lower.
If you are downgrading to Oracle Database 10g Release 1 (10.1), then the COMPATIBLE initialization parameter must be set to 10.1.0.
Perform a full backup of your Oracle Database 11g Release 2 (11.2) database before you downgrade. Follow the procedures given in Oracle Database Backup and Recovery User's Guide.
You can downgrade your Oracle Database 11g Release 2 (11.2) database to a major release or a relevant patchset upgrade.
To downgrade the database to an earlier release
If you have enabled Oracle Database Vault on your database, then you must:
Grant the Database Vault DV_PATCH_ADMIN role for the SYS account.
Disable Database Vault before downgrading the database.
|
See Also: Oracle Database Vault Administrator's Guide for instructions about disabling Oracle Database Vault |
If you previously had upgraded the database and then used the DBMS_DST PL/SQL package to update the database time zone version, then you must apply the patch for the same time zone file version into the earlier release's Oracle home before downgrading.
As an example scenario, assume that a release 10.2.0.4 database on Linux x64 using DSTv4 had been upgraded to release 11.2.0.2, and DBMS_DST was then run to update this database to DSTv14. Then, before downgrading from release 11.2.0.3 to 10.2.0.4, you need to apply on the release 10.2.0.4 side the DSTv14 patch for 10.2.0.4 for Linux x64. This ensures that your TIMESTAMP WITH TIME ZONE data is not logically corrupted during retrieval.
To find which time zone file version your database is using, run:
SELECT value$ FROM sys.props$ WHERE NAME = 'DST_PRIMARY_TT_VERSION';
If you had set the ORA_TZFILE environment variable to the full path name of the timezone.dat file when you upgraded to Oracle Database 11g Release 2 (11.2), then you must unset it if you subsequently downgrade your database.
Two time zone files are included in the Oracle home directory:
The default time zone file at
$ORACLE_HOME/oracore/zoneinfo/timezonelrg.dat
A smaller time zone file at
$ORACLE_HOME/oracore/zoneinfo/timezone.dat
If you do not unset the ORA_TZFILE variable, then connecting to the database using the smaller time zone file might produce the following errors:
SP2-1503: Unable to initialize Oracle call interface SP2-0152: ORACLE may not be functioning properly
|
See Also: Oracle Database Globalization Support Guide for more information about date and time data types and time zone support |
If you have Oracle Application Express on your database, then you must copy the apxrelod.sql file from the Oracle Database 11g Release 2 (11.2) ORACLE_HOME/apex/ directory to a directory outside of the Oracle home, such as the temporary directory on your system.
Make a note of the new location of this file.
If you have created objects based on fixed objects, then drop these objects to avoid possible ORA-00600 errors. You can re-create these objects after the downgrade.
Log in to the system as the owner of the Oracle Database 11g Release 2 (11.2) Oracle home directory.
This step is required only if Enterprise Manager Database Control is already configured for the database.
Stop Database Control, as follows:
Set the ORACLE_UNQNAME environment variable to the database unique name.
Run the following command:
ORACLE_HOME/bin/emctl stop dbconsole
If the database being downgraded is an Oracle RAC database, then perform this step on all instances.
If you are downgrading an Oracle RAC database to 10g Release 1 (10.1), then you must remove extra voting disks before shutting down the Oracle Clusterware stack.
To see the number of voting disks used and to list voting disk paths, run the following command:
Oracle_Clusterware_Home/bin/crsctl query css votedisk
Remove each additional voting disk you find in the previous step by running the following command, where path is the voting disk path listed in the File Name column displayed in the previous step:
Oracle_Clusterware_Home/bin/crsctl delete css votedisk path
For example:
Oracle_Clusterware_Home/bin/crsctl delete css votedisk /share/cluster2/vote_cluster2.dbf
Do not delete the last voting disk.
At a system prompt, change to the ORACLE_HOME/rdbms/admin directory.
|
Note: If you are downgrading a cluster database, then shut down the instance completely and change theCLUSTER_DATABASE initialization parameter to FALSE. After the downgrade, you must set this parameter back to TRUE. |
Using SQL*Plus, connect to the database instance as a user with SYSDBA privileges.
Start up the instance in DOWNGRADE mode:
SQL> STARTUP DOWNGRADE
You might be required to use the PFILE option to specify the location of your initialization parameter file.
If you have Enterprise Manager configured in your database, then drop the Enterprise Manager user:
DROP USER sysman CASCADE;
|
Note: After this step, MGMT* synonyms may be invalid. Follow the guidelines in "Restoring Oracle Enterprise Manager after Downgrading Oracle Database" to validate the synonyms. |
Set the system to spool results to a log file so you can track the changes and issues:
SQL> SPOOL downgrade.log
SQL> @catdwgrd.sql
The following are notes about running the script:
You must use the version of the script included with Oracle Database 11g Release 2 (11.2).
You must run the script in the Oracle Database 11g Release 2 (11.2) environment.
The script downgrades all Oracle Database components in the database to the major release or Oracle Database 11g patch release from which you originally upgraded.
If you encounter any problems when you run the script, or any of the scripts in the remaining steps, then correct the causes of the problems and rerun the script. You can rerun any of the scripts described in this chapter as many times as necessary.
If the downgrade for a component fails, then an ORA-39709 error is displayed and the SQL*Plus session terminates without downgrading the Oracle Database data dictionary. All components must be successfully downgraded before the Oracle Database data dictionary is downgraded. You must identify and fix the problem before rerunning the catdwgrd.sql script.
Turn off the spooling of script results to the log file:
SQL> SPOOL OFF
Then, check the spool file and verify that there were no errors generated during the downgrade. You named the spool file in Step 13 and the suggested name was downgrade.log. Correct any problems you find in this file and rerun the downgrade script if necessary.
|
Note: If you want to save the results of the first time you ran the downgrade script, then before you rerun it be sure to renamedowngrade.log to something else. |
Shut down the instance:
SQL> SHUTDOWN IMMEDIATE
Exit SQL*Plus.
If your operating system is Linux or UNIX, then change the following environment variables to point to the directories of the release to which you are downgrading:
ORACLE_HOME
PATH
You should also check that your oratab file and any client scripts that set the value of ORACLE_HOME point to the downgraded Oracle home.
|
See Also: Oracle Database Installation Guide for your operating system for information about setting other important environment variables on your operating system |
If your operating system is Windows, then complete the following steps:
Stop all Oracle services, including the OracleServiceSID Oracle service of the Oracle Database 11g Release 2 (11.2) database, where SID is the instance name.
For example, if your SID is ORCL, then enter the following at a command prompt:
C:\> NET STOP OracleServiceORCL
Delete the Oracle service at a command prompt by issuing the ORADIM command. For example, if your SID is ORCL, then enter the following command:
C:\> ORADIM -DELETE -SID ORCL
Create the Oracle service of the database that you are downgrading at a command prompt using the ORADIM command.
C:\> ORADIM -NEW -SID SID -INTPWD PASSWORD -MAXUSERS USERS -STARTMODE AUTO -PFILE ORACLE_HOME\DATABASE\INITSID.ORA
This syntax includes the following variables:
| Variable | Description |
|---|---|
SID | Same SID name as the SID of the database being downgraded. |
PASSWORD | Password for the database instance. This is the password for the user connected with SYSDBA privileges. The -INTPWD option is not required. If you do not specify it, then operating system authentication is used, and no password is required. |
USERS | Maximum number of users who can be granted SYSDBA and SYSOPER privileges. |
ORACLE_HOME | Oracle home directory of the database to which you are downgrading. Ensure that you specify the full path name with the -PFILE option, including drive letter of the Oracle home directory. |
For example, if you are downgrading to Oracle Database 10g Release 2 (10.2), if your SID is ORCL, your PASSWORD is TWxy5791, the maximum number of USERS is 10, and the ORACLE_HOME directory is C:\ORANT, then enter the following command:
C:\> ORADIM -NEW -SID ORCL -INTPWD TWxy5791 -MAXUSERS 10
-STARTMODE AUTO -PFILE C:\ORANT\DATABASE\INITORCL.ORA
|
Note: You are not required to change any Windows Registry settings when downgrading a database. TheORADIM utility makes all necessary changes automatically. |
Restore the configuration files (for example, parameter files, password files, and so on) of the release to which you are downgrading.
If this is an Oracle RAC database, execute the following command to return the database to single instance mode:
SET CLUSTER_DATABASE=FALSE
|
Note: If you are downgrading a cluster database, then perform this step on all nodes in which this cluster database has instances configured. Set theCLUSTER_DATABASE initialization parameter to FALSE. After the downgrade, you must set this initialization parameter back to TRUE. |
At a system prompt, change to the ORACLE_HOME/rdbms/admin directory of the previous release.
Start SQL*Plus.
Connect to the database instance as a user with SYSDBA privileges.
Start up the instance:
SQL> STARTUP UPGRADE
Set the system to spool results to a log file to track changes and issues:
SQL> SPOOL reload.log
Run catrelod.sql:
SQL> @catrelod.sql
The catrelod.sql script reloads the appropriate version of all of the database components in the downgraded database.
If you are downgrading to Oracle Database 11g Release 1 (11.1.0.6), run the xsrelod.sql script:
SQL> @xsrelod.sql
Running the xsrelod.sql script avoids the following error:
PLS-00306: wrong number or types of arguments in call to 'INVALIDATE_DSD_CACHE' DBMS_XS_DATA_SECURITY_EVENTS PL/SQL: Statement ignored
|
Note: The PLS-00306 error is not an issue for Oracle Database release 11.2.0.7 or later. |
If you are downgrading to Oracle Database 10g Release 1 (10.1.0.5) and you have XDB in your database, then run the dbmsxdbt.sql script:
@dbmsxdbt.sql
Running the dbmsxdbt.sql script avoids the following errors when reloading XDB.DBMS_XDBT package:
PLS-00201: identifier 'CTXSYS.CTX_OUTPUT' must be declaredPLS-00201: identifier 'CTX_DDL' must be declared
If you are downgrading to Oracle Database 11g Release 1 or earlier, and you have Oracle Application Express in your database, then change to the directory to which you had copied the apxrelod.sql script (in step 4). Manually reload Oracle Application Express by running the apxrelod.sql script:
SQL> @apxrelod.sql
Running the apxrelod.sql script avoids package APEX_030200.WWV_FLOW_HELP being INVALID due to the following error:
PLS-00201: identifier 'CTX_DDL' must be declared
Turn off the spooling of script results to the log file:
SQL> SPOOL OFF
Then, check the spool file and verify that the packages and procedures compiled successfully. You named the spool file in Step 25; the suggested name was reload.log. Correct any problems you find in this file and rerun the appropriate script if necessary.
Shut down and restart the instance for normal operation:
SQL> SHUTDOWN IMMEDIATE SQL> STARTUP
You might be required to use the PFILE option to specify the location of your initialization parameter file.
Perform this step if the database is configured for Oracle Label Security and you are downgrading to Oracle Database 10g Release 1 (10.1).
Copy the olstrig.sql script from the Oracle Database 11g Release 2 (11.2) Oracle home to the Oracle home of the version to which the database is to be downgraded.
Run olstrig.sql to re-create DML triggers on tables with Oracle Label Security policies.
SQL> @olstrig.sql
See the Oracle Label Security Administrator's Guide for more information.
Run the utlrp.sql script:
SQL> @utlrp.sql
The utlrp.sql script recompiles all existing PL/SQL modules that were previously in an INVALID state, such as packages, procedures, types, and so on.
Exit SQL*Plus.
If you are downgrading a cluster database, then you must run the following command to downgrade the Oracle Clusterware database configuration:
$ srvctl downgrade database -d db-unique-name -o old_ORACLE_HOME -t to_relnum
[where db-unique-name is the database name (not the instance name), old_ORACLE_HOME is the location of the old Oracle home in which the downgraded database will be running. In this example, to_relnum is the database release number to which the database is being downgraded. (For example: 11.2.0.1.0.)]
|
Caution: By default, any named user may create a server pool. To restrsQict the operating system users that have this privilege, Oracle strongly recommends that you add specific users to the CRS Administrators list.See Also: Oracle Clusterware Administration and Deployment Guide for more information about adding users to the CRS Administrators list |
|
Note: Execute this command from the current Oracle home, not from the Oracle home to which the database is being downgraded. |
Your database is now downgraded.
Tasks might be required after downgrading Oracle Database. This section contains the following topics:
Re-creating the Network Listener When Downgrading to Oracle Database Releases 10.2 or 11.1
Restoring Oracle Enterprise Manager after Downgrading Oracle Database
Re-enabling Oracle Database Vault after Downgrading Oracle Database
Restoration of the Configuration for Oracle Clusterware after Downgrading
If you are downgrading the new database to Oracle Database 10g or Oracle Database 11g Release 1, then you must recreate the listener after performing the downgrade steps. Run Oracle Net Manager to delete the old listener and create a new listener.
To start Oracle Net Manager from the Oracle Enterprise Manager console, select Service Management from the Tools menu, and then select Oracle Net Manager.
On Microsoft Windows, select Programs from the Start menu, and then select Oracle - HOME_NAME. Next, select Configuration and Migration Tools, and then Net Manager.
This task is required only if you are downgrading in some form and Oracle Enterprise Manager is configured on the host. To restore Oracle Enterprise Manager to its previous state, you must have saved your Oracle Enterprise Manager files and data before upgrading.
If this is an Oracle RAC database using Oracle Clusterware, the database must be registered with the srvctl before running the emca -restore command. This needs to be executed from the ORACLE_HOME/bin of the version to which the database is being downgraded.
Run the emca -restore command with the appropriate options to restore Oracle Enterprise Manager Database Control or Grid Control to the old Oracle home. The options that you specify depend on whether the database being downgraded is an Oracle RAC database or an Oracle ASM database, as follows:
|
Note: Use the Oracle Database 11g Release 2 (11.2) version ofemca for this procedure. See Oracle Database Administrator's Guide for complete information about emca. |
Single-Instance Oracle Database Without Oracle ASM
111Home/bin/emca -restore db
You are prompted to enter the following information:
Oracle home for the database to be restored
Database SID
Listener port number
Oracle RAC Database Without Oracle ASM
111Home/bin/emca -restore db -cluster
You are prompted to enter the following information:
Oracle home for the database to be restored
Database unique name
Listener port number
Single-Instance Oracle ASM Instance
111Home/bin/emca -restore asm
You are prompted to enter the following information:
Oracle home for the database to be restored
Oracle ASM port
Oracle ASM SID
Oracle ASM on Oracle RAC Instance
111Home/bin/emca -restore asm -cluster
You are prompted to enter the following information:
Oracle home for the database to be restored
Oracle ASM port
Single-Instance Oracle Database With Oracle ASM
111Home/bin/emca -restore db_asm
You are prompted to enter the following information:
Oracle home for the database to be restored
Database SID
Listener port number
Oracle ASM port
Oracle ASM home
Oracle ASM SID [+ASM]
Oracle RAC Database and Oracle ASM Instance
111Home/bin/emca -restore db_asm -cluster
You are prompted to enter the following information:
Oracle home for the database to be restored
Database unique name
Listener port number
Oracle ASM port
Oracle ASM Oracle home
Oracle ASM SID [+ASM]
The output of emca varies according to the options that you specify and the values that you enter at the prompts.
For an inplace patchset upgrade, the original home backup you saved before applying the patchset must be restored. This step must be repeated on all the nodes in Oracle RAC environments. Running the emca -restore command is not required for an inplace patchset upgrade.
After completing the emca -restore procedure you are ready to restore the Oracle Enterprise Manager Database files and data with the emdwgrd utility. You must run the emdwgrd utility from the Oracle Database 11g Release 2 (11.2) home. But ORACLE_HOME and other environment variables must be set to point to the Oracle home from which the upgrade originally took place.
The following procedure is for Linux and UNIX. To run it on Windows, simply substitute emdwgrd.bat for emdwgrd.
Follow these steps to restore your database control files and data:
Set ORACLE_HOME to the Oracle home from which the database upgrade originally took place.
For an inplace patchset upgrade, restore the backup of the original home (with one-off patch of Bug 7131048 if upgrading from 11.1.0.6), and set ORACLE_HOME to the current Oracle home.
Set ORACLE_SID to the SID of the database that was upgraded and then downgraded.
Set PATH, LD_LIBRARY_PATH and SHLIB_PATH to point to the Oracle home from which the database upgrade originally took place.
Go to the Oracle Database 11g Release 2 (11.2) home:
cd ORACLE_HOME/bin
Execute one of the following:
For a single-instance database, run the following command, where SID is the SID of the database that was upgraded and then downgraded and save_directory is the path to the storage location you chose when saving your database control files and data:
emdwgrd -restore -sid SID -path save_sirectory -tempTablespace TEMP
For an Oracle RAC database, remote copy is required across the cluster nodes. Define an environment variable to indicate which remote copy is configured. For example:
setenv EM_REMCP /usr/bin/scp
Then, execute the following restore command:
emdwgrd -restore -tempTablespace TEMP -cluster -sid SID10g -path save_directory
If 10g Oracle home is on a shared device, add -shared to the previous command line.
Enter the SYS and SYSMAN passwords when prompted by emdwgrd.
On a single-instance database, the emdwgrd utility produces output similar to the following:
Sat Apr 28 09:27:09 2007 - Verify EM DB Control files ... pass Sat Apr 28 09:27:09 2007 - Validating DB Connection to DB102 ... pass Sat Apr 28 09:27:19 2007 - Validating TEMP tablespace in DB102 ... pass Sat Apr 28 09:27:20 2007 - creating directory ... created Sat Apr 28 09:27:20 2007 - Stopping DB Control ... stopped Sat Apr 28 09:27:21 2007 - dropping sysman schema ... dropped Sat Apr 28 09:27:22 2007 - recreating sysman user ... recreated Sat Apr 28 09:27:23 2007 - Restoring DB Control files ... restored Sat Apr 28 09:27:23 2007 - Importing sysman schema ... imported Sat Apr 28 09:30:42 2007 - recompiling invalid objects ... recompiled Sat Apr 28 09:30:54 2007 - Starting DB Control ... started Sat Apr 28 09:32:37 2007 - DB Control was restored successfully.
When emdwgrd finishes, Oracle Enterprise Manager Database Control has been downgraded to the old Oracle home.
On an Oracle RAC database, the emdwgrd utility produces output similar to the following:
$ /scratch/oracle/product/11.1.0/db_1/bin/emdwgrd -srcOracleHome $ORACLE_HOME -sid DB102 -path /scratch/rpattabh/ravi/tmp/dbcdir5 -restore –cluster -tempTablespace TEMP Enter sys password for database DB102? ***** Enter sysman password for database DB102? ***** Sat Apr 28 09:27:09 2007 - Verify EM DB Control files ... pass Sat Apr 28 09:27:09 2007 - Validating DB Connection to DB102 ... pass Sat Apr 28 09:27:19 2007 - Validating TEMP tablespace in DB102 ... pass Sat Apr 28 09:27:20 2007 - creating directory ... created Sat Apr 28 09:27:20 2007 - Stopping DB Control on all Nodes stbdq04, r101b1, /oradbnas/sangeeta/10.1.0/db, stop, 0 stbdq05, r101b2, /oradbnas/sangeeta/10.1.0/db, stop, 1 Please Execute '/tmp/racdwgrd_dbctl.sh' on Node1, Node2. Press yes to continue when the operations are successful. Continue (yes/no) ? y ... stopped Sat Apr 28 09:27:21 2007 - dropping sysman schema ... dropped Sat Apr 28 09:27:22 2007 - recreating sysman user ... recreated Sat Apr 28 09:27:23 2007 - Restoring DB Control files Executing Restore directories to node Node1 Executing Restore directories to node Node2 ... restored Sat Apr 28 09:27:23 2007 - Importing sysman schema ... imported Sat Apr 28 09:30:42 2007 - recompiling invalid objects ... recompiled Sat Apr 28 09:32:37 2007 - DB Control was restored successfully. Sat Apr 28 09:33:54 2007 - Starting DB Control On All nodes Please Execute '/tmp/racdwgrd_dbctl.sh' on Node1, Node2. Press yes to continue when the operations are successful. Continue (yes/no) ? y ... started Sat Apr 28 09:38:57 2007 - Dump directory was dropped successfully.
If you use Oracle Database Vault, then you were instructed to disable it before downgrading your database. To use Oracle Database Vault after downgrading, you must re-enable it.
To enable Oracle Database Vault after downgrading:
Connect to SQL*Plus as a user who has been granted the DV_OWNER role.
Issue the following statements:
ALTER TRIGGER DVSYS.DV_BEFORE_DDL_TRG ENABLE; ALTER TRIGGER DVSYS.DV_AFTER_DDL_TRG ENABLE;
You can restore the Oracle Clusterware configuration to the state it was in before the Oracle Clusterware 11g release 2 (11.2) upgrade. To do this, you must restore the release from which you were upgrading. Any configuration changes you have performed during or after the 11g release 2 (11.2) upgrade process are removed and cannot be recovered.
|
See Also: |
Oracle provides troubleshooting information for issues that may occur when downgrading Oracle Database. For the latest information on this release, also refer to Oracle Database Readme.
Downgrading release 11.2 of Oracle Grid Infrastructure fails
If downgrading release 11.2 of Oracle Grid Infrastructure fails, then refer to the support note "How to Proceed from Failed Upgrade to Grid Infrastructure" on Linux/Unix [ID 969254.1]" on https://support.oracle.com. Oracle recommends that you read the entire note before taking action.
Error raised from the 11.2.0.1 xsrelod.sql script
When downgrading Oracle Database from release 11.2.0.2 or 11.2.0.3 to release 11.2.0.1, an error may be raised from the xsrelod.sql script, which is included with release 11.2.0.1. This problem only occurs after downgrading to release 11.2.0.1 and then attempting to enable XML DB indexes. The error "ORA-01418: specified index does not exist" may be raised and can safely be ignored.
Error raised from the Oracle Multimedia imrelod.sql script
When downgrading Oracle Database to release 11.2.0.2, an error may be raised from the imrelod.sql script which is included with release 11.2.0.2. The error "ORA-20000: Oracle ORDIM component in registry is status: DOWNGRADED. Oracle ORDIM must be installed and valid prior to Oracle Multimedia upgrade, downgrade, or patch." can safely be ignored.
Downgrading Oracle Database causes invalid object CTX_FILTER_CACHE_STATISTICS
After downgrading Oracle Database, the following invalid Text object may be seen:
CTX_FILTER_CACHE_STATISTICS (synonym) CTX_FILTER_CACHE_STATISTICS (view)
To fix this problem, in the current release of Oracle Database, after running the catdwgrd.sql script and before running the catrelod.sql script, issue the following two commands:
SQL> drop public synonym ctx_filter_cache_statistics; SQL> drop view ctx_filter_cache_statistics;
Upgrade Guide
11g Release 2 (11.2)
E23633-07
September 2012
Oracle Database Upgrade Guide, 11g Release 2 (11.2)
E23633-07
Copyright © 2002, 2012, Oracle and/or its affiliates. All rights reserved.
Primary Author: Cathy Shea
Contributors: Toshinori Ami, Vickie Carbonneau, Ian Dai, Mike Dietrich, Joseph Errede, Ayako Ito, Masakazu Ito, Cindy Lim, Brian McCarthy, Tony Morales, Carol Palmer, Satish Panchumarthy, Ravi Pattabhi, Kathy Rich, Mark Richwine, Craig Santelman, Viv Schupmann, Janet Stern, Carol Tagliaferri, Venkateshwaran Venkataramani, Douglas Williams
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.
Oracle provides upgrade options that are tailored to your database environment and tools that automate the process for upgrading Oracle Database.
This chapter contains the following topics:
Where to Find the Latest Information About Upgrading Oracle Database
Compatibility and Interoperability Between Oracle Database Releases
Moving From Standard Edition to Enterprise Edition of Oracle Database
About Moving From Enterprise Edition to Standard Edition of Oracle Database
About Upgrading from Oracle Database Express Edition to Oracle Database
Oracle provides late-breaking updates, discussions, and best practices about pre-upgrade, post-upgrade, compatibility, and interoperability on the My Oracle Support Web site at https://support.oracle.com. You can search on note IDs or key words like "Database Upgrade."
For the complete knowledge base and latest information about patch sets, go to My Oracle Support at https://support.oracle.com and enter your search criteria.
For information about upgrading to Oracle Database 11g Release 2, see Oracle Upgrade Companion ID 785351.1 at My Oracle Support at https://support.oracle.com. Other upgrade companions are also available for upgrading to earlier releases.
For information about downloading and running the pre-upgrade information tool, see Oracle Database Pre-Upgrade Utility ID 884522.1 at My Oracle Support at https://support.oracle.com.
The upgrade procedure transforms an existing Oracle Database system (including associated applications) into an Oracle Database 11g Release 2 (11.2) system. The upgrade steps apply to all operating systems, with the possible exception of a few operating system-specific details identified in your operating system-specific Oracle documentation.
Oracle Database 11g Release 2 (11.2) supports the following tools and methods for upgrading a database to the new release:
Database Upgrade Assistant (DBUA)
Provides a graphical user interface that guides you through the upgrade of a database. DBUA can be launched during installation with the Oracle Universal Installer, or you can launch DBUA as a standalone tool at any time in the future.
|
Note: DBUA is the recommended method for performing a major release upgrade or patch release upgrade. |
Manual upgrade using SQL scripts and utilities
Enables upgrades to be performed at the command line with SQL scripts and utilities.
Export and Import utilities
Uses Oracle Data Pump utilities, or the native Export and Import features within Oracle Database. These utilities perform a full or partial export from your database, followed by a full or partial import into the new Oracle Database 11g. Export/Import can copy a subset of the data, leaving the database unchanged.
CREATE TABLE AS SQL statement
Copies data from a database into a new Oracle Database 11g database. Data copying can copy a subset of the data, leaving the database unchanged.
|
See Also: "Choose an Upgrade Method for Upgrading Oracle Database" for more details about the upgrade tools and methods |
Detailed instructions for upgrading an existing Oracle database to the new Oracle Database 11g release are provided in the appropriate chapters in Oracle Database Upgrade Guide.
The following steps outline the major procedures performed during the upgrade process:
Step 1: Prepare to Upgrade
Become familiar with the features of the new Oracle Database 11g release.
Determine the upgrade path to the new release.
Choose an upgrade method.
Choose an Oracle home directory for the new release.
Develop a testing plan.
Prepare a backup strategy.
|
Note: During the upgrade, consider running multiple releases of the database software so you can use the existing release as your production environment while you test the new release. See "About Running Multiple Oracle Releases". |
Step 2: Test the Upgrade Process
Perform a test upgrade using a test database. The test upgrade should be conducted in an environment created for testing and should not interfere with the actual production database.
Step 3: Test the Upgraded Test Database
Perform the tests you planned in Step 1 on the test database and on the test database that was upgraded to the new Oracle Database 11g release.
Compare results, noting anomalies between test results on the test database and on the upgraded database.
Investigate ways to correct any anomalies you find and then implement the corrections.
Repeat Step 1, Step 2, and the first parts of Step 3, as necessary, until the test upgrade is completely successful and works with any required applications.
Chapter 2, "Preparing to Upgrade Oracle Database" provides detailed information about Steps 1 through 3.
Step 4: Prepare and Preserve the Production Database
Prepare the current production database as appropriate to ensure the upgrade to the new Oracle Database 11g release is successful.
Schedule the downtime required for backing up and upgrading the production database.
Back up the current production database. Perform a full or an incremental backup, as necessary, to ensure your database is protected against data loss.
Step 5: Upgrade the Production Database
Upgrade the production database to the new Oracle Database 11g release.
After the upgrade, perform a full backup of the production database and perform other post-upgrade tasks.
Chapter 3, "Upgrading to the New Release of Oracle Database" describes Steps 4 and 5 when using DBUA or when performing a manual upgrade. Chapter 4, "Post-Upgrade Tasks for Oracle Database" describes the backup procedure for Step 5 after the upgrade, and other post-upgrade tasks for Step 6.
Step 6: Tune and Adjust the New Production Database
Tune the new Oracle Database 11g production database. The new production database should perform to the same standards, or better than, the database before the upgrade.
Chapter 4, "Post-Upgrade Tasks for Oracle Database" describes these adjustments.
Determine which features of the new Oracle Database 11g release you want to use, and update your applications accordingly.
Develop new database administration procedures as needed.
Do not upgrade production users to the new release until all applications have been tested and operate properly.
Chapter 5, "Upgrading Applications After Upgrading Oracle Database" describes considerations for updating applications.
Figure 1-1 illustrates the major steps in the upgrade process.
Oracle Database Upgrade Guide describes moving between different releases of Oracle Database. Starting with Oracle9i Release 2 (9.2), maintenance releases of Oracle Database are denoted by a change to the second digit of a release number. In earlier releases, the third digit indicated a particular maintenance release.
Figure 1-2 illustrates each part of a release number and what it represents.
Figure 1-2 Example of an Oracle Release Number
More information about release numbers are contained in these topics:
When a statement is made in Oracle Database Upgrade Guide about a major database release number, the statement applies to all releases within that major database release. References to Oracle Database 11g include Oracle Database 11g Release 1 (11.1) and Oracle Database 11g Release 2 (11.2). References to Oracle Database 10g include Oracle Database 10g Release 1 (10.1) and Oracle Database 10g Release 2 (10.2), and references to Oracle9i include Oracle9i Release 1 (9.0.1) and Oracle9i Release 2 (9.2) and so forth.
Similarly, when a statement is made in Oracle Database Upgrade Guide about a maintenance release, the statement applies to all component-specific and platform-specific releases (also referred to as patchset releases) within that maintenance release. Therefore, a statement about Oracle Database 11g Release 2 (11.2) applies to releases 11.2.0.1, 11.2.0.2, and 11.2.0.3, and all other platform-specific releases within Oracle Database 11g Release 2 (11.2).
You can run different releases of Oracle Database on the same computer at the same time. However, you must observe the following conditions when simultaneously using multiple releases:
An Oracle Database release must be installed in a new Oracle home that is separate from earlier releases of Oracle.
There cannot be multiple releases for each Oracle home. Oracle recommends that you adopt an Optimal Flexible Architecture (OFA) when creating multiple Oracle homes.
Each database server can access only a database that is consistent with its release number.
For example, if you have Oracle9i and Oracle Database 11g installed on the same computer, then the Oracle9i database server can access Oracle9i databases but not Oracle Database 11g databases, and the Oracle Database 11g database server can access Oracle Database 11g databases but not Oracle9i databases.
|
See Also: Your operating system-specific Oracle documentation for more information about running multiple releases of Oracle Database on your operating system and any restrictions that may apply |
The following topics provide general information about running multiple releases of Oracle Database:
About Earlier Oracle Database Releases and Upgrading to the Current Release
About Upgrading Clients to the Current Release of Oracle Database
You may not be able to install earlier releases of Oracle Database on the same computer system and have clients connect to these databases. For example, you cannot have Oracle8i, Oracle9i, Oracle Database 10g, and Oracle Database 11g databases in multiple (or separate) Oracle homes on the same computer and have Oracle8i, Oracle9i, Oracle Database 10g, and Oracle Database 11g clients connecting to any or all of the databases. You may be able to have a combination of some releases on one system. However, be sure to obtain the latest information on compatibility and supported configurations.
|
See Also: Note 207303.1 "Client / Server / Interoperability Support Between Different Oracle Versions" on My Oracle Support athttps://support.oracle.com |
You can install Oracle8i, Oracle9i, Oracle Database 10g, and Oracle Database 11g databases in multiple (separate) Oracle homes on separate computers and have Oracle8i, Oracle9i, Oracle Database 10g, and Oracle Database 11g clients connecting to any or all of the databases.
You can upgrade an Oracle8i, Oracle9i, Oracle Database 10g, or Oracle Database 11g database to the new Oracle Database 11g release and have Oracle8i, Oracle9i, Oracle Database 10g, and Oracle Database 11g clients connecting to the upgraded database. Be sure to obtain the latest information on compatibility and supported configurations.
You can upgrade any or all of your Oracle8i, Oracle9i, Oracle Database 10g, or Oracle Database 11g clients to the new Oracle Database 11g release. The new Oracle Database 11g release client can access your Oracle8i, Oracle9i, Oracle Database 10g, and Oracle Database 11g databases.
Compatibility and interoperability issues may arise because of differences between Oracle Database releases. These differences might affect general database administration and existing applications.
The following topics discuss compatibility and interoperability:
|
See Also: Appendix A, "Behavior Changes After Upgrading Oracle Database" for more information on compatibility and interoperability for specific releases |
Databases from different releases of Oracle Database software are compatible if they support the same features and those features perform the same way. When you upgrade to a new release of Oracle Database, certain new features might make your database incompatible with your earlier release.
Your upgraded database becomes incompatible with your earlier release under the following conditions:
A new feature stores any data on disk (including data dictionary changes) that cannot be processed with your earlier release.
An existing feature behaves differently in the new environment as compared to the old environment.
The following topics contain more information about compatibility:
Default, Minimum, and Maximum Values of the COMPATIBLE Initialization Parameter for Oracle
Considerations for Downgrading Oracle Database and Compatibility
How the COMPATIBLE Initialization Parameter Operates in Oracle Database
When to Set the COMPATIBLE Initialization Parameter in Oracle Database
Oracle Database enables you to control the compatibility of your database with the COMPATIBLE initialization parameter. By default, when the COMPATIBLE initialization parameter is not set in your parameter file, it defaults to 11.2.0 for Oracle Database 11g Release 2 (11.2). You cannot use new Oracle Database 11g Release 2 (11.2) features that would make your upgraded database incompatible unless the COMPATIBLE initialization parameter is set to this value.
|
Note:
|
|
See Also: Oracle Database Administrator's Guide for information about managing initialization parameters |
Table 1-1 lists the default, minimum, and maximum values of the COMPATIBLE initialization parameter in Oracle Database 11g Release 2 (11.2) and in each release supported for upgrading to Oracle Database 11g Release 2 (11.2).
Table 1-1 The COMPATIBLE Initialization Parameter
| Oracle Database Release | Default Value | Minimum Value | Maximum Value |
|---|---|---|---|
|
Oracle9i Release 2 (9.2) |
|
|
|
|
Oracle Database 10g Release 1 (10.1) |
|
|
|
|
Oracle Database 10g Release 2 (10.2) |
|
|
|
|
Oracle Database 11g Release 1 (11.1) |
|
|
|
|
Oracle Database 11g Release 2 (11.2) |
|
|
|
Before upgrading to Oracle Database 11g Release 2 (11.2), the COMPATIBLE initialization parameter must be set to at least 10.0.0. Only a subset of Oracle Database 11g Release 2 (11.2) features are available while the COMPATIBLE initialization parameter is set to this value.
After upgrading to Oracle Database 11g Release 2 (11.2), you can set the COMPATIBLE initialization parameter to match the release number of the new release. Doing so enables you to use all features of the new release, but prevents you from downgrading to your earlier release.
If, after upgrading, you want to downgrade, then the COMPATIBLE initialization parameter must be set as follows after the upgrade:
Keep the setting at 10.1.0 if you upgraded from Oracle Database 10g Release 1 (10.1)
Set to 10.2.0 or 10.1.0 if you upgraded from Oracle Database 10g Release 2 (10.2)
Set to 11.1.0, 10.2.0, or 10.1.0 if you upgraded from Oracle Database 11g Release 1 (11.1)
|
Important: After you increase theCOMPATIBLE parameter, the database cannot subsequently be downgraded to releases earlier than what is set for compatibility. |
|
See Also: Chapter 6, "Downgrading Oracle Database to an Earlier Release" for more information about downgrading |
The COMPATIBLE initialization parameter operates in the following way:
It controls the behavior of your database. For example, if you run an Oracle Database 11g Release 2 (11.2) database with the COMPATIBLE initialization parameter set to 10.1.0, then it generates database structures on disk that are compatible with Oracle Database 10g Release 1 (10.1). Therefore, the COMPATIBLE initialization parameter enables or disables the use of features. If you try to use any new features that make the database incompatible with the COMPATIBLE initialization parameter, then an error is displayed. However, any new features that do not make incompatible changes on disk are enabled.
It makes sure that the database is compatible with its setting. If the database becomes incompatible with its setting, then the database does not start and terminates with an error. If this happens, then you must set the COMPATIBLE initialization parameter to an appropriate value for the database.
The compatibility level of your database corresponds to the value of the COMPATIBLE initialization parameter. For example, if you set the COMPATIBLE initialization parameter to 11.2.0, then the database runs at release 11.2.0 compatibility level.
To check the current value of the COMPATIBLE initialization parameter
Enter the following SQL statement:
SQL> SELECT name, value FROM v$parameter
WHERE name = 'compatible';
Oracle recommends increasing the COMPATIBLE parameter only after complete testing of the upgraded database has been performed. After the upgrade is complete, you can increase the setting of the COMPATIBLE initialization parameter to the maximum level for the new Oracle Database 11g release. However, after you increase the COMPATIBLE parameter, the database cannot subsequently be downgraded.
In Oracle Database, interoperability is the ability of different releases of Oracle Database to communicate and work in a distributed environment. A distributed database system can comprise different releases of Oracle Database, and all supported releases of Oracle Database can participate in the distributed database system. However, the applications that work with a distributed database must also be able to interoperate with the features and functions that are available at each node in the system.
Interoperability across disperate operating systems and operating system versions might be a problem (especially during rolling upgrades) because the minimum requirements for the new Oracle Database 11g release might require you to upgrade the operating systems on some or all of your hosts. Therefore, you must check for compatibilities between drivers, network, and storage for all the interim states of the system during the rolling upgrade.
|
Note: Because Oracle Database Upgrade Guide discusses upgrading and downgrading between different releases of Oracle Database, the definition of interoperability is for Oracle Database releases. Other Oracle documentation might use a broader definition of the term interoperability. For example interoperability might in some cases describe communication between different hardware platforms and operating systems. |
|
See Also: Note ID 207303.1 "Client / Server / Interoperability Support Between Different Oracle Versions" on My Oracle Support athttps://support.oracle.com |
Oracle recommends the Optimal Flexible Architecture (OFA) standard for Oracle Database installations. The OFA standard is a set of configuration guidelines for efficient and reliable Oracle databases, which results in more streamlined maintenance.
OFA provides the following benefits:
Organizes large amounts of complicated software and data on disk to avoid device bottlenecks and poor performance
Facilitates routine administrative tasks, such as software and data backup functions, which are often vulnerable to data corruption
Alleviates switching among multiple Oracle databases
Adequately manages and administers database growth
Helps to eliminate fragmentation of free space in the data dictionary, isolates other fragmentation, and minimizes resource contention
If you are not currently using the OFA standard, then switching to the OFA standard involves modifying your directory structure and relocating your database files.
|
See Also:
|
If you are installing 64-bit Oracle Database 11g software but were previously using a 32-bit Oracle Database installation, the database is automatically converted to 64-bit during a patch release or major release upgrade to the new Oracle Database 11g release.
To complete the conversion, you must manually perform the following post-upgrade tasks:
Increase initialization parameters affecting the system global area, such as SGA_TARGET and SHARED_POOL_SIZE, to support 64-bit operations.
Reconnect after starting up the database so that a new session is created with the appropriate 64-bit initialization. For example:
CONNECT AS SYSDBA STARTUP UPGRADE CONNECT AS SYSDBA SPOOL UPGRADE.LOG @catupgrd.sql
|
See Also:
|
Troubleshooting 32-bit to 64-bit Conversion for Oracle Database
When migrating a 32-bit database to 64-bit, when running the utlrp.sql script, there is a known error, ORA-07445.
ORA-07445: exception encountered: core dump [_intel_new_memcpy()+2132] [ACCESS_VIOLATION] [ADDR:0x11D1F0F67] [PC:0x621BEA4] [UNABLE_TO_READ] []
The utlrp.sql script, which is located in the ORACLE_HOME/rdbms/admin directory, is used to recompile stored PL/SQL and Java code. This error and workaround are described in Note 341880.1 "How to convert a 32-bit database to a 64-bit database on Linux" on My Oracle Support at http://support.oracle.com.
The rolling upgrade process supports Oracle Automatic Storage Management (Oracle ASM) instances in an Oracle Real Application Clusters (Oracle RAC) environment one at a time, without stopping the database. Depending on the method you choose to perform a rolling upgrade, you can upgrade the Oracle Database software or Oracle ASM instances, apply patchsets, or apply individual patches (sometimes referred to as one-off patches), incurring little or no database downtime. Database instance rolling upgrade is not supported.
|
See Also:
|
Oracle provides different methods and options for performing rolling upgrades depending on your environment and applications. Table 1-2 summarizes the various methods for performing rolling upgrades and provides cross-references to the appropriate documentation.
Table 1-2 Methods for Performing Rolling Upgrades for Oracle Database
| Method | Description | Reference |
|---|---|---|
|
Use SQL Apply and logical standby databases to upgrade Oracle Database software and patchsets. |
"About Upgrading Using Standby Databases" | |
|
Use an existing physical standby database to perform a rolling database upgrade by temporarily converting it to a logical standby database. |
"About Upgrading Using Standby Databases" | |
|
Oracle Streams |
By using Oracle Streams source and destination databases, you can upgrade to a new release of Oracle Database software, migrate an Oracle database to a different operating system and/or character set, upgrade user-created applications, and apply Oracle Database patches. |
Oracle Streams Concepts and Administration |
|
Use the OPatch Utility to perform rolling patch upgrades with Oracle RAC. You can use the OPatch utility only to apply individual patches, not patchset releases. This method enables some instances of the Oracle RAC to remain available during the patch upgrade. Only the Oracle RAC instance being patched must be brought down; the other instances can continue to remain available. The OPatch Utility enables you to apply the patch successively to the different instances of Oracle RAC. |
Oracle Universal Installer and OPatch User's Guide for Windows and UNIX | |
|
Oracle Clusterware and Oracle Universal Installer (OUI) |
Use OUI and Oracle Clusterware to perform a rolling upgrade to apply patchset releases of Oracle Clusterware.This method enables some instances of the Oracle RAC to remain available during the patchset upgrades. Only the node that is currently being patched must be brought down; the other instances remain available. OUI enables you to apply the patchset successively to the different instances of the cluster. |
Oracle Grid Infrastructure Installation Guide Oracle Universal Installer and OPatch User's Guide for Windows and UNIX |
|
Use Oracle ASM to independently upgrade or patch clustered Oracle ASM instances. This method allows all of the features of a clustered Oracle ASM environment to continue to function even while one or more Oracle ASM instances run different software versions. Note: An Oracle ASM rolling upgrade to Oracle Database 11g Release 2 (11.2) moves the Oracle ASM instance to an Oracle Grid Infrastructure home. |
Oracle Grid Infrastructure Installation Guide "Using Oracle ASM Rolling Upgrade" in Oracle Database Storage Administrator's Guide |
If you have Oracle Database Standard Edition at a release earlier than the new Oracle Database 11g release, then you can change it to Oracle Database Enterprise Edition by installing Oracle Enterprise Edition software and subsequently following the normal upgrade procedures, as described in Oracle Database Upgrade Guide.
To change your existing Standard Edition database to an Enterprise Edition database
Ensure that the release number of your Standard Edition server software is the same release as Enterprise Edition server software.
For example, if your Standard Edition server software is release 11.1.0.6, then you must upgrade to release 11.1.0.6 of Enterprise Edition.
Shut down your database.
If your operating system is Windows, then stop all Oracle services, including the OracleServiceSID Oracle service, where SID is the instance name.
Make a backup copy of files under $Oracle_Home/network/admin. This ensures that the listener is configured after you complete the steps in this procedure.
Back up all database files under the current Oracle home that you need to keep.
On Linux, back up $Oracle_Home/dbs/.
On Windows, back up $Oracle_Home/database/.
Edit the orabase_cleanup.lst file found in the Oracle_Home/utl directory and remove the "oradata" and "admin" entries. Refer to "Known Issue with the Deinstallation Tool for This Release".
Deinstall Standard Edition server software. (This step deletes all existing database files that reside under Oracle home.)
Run the deinstall tool from the Oracle home.
Install Enterprise Edition server software using Oracle Universal Installer (OUI).
Select the same Oracle home that was used for the Standard Edition that you uninstalled. During the installation, be sure to select Enterprise Edition. When prompted, choose Software Only from the Database Configuration screen.
Start up your database.
Your database is now upgraded to Enterprise Edition.
orabase_cleanup.lst file found in the $Oracle_Home/utl directory and remove the "oradata" and "admin" entries. Then, deinstall the Oracle home using the 11.2.0.3 deinstallation tool.To properly convert from an Enterprise Edition database to a Standard Edition database you must perform an Export/Import operation. Oracle recommends using the Standard Edition Export utility to export the data. If you only install Standard Edition software, then some data dictionary objects become invalid and create problems when maintaining the database.
Enterprise Edition contains data dictionary objects that are not available in Standard Edition. The Export/Import operation does not introduce data dictionary objects specific to the Enterprise Edition, because the SYS schema objects are not exported.
After the Import in the Standard Edition database, you are only required to drop all user schemas related to Enterprise Edition features, such as the MDSYS account used with Oracle Spatial.
To upgrade Oracle Database 10g Express Edition (Oracle Database XE) to Oracle Database 11g, you must install Oracle Database 11g on the same system as Oracle Database XE and use DBUA to perform the upgrade.
|
See Also:
|
When upgrading Oracle Database, you can use the Export and Import utilities in Oracle Data Pump to move data from one database to another.
This chapter contains the following topics:
|
See Also: Oracle Database Utilities for detailed information about Data Pump and the Export and Import utilities |
The Data Pump Export (expdp) and Import (impdp) utilities have a similar look and feel to the original Export (exp) and Import (imp) utilities, but they are completely separate. The Data Pump Export and Import utilities, first released in Oracle Database 10g Release 1 (10.1), are high performance replacements for the original Export and Import utilities. When upgrading your database, Oracle recommends the Data Pump Export and Import utilities because these utilities provide greatly enhanced performance compared to the original Export and Import utilities.
|
See Also:
|
Data Pump Export and Import offer the following advantages:
Provides greater data and metadata filtering capability than was provided by the original Export utility. Data Pump supports filtering the metadata that is exported and imported based upon objects and object types, using INCLUDE and EXCLUDE parameters.
Supports different modes for unloading/loading portions of the database including: full database mode, schema mode, table mode, tablespace mode, and transportable tablespace mode. (See the "Data Pump Export Modes" and "Data Pump Import Modes" sections in Oracle Database Utilities)
Enables you to specify how partitioned tables should be handled during import operations, using the PARTITION_OPTIONS parameter.
Provides support for the full range of data types.
The original Export/Import utilities are required for the following types of database upgrades and downgrades:
If you are upgrading from a release earlier than Oracle Database 10g Release 1 (10.1), then you must use the original Export/Import utilities to move the data. Likewise, if you are downgrading your database to a release earlier than Oracle Database 10g Release 1 (10.1), then you must use the original Export/Import utilities.
If you must downgrade to a release earlier than Oracle Database 10g Release 1 (10.1), then the original Export utility continues to provide support to ensure backward compatibility.
If you are moving tables of XMLType or tables containing XMLType columns (schema and non-schema-based) from Oracle Database 11g Release 1 (11.1) to Oracle Database 10g Release 2 (10.2).
|
See Also: Oracle Database Utilities for information on moving a database from one platform to another |
Dump files generated by the Data Pump Export utility are not compatible with dump files generated by the original Export utility. Therefore, files generated by the original Export (exp) utility cannot be imported with the Data Pump Import (impdp) utility, and vice versa.
Dump files created by one of the Export utilities can be imported into all future releases of Oracle Database. For example, an Oracle8 original Export dump file can be imported by the Oracle8i, Oracle9i, Oracle Database 10g, and Oracle Database 11g original Import utility.
Table 7-1 shows which releases to use when exporting data from releases earlier than Oracle Database 11g Release 2 (11.2) and then importing that data into Oracle Database 11g Release 2 (11.2).
Table 7-1 Exporting Data From Releases Earlier Than 11.2 and Importing Into Release 11.2
| Export From | Import To | Export Version to Use | Import Version to Use |
|---|---|---|---|
|
Release 11.1 |
Release 11.2 |
Data Pump Export Release 11.1 |
Data Pump Import Release 11.2 |
|
Release 10.2 |
Release 11.2 |
Data Pump Export Release 10.2 |
Data Pump Import Release 11.2 |
|
Release 10.1 |
Release 11.2 |
Data Pump Export Release 10.1 |
Data Pump Import Release 11.2 |
|
Release 9.2 |
Release 11.2 |
Original Export Release 9.2 |
Original Import Release 11.2 |
|
Release 8.1.7 |
Release 11.2 |
Original Export Release 8.1.7 |
Original Import Release 11.2 |
|
Release 8.0.6 |
Release 11.2 |
Original Export Release 8.0.6 |
Original Import Release 11.2 |
|
Release 7.3.4 |
Release 11.2 |
Original Export Release 7.3.4 |
Original Import Release 11.2 |
The Oracle Database release to which you downgrade can be one release older, at the most. For example, if the current database is Oracle Database 11g Release 1 (11.1), then Oracle Database 10g Release 2 (10.2) is the only release supported for the downgrade.
To obtain a downward compatible dump file:
With Data Pump Export, use the current version's Data Pump Export utility, but set the VERSION parameter to the target older version.
Data Pump Import cannot read dump file sets created by a database version that is newer than the current database version, unless those dump file sets were created with the VERSION parameter set to the version of the target database. Therefore, the best way to perform a downgrade is to use Data Pump Export with the VERSION parameter set to the version of the target database.
With original Export, run an older version of Export (exp) to produce a dump file that is compatible with the database version to which you want to downgrade. Then, run the target's original Import utility.
Original Export dump files are not downward compatible with the Import utilities of previous Oracle Database releases. That is, exported data cannot be imported by the Import utilities of previous Oracle Database releases. For example, an Oracle9i Export dump file cannot be imported by an Oracle8i Import utility, and an Oracle Database 10g export dump file cannot be imported by an Oracle9i Import utility. The following tables provide specific examples.
|
See Also: Oracle Database Utilities for more information about using different releases and versions of Export |
Table 7-2 shows which releases to use when exporting data from Oracle Database 11g Release 2 (11.2) and then importing that data into earlier releases. Major release downgrades are supported to 11.1, 10.2, and 10.1.
Table 7-2 Exporting Data From Release 11.1 and Importing Into Earlier Releases
| Export From | Import To | Export Version to Use | Import Version to Use |
|---|---|---|---|
|
Release 11.2 |
Release 11.1 |
Data Pump Export Release 11.2 with |
Data Pump Import Release 11.1 |
|
Release 11.1 |
Release 10.2 |
Data Pump Export Release 11.1 with |
Data Pump Import Release 10.2 |
|
Release 10.2 |
Release 10.1 |
Data Pump Export Release 10.2 with |
Data Pump Import Release 10.1 |
|
Note: When using the original Export utility, if the source database is newer than the target database, then you must run thecatexp.sql script supplied with the previous (older) release for the export to be successful. Once the export is done, then run the catexp.sql script from the newer release to restore the export views. Perform the steps as follows:
|
When you export data to a previous release, data that is incompatible with the previous release either is not exported at all or is exported with the loss of some features.
In general, if you must export data to a previous release, then first remove as many incompatibilities with the previous release as possible before you export the data.
To upgrade a database using the Data Pump Export/Import utilities, complete the following steps:
Export data from the current database using the Export utility shipped with the current database. See the current Oracle Database Utilities documentation for information about using the Export utility on the current database.
To ensure a consistent export, make sure the current database is not available for updates during and after the export. If the current database is available to users for updates after the export, then, before making the current database available, put procedures in place to copy the changes made in the current database to the new database after the import is complete.
Install the new Oracle Database software. Installation is operating-system specific. Installation steps for Oracle Database are provided in Oracle Database Installation Guide for your operating system.
If the new database has the same name as the current database, then shut down the current database before creating the new database.
Create the new database.
Start SQL*Plus in the new Oracle Database environment.
Connect to the database instance as a user with SYSDBA privileges.
Start an Oracle Database instance using STARTUP.
Optionally, you can change the storage parameters from the source database.
You can pre-create tablespaces, users, and tables in the new database to improve space usage by changing storage parameters. When you pre-create tables using SQL*Plus, either run the database in the original database compatibility mode or make allowances for the specific data definition conversions that occur during import. When items have been pre-created, specify one of the following options:
TABLE_EXISTS_ACTION=APPEND for Data Pump Import
IGNORE=Y for original Import
|
Note: If the new database is created on the same computer as the source database, and you do not want to overwrite the source database data files, then you must pre-create the tablespaces and specify one of the following options when you import:
|
Use the Import utility of the new database to import the objects exported from the current database. Include one of the following parameters to save the informational and error messages from the import session to a file:
The LOGFILE parameter for Data Pump Import
The LOG parameter for original Import
After the import, check the import log file for information about which imports of which objects completed successfully and, if there were failures, which failed.
|
See Also: Oracle Database Utilities and the Oracle DatabaseREADME.doc file for error handling information. |
Use further Import scenarios (see Oracle Database Utilities) or SQL scripts that create the database's objects to clean up incomplete imports (or possibly to start an entirely new import).
|
Note: If a Data Pump Export or Import job encounters a fatal error, then the job can be restarted after the condition inducing the failure is corrected. The job then continues automatically from the point of failure. |
If changes are made to the current database after the export, then make sure those changes are propagated to the new database before making it available to users. See Step 1 for more information.
Complete the procedures described in Chapter 4, "Post-Upgrade Tasks for Oracle Database".
As an alternative to the procedure in "Upgrading the Database Using Data Pump Export/Import", you can use the Data Pump Import utility with a database link to perform a full database import from a source database to a destination database without intermediate dump files.
|
Note: In order to avoid interoperability errors, ensure that the appropriate patchset has been applied to the database being upgraded. See My Oracle Support athttps://support.oracle.com to obtain the latest patchsets.
You may also refer to support note ID 4511371.8, which discusses ORA-6544 and ORA-4052 errors. |
Follow these steps to use a network link with impdp:
Ensure that the exporting user at the source database has the EXP_FULL_DATABASE role.
This user must be specified when you create the database link.
Ensure that the importing user at the destination database has the IMP_FULL_DATABASE role.
Create and test a database link between the source and destination databases.
Run the following command, where import_user is the username for the importing user, and db_link is the name of the database link owned by the exporting user:
IMPDP import_user/password NETWORK_LINK=db_link FULL=Y;
A log file for the import operation is written to the DATA_PUMP_DIR directory. You can discover the location of this directory by running the following command:
SQL> select * from dba_directories where DIRECTORY_NAME like 'DATA_PUMP_DIR';
|
Note: XML objects are not exported from the source database. |
|
Note: The import operation re-creates users on the new destination server, and the creation date fordba_users shows the actual import date. The expiration date is updated to be creation_date + password_life_time. The parameters for dba_users on the new server are different than the dba_users parameters on the source server. |
This manual guides you through the process of planning and executing Oracle Database upgrades. In addition, this manual provides information about compatibility, upgrading applications, and important changes in the new Oracle Database release, such as initialization parameter changes and data dictionary changes.
Oracle Database Upgrade Guide contains information that describes the features and functions of Oracle Database (also known as the standard edition) and Oracle Database Enterprise Edition products. Oracle Database and Oracle Database Enterprise Edition have the same basic features. However, several advanced features are available only with the Enterprise Edition, and some of these are optional. For example, to use application failover, you must have the Enterprise Edition with the Oracle Real Application Clusters option.
|
See Also: Oracle Database New Features Guide for information about the differences between Oracle Database and Oracle Database Enterprise Edition and the features and options that are available to you. |
This preface contains these topics:
Oracle Database Upgrade Guide is intended for database administrators (DBAs), application developers, security administrators, system operators, and anyone who plans or executes Oracle Database upgrades.
To use this document, you must be familiar with the following:
Relational database concepts
Your current release of Oracle Database
Your operating system environment
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.
Access to Oracle Support
Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.
For more information, see these Oracle resources:
"Oracle Upgrade Companion" Note ID 785351.1 on My Oracle Support at https://support.oracle.com.
Oracle Database Concepts for a comprehensive introduction to the concepts and terminology used in this manual
Oracle Database Administrator's Guide for information about administering Oracle Database
Oracle Database SQL Language Reference for information on Oracle Database SQL commands and functions
Oracle Database Utilities for information about utilities bundled with Oracle Database, including Data Pump, Export, Import, and SQL*Loader
Oracle Database Net Services Administrator's Guide for information about Oracle Net Services
Oracle Database Enterprise User Security Administrator's Guide for information about Oracle Label Security
Oracle Database High Availability Best Practices for Oracle operational best practices and help choosing an upgrade method that minimizes downtime.
Many of the examples in this guide use the sample schemas, which are installed by default when you select the Basic Installation option with an Oracle Database installation. Refer to Oracle Database Sample Schemas for information on how these schemas were created and how you can use them yourself.
The following text conventions are used in this document:
| Convention | Meaning |
|---|---|
| boldface | Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary. |
| italic | Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values. |
monospace | Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter. |
ÌR5~ |
~9sbʆGPg LJ`o1իh6[?R{A\_p :2\< }bUB{* }bUB{* }bUB{* }bUB{* }bUB{* / e_W
^TVP+å1ƕI:@`#b{eo p W)pKmc U*O- ,r%eW2\.)q.Zq aR-i3
Rᗎ*J<uםڵ3 _ J | :6euZ.A7 "wBYRi\΅U z W,IuTTs= 84'倧r> jkеP\:`;i]PQvTs*5pAp 4
Ou:@Tvw;#9OxZT9g9ssLhjTi@ c'Wc\\8233eiȽSFFPemr.iS멶`xw94M@( :lL;kd~BJӺZbVL5+aeA ,>F|2j3&{G02"` :'"&#bvC[&] +\!wn`Z!mQ;-9e;l-Ma'Mڔ,f .߆ܙY ,oAb˓k%"Bי
t[L|YY$nC|
cy FNP{mAs 8L(,s+H9& jfgWc9ol88zd,yy(n4z6% l.{3FU PiG RnxdY\ һ%u[wop&{2cI` _X ̅nbS4[Udѷ Mǝ=c#&!qՎiC[vN 8ھ^|k |,| q,tP1G\:6z{c .Qv ~dQA
-R
u[qDښdtLǏB<:<8_.}&oXn
9" 2OZ ;C nrŜPP'3x|+=w8"<=2AߍsHpákf\T9. b=/GįW5Q鎧ޘ]6p<\#zŘ$;C4:dPU۳0.ّc8A 尵/~#ԁusmz CF4q9v .x C 컔d|@iDsK (6)4NcIj( (8 0S,+Sލ= g.-ێGL_AMw6@x݀4X1xRZz/tBޫ [~㕷MS? ,+e<#@ii!GwW _us0}_- |P̌xnhwaU'´Ykϳ;ߋgWsu'QɊ_Vn[mmik7X.I7c===g5P*KkkItdRv۬pS{AP2j@J\HP}U*jpQ!%>T)A_;R-F{UNwM{ϭ羢g`Ol6)J ЂI\Kh)MVT ?zTpb fdȘ ןcY+r : Aݽt6 . .lzNthȐdz]5kG:, w;/?01K$82 03>iE$= Y ̑a'7 sB\4T6;[~LVNC#eb6㡼s> *T 9|Q_m IT/"r-ϭ羢 ._;EP/Z[}E} ]'Pw^ >_h O¡|A@h }n=tBނ*x'/<~{+?
UN_%yW@~ zK@u隷 *T 9|Q_m IT/"r-ϭ羢 ._;EP/Z[}E} ]'Pw^ >_h O¡|A@h }n=kW8|p/:Y}8/2w_se~ݿN}<)-Mv@\̺ s*jp|IkZրˠ/
$S~^(oP' )$:2EVV0r?nf #`1!icPU͘0bGHh,!,8^~/*a_6}3p0 KŏmZnRj6lz1u&n >[>Xmf#W#[3~x
':xr1vmN`l4-vmc廼oƪ
* ] e@esu9
ڌ-j]8o1O
ᵻ/E/Cps pS~о1o/{ܺklȫKƚqkj67=? E7_N\V-?rjBk :Q/E(!yn8^ J Z/-Ч d DK^TA{(kjBh/}%Y-{_RRS %k^QB
q@Ad J5H^[N4,z)F t)ƂQ/E(!yn8^ J Z/-Ч d DK^TA{(kjBh/}%Y-{_RRS %k^QB
q@Ad J5H^[N4,z)F t)ƂQ/E(!yn8k7> /N_z7zvo1>,
sd~ݸʲxwn^ȝW%^igz x&J{ֆBY(t\ K~ڕU,pp.K? PEEG)tf0w
Z6t}NY2XZ@ OD+JFɶo "vBִjԛ~+$k
M^s-7Lh" Lf@7P}|qYẟL{BG/V*)(P'\/7[;QRRnjR,܍m
+Е y^k=^OW3t
ϼT}p뚍@SZ҆O$Ս=8ӝ]]h]^6*HdV4lL1`zۛtkڵeRuwU/,I3Sᅬ4s+vz4lZʮmF6I9F44/14Xj"7}M-I\nN͖2r6Ŧy[C \7 k2O5e˘{a vcI$>~T" T\9@N8AQfH2
rL5EMe9G+Cbq
+#
pVwY2L-OԇJR4 vW^wj<\zg|p.S=*/س{`GsI @ @ @ @ @ @
3{_k\e(WId +WKoCnG㛳( 4 uAǺ vۅ$ 0鍮Oԇ*֣S0JF P KL4t w3nV]Jmvw:NkiKK:#[g2b1
r7WefSnFkP =0L[1&
LI +nje,jiA۳.X[$c9[(5ͷ1;2Lƕ)2fKg6X c)nͻn|Xtxqe5I>v0r"h&#dPQ4{ٶ0C dGrv,F.hJނxj Dm16Hd| +2a(LCml2wĠd$$%Z m% vI>c(4 8hR J ͔/T
Tz!xPOoYv_({6PhP)QA=gۺ~ B@Gnh .e ƀU ^{]᠀J ͔/T
Tz!xPOoYv_({6PhP)QA=gۺ~ B@Gnh .e ƀU ^{]᠀J ͔/T
Tz!xPOoYv_({6PhP)QA=gۺ~ B@Gnh .e ƀU ^{]᠀J ͔/T
Tz!xPOoYv_({6Ph9Q>/ %d]TÇ
;Y<+y*i?~ O߷Kt_$ j=i7 $ D
v TT]>Ƿ[:'MҥǏУ'Y |ŘpZ8֎&yoLd=M \Zj V h
< ;/Pd!ꞣdn\xo vF1hitM+ DMIݺ!2< 79A{P,s%B7J%Y9{JT ndK_@r
("Ȗ;ځdA*P'ɺPE-~w';ނT*Ot"ZjNwU@&AD ' z 7,N>+D 'G_U2~H }mE6$l7NH u3!p6}S{[f&fN'xL}M_cW?'zyܳև j~^Obz
IJC_}j IT^'qp؈~-tS47/렿wkٿ_*~] ~ _Of"u_t6o*~] ~ _Of"u_t6o*~] ~ _Of"u_t6o*~] ~ _Of"u_t6o*~] ~ _Of"u_t6o*w$x6\^ic e ͤ6FkOU_/bٿ_ȩtn1~]?
ޮq3s9! 4E?
~] ~ _Of"u_t6o*~] ~ _Of"9oli136l̜Y`(d9q{t6o*aվٳ1ab67ֵSٿ_Ȫu_t6o*~] ~ _Of"8w,806qqd0Dǥִv zEU{ ?/˧^S/b~7?{ ?/˧^S/b~7?{ ?/˧^S/b~7?{ ?/˧^S/b~7?{ ?/˧^S/b~7?{ ?/˧^S/b~7?{ ?/˧^S/b~7?{ ?/˧^S/b~7n}j뭃w%n1 Lj&ݺiwfdK_Z?+BOТ·[7= 6<{{$S!< @b괽',_7FW+'xL}M_cfޞv"IXh ,E{ٹ)^ua` .ʶ4L]
Q=e@cs1{[#9-x!9ogܭ}¼oDٷ h'(\Ծ&\n s" {sѺ%/R<p^± :\9fradyl ai
]IJqޚE2K
T۳yyxZrW5$U}@hRCahT vPv65s2\xqp/W( )Eo?kɢT
O @
[t$]K% oEuVFG{"T˗\]wh|6{]6~mB }YY` ngJoRXgGr9 (% JofUwJ} 3hf6͈鑧!:{QdE?3j'/xt2r%m r sW77 B
:{p"hZ6v@o};wai nCӻ}j5^QotNjM>VTg2rǺmjFV@djIsDjfkH? nE "]xU̓KݥLv0}E= qdfəTic^CEkն'F:@P(6& 6F%`m2xܡ0`FGimMܸ֥LY|1 UsһTظ!3Bi2 8 DI@@E537 齊WFFdbca lk1v<МGkvG]>?8=ϡv,Cђ餓/"Y[+Nhv7 -16Rۑ6M?~1;Ó͚(rq3= dK5ZkVr迊cg Nm2#qd8I:lhlhn tEx
}șػ1sXNɥͣ{_#27cv{o3 in,ۋ2"*#~8Y
18
%ov2nӓ xG-һ1+[# oK0@ZhGۦb{\9njذ79XX=4?% }qg| 6⽹%`/N'WG` |JbɐXc3?6G?A,]$jG`fyrb1 1HNZmER'}uGģğ\_,Oq{.v[ ՏYwT|J*e2a|fd($>=Zu<ǭ;dJp~ccݳQdc#bгI{WqCcgt]8=s
Oi)ٻ>%?vO\