Oracle® Database Upgrade Guide 11g Release 2 (11.2) Part Number E10819-02 |
|
|
View PDF |
This chapter guides you through the procedures to perform after you have completed an upgrade of your database. This chapter contains the following topics:
Complete the following tasks after you have upgraded your database, regardless of whether you performed the upgrade manually or by using Database Upgrade Assistant (DBUA):
If your operating system is Linux or UNIX, then make sure that the following environment variables point to the directories of the new Oracle Database 11g release:
ORACLE_HOME
PATH
Also check that your oratab
file and any client scripts that set the value of ORACLE_HOME
point to the new Oracle Database 11g release.
Note:
TheORACLE_HOME
, PATH
, and oratab
checks are required only if you upgrade manually. DBUA automatically points oratab
to the new Oracle home. Client scripts must be checked no matter how you upgrade.
If you are upgrading a cluster database, then perform these checks on all nodes in which this cluster database has instances configured.
See Also:
Your operating system-specific Oracle Database installation documents for information about setting other important environment variables on your operating system.For complete information about upgrading the recovery catalog and the UPGRADE CATALOG
command, see the Oracle Database Backup and Recovery User's Guide.
If the Pre-Upgrade Information Tool instructed you to upgrade the time zone files after completing the database upgrade, then use the DBMS_DST
PL/SQL package to upgrade the time zone file.
See Also:
Oracle Database Globalization Support Guide and follow the instructions in "Steps to Upgrade Time Zone File and Timestamp with Time Zone Data"
If you created statistics tables using the DBMS_STATS.CREATE_STAT_TABLE
procedure, then upgrade these tables by executing the following procedure:
EXECUTE DBMS_STATS.UPGRADE_STAT_TABLE('scott', 'stat_table');
In the example, SCOTT
is the owner of the statistics table and STAT_TABLE
is the name of the statistics table. Execute this procedure for each statistics table.
If you are upgrading from Oracle9i Release 2 (9.2) or Oracle Database 10g Release 1 (10.1), and you are using externally authenticated SSL users, then you must run the following command to upgrade those users:
ORACLE_HOME/rdbms/bin/extusrupgrade --dbconnectstring
<hostname:port_no:sid> --dbuser <db admin> --dbuserpassword
<password> -a
Note:
If you are upgrading from Oracle Database 10g Release 2 (10.2) or higher, then you are not required to run this command.See Also:
Oracle Database Enterprise User Security Administrator's Guide for more information on theextusrupgrade
scriptThe Oracle Text supplied knowledge bases are part of the companion Oracle Database 11g release products and are not immediately available after an upgrade to the new Oracle Database 11g release. Any Oracle Text features dependent on the supplied knowledge bases which were available before the upgrade do not function after the upgrade. To re-enable such features, you must install the Oracle Text supplied knowledge bases from the installation media.
After an upgrade, all user extensions to the Oracle Text supplied knowledge bases must be regenerated. These changes affect all databases installed in the given Oracle home.
See Also:
Oracle Text Application Developer's Guide for information about Oracle Text supplied knowledge bases
The post-installation tasks section of your platform-specific Oracle Database Installation Guide for companion products
If your database originally included Application Express Version 3.2, then there is no additional configuration necessary after upgrading to the new Oracle Database 11g release.
If your database was not an Oracle Express Edition (XE) database, but contained a prior version of Application Express (HTML DB), then version 3.2 is automatically installed during the upgrade. You must complete a series of post-installation steps to configure Application Express Version 3.2 for use with the new Oracle Database 11g release. These steps are described in the section on post-installation tasks in the Oracle Application Express Installation Guide.
If your database was an Oracle Express Edition (XE) database, then it contained a prior version of Application Express tailored for the XE environment. See the OTN document describing the differences between Oracle XE and Oracle Application Express 3.2 at:
http://www.oracle.com/technology/products/database/application_express/html/3.2_and_xe.html
The database administration features available with the XE version of Application Express are not available in version 3.2, but Oracle Enterprise Manager DB Control can, optionally, be installed to provide a graphical interface for database administration.
Oracle Database 11g includes fine-grained access control to the UTL_TCP
, UTL_SMTP
, UTL_MAIL
, UTL_HTTP
, or UTL_INADDR
packages using Oracle XML DB. If you have applications that use one of these packages, you must install Oracle XML DB if it is not already installed. You must also configure network access control lists (ACLs) in the database before these packages can work as they did in prior releases.
The following example first looks for any ACL currently assigned to host_name
. If one is found, then the example grants user_name
the CONNECT
privilege in the ACL only if that user does not already have it. If no ACL exists for host_name
, then the example creates a new ACL called ACL_name
, grants the CONNECT
privilege to user_name
, and assigns the ACL to host_name
.
DECLARE acl_path VARCHAR2(4000); BEGIN SELECT acl INTO acl_path FROM dba_network_acls WHERE host = 'host_name' AND lower_port IS NULL AND upper_port IS NULL; IF DBMS_NETWORK_ACL_ADMIN.CHECK_PRIVILEGE(acl_path, 'user_name','connect') IS NULL THEN DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(acl_path, 'user_name', TRUE, 'connect'); END IF; EXCEPTION WHEN no_data_found THEN DBMS_NETWORK_ACL_ADMIN.CREATE_ACL('ACL_name.xml', 'ACL description', 'user_name', TRUE, 'connect'); DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL('ACL_name.xml','host_name'); END; COMMIT;
Note:
The transaction must be committed for the changes to take effect.See Also:
Oracle Database Security Guide for more complicated situations, such as connecting some users to host A and other users to host BIf you use Oracle Database Vault, then you were instructed to disable it before upgrading your database. You must now:
Enable Database Vault.
Revoke the Database Vault DV_PATCH_ADMIN
role for the SYS
account.
See Also:
The appendix about "Disabling and Enabling Oracle Database Vault" in Oracle Database Vault Administrator's Guide
The section about "Manually Deploying Oracle Database Vault Administrator" in Oracle Database Vault Administrator's Guide
The appendix about "Post-installation Oracle Database Vault Procedures" in Oracle Database Vault Administrator's Guide
Performing the following tasks is recommended, but not required, after you have upgraded your database. These tasks are recommended regardless of whether you performed the upgrade manually or by using DBUA:
Recommended Tasks After Upgrading an Oracle Database 10g Release 1 (10.1) Database
Recommended Tasks After Upgrading an Oracle Express Edition Database
Performing the following tasks is recommended, but not required, after you have upgraded your database.
Make sure you perform a full backup of the production database.
See Also:
Oracle Database Backup and Recovery User's Guide for details about backing up a databaseStarting with Oracle Database 11g Release 1 (11.1), you can enforce case sensitivity for passwords. For example, the password hPP5620qr
fails if it is entered as hpp5620QR
or hPp5620Qr
. In previous releases, passwords were not case sensitive.
To take advantage of enforced case-sensitive passwords, you must reset the passwords of existing users during the database upgrade procedure. For new database instances, there are no additional tasks or management requirements. For upgraded databases, each user password must be reset with an ALTER
USER
statement.
Alternatively, you can change the default to make the password verifier case insensitive. For regular users, set the initialization parameter sec_case_sensitive_logon
to false
:
sql> alter system set sec_case_sensitive_logon=false;
For sysdba
and sysoper
users, you can generate a new orapw file using the new command line switch ignorecase
.
Note:
If the default Oracle Database 11g security settings are in place, then passwords must be at least 8 characters, and passwords such aswelcome
and oracle
are not allowed. See Oracle Database Security Guide for more information.See Also:
Oracle Database Security GuideWhen using DBUA, you can choose to upgrade an Oracle Database instance, an ASM instance, or both. However, when performing a manual upgrade, you must upgrade ASM separately from the Oracle Database upgrade.
Oracle Database New Features Guide describes many of the new features available in the new Oracle Database 11g release. Determine which of these new features can benefit the database and applications; then, develop a plan for using these features.
It is not necessary to make any immediate changes to begin using your new Oracle Database software. You might prefer to introduce these enhancements into your database and corresponding applications gradually.
Chapter 5, "Upgrading Your Applications" describes ways to enhance your applications so that you can take advantage of the features of the new Oracle Database 11g release. However, before you implement new features, test your applications and successfully run them with the upgraded database.
After familiarizing yourself with the features of the new Oracle Database 11g release, review your database administration scripts and procedures to determine whether any changes are necessary.
Coordinate your changes to the database with the changes that are necessary for each application. For example, by enabling integrity constraints in the database, you might be able to remove some data checking from your applications.
An upgraded Oracle Database 11g Release 1 (11.1) database has the Tablespace Alerts disabled (the thresholds are set to null). Tablespaces in the database that are candidates for monitoring must be identified and the appropriate threshold values set.
The default threshold values (for a newly created Oracle Database 11g Release 1 (11.1) database) are:
85% full warning
97% full critical
This section describes the steps to migrate the database that is being upgraded from using rollback segments (manual undo management) to automatic undo management.
Starting with Oracle Database 11g Release 1 (11.1), automatic undo management is the default undo space management mode. The UNDO_MANAGEMENT
initialization parameter specifies which undo space management mode the system should use, as follows:
If UNDO_MANAGEMENT
=AUTO
(or if UNDO_MANAGEMENT
is not set), then the database instance starts in automatic undo management mode.
A null UNDO_MANAGEMENT
initialization parameter defaults to automatic undo management mode in Oracle Database 11g Release 1 (11.1), but it defaults to manual undo management mode in earlier releases. You must therefore use caution when upgrading a previous release to Oracle Database 11g.
If UNDO_MANAGEMENT
=MANUAL
, then undo space is allocated externally as rollback segments.
If you are currently using rollback segments to manage undo space, then Oracle recommends that you migrate your Oracle Database 11g Release 1 (11.1) database to automatic undo management. This change requires that you first create an undo tablespace before opening a newly upgraded database to use automatic undo management. The required size of undo tablespace depends upon the system workload and Flashback requirements.
To migrate to automatic undo management, perform the following steps:
Set UNDO_MANAGEMENT=MANUAL
.
Start the instance again and run through a standard business cycle to obtain a representative workload. Doing this to assess the workload and compute the size of the undo tablespace required for automatic undo management.
After the standard business cycle completes, run the following function to collect the undo tablespace size and help with the sizing of the undo tablespace (DBA privileges are required to execute this function):
DECLARE utbsiz_in_MB NUMBER; BEGIN utbsiz_in_MB := DBMS_UNDO_ADV.RBU_MIGRATION; end; /
This function runs a PL/SQL procedure that provides information on how to size your new undo tablespace based on the configuration and usage of the rollback segments in your system. The function returns the sizing information directly.
Create an undo tablespace of the required size and turn on the automatic undo management by setting UNDO_MANAGEMENT=AUTO
or by removing the parameter.
For Oracle Real Application Clusters (Oracle RAC) configurations, repeat these steps on all instances.
The Data Guard broker property LocalListenerAddress
is being deprecated. Because the manner in which broker communication and redo transport setting are being changed, the value of the LocalListenerAddress
is not maintained in Oracle Database 11g Release 1 (11.1).
The broker property InitialConnectIdentifier
is being changed to DGConnectIdentifier
. The value of DGConnectIdentifier
is used for all Data Guard network traffic, all of the time. While upgrading an Oracle Database 10g configuration to Oracle Database 11g Release 1 (11.1), the InitialConnectIdentifier
value is retained as the new DGConnectIdentifier
value for that database. During the upgrade, it is up to the database administrator to ensure that the InitialConnectIdentifier
reaches all instances if this is an Oracle Real Application Clusters (Oracle RAC) database.
LOB
data types (BFILE
, BLOB
, CLOB
, and NCLOB
) can provide many advantages over LONG
data types. See Oracle Database Concepts for information about the differences between LONG
and LOB
data types.
In Oracle9i Release 1 (9.0.1) and later, the ALTER TABLE
statement can be used to change the data type of a LONG
column to CLOB
and that of a LONG RAW
column to BLOB
.
In the following example, the LONG
column named long_col
in table long_tab
is changed to data type CLOB
:
SQL> ALTER TABLE Long_tab MODIFY ( long_col CLOB );
After using this method to change LONG
columns to LOBs, all the existing constraints and triggers on the table are still usable. However, all the indexes, including Domain indexes and Functional indexes, on all columns of the table become unusable and must be rebuilt using an ALTER INDEX...REBUILD
statement. Also, the Domain indexes on the LONG
column must be dropped before changing the LONG
column to a LOB.
See Also:
Oracle Database SecureFiles and Large Objects Developer's Guide for information about modifying applications to use LOB dataIf you upgraded a test database to the new Oracle Database 11g release and then tested it, then you can now repeat those tests on the production database that you upgraded to the new Oracle Database 11g release. Compare the results, noting anomalies. Repeat the test upgrade as many times as necessary.
Test the newly upgraded production database with existing applications to verify that they operate properly with a new Oracle database. You also might test enhanced functions by adding available Oracle Database features. However, first make sure that the applications operate in the same manner as they did before the upgrade.
See Also:
Chapter 5, "Upgrading Your Applications" for more information on using applications with Oracle DatabasePerforming the following tasks is recommended, but not required, after you have upgraded from Oracle Database 10g Release 1 (10.1) or Oracle Database 10g Release 2 (10.2).
Starting with Oracle Database 10g Release 2 (10.2), Asynchronous Change Data Capture (CDC) no longer requires the same operating system for source and target databases. This feature enables a heterogeneous CDC setup with different operating systems and Oracle versions, enabling asynchronous CDC to leverage any existing Oracle9i Release 2 (9.2) system as a source.
See the Oracle Database Data Warehousing Guide for complete information about how to upgrade an Oracle9i Release 2 (9.2) or Oracle Database 10g Release 1 (10.1) database to the new Oracle Database 11g release with Change Data Capture. The discussion describes the supported configurations for the Distributed HotLog mode of Change Data Capture as well as the restrictions.
To configure HTTPS access to Oracle XML DB, follow the steps in this section to provide correct configuration information.
When a database is upgraded to Oracle Database 10g Release 2 (10.2) or later, the XML schema for the XDB configuration file is automatically upgraded so that the XDB configuration file (located at /xdbconfig.xml
in the repository) can have two additional elements, http2-port
and http2-protocol
. These elements are not added to the XDB configuration file by default during an upgrade. If you wish to have support for HTTPS, then you must edit the configuration file to add these two new elements (see the XML schema for their exact locations), and to set the value of http2-protocol
to tcps
. The value of http2-port
should be different from the value of http-port
.
In addition to specifying the parameters http2-port
and http2-protocol
in the XDB configuration file, you must configure the database and the listener to enable Oracle XML DB to use HTTPS. Additionally, if the following steps were not taken before the upgrade, then you must perform them after the upgrade:
Enable the HTTP listener and the database to use SSL
Enable launching of a TCPS dispatcher
For more information on how to do this, see Oracle XML DB Developer's Guide.
Note:
If Oracle XML DB is not already installed on the system, then you must install it during the upgrade procedure. Oracle XML DB is required to properly maintain the access control lists.If anonymous access to XML DB repository data through HTTP is not required, then you are not required to perform this step. If anonymous access to XML DB repository data through HTTP is required, then you must provide correct configuration information, as described in this section. The administrator must carefully consider whether anonymous access is to be allowed, given the inherent security risks.
When a database is upgraded to Oracle Database 10g Release 2 (10.2) or later, the XML schema for the XML DB configuration file (located at /xdbconfig.xml
in the repository) is automatically upgraded so that it can have an additional element, allow-repository-anonymous-access
. This element is of Boolean type which means it can have a value of true
or false
. It can be used to disallow unauthenticated access to your Oracle XML DB Repository data through HTTP even if you unlock the ANONYMOUS
user account. It is not added to the XML DB configuration file by default during an upgrade but when this element is missing, it is interpreted as false
.
Therefore, anonymous access to XML DB repository data through HTTP is disabled when you upgrade to Oracle Database 10g Release 2 (10.2) or later. If you wish to have anonymous access to XML DB repository data through HTTP, then you must change the configuration file to set this new element to true
, in addition to unlocking the ANONYMOUS
user account.
Caution:
There is an inherent security risk associated with allowing unauthenticated access to the repository.See Also:
Oracle XML DB Developer's Guide for more information about theallow-repository-anonymous-access
element and configuring Oracle XML DBAn Oracle Express Edition database contains only a subset of the components available in a Standard Edition or Enterprise Edition database. After upgrading to the new Oracle Database 11g release, you can use the Database Configuration Assistant to install additional components into your database. If you did not install Enterprise Manager DB Control during the DBUA upgrade, then you can install it, along with any other components you would like to have in the database.
If you are performing a manual upgrade rather than using DBUA, then you must perform the following tasks after your database is upgraded:
Migrate Your Initialization Parameter File to a Server Parameter File
Adjust the Initialization Parameter File for the New Release
Depending on the release from which you upgraded, there might be new Oracle supplied accounts. Oracle recommends that you lock all Oracle supplied accounts except for SYS
and SYSTEM
, and expire their passwords, thus requiring new passwords to be specified when the accounts are unlocked.
Note:
If the default Oracle Database 11g security settings are in place, then passwords must be at least 8 characters, and passwords such aswelcome
and oracle
are not allowed. See Oracle Database Security Guide for more information.You can view the status of all accounts by issuing the following SQL statement:
SQL> SELECT username, account_status FROM dba_users ORDER BY username;
To lock and expire passwords, issue the following SQL statement:
SQL> ALTER USER username PASSWORD EXPIRE ACCOUNT LOCK;
If you are currently using a traditional initialization parameter file, then perform the following steps to migrate to a server parameter file:
If the initialization parameter file is located on a client computer, then transfer the file from the client computer to the server computer.
Note:
If you are using Oracle Real Application Clusters, then you must combine all of your instance-specific initialization parameter files into a single initialization parameter file. Instructions for doing this, and other actions unique to using a server parameter file for cluster databases, are discussed in:Oracle Real Application Clusters Administration and Deployment Guide
The Real Application Cluster installation guide for your operating system
Create a server parameter file using the CREATE SPFILE
statement. This statement reads the initialization parameter file to create a server parameter file. You are not required to start the database to issue a CREATE SPFILE
statement.
Start up the instance using the newly-created server parameter file.
See Also:
Oracle Database Administrator's Guide for more information about creating server parameter files
Oracle Database SQL Language Reference for information about the CREATE SPFILE
statement
After an upgrade to the new Oracle Database 11g release, copy the following files from the previous Oracle home to the new Oracle home:
Stemming user-dictionary files
User-modified KOREAN_MORPH_LEXER
dictionary files
USER_FILTER
executables
These files affect all databases installed in the given Oracle home.
You can obtain a list of the above files by:
Looking at $ORACLE_HOME/ctx/admin/ctxf102.txt
Executing $ORACLE_HOME/ctx/admin/ctxf102.sql
as database user SYS
, SYSTEM
, or CTXSYS
If your Oracle Text index uses KOREAN_LEXER
which was deprecated in Oracle 9i and desupported in Oracle Database 10g Release 2 (10.2), see Support Note 300172.1 for further information on manual migration from KOREAN_LEXER
to KOREAN_MORPH_LEXER
.
See Also:
Oracle Text Reference for more information about these files
Oracle Text Application Developer's Guide for information about upgrading your applications from previous releases of Oracle Text
If you are using Oracle Clusterware, then you must upgrade the Oracle Cluster Registry (OCR) keys for the database.
Use one of the following options to upgrade the OCR configuration to the new Oracle Database 11g release:
Use srvconfig
from the Oracle Database 11g Release 2 (11.2) Oracle home. For example:
% srvconfig -upgrade -dbname db_name -orahome pre-11g_Oracle_home
Run srvctl
. For example:
pre-11g_Oracle_home/bin/srvctl remove database -d db_name 11g_Oracle_home/bin/srvctl add database -d db_name -o 11g_Oracle_home 11g_Oracle_home/bin/srvctl add instance -d db_name -i instance -n node
Each release of Oracle Database introduces new initialization parameters, deprecates some initialization parameters, and makes some initialization parameters obsolete. You should adjust the parameter file to account for these changes and to take advantage of new initialization parameters that might be beneficial to your system.
See Also:
The "What's New in Oracle Database Reference" section of Oracle Database Reference for a list of the new initialization parameters in the new Oracle Database 11g release, and for information about each parameter
Appendix A, "Behavior Changes" for lists of obsolete and deprecated initialization parameters in the new Oracle Database 11g release
The COMPATIBLE
initialization parameter controls the compatibility level of your database. When you are certain that you no longer need the ability to downgrade your database to its original release, set the COMPATIBLE
initialization parameter based on the compatibility level you want for your new database.
Complete the following steps to set the COMPATIBLE
initialization parameter to a higher value:
Perform a backup of your database before you raise the COMPATIBLE
initialization parameter (optional).
Raising the COMPATIBLE
initialization parameter might cause your database to become incompatible with earlier releases of Oracle Database, and a backup ensures that you can return to the earlier release if necessary.
See Also:
Oracle Database Backup and Recovery User's Guide for more information about performing a backupIf you are using a server parameter file, then complete the following steps:
Update the server parameter file to set or change the value of the COMPATIBLE
initialization parameter.
For example, to set the COMPATIBLE
initialization parameter to 11.0.0
, enter the following statement:
SQL> ALTER SYSTEM SET COMPATIBLE = '11.0.0' SCOPE=SPFILE;
Shut down and restart the instance.
Note:
When upgrading systems with HARD-compliant storage (Hardware Assisted Resilient Data), consider the following:If the COMPATIBLE
parameter is set to a release number earlier than 11.0.0, then you cannot locate the server parameter file (SPFILE
) on HARD storage.
If the COMPATIBLE
parameter is set to 11.0.0, then you can optionally locate the server parameter file on HARD storage.
Because the default SPFILE
location (ORACLE_HOME/dbs) might not be on a HARD-compliant storage system, it is likely you must provide a parameter file that specifies the location of the SPFILE
.
See Also:
Oracle Database High Availability Overview or Oracle Database Concepts for more information on HARD storageIf you are using an initialization parameter file, then complete the following steps:
Shut down the instance if it is running:
SQL> SHUTDOWN IMMEDIATE
Edit the initialization parameter file to set or change the value of the COMPATIBLE
initialization parameter.
For example, to set the COMPATIBLE
initialization parameter to 11.0.0
, enter the following in the initialization parameter file:
COMPATIBLE = 11.0.0
Start the instance using STARTUP
.
If you are not yet using Oracle Enterprise Manager to manage your database, then install and configure Enterprise Manager Database Control.
If your database is being managed by Oracle Enterprise Manager Database Control or Oracle Enterprise Manager Grid Control, then use the following command to update the configuration:
emca -upgrade (db | asm | db_asm) [-cluster] [-silent] [parameters]
You need to run this from the Oracle home of the new Oracle Database 11g release. When prompted, provide the Oracle home from which the configuration is being upgraded.
You can also configure Enterprise Manager using DBCA. Select the Configure Database Options option, and then select the Enterprise Manager Repository option.
In "Prepare the New Oracle Home", you were instructed to set the CLUSTER_DATABASE
initialization parameter to false
before upgrading a cluster database. Now that the upgrade is finished, you must set this parameter to true
.
The following tasks are required after an ASM Upgrade:
If your operating system is Linux or UNIX, then make sure that the following environment variables point to the directories of the new Oracle Database 11g release:
ORACLE_HOME
PATH
Also check that your oratab
file and any client scripts that set the value of ORACLE_HOME
point to the Oracle home of the new Oracle Database 11g release.
Note:
TheORACLE_HOME
, PATH
, and oratab
checks are required only if you upgrade manually. DBUA automatically points oratab
to the new Oracle home. Client scripts must be checked no matter how you upgrade.
If you are upgrading a clustered ASM, then perform these checks on all nodes in which this clustered ASM has instances configured.
See Also:
Your operating system-specific Oracle Database installation documents for information about setting other important environment variables on your operating system.If ASM version 10.2 is installed in Oracle Home 1 (OH1
) and the operating system user is orauser
, execute the following steps:
As orauser
, upgrade ASM to release 11.2 using OUI and DBUA. The new ASM release 11.2 should be running in a new Oracle Home 2 (OH2
). ASM should still be running as orauser
.
As orauser
, bring down the ASM instance and the listener.
As root
, run /etc/init.d/init.cssd stop
to stop CSS.
As a new user (asmuser
), install 11.2 in a third Oracle Home (OH3
). This should be a software-only installation.
As root
, run localconfig reset
from OH3
.
Update /etc/oratab
so that OH3
is the Oracle home with the +ASM
entry.
Copy listener.ora
, sqlnet.ora
, and tnsnames.ora
from OH2
.
Run EMCP to change the ASM instance path and connect-string
role.
Make sure the disks are owned by asmuser
and by OSDBA for ASM. They should also have the O660
permission set.
As asmuser
, start the listener.
As asmuser
, start ASM (connect as SYSASM
).
Run the command, GRANT sysasm TO sys
.
For cluster ASM upgrade, execute the following steps:
As orauser
, upgrade ASM to release 11.2 using OUI and DBUA. The new ASM release 11.2 should be running in a new Oracle Home 2 (OH2
). ASM should still be running as orauser
.
Bring down the ASM and Listener resources from CRS home.
As a new user (asmuser
), install 11.2 in a third Oracle Home (OH3
). This should be a software-only installation.
From CRS home, run:
srvctl remove listener -n node_name srvctl add listener -n node_name -o OH3 srvctl modify asm -n node_name -i ASM_instance_name -o ORACLE_HOME_path
Update /etc/oratab
so that OH3
is the Oracle home with the +ASM
entry.
Copy listener.ora
, sqlnet.ora
, and tnsnames.ora
from OH2
.
Run EMCP to change the ASM instance path and connect-string
role.
Make sure the disks are owned by asmuser
and by OSDBA for ASM. They should also have the O660
permission set.
Start ASM and Listener resources from the new ASM 11g ORACLE_HOME or the new Oracle Database 11g ORACLE_HOME.
Run the command, GRANT sysasm TO sys
.
If you have clustered ASM instances, then you also have the option of performing a rolling ASM upgrade. A rolling upgrade enables you to independently upgrade or patch ASM nodes without affecting database availability, thus providing greater uptime.
See Also:
Oracle Database Storage Administrator's Guide for more information on rolling ASM upgradesPerforming the following tasks is recommended, but not required, after you have upgraded ASM:
You should also consider performing the following tasks, discussed earlier in this chapter:
Starting with Oracle Database 11g Release 1 (11.1), you can enforce case sensitivity for passwords. For example, the password hPP5620qr
fails if it is entered as hpp5620QR
or hPp5620Qr
. In previous releases, passwords were not case sensitive.
To take advantage of enforced case-sensitive passwords, you must reset the passwords of existing users during the database upgrade procedure. For new ASM instances, there are no additional tasks or management requirements. For upgraded ASM instances, each user password must be reset with an ALTER
USER
statement.
Note:
If the default Oracle Database 11g security settings are in place, then passwords must be at least 8 characters, and passwords such aswelcome
and oracle
are not allowed. See Oracle Database Security Guide for more information.See Also:
Oracle Database Security GuideStarting with Oracle Database 11g Release 1 (11.1), you can advance the Oracle Database and the ASM disk group compatibility settings across software versions.
Advancing compatibility enables new features only available in the new version. However, it makes the disk group incompatible with older versions of the software. Note that advancing on-disk compatibility is an irreversible operation.
You use the compatible.rdbms
and compatible.asm
attributes to specify the minimum software version required by the database instance and the ASM instance, respectively, to access the disk group. For example, the following ALTER DISKGROUP
statement advances the ASM compatibility of the disk group asmdg2
:
ALTER DISKGROUP asmdg2 SET ATTRIBUTE 'compatible.asm' = '11.1'
In this case, the disk group can be managed only by ASM software of version 11.1 or higher, while any database client of version 10.1 or higher can use the disk group.
See Also:
Oracle Database Storage Administrator's Guide for complete information about disk group compatibility, and Oracle Database SQL Language Reference for more information about the disk group compatibility attributes on theALTER DISKGROUP
and CREATE DISKGROUP
statementsASM administrators can specify some disks to be preferred over others for read I/O operations. When ASM preferred read failure groups are defined, ASM can read from the extent that is closest to it, rather than always reading the primary copy.
See Also:
Oracle Clusterware Administration and Deployment Guide for information about specifying failure groups settings in an extended cluster
Oracle Database Storage Administrator's Guide for complete information about ASM preferred read failure groups, and specifying the new ASM_PREFERRED_READ_FAILURE_GROUPS
initialization parameter to list failure group names that contain the preferred read disks for each node in a cluster
Oracle Database Reference for the ASM_PREFERRED_READ_FAILURE_GROUPS
initialization parameter
If you separate the operating system ownership of Oracle homes belonging to ASM and to one or more databases, then you must migrate the operating system user of an upgraded ASM or database home by executing the steps in the following section:
If you are migrating to an environment with separate operating system users, you must upgrade the database after upgrading ASM. The database user must be a member of OSDBA for ASM.
There are three scenarios to consider:
Changing the Operating System User For a Single-Instance Database
Changing the Operating System User for an Oracle RAC Database
See Also:
Oracle Database Storage Administrator's Guide for information on making an ASM disk group compatible with Oracle Database 10g and Oracle Database 11gIf you are maintaining the operating system user as orauser
, run DBUA to upgrade the database from 10.2 to 11.1 in a new Oracle Home (OH4
) which is separate from the ASM Oracle Home (OH3
).
Consider your 10.2 database is installed in Oracle Home 4 (OH4
) and currently running orauser
as the operating system user:
As orauser
, run DBUA to upgrade the database from 10.2 to 11.1 in a new Oracle Home (OH5
).
As orauser
, bring down the database instance.
As newuser
, install 11.1 in a separate Oracle Home (OH6
).
Update /etc/oratab
to that OH6
is the Oracle home with the database entry.
Copy sqlnet.ora
. Update listener.ora so that all occurrences of OH5
are now OH6
.
Modify the SPFILE
in the ASM disk group to use OH6
instead of OH5
.
Copy the password file from OH5
to OH6
.
Run EMCP to change ASM instance path and connect-string
role.
Start the database instance.
This is useful if you have two databases using ASM. If needed, the user can change the operating system user of the database in order to allow separate databases to run as separate operating system users.
Consider your 10.2 database is installed in Oracle Home 4 (OH4
) and currently running orauser
as the operating system user:
As orauser
, run DBUA to upgrade the database from 10.2 to 11.1 in a new Oracle Home (OH5
).
As orauser
, bring down the database instance.
Run srvctl remove <
db-name
>
.
As newuser
, install 11.1 in a separate Oracle Home (OH6
).
Update /etc/oratab
to that OH6
is the Oracle home with the database entry.
Copy sqlnet.ora
. Update listener.ora so that all occurrences of OH5
are now OH6
.
Modify the SPFILE
in the ASM disk group to use OH6
instead of OH5
.
Copy the password file from OH5
to OH6
.
Run EMCP to change ASM instance path and connect-string
role.
Run srvctl add <
db-name
>
.
Start the database instance.
If you are performing a manual upgrade, then you must perform the following tasks after ASM is upgraded:
Upgrade the Oracle Cluster Registry (OCR) Configuration for ASM
Adjust the ASM Initialization Parameter File for the New Release
Install and Configure Enterprise Manager Database Control for ASM
If you are using Oracle Clusterware, then you must upgrade the Oracle Cluster Registry (OCR) keys for ASM by running the following command:
srvctl modify asm -n node [-p spfile] -o asm_home -i instance
The -p
option is necessary only if you are using an SPFILE
and it was moved.
Each release of Oracle Database introduces new initialization parameters, deprecates some initialization parameters, and makes some initialization parameters obsolete. You should adjust the parameter file to account for these changes and to take advantage of new initialization parameters that might be beneficial to your system.
See Also:
The "What's New in Oracle Database Reference" section in Oracle Database Reference for a list of the new initialization parameters in the new Oracle Database 11g release, and for information about each parameter
Appendix A, "Behavior Changes" for lists of obsolete and deprecated initialization parameters in the new Oracle Database 11g release
If you want to use Enterprise Manager Database Control with ASM, then you must install and configure it.
See Also:
Oracle Enterprise Manager Advanced Configuration for information on configuring Enterprise Manager Database Control