Skip Headers
Oracle® Database Upgrade Guide
11g Release 1 (11.1)

Part Number B28300-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

4 After Upgrading to the New Release

This chapter guides you through the procedures to perform after you have completed an upgrade of your database. The following topics are discussed:

Required Tasks After Database Upgrades

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

Update Environment Variables (Linux and UNIX Systems Only)

If your operating system is Linux or UNIX, then make sure that the following environment variables point to the new Oracle Database 11g Release 1 (11.1) directories:

  • ORACLE_HOME

  • PATH

Also check that your oratab file and any client scripts that set the value of ORACLE_HOME point to the Oracle Database 11g Release 1 (11.1) home.

Note:

The ORACLE_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.

Upgrade the Recovery Catalog

For complete information about upgrading the recovery catalog and the UPGRADE CATALOG command, see the Oracle Database Backup and Recovery User's Guide.

Upgrade Statistics Tables Created by the DBMS_STATS Package

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.

Upgrade Externally Authenticated SSL Users

If you are upgrading from Oracle Database9i 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 the extusrupgrade script

Install Oracle Text Supplied Knowledge Bases

The Oracle Text supplied knowledge bases are part of the companion Oracle Database 11g Release 1 (11.1) products and are not immediately available after an upgrade to Oracle Database 11g Release 1 (11.1). Any Oracle Text features dependent on the supplied knowledge bases which were available before the upgrade do not function after the upgrade. To reenable 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:

Update Your Oracle Application Express Configuration

If your database originally included Application Express Version 3.0, there is no additional configuration necessary after upgrading to Oracle Database 11g Release 1 (11.1).

If your database was not an Oracle Express Edition (XE) database, but contained a prior version of Application Express (HTML DB), then version 3.0 is automatically installed during the upgrade. You must complete a series of post-installation steps to configure Application Express Version 3.0 for use with Oracle Database 11g. These steps are described in the section on post-installation tasks in the Oracle Database Application Express Installation Guide.

If your database was an Oracle Express Edition (XE) database, it contained a prior version of Application Express tailored for the XE environment. Refer to the OTN document describing the differences between Oracle Database XE Application Express and Application Express 3.0 at:

http://www.oracle.com/technology/products/database/application_express/html/upgrade_apex_for_xe.html

The database administration features available with the XE version of Application Express are not available in version 3.0, but Oracle Enterprise Manager DB Control can, optionally, be installed to provide a graphical interface for database administration.

Configure Fine-Grained Access to External Network Services

Oracle Database 11g Release 1 (11.1) 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 B

Enable Oracle Database Vault

If you use Oracle Database Vault, then you were instructed to disable it before upgrading your database. You must now enable Database Vault again.

See Also:

Deploy Database Vault Administrator (DVA)

You can manually deploy Database Vault Administrator (DVA) to the following Oracle Application Server Containers for J2EE (OC4J) home:

$ORACLE_HOME/oc4j/j2ee/home

Use the following steps to manually deploy the DVA application:

  1. Edit the file, $ORACLE_HOME/oc4j/j2ee/home/config/server.xml. Enter the following line just before the last line that reads, </application-server>:

    <application name="dva" path="$ORACLE_HOME/dv/jlib/dva_webapp.ear" auto-start="true" />
    
    

    For example:

    <application name="dva" path="/u00/app/oracle/oracle/product/dv12/dv/jlib/dva_webapp.ear" auto-start="true" />
    
    
  2. Edit the file, $ORACLE_HOME/oc4j/j2ee/home/config/http-web-site.xml. Enter the following line just above the last line that reads, </web-site>:

    <web-app application="dva" name="dva_webapp" root="/dva" />
    
    
  3. Edit the file, $ORACLE_HOME/oc4j/j2ee/home/config/global-web-application.xml. Search for <servlet-class>oracle.jsp.runtimev2.JspServlet</servlet-class>. Uncomment the following lines after this:

    <init-param>
       <param-name>main_mode</param-name>
       <param-value>justrun</param-value>
    </init-param>
    
    
  4. Create the following directory:

    mkdir -p $ORACLE_HOME/dv/jlib/sysman/config
    
    
  5. Create the database connection configuration file, emoms.properties, in the configuration directory that you just created. Add the following lines to the file:

    oracle.sysman.emSDK.svlt.ConsoleMode=standalone
    oracle.sysman.eml.mntr.emdRepRAC=FALSE
    oracle.sysman.eml.mntr.emdRepDBName=ORACLE_SID
    oracle.system.eml.mntr.emdRepConnectDescriptor=TNS_connection_string
    
    

    Note:

    • oracle.sysman.eml.mntr.emdRepRAC should be set to TRUE for Oracle Real Application Clusters database.

    • For oracle.sysman.eml.mntr.emdRepConnectDescriptor, you can use an alias from $ORACLE_HOME/network/admin/tnsnames.ora. Alternatively, you can use the following syntax:

      oracle.sysman.eml.mntr.emdRepConnectDescriptor=(DESCRIPTION\=(ADDRESS_LIST\=(ADDRESS\=(PROTOCOL\=TCP) (HOST\=HOSTNAME)(PORT\=PORT))) (CONNECT_DATA\=(SERVICE_NAME\=ORACLE_SID)))
      
  6. Start OC4J. Before starting OC4J, ensure that the correct environment variables are set. For example:

    ORACLE_SID=orcl
    export ORACLE_SID
    ORACLE_HOME=/u00/app/oracle/product/10.2/dv
    export ORACLE_HOME
    LD_LIBRARY_PATH=$ORACLE_HOME/bin:$ORACLE_HOME/lib:$ORACLE_HOME/jdbc/lib
    export LD_LIBRARY_PATH
    PATH=$ORACLE_HOME/bin:$ORACLE_HOME/jdk/bin:$PATH
    export PATH
    

    Note:

    LD_LIBRARY_PATH must be set to use the OCI-based JDBC libraries.

    Start OC4J using the following syntax:

    $ORACLE_HOME/jdk/bin/java -Djava.awt.headless=true -DEMDROOT=$ORACLE_HOME/dv/jlib -jar $ORACLE_HOME/oc4j/j2ee/home/oc4j.jar -userThreads -config $ORACLE_HOME/oc4j/j2ee/home/config/server.xml
    
    
  7. You can now access the DVA application. The HTTP port defaults to 8888 for this environment. Use the following URL:

    http://hostname:8888/dva
    

Recommended Tasks After Database Upgrades

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 All Database Upgrades

Performing the following tasks is recommended, but not required, after you have upgraded your database.

Back Up the 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 database

Reset Passwords to Enforce Case-Sensitivity

Beginning in 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.

Note:

If the default Oracle Database 11g Release 1 (11.1) security settings are in place, then passwords must be at least 8 characters, and passwords such as welcome and oracle are not allowed. See Oracle Database Security Guide for more information.

Upgrade Automatic Storage Management (ASM)

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

Add New Features as Appropriate

Oracle Database New Features Guide describes many of the new features available in Oracle Database 11g Release 1 (11.1). 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 6, "Upgrading Your Applications" describes ways to enhance your applications so that you can take advantage of new Oracle Database 11g Release 1 (11.1) features. However, before you implement new features, test your applications and successfully run them with the upgraded database.

Develop New Administrative Procedures as Needed

After familiarizing yourself with Oracle Database 11g Release 1 (11.1) features, 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.

Set Threshold Values for Tablespace Alerts

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

Migrate From Rollback Segments to Automatic Undo Mode

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 Release 1 (11.1).

  • 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:

  1. Set UNDO_MANAGEMENT=MANUAL.

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

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

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

  5. For Oracle Real Application Clusters (Oracle RAC) configurations, repeat these steps on all instances.

Configure Oracle Data Guard Broker

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.

Migrate Tables from the LONG Data Type to the LOB Data Type

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 data

Recommended Tasks After Upgrading a 10g Release 1 (10.1) Database

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

Upgrade Change Data Capture

Beginning 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 Oracle Database9i Release 2 (9.2) system as a source.

See the Oracle Database Data Warehousing Guide for complete information about how to upgrade an Oracle Database9i Release 2 (9.2) or Oracle Database 10g Release 1 (10.1) database to Oracle Database 11g Release 1 (11.1) with Change Data Capture. The discussion describes the supported configurations for the Distributed HotLog mode of Change Data Capture as well as the restrictions.

Configure Secure HTTP

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:

  1. Enable the HTTP listener and the database to use SSL

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

Provide Anonymous Access to XML DB Repository Data Through HTTP

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 releases, 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 10g Release 2. 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 the allow-repository-anonymous-access element and configuring Oracle XML DB

Recommended Tasks After Upgrading an Oracle Express Edition Database

An Oracle Express Edition database contains only a subset of the components available in a Standard Edition or Enterprise Edition database. After upgrading to Oracle Database 11g Release 1 (11.1), 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.

Tasks to Complete Only After Manual Database Upgrades

If you are performing a manual upgrade rather than using DBUA, then you must perform the following tasks after your database is upgraded:

Change Passwords for Oracle-Supplied Accounts

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 Release 1 (11.1) security settings are in place, then passwords must be at least 8 characters, and passwords such as welcome 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;

Migrate Your Initialization Parameter File to a Server Parameter File

If you are currently using a traditional initialization parameter file, then perform the following steps to migrate to a server parameter file:

  1. 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:
  2. 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.

  3. Start up the instance using the newly-created server parameter file.

See Also:

Upgrade Oracle Text

After an upgrade to Oracle Database 11g Release 1 (11.1), 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:

  1. Looking at $ORACLE_HOME/ctx/admin/ctxf102.txt

  2. 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 10g Release 2, see Support Note 300172.1 for further information on manual migration from KOREAN_LEXER to KOREAN_MORPH_LEXER.

See Also:

Upgrade the Oracle Cluster Registry (OCR) Configuration

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 11g:

  • Use srvconfig from the Oracle Database 11g Release 1 (11.1) 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
    

Adjust the Initialization Parameter File for the New Release

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 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 version, set the COMPATIBLE initialization parameter based on the compatibility level you want for your new database.

Configure Enterprise Manager

If you are not yet using Oracle Enterprise Manager to manage your database, 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 new Oracle Database 11g Oracle Home. When prompted, provide the Oracle home from which the configuration is being upgraded.

Set CLUSTER_DATABASE Initialization Parameter

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.

Required Tasks After ASM Upgrades

If your operating system is Linux or UNIX, then make sure that the following environment variables point to the new Oracle Database 11g Release 1 (11.1) directories:

Also check that your oratab file and any client scripts that set the value of ORACLE_HOME point to the Oracle Database 11g Release 1 (11.1) home.

Note:

The ORACLE_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.

Recommended Tasks After ASM Upgrades

Performing 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:

Reset ASM Passwords to Enforce Case-Sensitivity

Beginning in 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 Release 1 (11.1) security settings are in place, then passwords must be at least 8 characters, and passwords such as welcome and oracle are not allowed. See Oracle Database Security Guide for more information.

Advance the ASM and Oracle Database Disk Group Compatibility

Beginning 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 the ALTER DISKGROUP and CREATE DISKGROUP statements

Set Up ASM Preferred Read Failure Groups

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

Both the ASM clients and ASM require Oracle Database 11g Release 1 (11.1) or higher to use the preferred read feature. The compatible.asm and compatible.rdbms attributes are the disk group attributes that must be advanced to release 11.1 to use this new feature.

See Also:

Optional Tasks After ASM Upgrade

If you separate the operating system ownership of Oracle homes belonging to ASM and to one or more databases, you need to migrate the operating system user of an upgraded ASM or database home by executing the steps in the following sections:

Single-Instance ASM Upgrade

If ASM version 10.2 is installed in Oracle Home 1 (OH1) and the operating system user is orauser, execute the following steps:

  1. As orauser, upgrade ASM to release 11.1 using OUI and DBUA. The new ASM release 11.1 should be running in a new Oracle Home 2 (OH2). ASM should still be running as orauser.

  2. As orauser, bring down the ASM instance and the listener.

  3. As root, run /etc/init.d/init.cssd stop to stop CSS.

  4. As a new user (asmuser), install 11.1 in a third Oracle Home (OH3). This should be a software-only installation.

  5. As root, run localconfig reset from OH3.

  6. Update /etc/oratab so that OH3 is the Oracle home with the +ASM entry.

  7. Copy listener.ora, sqlnet.ora, and tnsnames.ora from OH2.

  8. Copy spfile+ASM.ora and init+ASM.ora to the new OH3/dbs. Update these two files so that any reference to OH2 is changed to OH3.

  9. Copy orapw+ASM file from OH2 to OH3.

  10. Run EMCP to change the ASM instance path and connect-string role.

  11. Make sure the disks are owned by asmuser and by OSDBA for ASM. They should also have the O660 permission set.

  12. As asmuser, start the listener.

  13. As asmuser, start ASM (connect as SYSASM).

  14. Run the command, GRANT sysasm TO sys.

Cluster ASM Upgrade

For cluster ASM upgrade, execute the following steps:

  1. As orauser, upgrade ASM to release 11.1 using OUI and DBUA. The new ASM release 11.1 should be running in a new Oracle Home 2 (OH2). ASM should still be running as orauser.

  2. Bring down the ASM and Listener resources from CRS home.

  3. As a new user (asmuser), install 11.1 in a third Oracle Home (OH3). This should be a software-only installation.

  4. Execute the following:

    1. As orauser, from 10.2 Oracle home, run:

      srvctl modify instance -d <db-name> -i <db-inst-sid> -n <node-name> -r
      
      
    2. From CRS home, run:

      srvctl remove listener -n <node-name>
      srvctl add listener -n <node-name> -o <OH3>
      srvctl remove asm -n <node-name>
      srvctl add asm -n <node-name> -i <asm-sid> -o <OH3>
      
      
    3. As asmuser, from 10.2 Oracle home, run:

      srvctl modify instance -d <db-name> -i <db-inst-sid> -s <asm-sid>
      
      

    Repeat these steps for each node.

  5. Update /etc/oratab so that OH3 is the Oracle home with the +ASM entry.

  6. Copy listener.ora, sqlnet.ora, and tnsnames.ora from OH2.

  7. Copy spfile+ASM.ora and init+ASM.ora to the new OH3/dbs. Update these two files so that any reference to OH2 is changed to OH3.

  8. Copy orapw+ASM file from OH2 to OH3.

  9. Run EMCP to change the ASM instance path and connect-string role.

  10. Make sure the disks are owned by asmuser and by OSDBA for ASM. They should also have the O660 permission set.

  11. Start ASM and Listener resources from CRS home.

  12. As asmuser, start ASM (connect as SYSASM).

  13. Run the command, GRANT sysasm TO sys.

Database Upgrade After ASM Upgrade

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:

Keeping orauser as the Operating System User

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

Changing the Operating System User For a Single-Instance Database

Consider your 10.2 database is installed in Oracle Home 4 (OH4) and currently running orauser as the operating system user:

  1. As orauser, run DBUA to upgrade the database from 10.2 to 11.1 in a new Oracle Home (OH5).

  2. As orauser, bring down the database instance.

  3. As newuser, install 11.1 in a separate Oracle Home (OH6).

  4. Update /etc/oratab to that OH6 is the Oracle home with the database entry.

  5. Copy sqlnet.ora. Update listener.ora so that all occurrences of OH5 are now OH6.

  6. Modify the SPFILE in the ASM disk group to use OH6 instead of OH5.

  7. Copy the password file from OH5 to OH6.

  8. Run EMCP to change ASM instance path and connect-string role.

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

Changing the Operating System User for an Oracle RAC Database

Consider your 10.2 database is installed in Oracle Home 4 (OH4) and currently running orauser as the operating system user:

  1. As orauser, run DBUA to upgrade the database from 10.2 to 11.1 in a new Oracle Home (OH5).

  2. As orauser, bring down the database instance.

  3. Run srvctl remove <db-name>.

  4. As newuser, install 11.1 in a separate Oracle Home (OH6).

  5. Update /etc/oratab to that OH6 is the Oracle home with the database entry.

  6. Copy sqlnet.ora. Update listener.ora so that all occurrences of OH5 are now OH6.

  7. Modify the SPFILE in the ASM disk group to use OH6 instead of OH5.

  8. Copy the password file from OH5 to OH6.

  9. Run EMCP to change ASM instance path and connect-string role.

  10. Run srvctl add <db-name>.

  11. Start the database instance.

Tasks to Complete Only After Manual ASM Upgrades

If you are performing a manual upgrade rather than using DBUA, then you must perform the following tasks after ASM is upgraded:

Upgrade the Oracle Cluster Registry (OCR) Configuration 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.

Adjust the ASM Initialization Parameter File for the New Release

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:

Install and Configure Enterprise Manager Database Control for ASM

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