Extended Datatype Support: SQL
Apply and Streams
An Oracle White Paper
June 2008
Maximum
Availability
Architecture
Oracle Best Practices For High Availability
Maximum Availability Architecture
Extended Datatype Support: SQL Apply and Streams
INTRODUCTION
Oracle Data Guard SQL Apply and Oracle Streams are highly flexible features of
Oracle Database that enable information sharing between databases. A primary
capability of SQL Apply and Streams is the ability to replicate information from
one database to another. Data Guard SQL Apply is designed for simpler, one-way
replication of an entire database. Streams is a full featured information distribution
solution capable of more sophisticated replication scenarios (for example, n-way
multi-master replication, hub & spoke replication, many-to-one replication,
selective replication of only a portion of a database, and data transformations).
SQL Apply and Streams provide database support for a wide variety of datatypes,
but do not provide native support for data movement of some advanced datatypes.
However, by using Extended Datatype Support, you can take advantage of the
flexibility of SQL Apply and Streams to accommodate several more advanced
datatypes. This Maximum Availability Architecture (MAA) white paper provides
an overview of using Extended Datatype Support with SQL Apply and Streams.
EXTENDED DATATYPE SUPPORT
Extended Datatype Support (EDS) enables SQL Apply and Streams to replicate
changes to tables that contain datatypes not natively supported from one database
to another. Without EDS, only the tables that contain natively supported datatypes
can be replicated. With EDS, SQL Apply and Streams can replicate natively
supported datatypes plus the additional datatypes described in the next section,
titled “Datatypes Supported with EDS".
For a list of natively supported datatypes for Streams, see the “Datatypes
Captured” section in Oracle Streams Concepts and Administration documentation at
http://otn.oracle.com/pls/db102/db102.to_toc?partno=b14229. Similarly, for more
information about natively supported datatypes in a Data Guard SQL Apply
configuration, see the “Prerequisite Conditions for Creating a Logical Standby
Database” section in the Oracle Data Guard Concepts and Administration
documentation at http://otn.oracle.com/pls/db102/db102.to_toc?partno=b14239.
EDS is available in Oracle Database 10g Release 2 starting with Patch Set 3
(10.2.0.4) and in Oracle Database 11g Release 1 starting with Patch Set 1 (11.1.0.7).
Extended Datatype Support: SQL Apply and Streams
Page 2
Maximum Availability Architecture
Datatypes Supported with EDS
EDS currently supports tables with the following advanced datatypes that are not
handled natively:
•
Column objects (with simple or nested user-defined types) 1
•
Varrays
•
Oracle-supplied Spatial type SDO_GEOMETRY
The following examples show the datatypes supported by EDS:
Column object example (with simple user-defined type):
create type address_typ as object (
street
varchar2(200),
city
varchar2(200),
state
char(2),
zip
varchar2(20)
)
/
create table customer (
custid
varchar2(10) primary key,
name
varchar2(50),
address
address_typ
);
Column object example (with nested user-defined type):
create type point_typ as object (
x
number,
y
number
)
/
create type lineseg_typ as object (
startcoord
point_typ,
endcoord
point_typ
)
/
create table drawings (
name
varchar2(50) primary key,
vector
lineseg_typ
);
Varray example:
create type phone_typ as object (
country_code
varchar2(2),
area_code
varchar2(3),
ph_number
varchar2(7));
/
create type phone_varray_typ as varray(5) of phone_typ;
/
create table dept_phone_list (
dept_no
number(5) primary key,
phone_list
phone_varray_typ
);
SQL Apply and Streams natively support tables with LOB columns. However, tables
with LOB columns that require EDS are only supported with Streams.
1
Extended Datatype Support: SQL Apply and Streams
Page 3
Maximum Availability Architecture
Oracle-supplied Spatial type SDO_GEOMETRY example:
create table cola_markets (
mkt_id
number primary key,
name
varchar2(32),
shape
MDSYS.SDO_GEOMETRY
);
Future releases of EDS may support additional datatypes not natively supported by
SQL Apply or Streams.
How Extended Datatype Support Works
When EDS is in place, changes to tables that contain only supported datatypes are
handled by SQL Apply or Streams in a normal fashion. Changes to tables that
contain unsupported datatypes are handled by EDS, which represents unsupported
datatypes with supported datatypes in a logging table. Then, SQL Apply or Streams
replicates the changes to the logging table.
This is accomplished by creating the following database objects for each base table
that contains a datatype not natively supported:
•
Logging table—The logging table structure is similar to the base table it
represents, except that columns defined as an unsupported datatype in the
base table are instead represented as a natively supported type in the
logging table. SQL Apply or Streams replicates the changes made to the
logging table instead of the base table. For example, the table CUST
contains the column ADDRESS, which has the user-defined datatype
ADDRESS_TYP:
Table CUST
custid
name
address
varchar2(10)
varchar2(50)
address_typ
The ADDRESS_TYP datatype is defined using all supported datatypes:
Type ADDRESS_TYP
street
city
state
zip
varchar2(200)
varchar2(200)
char(2)
varchar2(20)
The logging table definition contains column definitions that are only
supported types:
Columns for table CUST with ADDRESS_TYP expanded
custid
varchar2(10)
name
varchar2(50)
street
varchar2(200)
city
varchar2(200)
state
char(2)
zip
varchar2(20)
Extended Datatype Support: SQL Apply and Streams
Page 4
Maximum Availability Architecture
In addition to representing unsupported columns with only the supported
datatypes, the logging table also contains the type of DML performed on
the base table. There are additional differences between the base table and
its logging table, but these differences do not need to be described for the
purposes of this example. Note that the logging table does not continue
to grow in size. See the Base table trigger description for an explanation.
•
Base table trigger—A trigger on the base table is created and fired for
every row modification performed by any DML operation on the base
table. The trigger inserts a row into the logging table, and then
immediately deletes the row to prevent growth of the logging table. The
row data contains the DML type performed on the base table (INSERT,
UPDATE, or DELETE) as well as the necessary values required to replay
the statement on the target database.
•
Logging table trigger or DML handler—When using EDS with SQL
Apply, a trigger is created on the logging table on the target database.
With Streams, a DML handler is created instead to process changes made
to the logging table. When changes are made on the source database to
the logging table by the base table trigger, each change is captured and
propagated to the target database. When these changes are processed on
the target database, the logging table trigger or DML handler is called to
apply the changes to the base table on the target database.
Large Object (LOB) Support
2
LOB columns in base tables that require EDS are handled as a special case because
table triggers do not fire when there is a piecewise update (via OCI or
DBMS_LOB) of a LOB. EDS uses a fast refreshable, ON COMMIT materialized
view to capture and propagate all changes made to LOB columns. Changes to all
other columns of the base table are propagated through the logging table.
Note: EDS currently supports LOB columns outside of an object column. LOB
attributes within an object column are not supported.
EDS Example
In the following example of using Streams with EDS, the HR.EMP table contains
only columns natively supported by Streams and the table is replicated normally.
The HR.CUST table contains an object column with a simple object type
ADDRESS_TYP, which is not natively supported by Streams, but is supported by
EDS. On the source database, EDS uses the logging table CUST_LOG and a
trigger on HR.CUST. On the target database, EDS uses a DML handler.
When an insert occurs to HR.CUST, the base table trigger fires to insert a row into
CUST_LOG, indicating that the DML performed was INSERT. The object
SQL Apply and Streams natively support tables with LOB columns. However, tables
with LOB columns that require EDS are only supported with Streams.
2
Extended Datatype Support: SQL Apply and Streams
Page 5
Maximum Availability Architecture
attributes for ADDRESS_TYP are flattened and inserted as their scalar equivalents.
Oracle Streams captures and propagates changes that occur to CUST_LOG. When
the Streams Apply component processes a change record for CUST_LOG, the
DML handler is run to insert the row into the HR.CUST table on the target
database.
Figure 1: Example of EDS Processing a Change Record
EDS with SQL Apply works in a similar fashion, except that a logging table and
trigger for the logging table are used in place of the DML Handler.
WHEN DO I USE EDS?
Use EDS with SQL Apply or Streams to reduce downtime for certain planned
maintenance activities, such as rolling database upgrade or platform migration,
when your database contains datatypes that are not natively supported. EDS is
intended to be in place temporarily while the planned maintenance activity is
performed.
Rolling Database Upgrade with SQL Apply and EDS
Data Guard SQL Apply (logical standby) is the preferred method for performing a
rolling database upgrade from Oracle Database 10g Release 2 to a later Oracle
Database release (for example, to a later Oracle Database 10g Release 2 patch set, or
to a later release such as Oracle Database 11g). Beginning with Oracle Database
10g Release 2 (10.2.0.4) Patch Set 3, SQL Apply supports the ability for triggers to
fire on the logical standby database, which provides the basis of EDS.
Extended Datatype Support: SQL Apply and Streams
Page 6
Maximum Availability Architecture
The following list provides the high level steps required to perform a rolling
database upgrade with minimal downtime using SQL Apply with EDS:
1.
Create the EDS objects in the source database for tables that have
datatypes not natively supported by SQL Apply.
2.
Instantiate the logical standby database.
3.
Perform the rolling database upgrade.
For additional information about logical standby database instantiation and rolling
database upgrade with logical standby, see the Oracle Data Guard Concepts and
Administration documentation at
http://otn.oracle.com/pls/db102/db102.to_toc?partno=b14239.
Platform Migration with Streams and EDS
You can use Streams to minimize downtime for platform migration. The following
list provides the high level steps required to perform a platform migration with
minimal downtime using Streams with EDS:
1.
Create the source database EDS objects. For tables that require EDS,
triggers and logging tables are created.
2.
Prepare the environment for Streams use.
3.
Instantiate the target database on the new platform using Data Pump,
Transportable Database (TDB), or Cross Platform Transportable
Tablespaces (XTTS).
During this step, users remain connected to the source database and
requests are processed normally. Changes made to the source database
are queued and will be replicated to the target database (step 6).
4.
Complete the Streams configuration.
5.
Create the target database EDS objects. For tables that require EDS,
DML handlers are created.
6.
Enable Streams. All changes that occurred on the source database
while the target database was being created are propagated and applied
to the target database. The source database continues to service user
transactions.
7.
Once the target database is mostly caught up with the source database,
disconnect users from the source database to allow the final changes to
be applied to the target database. The outage time experienced by users
consists of the amount of time it takes to perform this step.
8.
Once the remaining transactions have been applied to the target
database, allow users to reconnect to the target database.
Extended Datatype Support: SQL Apply and Streams
Page 7
Maximum Availability Architecture
HOW DO I GET EDS?
For additional information about using EDS with SQL Apply, see MetaLink Note
559353.1. To obtain additional information about EDS for Streams, see MetaLink
Note 556742.1.
CONCLUSION
This paper describes how, by using EDS with SQL Apply or Streams, you can
maintain natively supported datatypes plus some advanced datatypes to:
•
•
Make changes to tables that contain supported or unsupported datatypes:
o
Changes to supported datatypes are handled by SQL Apply or
Streams in a normal fashion.
o
Changes to unsupported datatypes are handled by EDS, which
represents/substitutes unsupported columns with only the
supported datatypes.
Handle many unsupported datatypes while in maintenance mode during a
SQL Apply rolling upgrade process.
The support for certain unsupported datatypes is provided as PL/SQL
code and scripts that are installed temporarily while the planned
maintenance activity is taking place.
Extended Datatype Support: SQL Apply and Streams
Page 8
Extended Datatype Support: SQL Apply and Streams
June 2008
Author: Douglas Utzig
Oracle USA, Inc.
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com
Copyright © 2008, Oracle. All rights reserved.
This document is provided for information purposes only and the
contents hereof are subject to change without notice.
This document is not warranted to be error-free, nor subject to any
other warranties or conditions, whether expressed orally or implied
in law, including implied warranties and conditions of merchantability
or fitness for a particular purpose. We specifically disclaim any
liability with respect to this document and no contractual obligations
are formed either directly or indirectly by this document. This document
may not be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without our prior written permission.
Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of
Oracle Corporation and/or its affiliates. Other names may be trademarks
of their respective owners.
Extended Datatype Support: SQL Apply and Streams
Page 9