12 Using SQL Apply to Upgrade the Oracle Database

12.1 Benefits of a Rolling Upgrade Using SQL Apply

Performing a rolling upgrade with SQL Apply provides several advantages:

• Your database will incur very little downtime. The overall downtime can be as little as the time it takes to perform a switchover.

• You eliminate application downtime due to PL/SQL recompilation.

• You can validate the upgraded database release without affecting the primary database.

12.2 Requirements to Perform a Rolling Upgrade Using SQL Apply

The rolling upgrade procedure requires the following:

• A primary database that is running Oracle Database release x and a logical standby database that is running Oracle Database release y.

• The databases must not be part of a Data Guard Broker configuration. See Oracle Data Guard Broker for information about removing databases from a broker configuration.

• The Data Guard protection mode must be set to either maximum availability or maximum performance. Query the PROTECTION_LEVEL column in the V$DATABASE view to find out the current protection mode setting.

• To ensure the primary database can proceed while the logical standby database is being upgraded, the LOG_ARCHIVE_DEST_n initialization parameter for the logical standby database destination must not be set to MANDATORY.

• The COMPATIBLE initialization parameter must match the software release prior to the upgrade. That is, a rolling upgrade from release x to release y requires that the COMPATIBLE initialization parameter be set to release x on both the primary and standby databases.

12.3 Figures and Conventions Used in the Upgrade Instructions

Figure 12-1 shows a Data Guard configuration before the upgrade begins, with the primary and logical standby databases both running the same Oracle Database software release.

Figure 12-1 Data Guard Configuration Before Upgrade

Description of "Figure 12-1 Data Guard Configuration Before Upgrade"

During the upgrade process, the Data Guard configuration operates with mixed database releases at several points in this process. Data protection is not available across releases. During these steps, consider having a second standby database in the Data Guard configuration to provide data protection.

The steps and figures describing the upgrade procedure refer to the databases as "Database A" and "Database B" rather than as the "primary database" and "standby database." This is because the databases switch roles during the upgrade procedure. Initially, Database A is the primary database and Database B is the logical standby database, as shown in Figure 12-1.

The following sections describe scenarios in which you can use the SQL Apply rolling upgrade procedure:

• Section 12.4, "Performing a Rolling Upgrade By Creating a New Logical Standby Database"

• Section 12.5, "Performing a Rolling Upgrade With an Existing Logical Standby Database"

• Section 12.6, "Performing a Rolling Upgrade With an Existing Physical Standby Database"

12.4 Performing a Rolling Upgrade By Creating a New Logical Standby Database

This scenario assumes that you do not have an existing Data Guard configuration, but you are going to create a logical standby database solely for the purpose of performing a rolling upgrade of the Oracle Database.

Perform the following steps to prepare the primary and standby databases for upgrading.

Step 1   Identify unsupported data types and storage attributes

To identify unsupported database objects on the primary database and decide how to handle them, follow these steps:

1. Identify unsupported data types and storage attributes for tables:

   • Review the list of supported data types and storage attributes provided in Appendix C, "Data Type and DDL Support on a Logical Standby Database".

   • Query the DBA_LOGSTDBY_UNSUPPORTED and DBA_LOGSTDBY_SKIP views on the primary database. Changes that are made to the listed tables and schemas on the primary database will not be applied on the logical standby database. The following query shows an example of a list of unsupported tables:

     SQL> SELECT DISTINCT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED;
     OWNER      TABLE_NAME
     ---------- -----------------
     OE         CATEGORIES_TAB
     OE         CUSTOMERS
     OE         WAREHOUSES
     PM         ONLINE_MEDIA
     PM         PRINT_MEDIA
     SCOTT      MYCOMPRESS
     SH         MVIEW$_EXCEPTIONS
     7 rows selected.
     
     SQL> 
     SQL> SELECT OWNER FROM DBA_LOGSTDBY_SKIP
       2   WHERE STATEMENT_OPT = 'INTERNAL SCHEMA';
     
     OWNER
     ------------------------------
     CTXSYS
     DBSNMP
     DIP
     ORDPLUGINS
     ORDSYS
     OUTLN
     SI_INFORMTN_SCHEMA
     SYS
     SYSTEM
     WMSYS
     10 rows selected.
     

2. Decide how to handle unsupported tables.

   If unsupported objects are being modified on your primary database, it might be possible to perform the upgrade anyway by temporarily suspending changes to the unsupported tables for the period of time it takes to perform the upgrade procedure.

   If you can prevent changes to unsupported changes, then using SQL Apply might still be a viable way to perform the upgrade procedure. This method requires that you prevent users from modifying any unsupported tables from the time you create the logical standby control file to the time you complete the upgrade. For example, assume that the Payroll department updates an object table, but that department updates the database only Monday through Friday. However, the Customer Service department requires database access 24 hours a day, 7 days a week, but uses only supported data types and tables. In this scenario, you could perform the upgrade over a weekend. You can monitor transaction activity in the DBA_LOGSTDBY_EVENTS view and discontinue the upgrade (if necessary) up to the time you perform the first switchover.

   If you cannot prevent changes to unsupported tables during the upgrade, any unsupported transactions that occur are recorded in the DBA_LOGSTDBY_EVENTS table on the logical standby database. After the upgrade is completed, you might be able to use Oracle Data Pump or the Export/Import utility to import the changed tables to the upgraded databases.

   The size of the changed tables will determine how long database operations will be unavailable, so you must decide if a table is too large to export and import its data into the standby database. For example, a 4-terabyte table is not a good candidate for the export/import process.

Step 2   Create a logical standby database

To create a logical standby database, follow the instructions in Chapter 4.

Oracle recommends configuring a standby redo log on the logical standby database to minimize downtime.

Step 3   Perform a rolling upgrade

Now that you have created a logical standby database, you can follow the procedure described in Section 12.5, "Performing a Rolling Upgrade With an Existing Logical Standby Database", which assumes that you have a logical standby running the same Oracle software.

12.5 Performing a Rolling Upgrade With an Existing Logical Standby Database

This section provides a step-by-step procedure for upgrading the logical standby database and the primary database. Table 12-1 lists the steps.

Step 1   Prepare for rolling upgrade

Follow these steps to prepare to perform a rolling upgrade of Oracle Software:

1. Stop SQL Apply by issuing the following statement on the logical standby database (Database B):

   SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
   

2. Set compatibility, if needed, to the highest value.

   Ensure the COMPATIBLE initialization parameter specifies the release number for the Oracle Database software running on the primary database prior to the upgrade.

   For example, if the primary database is running release 10.1, then set the COMPATIBLE initialization parameter to 10.1 on both databases. Be sure to set the COMPATIBLE initialization parameter on the standby database first before you set it on the primary database.

Step 2   Upgrade the logical standby database

Upgrade Oracle database software on the logical standby database (Database B) to release y. While the logical standby database is being upgraded, it will not accept redo data from the primary database.

Step 3   Obtain information about unsupported tables

Oracle recommends that you use the DBMS_LOGSTDBY PL/SQL procedure on Database B to capture information about transactions running on the primary database that will not be supported by a logical standby database. Run the following procedures to capture and record the information as events in the DBA_LOGSTDBY_EVENTS table:

EXEC DBMS_LOGSTDBY.APPLY_SET('MAX_EVENTS_RECORDED',DBMS_LOGSTDBY.MAX_EVENTS);
EXEC DBMS_LOGSTDBY.APPLY_SET('RECORD_UNSUPPORTED_OPERATIONS', 'TRUE');

To upgrade Oracle database software, refer to the Oracle Database Upgrade Guide for the applicable Oracle Database release.

Figure 12-2 shows Database A running release x, and Database B running release y. During the upgrade, redo data accumulates on the primary system.

Figure 12-2 Upgrade the Logical Standby Database Release

Description of "Figure 12-2 Upgrade the Logical Standby Database Release"

Step 4   Restart SQL Apply on the upgraded logical standby database

Restart SQL Apply and operate with release x on Database A and release y on Database B. To start SQL Apply, issue the following statement on Database B:

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

The redo data that was accumulating on the primary system is automatically transmitted and applied on the newly upgraded logical standby database. The Data Guard configuration can run the mixed releases shown in Figure 12-3 for an arbitrary period while you verify that the upgraded Oracle Database software release is running properly in the production environment.

Figure 12-3 Running Mixed Releases

Description of "Figure 12-3 Running Mixed Releases"

To monitor how quickly Database B is catching up to Database A, query the V$LOGSTDBY_PROGRESS view on Database B. For example:

SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YY HH24:MI:SS';
Session altered.

SQL> SELECT SYSDATE, APPLIED_TIME FROM V$LOGSTDBY_PROGRESS;

SYSDATE            APPLIED_TIME
------------------ ------------------
27-JUN-05 17:07:06 27-JUN-05 17:06:50

Step 5   Monitor events on the upgraded standby database

You should frequently query the DBA_LOGSTDBY_EVENTS view to learn if there are any DDL and DML statements that have not been applied on Database B. Example 12-1 demonstrates how monitoring events can alert you to potential differences in the two databases.

SQL> SET LONG 1000
SQL> SET PAGESIZE 180
SQL> SET LINESIZE 79
SQL> SELECT EVENT_TIMESTAMP, EVENT, STATUS FROM DBA_LOGSTDBY_EVENTS
ORDER BY EVENT_TIMESTAMP;

EVENT_TIMESTAMP
---------------------------------------------------------------------------
EVENT
--------------------------------------------------------------------------------
STATUS
--------------------------------------------------------------------------------
…
24-MAY-05 05.18.29.318912 PM
CREATE TABLE SYSTEM.TST (one number)
ORA-16226: DDL skipped due to lack of support
 
24-MAY-05 05.18.29.379990 PM
"SYSTEM"."TST"
ORA-16129: unsupported dml encountered

In the preceding example:

• The ORA-16226 error shows a DDL statement that could not be supported. In this case, it could not be supported because it belongs to an internal schema.

• The ORA-16129 error shows that a DML statement was not applied.

These types of errors indicate that not all of the changes that occurred on Database A have been applied to Database B. At this point, you must decide whether or not to continue with the upgrade procedure. If you are certain that this difference between the logical standby database and the primary database is acceptable, then continue with the upgrade procedure. If not, discontinue and reinstantiate Database B and perform the upgrade procedure at another time.

Step 6   Begin a switchover

When you are satisfied that the upgraded database software is operating properly, perform a switchover to reverse the database roles by issuing the following statement on Database A:

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;

This statement must wait for existing transactions to complete. To minimize the time it takes to complete the switchover, users still connected to Database A should log off immediately and reconnect to Database B.

Step 7   Import any tables that were modified during the upgrade

Step 5 "Monitor events on the upgraded standby database" described how to list unsupported tables that are being modified. If unsupported DML statements were issued on the primary database (as described in Example 12-1), import the latest version of those tables using an import utility such as Oracle Data Pump.

For example, the following import command truncates the scott.emp table and populates it with data matching the former primary database (A):

IMPDP SYSTEM/MANAGER NETWORK_LINK=DATABASEA TABLES=SCOTT.EMP TABLE_EXIST_ACTION=TRUNCATE

Step 8   Complete the switchover and activate user applications

When you are satisfied that the upgraded database software is operating properly, complete the switchover to reverse the database roles:

1. On Database B, query the SWITCHOVER_STATUS column of the V$DATABASE view, as follows:

   SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
   
   SWITCHOVER_STATUS
   --------------------
   TO PRIMARY
   

2. When the SWITCHOVER_STATUS column displays TO PRIMARY, complete the switchover by issuing the following statement on Database B:

   SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL PRIMARY;
   

   Note:

   The usual two-phased prepared switchover described in 7.3.1 cannot be used because it requires both primary and standby databases to be running the same version of the Oracle software and at this point, the primary database is running a lower version of the Oracle software. Instead, the single-phased unprepared switchover procedure documented above is used. The unprepared switchover should only be used in the context of a rolling upgrade using logical standby database.

3. Activate the user applications and services on Database B, which is now running in the primary database role.

After the switchover, you cannot send redo data from the new primary database (B) that is running the new database software release to the new standby database (A) that is running an older software release. This means the following:

• Redo data is accumulating on the new primary database.

• The new primary database is unprotected at this time.

Figure 12-4 shows Database B, the former standby database (running release y), is now the primary database, and Database A, the former primary database (running release x), is now the standby database. The users are connected to Database B.

If Database B can adequately serve as the primary database and your business does not require a logical standby database to support the primary database, then you have completed the rolling upgrade process. Allow users to log in to Database B and begin working there, and discard Database A when it is convenient. Otherwise, continue with step 9.

Figure 12-4 After a Switchover

Description of "Figure 12-4 After a Switchover"

Step 9   Upgrade the old primary database

Database A is still running release x and cannot apply redo data from Database B until you upgrade it and start SQL Apply.

For more information about upgrading Oracle Database software, see the Oracle Database Upgrade Guide for the applicable Oracle Database release.

Figure 12-5 shows the system after both databases have been upgraded.

Figure 12-5 Both Databases Upgraded

Description of "Figure 12-5 Both Databases Upgraded"

Step 10   Start SQL Apply on the old primary database

Issue the following statement to start SQL Apply on Database A and, if necessary, create a database link to Database B:

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE NEW PRIMARY db_link_to_b;

When you start SQL Apply on Database A, the redo data that is accumulating on the primary database (B) is sent to the logical standby database (A). The primary database is protected against data loss once all the redo data is available on the standby database.

Step 11   Optionally, raise the compatibility level on both databases

Raise the compatibility level of both databases by setting the COMPATIBLE initialization parameter. You must raise the compatibility level at the logical standby database before you raise it at the primary database. Set the COMPATIBLE parameter on the standby database before you set it on the primary database. See Oracle Database Reference for more information about the COMPATIBLE initialization parameter.

Step 12   Monitor events on the new logical standby database

To ensure that all changes performed on Database B are properly applied to the logical standby database (A), you should frequently query the DBA_LOGSTDBY_EVENTS view, as you did for Database A in step 5. (See Example 12-1.)

If changes were made that invalidate Database A as a copy of your existing primary database, you can discard Database A and create a new logical standby database in its place. See Chapter 4, "Creating a Logical Standby Database" for complete information.

Step 13   Optionally, perform another switchover

Optionally, perform another switchover of the databases so Database A is once again running in the primary database role (as shown in Figure 12-1).

12.6 Performing a Rolling Upgrade With an Existing Physical Standby Database

The steps in this section show you how to perform a rolling upgrade of Oracle software and then get back to your original configuration in which A is the primary database and B is the physical standby database, and both of them are running the upgraded Oracle software. These steps assume that you have a primary database (A) and a physical standby database (B) already set up.

Step 1   Prepare the primary database for rolling upgrade (perform these steps on Database A)

1. Enable Flashback Database, if needed:

   SQL> shutdown immediate;
   SQL> startup mount
   SQL> alter database flashback on;
   SQL> alter database open;
   

2. Create a guaranteed restore point:

   SQL> create restore point pre_upgrade guarantee flashback database;
   

3. Create a physical standby control file:

   SQL> alter database create physical standby controlfile as '/tmp/control.phys' reuse;
   

Step 2   Convert the physical standby database into a logical standby database (perform these steps on Database B)

Follow the steps outlined in Chapter 4, "Creating a Logical Standby Database" except for the following difference. In Section 4.2.4.1, "Convert to a Logical Standby Database" you must use a different command to convert the logical standby database. Instead of ALTER DATABASE RECOVER TO LOGICAL STANDBY db_name, issue the following command:

SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY KEEP IDENTITY;

This will convert the physical standby database to a logical standby, but it will still have the same DBID and DB_NAME. Note that the KEEP IDENTITY clause should only be used in a rolling upgrade situation involving a physical standby database, and should not be used while creating a logical standby database for the usual purposes. Execute the following statements to disable automatic deletion of foreign archived logs at the logical standby database and then start SQL Apply for the first time:

SQL> execute DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE', 'FALSE');

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

Step 3    Upgrade the logical standby database and catch up with the primary database (perform these steps on Database B)

You can now follow Steps 1 through 6 as described in Section 12.5, "Performing a Rolling Upgrade With an Existing Logical Standby Database". At the end of these steps, Database B will be your primary database running the higher version of the Oracle software, and Database A has become your logical standby database.

Move on to the next step to turn Database A into the physical standby for Database B.

Step 4   Flashback Database A to the guaranteed restore point (perform these steps on Database A)

SQL> shutdown immediate;
SQL> startup mount
SQL> flashback database to restore point pre_upgrade;

Step 5   On Database A restore the standby control file that you created in Step 1

SQL> shutdown immediate;
RMAN> startup nomount
RMAN> restore controlfile from '/tmp/control.phys';
RMAN> shutdown

Step 6   Bring up Database A as a physical standby to Database B using the new version of Oracle software

At this point, you should switch the Oracle binary at Database A to use the higher version of the Oracle software. You will not run the upgrade scripts, since Database A will be turned into a physical standby, and will be upgraded automatically as it applies the redo data generated by Database B.

SQL> startup mount
SQL> recover managed standby database using current logfile disconnect;

Step 7   Perform a switchover to make Database A the primary database

At this point, Database B is your primary database and Database A is your physical standby, both running the higher version of the Oracle software.

Make sure that Database A has caught up with Database B.

On Database B, perform the following steps:

SQL> select switchover_status from v$database;
SWITCHOVER_STATUS
---------------------------------
TO STANDBY
SQL> alter database commit to switchover to physical standby with session shutdown;
SQL> shutdown immediate;
SQL> startup mount;
 

On Database A, perform the following steps:

SQL> select switchover_status from v$database;
SWITCHOVER_STATUS
--------------------
TO PRIMARY
SQL> alter database commit to switchover to primary;
SQL> shutdown immediate;
SQL> startup

At this point, you have your original configuration back, with Database A as the primary database, and Database B as the physical standby, and both running the higher version of the Oracle software.