Oracle® Streams Concepts and Administration 11g Release 2 (11.2) Part Number E10704-02 |
|
|
View PDF |
This appendix describes how to perform a database upgrade from one of the following Oracle Database releases with Oracle Streams:
Oracle Database 10g Release 1 (10.1)
Oracle9i Database Release 2 (9.2)
The database upgrade operation described in this appendix uses the features of Oracle Streams to achieve little or no database down time.
The following topics describe performing an online database upgrade with Oracle Streams:
See Also:
Appendix D, "Online Database Upgrade and Maintenance with Oracle Streams" for information about upgrading from Oracle Database 10g Release 2 (10.2) or later and for information about performing other database maintenance operations with Oracle StreamsAn Oracle database upgrade is the process of transforming an existing, prior release of an Oracle database into the current release. A database upgrade typically requires substantial database down time, but you can perform a database upgrade with little or no down time by using the features of Oracle Streams. To do so, you use Oracle Streams to configure a replication environment with the following databases:
Source Database: The original database that is being upgraded.
Capture Database: The database where a capture process captures changes made to the source database during the upgrade.
Destination Database: The copy of the source database where an apply process applies changes made to the source database during the upgrade process.
Specifically, you can use the following general steps to perform a database upgrade while the database is online:
Create an empty destination database.
Configure an Oracle Streams replication environment where the original database is the source database and a copy of the database is the destination database for the changes made at the source.
Perform the database upgrade on the destination database. During this time the original source database is available online.
Use Oracle Streams to apply the changes made at the source database to the destination database.
When the destination database has caught up with the changes made at the source database, take the source database offline and make the destination database available for applications and users.
Figure E-1 provides an overview of this process.
Figure E-1 Online Database Upgrade with Oracle Streams
During the upgrade process, the capture database is the database where the capture process is created. Downstream capture was introduced in Oracle Database 10g Release 1 (10.1). If you are upgrading a database from Oracle Database 10g Release 1, then you have the following options:
A local capture process can be created at the source database during the upgrade process.
A downstream capture process can be created at the destination database. If the destination database is the capture database, then a propagation from the capture database to the destination database is not needed.
A third database can be the capture database. In this case, the third database can be an Oracle Database 10g Release 1 or later database.
However, if you are upgrading a database from Oracle9i Database Release 2 (9.2) to Oracle Database 11g Release 2, then downstream capture is not supported, and a local capture process must be created at the source database.
A downstream capture process reduces the resources required at the source database during the upgrade process, but a local capture process is easier to configure. Table E-1 describes which database can be the capture database during the upgrade process.
Table E-1 Supported Capture Database During Upgrade
Existing Database Release | Capture Database Can Be Source Database? | Capture Database Can Be Destination Database? | Capture Database Can Be Third Database? |
---|---|---|---|
9.2 |
Yes |
No |
No |
10.1 |
Yes |
Yes |
Yes |
Note:
If you are upgrading from Oracle Database 10g Release 1 (10.1), then, before you begin the upgrade, decide which database will be the capture database.See Also:
"Local Capture and Downstream Capture"The instructions in this appendix assume that all of the following statements are true for the database being upgraded:
The database is not part of an existing Oracle Streams environment.
The database is not part of an existing logical standby environment.
The database is not part of an existing Advanced Replication environment.
No tables at the database are master tables for materialized views in other databases.
No messages are enqueued into user-created queues during the upgrade process.
If possible, ensure that no job queue processes are created, modified, or deleted during the upgrade process, and that no Oracle-supplied PL/SQL package subprograms are invoked during the upgrade process that modify both user data and dictionary metadata at the same time. The following packages contain subprograms that modify both user data and dictionary metadata at the same time: DBMS_RLS
, DBMS_STATS
, and DBMS_JOB
.
It might be possible to perform such actions on the database if you ensure that the same actions are performed on the source database and destination database in Steps 13 and 14 in "Task 5: Finishing the Upgrade and Removing Oracle Streams". For example, if a PL/SQL procedure gathers statistics on the source database during the upgrade process, then the same PL/SQL procedure should be invoked at the destination database in Step 14.
The following sections describe tasks to complete before starting the database upgrade with Oracle Streams:
User-defined types include object types, REF
values, varrays, and nested tables. Currently, Oracle Streams capture processes and apply processes do not support user-defined types. This section discusses using Oracle Streams to perform a database upgrade on a database that has user-defined types.
One option is to ensure that no data manipulation language (DML) or data definition language (DDL) changes are made to the tables that contain user-defined types during the database upgrade. In this case, these tables are instantiated at the destination database, and no changes are made to these tables during the entire operation. After the upgrade is complete, make the tables that contain user-defined types read/write at the destination database.
If tables that contain user-defined types must remain open during the upgrade, then the following general steps can be used to retain changes to these tables during the upgrade:
Before you begin the upgrade process described in "Performing a Database Upgrade Using Oracle Streams", create one or more logging tables to store row changes to tables at the source database that include user-defined types. Each column in the logging table must use a data type that is supported by Oracle Streams in the source database release.
Before you begin the upgrade process described in "Performing a Database Upgrade Using Oracle Streams", create a DML trigger at the source database that fires on the tables that contain the user-defined data types. The trigger converts each row change into relational equivalents and logs the modified row in a logging table created in Step 1.
When the instructions in "Performing a Database Upgrade Using Oracle Streams" say to configure a capture process and propagation, configure the capture process and propagation to capture changes to the logging table and propagate these changes to the destination database. Changes to tables that contain user-defined types must not be captured or propagated.
When the instructions in "Performing a Database Upgrade Using Oracle Streams" say to configure a an apply process on the destination database, configure the apply process to use a procedure DML handler that processes the changes to the logging tables. The procedure DML handler reconstructs the user-defined types from the relational equivalents and applies the modified changes to the tables that contain user-defined types.
For instructions, go to the My Oracle Support (formerly OracleMetaLink) Web site using a Web browser:
http://metalink.oracle.com/
Database bulletin 556742.1 describes extended data type support for Oracle Streams.
See Also:
Oracle Database PL/SQL Language Reference for more information about creating triggers
Before you begin the database upgrade, decide whether you want to use the Export/Import utilities (Data Pump or original) or the Recovery Manager (RMAN) utility to instantiate the destination database during the operation. The destination database will replace the existing database that is being upgraded.
Consider the following factors when you make this decision:
If you use original Export/Import or Data Pump Export/Import, then you can make the destination database an Oracle Database 11g Release 2 (11.2) database at the beginning of the operation. Therefore, you do not need to upgrade the destination database after the instantiation.
If you use Export/Import for instantiation, and Data Pump is supported, then Oracle recommends using Data Pump. Data Pump can perform the instantiation faster than original Export/Import.
If you use the RMAN DUPLICATE
command, then the instantiation might be faster than with Export/Import, especially if the database is large, but the database release must be the same for RMAN instantiation. Therefore, the following conditions must be met:
If the database is an Oracle9i Database Release 2 (9.2) database, then the destination database is an Oracle9i Database Release 2 database when it is instantiated.
If the database is an Oracle Database 10g Release 1 (10.1) database, then the destination database is an Oracle Database 10g Release 1 database when it is instantiated.
After the instantiation, you must upgrade the destination database.
Also, Oracle recommends that you do not use RMAN for instantiation in an environment where distributed transactions are possible. Doing so might cause in-doubt transactions that must be corrected manually.
Table E-2 describes whether each instantiation method is supported based on the release being upgraded, whether the platform at the source and destination databases are different, and whether the character set at the source and destination databases are different. Each instantiation method is supported when the platform and character set are the same at the source and destination databases.
Table E-2 Instantiation Methods for Database Upgrade with Oracle Streams
Instantiation Method | Supported When Upgrading From | Different Platforms Supported? | Different Character Sets Supported? |
---|---|---|---|
Original Export/Import |
9.2 or 10.1 |
Yes |
Yes |
Data Pump Export/Import |
10.1 |
Yes |
Yes |
RMAN |
9.2 or 10.1 |
No |
No |
This section contains instructions for performing a database upgrade using Oracle Streams. These instructions describe using Oracle Streams to upgrade one of the following Oracle Database releases: Oracle9i Database Release 2 (9.2) or Oracle Database 10g Release 1 (10.1).
Complete the following tasks to upgrade a database using Oracle Streams:
Complete the following steps to begin the upgrade using Oracle Streams:
Create an empty destination database. Ensure that this database has a different global name than the source database. This example assumes that the global name of the source database is orcl.example.com
and the global name of the destination database during the upgrade is updb.example.com
. The global name of the destination database is changed when the destination database replaces the source database at the end of the upgrade process.
The release of the empty database you create depends on the instantiation method you decided to use in "Deciding Which Utility to Use for Instantiation":
If you decided to use export/import for instantiation, then create an empty Oracle Database 11g Release 2 database. This database will be the destination database during the upgrade process.
See the Oracle Database installation guide for your operating system if you must install Oracle Database, and see the Oracle Database Administrator's Guide for information about creating a database.
If you decided to use RMAN for instantiation, then create an empty Oracle database that is the same release as the database you are upgrading.
Specifically, if you are upgrading an Oracle9i Database Release 2 (9.2) database, then create an Oracle9i Release 2 database. Alternatively, if you are upgrading an Oracle Database 10g Release 1 (10.1) database, then create an Oracle Database 10g Release 1 database.
This database will be the destination database during the upgrade process. Both the source database that is being upgraded and the destination database must be the same release of Oracle when you start the upgrade process.
See the Oracle installation guide for your operating system if you must install Oracle, and see the Oracle Database Administrator's Guide for the release for information about creating a database.
Ensure that the source database is running in ARCHIVELOG
mode. See the Oracle Database Administrator's Guide for the source database release for information about running a database in ARCHIVELOG
mode.
Ensure that the initialization parameters are set properly at each database to support an Oracle Streams environment. For the source database, see the Oracle Streams documentation for the source database release. For the destination database, see Oracle Streams Replication Administrator's Guide for information about setting initialization parameters that are relevant to Oracle Streams. If the capture database is a third database, then see the Oracle Streams documentation for the capture database release.
At the source database, ensure that no changes are made during the upgrade process to any database objects that were not supported by Oracle Streams in the release you are upgrading:
If you are upgrading an Oracle9i Database Release 2 (9.2) database, then tables with columns of the following data types are not supported: NCLOB
, LONG
, LONG
RAW
, BFILE
, ROWID
, and UROWID
, and user-defined types (including object types, REFs, varrays, and nested tables). In addition, the following types of tables are not supported: temporary tables, index-organized tables, and object tables. See Oracle9i Streams for complete information about unsupported database objects.
If you are upgrading an Oracle Database 10g Release 1 (10.1) database, then query the DBA_STREAMS_UNSUPPORTED
data dictionary view to list the database objects that are not supported by Oracle Streams. Ensure that no changes are made to these database objects during the upgrade process.
"Preparing to Upgrade a Database with User-Defined Types" discusses a method for retaining changes to tables that contain user-defined types during the upgrade. If you are using this method, then tables that contain user-defined types can remain open during the upgrade.
At the source database, configure an Oracle Streams administrator:
If you are upgrading an Oracle9i Database Release 2 (9.2) database, then see Oracle9i Streams for instructions.
If you are upgrading an Oracle Database 10g Release 1 database, then see Oracle Streams Concepts and Administration for that release for instructions.
These instructions assume that the name of the Oracle Streams administrator at the source database is strmadmin
. This Oracle Streams administrator will be copied automatically to the destination database during instantiation.
In SQL*Plus, connect to the source database orcl.example.com
as an administrative user.
See the Oracle Database Administrator's Guide for the source database release for information about connecting to a database in SQL*Plus.
Specify database supplemental logging of primary keys, unique keys, and foreign keys for all updates. For example:
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE, FOREIGN KEY) COLUMNS;
The specific instructions for setting up Oracle Streams prior to instantiation depend on which database is the capture database. Follow the instructions in the appropriate section:
See Also:
"Overview of Using Oracle Streams in the Database Upgrade Process" for information about the capture databaseComplete the following steps to set up Oracle Streams prior to instantiation when the source database is the capture database:
Configure your network and Oracle Net so that the source database can communicate with the destination database. See Oracle Database Net Services Administrator's Guide for instructions.
In SQL*Plus, connect to the source database orcl.example.com
as the Oracle Streams administrator.
Seethe Oracle Database Administrator's Guide for the source database release for information about connecting to a database in SQL*Plus.
Create an ANYDATA
queue that will stage changes made to the source database during the upgrade process. For example:
BEGIN DBMS_STREAMS_ADM.SET_UP_QUEUE( queue_table => 'strmadmin.capture_queue_table', queue_name => 'strmadmin.capture_queue'); END; /
Configure a capture process that will capture all supported changes made to the source database and stage these changes in the queue created in Step 3. Do not start the capture process. For example:
BEGIN DBMS_STREAMS_ADM.ADD_GLOBAL_RULES( streams_type => 'capture', streams_name => 'capture_upgrade', queue_name => 'strmadmin.capture_queue', include_dml => TRUE, include_ddl => TRUE, include_tagged_lcr => FALSE, source_database => 'orcl.example.com', inclusion_rule => TRUE); END; /
"Preparing to Upgrade a Database with User-Defined Types" discusses a method for retaining changes to tables that contain user-defined types during the maintenance operation. If you are using this method, then ensure that the capture process does not attempt to capture changes to tables with user-defined types. See the Oracle Streams documentation for the source database release for information about excluding database objects from an Oracle Streams configuration with rules.
Proceed to "Task 3: Instantiating the Database".
The database being upgraded must be an Oracle Database 10g Release 1 (10.1) database to use this option. Complete the following steps to set up Oracle Streams prior to instantiation when the destination database is the capture database:
Configure your network and Oracle Net so that the source database and destination database can communicate with each other. See Oracle Database Net Services Administrator's Guide for instructions.
Follow the instructions in the appropriate section based on the method you are using for instantiation:
Export/Import
Complete the following steps if you are using export/import for instantiation:
In SQL*Plus, connect to the destination database updb.example.com
as the Oracle Streams administrator.
See Oracle Database Administrator's Guide for information about connecting to a database in SQL*Plus.
Create an ANYDATA
queue that will stage changes made to the source database during the upgrade process. For example:
BEGIN DBMS_STREAMS_ADM.SET_UP_QUEUE( queue_table => 'strmadmin.destination_queue_table', queue_name => 'strmadmin.destination_queue'); END; /
Configure a downstream capture process that will capture all supported changes made to the source database and stage these changes in the queue created in Step b. Ensure that the capture process uses a database link to the source database. The capture process can be a real-time downstream capture process or an archived-log downstream capture process. See Oracle Streams Replication Administrator's Guide for instructions. Do not start the capture process.
"Preparing to Upgrade a Database with User-Defined Types" discusses a method for retaining changes to tables that contain user-defined types during the maintenance operation. If you are using this method, then ensure that the capture process does not attempt to capture changes to tables with user-defined types. See the Oracle Streams documentation for the source database for information about excluding database objects from an Oracle Streams configuration with rules.
RMAN
Complete the following steps if you are using RMAN for instantiation:
In SQL*Plus, connect to the source database orcl.example.com
as the Oracle Streams administrator.
See Oracle Database Administrator's Guide for information about connecting to a database in SQL*Plus.
Perform a build of the data dictionary in the redo log:
SET SERVEROUTPUT ON DECLARE scn NUMBER; BEGIN DBMS_CAPTURE_ADM.BUILD( first_scn => scn); DBMS_OUTPUT.PUT_LINE('First SCN Value = ' || scn); END; / First SCN Value = 1122610
This procedure displays the valid first SCN value for the capture process that will be created at the destination database. Make a note of the SCN value returned because you will use it when you create the capture process at the destination database.
Prepare the source database for instantiation:
exec DBMS_CAPTURE_ADM.PREPARE_GLOBAL_INSTANTIATION();
Proceed to "Task 3: Instantiating the Database".
To use this option, meet the following requirements:
The database being upgraded must be an Oracle Database 10g Release 1 (10.1) database.
The third database must be an Oracle Database 10g Release 1 or later database.
This example assumes that the global name of the third database is thrd.example.com
. Complete the following steps to set up Oracle Streams prior to instantiation when a third database is the capture database:
Configure your network and Oracle Net so that the source database, destination database, and third database can communicate with each other. See Oracle Database Net Services Administrator's Guide for instructions.
In SQL*Plus, connect to the third database thrd.example.com
as an administrative user.
See Oracle Database Administrator's Guide for information about connecting to a database in SQL*Plus.
Create an Oracle Streams administrator:
If the third database is an Oracle Database 10g database or an Oracle Database 11g Release 1 database, then see the Oracle Streams Concepts and Administration book for that release for instructions.
If the third database is an Oracle Database 11g Release 2 database, then see Oracle Streams Replication Administrator's Guide for instructions.
These instructions assume that the name of the Oracle Streams administrator at the third database is strmadmin
.
While still connected to the third database as the Oracle Streams administrator, create an ANYDATA
queue that will stage changes made to the source database during the upgrade process. For example:
BEGIN DBMS_STREAMS_ADM.SET_UP_QUEUE( queue_table => 'strmadmin.capture_queue_table', queue_name => 'strmadmin.capture_queue'); END; /
Configure a downstream capture process that will capture all supported changes made to the source database and stage these changes in the queue created in Step 4. Ensure that the capture process uses a database link to the source database. Do not start the capture process.
See the following documentation for instructions:
If the capture database is an Oracle Database 10g database or an Oracle Database 11g Release 1 database, then see the Oracle Streams Concepts and Administration book for that release for instructions.
If the capture database is an Oracle Database 11g Release 2 database, then see Oracle Streams Replication Administrator's Guide.
The capture process can be a real-time downstream capture process or an archived-log downstream capture process.
"Preparing to Upgrade a Database with User-Defined Types" discusses a method for retaining changes to tables that contain user-defined types during the upgrade operation. If you are using this method, then ensure that the capture process does not attempt to capture changes to tables with user-defined types. See the Oracle Streams documentation for the source database for information about excluding database objects from an Oracle Streams configuration with rules.
Proceed to "Task 3: Instantiating the Database".
"Deciding Which Utility to Use for Instantiation" discusses different options for instantiating an entire database. Complete the steps in the appropriate section based on the instantiation option you are using:
Complete the following steps to instantiate the destination database using export/import:
Instantiate the destination database using Export/Import. See Oracle Streams Replication Administrator's Guide for more information about performing instantiations, and see Oracle Database Utilities for information about performing an export/import using the Export and Import utilities.
If you use Oracle Data Pump or original Export/Import to instantiate the destination database, then ensure that the following parameters are set to the appropriate values:
Set the STREAMS_CONFIGURATION
import parameter to n
.
If you use original Export/Import, then set the CONSISTENT
export parameter to y
. This parameter does not apply to Data Pump exports.
If you use original Export/Import, then set the STREAMS_INSTANTIATION
import parameter to y
. This parameter does not apply to Data Pump imports.
If you are upgrading an Oracle9i Database Release 2 (9.2) database, then you must use original Export/Import.
At the destination database, disable any imported jobs that modify data that will be replicated from the source database. Query the DBA_JOBS
data dictionary view to list the jobs.
Proceed to "Task 4: Setting Up Oracle Streams After Instantiation".
Complete the following steps to instantiate the destination database using the RMAN DUPLICATE
command:
Note:
These steps provide a general outline for using RMAN to duplicate a database. If you are upgrading an Oracle9i Release 2 database, then see the Oracle9i Recovery Manager User's Guide for detailed information about using RMAN in that release. If you upgrading an Oracle Database 10g Release 1 (10.1) database, then see the Oracle Database Backup and Recovery Advanced User's Guide for that release.Create a backup of the source database if one does not exist. RMAN requires a valid backup for duplication. In this example, create a backup of orcl.example.com
if one does not exist.
In SQL*Plus, connect to the source database orcl.example.com
as an administrative user.
Seethe Oracle Database Administrator's Guide for the source database release for information about connecting to a database in SQL*Plus.
Determine the until SCN for the RMAN DUPLICATE
command. For example:
SET SERVEROUTPUT ON SIZE 1000000 DECLARE until_scn NUMBER; BEGIN until_scn:= DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER; DBMS_OUTPUT.PUT_LINE('Until SCN: ' || until_scn); END; /
Make a note of the until SCN value. This example assumes that the until SCN value is 439882
. You will set the UNTIL
SCN
option to this value when you use RMAN to duplicate the database in Step 7.
While still connected as an administrative user in SQL*Plus to the source database, archive the current online redo log. For example:
ALTER SYSTEM ARCHIVE LOG CURRENT;
Prepare your environment for database duplication, which includes preparing the destination database as an auxiliary instance for duplication. See the documentation for the release from which you are upgrading for instructions. Specifically, see the "Duplicating a Database with Recovery Manager" chapter in the Oracle9i Recovery Manager User's Guide or Oracle Database Backup and Recovery Advanced User's Guide (10g) for instructions.
Start the RMAN client, and connect to the database orcl.example.com
as TARGET
and to the updb.example.com
database as AUXILIARY
. Connect to each database as an administrative user.
See the RMAN documentation for your Oracle Database release for more information about the RMAN CONNECT
command.
Use the RMAN DUPLICATE
command with the OPEN
RESTRICTED
option to instantiate the source database at the destination database. The OPEN
RESTRICTED
option is required. This option enables a restricted session in the duplicate database by issuing the following SQL statement: ALTER
SYSTEM
ENABLE
RESTRICTED
SESSION
. RMAN issues this statement immediately before the duplicate database is opened.
You can use the UNTIL
SCN
clause to specify an SCN for the duplication. Use the until SCN determined in Step 3 for this clause. Archived redo logs must be available for the until SCN specified and for higher SCN values. Therefore, Step 4 archived the redo log containing the until SCN.
Ensure that you use TO
database_name
in the DUPLICATE
command to specify the database name of the duplicate database. In this example, the database name of the duplicate database is updb
. Therefore, the DUPLICATE
command for this example includes TO
updb
.
The following is an example of an RMAN DUPLICATE
command:
RMAN> RUN { SET UNTIL SCN 439882; ALLOCATE AUXILIARY CHANNEL updb DEVICE TYPE sbt; DUPLICATE TARGET DATABASE TO updb NOFILENAMECHECK OPEN RESTRICTED; }
In SQL*Plus, connect to the destination database as an administrative user.
Use the ALTER
SYSTEM
statement to disable the RESTRICTED
SESSION
:
ALTER SYSTEM DISABLE RESTRICTED SESSION;
While still connected as an administrative user in SQL*Plus to the destination database, rename the database global name. After the RMAN DUPLICATE
command, the destination database has the same global name as the source database, but the destination database must have its original name until the end of the upgrade. For example:
ALTER DATABASE RENAME GLOBAL_NAME TO updb.example.com;
At the destination database, disable any jobs that modify data that will be replicated from the source database. Query the DBA_JOBS
data dictionary view to list the jobs.
Upgrade the destination database to Oracle Database 11g Release 2. See the Oracle Database Upgrade Guide for instructions.
If you have not done so already, configure your network and Oracle Net so that the source database and destination database can communicate with each other. See Oracle Database Net Services Administrator's Guide for instructions.
Connect to the destination database as the Oracle Streams administrator in SQL*Plus. In this example, the destination database is updb.example.com
.
Create a database link to the source database. For example:
CREATE DATABASE LINK orcl.example.com CONNECT TO strmadmin
IDENTIFIED BY password
USING 'orcl.example.com';
Set the instantiation SCN for the entire database and all of the database objects. The RMAN DUPLICATE
command duplicates the database up to one less than the SCN value specified in the UNTIL
SCN
clause. Therefore, you should subtract one from the until SCN value that you specified when you ran the DUPLICATE
command in Step 7. In this example, the until SCN was set to 439882
. Therefore, the instantiation SCN should be set to 439882
-
1
, or 439881
.
BEGIN DBMS_APPLY_ADM.SET_GLOBAL_INSTANTIATION_SCN( source_database_name => 'orcl.example.com', instantiation_scn => 439881, recursive => TRUE); END; /
Proceed to "Task 4: Setting Up Oracle Streams After Instantiation".
The specific instructions for setting up Oracle Streams after instantiation depend on which database is the capture database. Follow the instructions in the appropriate section:
See Also:
"Overview of Using Oracle Streams in the Database Upgrade Process" for information about the capture databaseComplete the following steps to set up Oracle Streams after instantiation when the source database is the capture database:
In SQL*Plus, connect to the destination database as the Oracle Streams administrator. In this example, the destination database is updb.example.com
.
See Oracle Database Administrator's Guide for information about connecting to a database in SQL*Plus.
Remove the Oracle Streams components that were cloned from the source database during instantiation:
If export/import was used for instantiation, then remove the ANYDATA
queue that was cloned from the source database.
If RMAN was used for instantiation, then remove the ANYDATA
queue and the capture process that were cloned from the source database.
To remove the queue that was cloned from the source database, run the REMOVE_QUEUE
procedure in the DBMS_STREAMS_ADM
package. For example:
BEGIN DBMS_STREAMS_ADM.REMOVE_QUEUE( queue_name => 'strmadmin.capture_queue', cascade => FALSE, drop_unused_queue_table => TRUE); END; /
To remove the capture process that was cloned from the source database, run the DROP_CAPTURE
procedure in the DBMS_CAPTURE_ADM
package. For example:
BEGIN DBMS_CAPTURE_ADM.DROP_CAPTURE( capture_name => 'capture_upgrade', drop_unused_rule_sets => TRUE); END; /
Create an ANYDATA
queue. This queue will stage changes propagated from the source database. For example:
BEGIN DBMS_STREAMS_ADM.SET_UP_QUEUE( queue_table => 'strmadmin.destination_queue_table', queue_name => 'strmadmin.destination_queue'); END; /
Connect to the source database as the Oracle Streams administrator. In this example, the source database is orcl.example.com
.
Create a database link to the destination database. For example:
CREATE DATABASE LINK updb.example.com CONNECT TO strmadmin
IDENTIFIED BY password
USING 'updb.example.com';
Create a propagation that propagates all changes from the source queue to the destination database created in Step 3. For example:
BEGIN DBMS_STREAMS_ADM.ADD_GLOBAL_PROPAGATION_RULES( streams_name => 'to_updb', source_queue_name => 'strmadmin.capture_queue', destination_queue_name => 'strmadmin.destination_queue@updb.example.com', include_dml => TRUE, include_ddl => TRUE, include_tagged_lcr => TRUE, source_database => 'orcl.example.com'); END; /
Connect to the destination database as the Oracle Streams administrator.
Create an apply process that applies all changes in the queue created in Step 3. For example:
BEGIN DBMS_STREAMS_ADM.ADD_GLOBAL_RULES( streams_type => 'apply', streams_name => 'apply_upgrade', queue_name => 'strmadmin.destination_queue', include_dml => TRUE, include_ddl => TRUE, include_tagged_lcr => TRUE, source_database => 'orcl.example.com'); END; /
Proceed to "Task 5: Finishing the Upgrade and Removing Oracle Streams".
Complete the following steps to set up Oracle Streams after instantiation when the destination database is the capture database:
Complete the following steps if you used RMAN for instantiation. If you used export/import for instantiation, then proceed to Step 2.
In SQL*Plus, connect to the destination database as the Oracle Streams administrator. In this example, the destination database is updb.example.com
.
See Oracle Database Administrator's Guide for information about connecting to a database in SQL*Plus.
Create an ANYDATA
queue that will stage changes made to the source database during the upgrade process. For example:
BEGIN DBMS_STREAMS_ADM.SET_UP_QUEUE( queue_table => 'strmadmin.destination_queue_table', queue_name => 'strmadmin.destination_queue'); END; /
Configure a downstream capture process that will capture all supported changes made to the source database and stage these changes in the queue created in Step b.
Ensure that you set the first_scn
parameter in the CREATE_CAPTURE
procedure to the value obtained for the data dictionary build in Step 2b in "The Destination Database Is the Capture Database". In this example, the first_scn
parameter should be set to 1122610
.
The capture process can be a real-time downstream capture process or an archived-log downstream capture process. See Oracle Streams Replication Administrator's Guide for instructions. Do not start the capture process.
"Preparing to Upgrade a Database with User-Defined Types" discusses a method for retaining changes to tables that contain user-defined types during the maintenance operation. If you are using this method, then ensure that the capture process does not attempt to capture changes to tables with user-defined types. See the Oracle Streams documentation for the source database for information about excluding database objects from an Oracle Streams configuration with rules.
Create an apply process that applies all changes in the queue used by the downstream capture process. For example:
BEGIN DBMS_STREAMS_ADM.ADD_GLOBAL_RULES( streams_type => 'apply', streams_name => 'apply_upgrade', queue_name => 'strmadmin.destination_queue', include_dml => TRUE, include_ddl => TRUE, include_tagged_lcr => TRUE, source_database => 'orcl.example.com'); END; /
Proceed to "Task 5: Finishing the Upgrade and Removing Oracle Streams".
This example assumes that the global name of the third database is thrd.example.com
. Complete the following steps to set up Oracle Streams after instantiation when a third database is the capture database:
In SQL*Plus, connect to the destination database as the Oracle Streams administrator. In this example, the destination database is updb.example.com
.
See Oracle Database Administrator's Guide for information about connecting to a database in SQL*Plus.
Create an ANYDATA
queue. This queue will stage changes propagated from the capture database. For example:
BEGIN DBMS_STREAMS_ADM.SET_UP_QUEUE( queue_table => 'strmadmin.destination_queue_table', queue_name => 'strmadmin.destination_queue'); END; /
Connect to the capture database as the Oracle Streams administrator. In this example, the capture database is thrd.example.com
.
Create a database link to the destination database. For example:
CREATE DATABASE LINK updb.example.com CONNECT TO strmadmin
IDENTIFIED BY password
USING 'updb.example.com';
Create a propagation that propagates all changes from the source queue at the capture database to the destination queue created in Step 2. For example:
BEGIN DBMS_STREAMS_ADM.ADD_GLOBAL_PROPAGATION_RULES( streams_name => 'to_updb', source_queue_name => 'strmadmin.capture_queue', destination_queue_name => 'strmadmin.destination_queue@updb.example.com', include_dml => TRUE, include_ddl => TRUE, include_tagged_lcr => TRUE, source_database => 'orcl.example.com'); END; /
Connect to the destination database as the Oracle Streams administrator. In this example, the destination database is updb.example.com
.
Create an apply process that applies all changes in the queue created in Step 2. For example:
BEGIN DBMS_STREAMS_ADM.ADD_GLOBAL_RULES( streams_type => 'apply', streams_name => 'apply_upgrade', queue_name => 'strmadmin.destination_queue', include_dml => TRUE, include_ddl => TRUE, include_tagged_lcr => TRUE, source_database => 'orcl.example.com'); END; /
Complete the steps in "Task 5: Finishing the Upgrade and Removing Oracle Streams".
Complete the following steps to finish the upgrade operation using Oracle Streams and remove Oracle Streams components:
Connect to the destination database as the Oracle Streams administrator. In this example, the destination database is updb.example.com
.
See Oracle Database Administrator's Guide for information about connecting to a database in SQL*Plus.
Start the apply process. For example:
BEGIN DBMS_APPLY_ADM.START_APPLY( apply_name => 'apply_upgrade'); END; /
Connect to the capture database as the Oracle Streams administrator.
Start the capture process. For example:
BEGIN DBMS_CAPTURE_ADM.START_CAPTURE( capture_name => 'capture_upgrade'); END; /
This step begins the process of replicating changes that were made to the source database during instantiation of the destination database.
While still connected as the Oracle Streams administrator in SQL*Plus to the capture database, monitor the Oracle Streams environment until the apply process at the destination database has applied most of the changes from the source database.
To determine whether the apply process at the destination database has applied most of the changes from the source database, complete the following steps:
Query the enqueue message number of the capture process and the message number with the oldest system change number (SCN) for the apply process to see if they are nearly equal.
For example, if the name of the capture process is capture_upgrade
, and the name of the apply process is apply_upgrade
, then run the following query at the capture database:
COLUMN ENQUEUE_MESSAGE_NUMBER HEADING 'Captured SCN' FORMAT 99999999999 COLUMN OLDEST_SCN_NUM HEADING 'Oldest Applied SCN' FORMAT 99999999999 SELECT c.ENQUEUE_MESSAGE_NUMBER, a.OLDEST_SCN_NUM FROM V$STREAMS_CAPTURE c, V$STREAMS_APPLY_READER@updb.example.com a WHERE c.CAPTURE_NAME = 'CAPTURE_UPGRADE' AND a.APPLY_NAME = 'APPLY_UPGRADE';
When the two values returned by this query are nearly equal, most of the changes from the source database have been applied at the destination database, and you can proceed to the next step. At this point in the process, the values returned by this query might never be equal because the source database still allows changes.
If this query returns no results, then ensure that the Oracle Streams clients in the environment are enabled by querying the STATUS
column in the DBA_CAPTURE
view at the capture database and the DBA_APPLY
view at the destination database. If a propagation is used, you can check the status of the propagation by running the query in "Displaying Information About the Schedules for Propagation Jobs".
If an Oracle Streams client is disabled, then try restarting it. If an Oracle Streams client will not restart, then troubleshoot the environment using the information in Chapter 30, "Identifying Problems in an Oracle Streams Environment".
Query the state of the apply process apply servers at the destination database to determine whether they have finished applying changes.
For example, if the name of the apply process is apply_upgrade
, then run the following query at the capture database:
COLUMN STATE HEADING 'Apply Server State' FORMAT A20 SELECT STATE FROM V$STREAMS_APPLY_SERVER@updb.example.com WHERE APPLY_NAME = 'APPLY_UPGRADE';
When the state for all apply servers is IDLE
, you can proceed to the next step.
Connect to the destination database as the Oracle Streams administrator. In this example, the destination database is updb.example.com
.
Ensure that there are no apply errors by running the following query:
SELECT COUNT(*) FROM DBA_APPLY_ERROR;
If this query returns zero, then proceed to the next step. If this query shows errors in the error queue, then resolve these errors before continuing. See "Managing Apply Errors" for instructions.
Disconnect all applications and users from the source database.
Connect as an administrative user to the source database. In this example, the source database is orcl.example.com
.
Restrict access to the database. For example:
ALTER SYSTEM ENABLE RESTRICTED SESSION;
Connect as an administrative user in SQL*Plus to the capture database, and repeat the query you ran in Step 5a. When the two values returned by the query are equal, all of the changes from the source database have been applied at the destination database, and you can proceed to the next step.
Connect as the Oracle Streams administrator in SQL*Plus to the destination database, and repeat the query you ran in Step 7. If this query returns zero, then move on to the next step. If this query shows errors in the error queue, then resolve these errors before continuing. See "Managing Apply Errors" for instructions.
If you performed any actions that created, modified, or deleted job queue processes at the source database during the upgrade process, then perform the same actions at the destination database. See "Considerations for Job Queue Processes and PL/SQL Package Subprograms" for more information.
If you invoked any Oracle-supplied PL/SQL package subprograms at the source database during the upgrade process that modified both user data and dictionary metadata at the same time, then invoke the same subprograms at the destination database. See "Considerations for Job Queue Processes and PL/SQL Package Subprograms" for more information.
Shut down the source database. This database should not be opened again.
Connect to the destination database as an administrative user.
Change the global name of the database to match the source database. For example:
ALTER DATABASE RENAME GLOBAL_NAME TO orcl.example.com;
At the destination database, enable any jobs that you disabled earlier.
Make the destination database available for applications and users. Redirect any applications and users that were connecting to the source database to the destination database. If necessary, reconfigure your network and Oracle Net so that systems that communicated with the source database now communicate with the destination database. See Oracle Database Net Services Administrator's Guide for instructions.
At the destination database, remove the Oracle Streams components that are no longer needed. Connect as an administrative user to the destination database, and run the following procedure:
Note:
Running this procedure is dangerous. It removes the local Oracle Streams configuration. Ensure that you are ready to remove the Oracle Streams configuration at the destination database before running this procedure.EXEC DBMS_STREAMS_ADM.REMOVE_STREAMS_CONFIGURATION();
If you no longer need database supplemental logging at the destination database, then run the following statement to drop it:
ALTER DATABASE DROP SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE, FOREIGN KEY) COLUMNS;
If you no longer need the Oracle Streams administrator at the destination database, then run the following statement:
DROP USER strmadmin CASCADE;
If the capture database was a third database, then, at the third database, remove the Oracle Streams components that are no longer needed. Connect as an administrative user to the third database, and run the following procedure:
Note:
Running this procedure is dangerous. It removes the local Oracle Streams configuration. Ensure that you are ready to remove the Oracle Streams configuration at the third database before running this procedure.EXEC DBMS_STREAMS_ADM.REMOVE_STREAMS_CONFIGURATION();
If you no longer need database supplemental logging at the third database, then run the following statement to drop it:
ALTER DATABASE DROP SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE, FOREIGN KEY) COLUMNS;
If you no longer need the Oracle Streams administrator at the destination database, then run the following statement:
DROP USER strmadmin CASCADE;
The database upgrade is complete.