TWP Streams 11gr1 134658

Oracle Database 11g: Oracle
Streams

.v Oracte !bite Paer
]vt, 200
OracIe Database 11g: OracIe Streams Page 2
Oracle Database 11g: Oracle Streams
Oracle Database 11g: Oracle Streams
EXECUTIVE OVERVIEW
Businesses hae a need to share inormation in a ariety o ways. 1his can include
disseminating price lists to ield oices, consolidating sales data rom multiple
stores, proisioning data in a grid enironment, or notiying a payroll application
that a new employee has been hired. By sharing inormation in near real time,
businesses can synchronize multiple copies o data to proide improed aailability
and scalability, or example, by synchronizing multiple call center locations.
Oracle Database 11g proides a uniied solution or inormation sharing-Oracle
Streams. Oracle Streams captures and distributes database updates, eents, and
application messages. It can automatically apply updates to destination databases, or
pass eents and messages to custom procedures and applications. Combining these
capabilities proides an extremely lexible solution or replication, message queuing,
and eent notiication solutions. Unlike traditional solutions, you can use Streams
to create powerul inormation sharing solutions that incorporate some or all o the
capabilities o classic inormation sharing solutions, all through the use o a single
eature.
1his paper discusses how the three basic elements o the Oracle Streams
technology ,capture, stage, consumption, are used to share inormation in the
Oracle 11g database. It urther describes how these eatures enable not only
eicient inormation sharing and eriication, but eicient data proisioning or
grid computing as well.
ORACLE STREAMS OVERVIEW
As a company grows and expands, it becomes increasingly important or that
company to be able to share inormation among multiple databases and
applications. 1raditionally, a company may hae selected rom among a ariety o
inormation sharing technologies, each aimed at soling a speciic business
problem. \hile these targeted solutions may hae initially appeared easier to use
and implement, they ail to delier once the needs o the company grow beyond the
capabilities o the simple targeted solution. Suddenly, deelopers must implement
multiple tools to build a solution, and complexity grows exponentially.
Oracle Database 11g proides a single, uniied solution or inormation sharing-
Oracle Streams. Oracle Streams proides a set o elements designed to acilitate the
capture, staging, and consumption o eents within the Oracle database. 1hese
eents include both messages enqueued into a database queue by applications, as
well as, modiications to database objects, such as tables or procedures, using DML
or DDL.
Lach element o streams can be conigured explicitly or implicitly. Lxplicit capture
allows user applications to explicitly enqueue messages into a staging area on the
source database. Using the implicit capture mechanism o Oracle Streams, changes
made to a database can be eiciently captured and replicated to one or more
remote systems with little impact to the originating system. 1his capture
mechanism extracts both data changes ,DML, and structure changes ,DDL, rom
the redo log and publishes these updates to the staging area.
Both explicitly and implicitly captured changes can be propagated to one or more
remote staging areas where they can be applied at the destination site. Changes in a
staging area are consumed by the apply engine, where the changes they represent
are applied to a database, or they are consumed by an application. Oracle Streams
includes a lexible apply engine, that allows use o a standard or custom apply
unction. 1his enables data to be transormed when necessary.
Lxisting applications can use Oracle Streams with minimal modiication or special
handling. Oracle Streams can speciy rules at multiple leels o granularity: database,
schema, and table. Lach element o Oracle Streams can use these rules to easily
conigure, or example, the capture o changes or an entire database, or a set o
schemas, or indiidual tables.
Using these basic elements, users control: how inormation is put into a stream,
how the stream lows or is routed rom node to node, what happens to eents in
the stream as they low into each node, and how the stream terminates. By
speciying the coniguration o the elements acting on the stream, a user can
address speciic requirements. 1o simpliy the deployment o Oracle Streams,
Oracle proides applications specially conigured or speciic markets.
Unique Databases
Databases using Oracle Streams technology need not be identical. Participating
databases can maintain dierent data structures using Streams to transorm the data
into the appropriate ormat. Streams proides the ability to transorm the stream at
multiple points: during capture, while propagating to another destination, or during
application at the destination site. 1hese transormations can be Oracle-supplied or
user-deined unctions registered within the Oracle Streams ramework.
1ransormations can be used to change the data type representation o a particular
column in a table, change the name o a column in a table, or change a table name.
1he data at each site can be subsetted based on content as well. lor example, you
could implement a rule that only eents ,or changes, related to the employees o a
particular diision, based on the department identiier column, be applied to a
particular table. Oracle Streams automatically manages the changes to ensure that
the data applied to the table matches the subset rule criteria.
Directed Networks
Although locally captured or enqueued eents can be consumed locally, they can
also be propagated to one or more remote locations. 1he directed network
capability o streams allows changes to be directed through intermediate databases
as a pass-through. Changes at any database can be published and propagated to or
through other databases anywhere on the network. By using the rules-based publish
and subscribe capabilities o the staging area queues, database administrators can
choose which changes are propagated to each destination database, and can speciy
the route messages will traerse on their way to a destination. 1his directed network
approach is also riendly to \ide Area Networks ,\AN,, enabling changes to
subsequent destinations to traerse the network once to a single site or later an-
out to other destinations, rather than sending to each destination directly.
TabIe Data Comparison and Convergence
An important adjunct to sharing data in multiple locations is the ability to eriy
data consistency between databases. 1he Oracle Database 11g includes a package to
compare table data between databases. Complete data, data ranges, or data subsets
may be checked on a periodic or as needed basis, without intererence to running
applications. Data consistency can be conirmed at the table or row leel and
dierences can be re-examined in case o transient dierences due to in-light
transactions. I necessary, diergent data can be conerged so that both compared
databases relect the same data.
STREAMS ARCHITECTURE
1here are three basic elements o Oracle Streams: capture, staging, and
consumption.
Consumption Consumption
Staging Staging Capture Capture
Capture
Oracle Streams supports capture o eents into the staging area. 1hese eents are
captured in three ways. Lxplicit capture allows applications to explicitly generate
eents and place them in the staging area. Implicit capture automates the capture o
changes within the database. Oracle Database 11g proides two techniques or
implicitly capturing changes: log-based capture and synchronous capture. \ith log-
based capture, the serer captures DML and DDL eents or a source database by
mining the source redo logs and archie logs locally. Alternatiely, the serer can
mine the redo and,or archied logs o the source database at an alternate database,
assuming the alternatie database is on a similar platorm type and operating
system. \ith synchronous capture, DML changes are captured ia an eicient
internal mechanism during the user`s transaction actiity.
Log-Based Capture
1he log-based capture mechanism leerages the act that changes made to tables
are logged in the redo log to guarantee recoerability in the eent o a crash or
media ailure. Capturing changes directly rom the redo log iles minimizes the
oerhead on the system. Oracle can read, analyze, and interpret redo inormation,
which contains inormation about the history o actiity on a database. Oracle
Streams mines the inormation and deliers change data to the capture process.
1ables identiied or replication with Oracle Streams automatically log supplemental
inormation into the redo stream, such as primary key columns, to acilitate the
deliery o this inormation. Additional inormation, such as columns required or
conlict resolution, must also be logged.
1he capture process consists o seeral subcomponents. A reader serer reads the
redo log and diides the redo log into regions. Prepare serers scan the regions
deined by the reader serer in parallel and perorm preiltering o changes ound in
the redo log,based upon user-deined rules. 1hus, only changes to desired objects
are captured.
A builder serer merges redo records rom the preparer serers and passes the
merged redo records to the capture process. 1he capture process thenormats each
change into a Logical Change Record ,LCR,. I the LCR is ound to satisy the
deined rules it then enqueues the LCR into the staging area or urther processing..
1he capture process is an Oracle background process
LogicaI Change Records
Logical change records describe changes made to a single row o a table modiied
with a single DML statement. A single DML statement that operates on multiple
rows within a table will generate multiple LCRs, and a single transaction can consist
o multiple DMLs. Lach logical change record includes the name o the changed
table, the old and new alues or any changed columns, and the alues or the key
columns. Armed with this inormation, changes can be applied to the correct rows
at the destination sites and conlicts can be detected.
It can be important to dierentiate between changes that originate at dierent sites,
so each LCR is tagged with identiication inormation rom the source database
about the origin o the change. 1hese tags are typically used during the
consumption phase o Streams. In certain cases this inormation is used to ilter out
changes that originated at another site and were made by the apply process, to
preent their being placed in the staging area and cycling back to the originating
site. 1his is most notably the case in an N-way replication coniguration, where
each replicated site communicates its changes directly to eery other site in the
coniguration. In other cases, or example a hub and spoke coniguration, it is
important to capture all changes, including those that originate at other sites. In
these cases, it may be desirable to hae changes rom an indiidual spoke relected
through the hub to other spokes in the coniguration
LocaI vs. Downstream Capture
Oracle Streams supports mining rom the in-memory log buer, hot mining o the
actie redo log, as well as mining archied log iles. In the case o hot mining, the
redo stream is mined or change data at the same time it is written to the actie
redo log, reducing the latency o capture. Streams seamlessly traerses the log
buer, redo log, or archied log as necessary without any additional coniguration.
Only LCRs that satisy the selection criteria or capture are placed in the staging
area.
Streams also has the ability to capture changes or a source database at a dierent
serer. Using Oracle`s Log 1ransport Serices, the archied log iles o the source
database are written to the remote serer as they are written locally, using the same
data protection modes as Oracle Data Guard. 1he remote serer, capturing changes
into the staging area on this remote serer, then mines these remote logs. Should
the remote serer be a subscriber to the changes, they can also be applied. 1his has
two important beneits. lirst, it allows or complete oloading o Streams actiities
rom the production database serer-oten a critical requirement or high olume
OL1P databases. Secondly, since the log iles are written remotely using Oracle
Data Guard protection modes, you can choose the mode appropriate to your
enironment. A single remote serer can be used to capture changes or multiple
source databases.
Synchronous Capture
Synchronous capture uses an internal mechanism to capture DML changes to
speciied tables. \hen a DML change is made to a table, it can result in changes to
one or more rows in the table. Synchronous capture captures each row change and
conerts it to a Logical Change Record (LCR). Ater capturing an LCR,
synchronous capture writes a message containing the LCR to disk into a queue.
Synchronous capture can be especially useul in situations where you want to
replicate only a small subset o the total number o tables in your database.
Synchronous capture oers the same tagging capabilities as log-based capture. Lach
LCR is tagged with identiication inormation rom the source database about the
origin o the change. 1hese tags are typically used during the consumption phase o
Streams. In certain cases this inormation is used to ilter out changes that
originated at another site and were made by the apply process, to preent their
being placed in the staging area and cycling back to the originating site. 1his is most
notably the case in an N-way replication coniguration, where each replicated site
communicates its changes directly to eery other site in the coniguration. In other
cases, or example a hub and spoke coniguration, it is important to capture all
changes, including those that originate at other sites. In these cases, it may be
desirable to hae changes rom an indiidual spoke relected through the hub to
other spokes in the coniguration
ExpIicit Capture
Lxplicit capture allows applications to explicitly generate eents and place them in
the staging area. Applications can use strongly typed queues, as has been
characteristic o the queues in preious releases o the database, or can use the
Streams AnyData queues. AnyData queues can hold messages o dierent types, so
it is possible to enqueue dierent types o messages into a single staging area. I
desired, these messages can be ormatted as LCRs, and subsequently consumed by
an apply engine.
Staging
Once captured, eents are placed in a staging area. 1he staging area is a queue
designed to store and manage captured eents. Database changes, already ormatted
as LCRs by the capture process, are stored in an in-memory queue until consumed
by all subscribers. LCRs captured ia synchronous capture are stored in a disk
staging area. Lents explicitly queued to the staging area by applications or uture
processing are also maintained in the staging area. 1he queue proides a holding
area with security, as well as auditing and tracking o eent data.
Subscribers examine the contents o the staging area and determine whether or not
they hae an interest in the message representing that eent. A subscriber can either
be a user application, another staging area ,usually on another system,, or the
deault apply process. 1he subscriber can optionally ealuate a set o rules to
determine whether the message meets the criteria set orth in the subscription. I
so, then the message will be consumed by the subscriber.
I the subscriber is a user application, the application will explicitly dequeue the
message rom the staging area in order to consume the message. I the subscriber is
another staging area, the message will be propagated and enqueued to that staging
area. I the subscriber is an apply process, the messages will be dequeued and
consumed by the apply process.
Propagation
Lents in the staging area can be propagated to staging areas in other databases. 1o
simpliy network routing and reduce \AN traic, eents need not be transmitted
to all databases and applications. Rather, they can be directed through queues on
one or more systems until they reach the subscribing system. lor example, consider
a network between three sites A, B, and C where sites A and B can communicate
directly, as can B and C, but sites C and A do not hae direct communication.
Streams is conigurable to allow the changes at site A to be relected at site C ia
site B. Site B can pass the eents through to site C without requiring site B to apply
the change locally. O course, i the change is also desired at this intermediate site
as well, the change can be applied at site B without impacting the pass-through to
site C.
Administrators hae a great deal o lexibility to use in speciying the routing o the
Streams. By using the rules-based publish and subscribe capabilities o the staging
area queues, they can choose which changes are propagated to each destination
database, and can speciy the route messages will traerse on their way to a
destination. 1hroughout the system, Oracle Streams maintains the source database
inormation or each eent, as it can be important to dierentiate between changes
that originate at dierent sites. 1he administrator controls whether to select all
changes, including those that originate at other sites, or only those changes made at
the local site and not by the apply engine
Consumption
Messages in a staging area are consumed by the apply engine, where the changes
they represent are applied to a database, or they are consumed by an application.
1he Oracle Streams apply engine applies DML changes, DDL changes, user-
supplied LCRs, and user-enqueued messages. \hen the destination database is an
Oracle database, the apply engine runs locally on the system hosting the Oracle
database. lor greater lexibility, the Oracle Streams apply engine supports both
deault and custom apply procedures. Support or explicit dequeue allows
application deelopers to use Oracle Streams to notiy applications o changes to
data, while still leeraging the change capture and propagation eatures o Oracle
Streams.
DefauIt AppIy
1he deault apply engine can apply automatically captured DML and DDL changes,
as well as user-supplied LCRs. 1he deault apply engine detects conlicts where the
destination row has been changed and does not contain the expected original
alues. I a conlict is detected, a conlict resolution routine may be inoked, i
desired.
1he apply engine is a background process consisting o a set o serer processes: an
apply coordinator, a reader serer, and one or more apply serers. 1he reader serer
assembles transactions or capture-generated LCRs. 1he apply coordinator
perorms transaction dependency and DML leel dependency scheduling to
maximize concurrency. 1he apply serers actually apply the changes. Since the
apply coordinator and apply serers are typically in the same Oracle instance, there
is no network roundtrip inoled in dependency scheduling. 1he apply engine can
inoke user-supplied unctions to transorm changes to the correct ormat or name
or each LCR.
Changes rom multiple databases may be sent to a single destination staging area.
Multiple apply engines apply the changes rom each source database concurrently.
lor example, queue1 rom database A and queue2 rom database B can propagate
to queue3 at database C. Database C will use two apply engines to apply these
changes. 1he administrator conigures the two apply engines using rule sets to
ensure each apply engine applies changes rom each source site. 1hroughout the
system, Oracle Streams maintains the source database inormation, as it can be
important to dierentiate between changes that originate at dierent sites. 1he
administrator controls whether to capture all changes, including those that originate
at other sites, or only those changes made at the local site and not by the apply
engine.
User-Defined Custom AppIy
User-deined custom apply procedures enable total control oer the eents to be
applied. \ith customized apply, the apply engine passes the LCR or user-enqueued
message to a user-deined procedure, or apply handler. 1his proides greater
lexibility in processing the message. 1o urther maximize lexibility in apply
handing, users can deine multiple apply handlers or non-LCR messages, as well as
separate apply handlers or each type o DML operation ,inserts, updates, or
deletes, perormed on a particular table.
lor example, using this custom apply capability, a user could write a procedure to
skip the apply o all deletes or the Lmployee table. Only the behaior o LCRs that
perorm deletes on the table Lmployee are aected in this scenario. Inserts and
updates to the Lmployee table continue to be applied using the deault apply
engine. 1hus no delete LCRs rom other sites will be perormed on the Streams site
replica and all o the rows in that Lmployee table will still exist at the replica site.
1hese custom DML handlers allow the user to exercise complete control oer the
behaior o the apply engine, enabling users to implement custom Streams sites to
satisy any business requirement.
ExpIicit Dequeue
Similar to the explicit capture eature where applications explicitly enqueue
messages into the Streams queues, user applications can explicitly dequeue LCRs or
other messages rom the staging area. Messages directly enqueued into the source
staging area can be directly dequeued by a subscribing application without any
interention rom the apply engine. Subscribing applications can directly dequeue
messages rom the staging area. I the application is remote, a staging area may be
created in a remote database that will subscribe to messages published in the source
staging area. 1he destination application can then dequeue rom the remote staging
area. Alternatiely, the destination application can directly dequeue rom the source
staging area using a ariety o standard protocols.
CUSTOMIZING ORACLE STREAMS
It is possible to control which eents, or changes, are captured, propagated and
applied using a combination o Oracle Streams rules and transormations.
RuIes
Lach element o Oracle Streams uses a set o rules to distinguish the eents to be
managed. 1hese user-speciied rules are enorced by capture to selectiely enqueue
change eents into the staging area. Similarly, the apply engine will selectiely apply
changes based on the rules deined or apply. Rules are also used to selectiely
propagate eents between staging areas. Rules can speciy the selection o the entire
database, or schemas, as well as indiidual tables. Rules are SQL-like expressions
that ealuate to either 1RUL or lALSL. Rules can also be used to limit eents
based on the content o the eent itsel. An example o a rule limited to any
untagged DML changes to the lR schema is:
:dml.get_object_owner() = 'HR' AND
:dml.is_null_tag() = 'Y'

Note the use o the tag in this rule. In most cases, changes local to a database hae
no tag ,null tag,, while changes applied rom other databases are tagged in the redo
log with a non-null alue.
lor simplicity, rules are organized into named collections reerred to as rule sets.
Rules can easily be added to or subtracted rom the rule set. Multiple rules can
belong to a rule set and multiple rule sets can contain the same indiidual rules. 1he
DBMS_RULLS_ADM package is proided to acilitate the management o these
rules.
Lach Streams process uses two rule sets, a positie rule set and a negatie rule set,
and rule set ealuation is optimized to eiciently identiy the eents that meet the
speciied criteria or each process. 1he positie rule set identiies the rules or
objects to be included or Streams processing. 1he negatie rule set lists the rules
or objects to be discarded rom Streams processing. Lach Streams process
ealuates the negatie rule set irst, discarding any message that satisies a rule in
this negatie rule set. 1he process then ealuates rules using the positie rule set.
Only messages that ealuate to 1RUL as a result o a rule in the positie rule set
are passed on to the process.
HorizontaI and VerticaI Subsetting
Lach o the Oracle Streams elements supports subsetting o objects, so a
destination need only subscribe to a subset o the data at the source. Consider a
typical distributed scenario inoling headquarter databases and branch oice
databases. 1he branch oice database only needs the data releant or that branch.
A branch oice would thereore only subscribe to eents aecting that branch.
Other branches would receie dierent subsets.
Oracle Streams supports migration o data rom one subset to another.
Subscriptions are content-based, and should that content change, the subscriptions
may change. 1his may require data to be deleted rom one subset database, and
inserted into another. Streams automatically manages the changes and row
migration issues to ensure that the data applied to the replica relects the subset
criteria. By coniguring subset rules or propagation to a particular destination,
Insert and Delete LCRs that do not match the subset criteria are not sent to the
replica site. Update LCRs are examined to determine i the change aects the
replica and, i so, conerts the update into the appropriate command ,insert or
delete, to apply the change correctly. 1he ollowing example shows how to
conigure the rules or an apply site to maintain data only or the customers in
Caliornia ,CA,. 1he table Customers is in the lR schema and this subset o data is
replicated to the M\RLP.\ORLD database into the Streams queue:
DBMS_STREAMS_ADM.ADD_SUBSET_PROPAGATION_RULES(
table_name => `HR.CUSTOMER',
dml_condition => `STATE=''CA''',
streams_type => 'PROPAGATION',
queue_name =>'strmadmin.streams_queue',
destination_queue_name =>
`strmadmin.streams_queue@MYREP.WORLD'
source_database => `MYDB.WORLD'
);

In this example, the CUS1OMLR table contains a column S1A1L, and each
replica site is limited to customers or a particular state. In this instance, state ~ CA.
I an LCR with an insert or delete or a customer has the state column equal to CA,
the LCR is sent to the target site. I the insert or delete is or any other state, the
LCR is not sent. loweer, suppose an update to the customer table occurs
showing that customer Joe has moed rom Caliornia to New \ork. Streams will
automatically remoe the customer record or Joe, so that Joe will no longer appear
in the replica as a Caliornia customer. I the update to the customer table shows
that customer Jim moed into Caliornia rom Pennsylania, then the customer
record or Jim will be automatically inserted into the database.
Vertical subsetting o data can be implemented using transormations, as described
in the next section.
Transformations
A transormation is a change in the orm o an object being captured, propagated
or applied, or a change in the data it holds. 1ransormations can include changing
the data type representation o a particular column in a table at a particular site, or
renaming a column to a table at a particular site, or een changing the data alues.
Streams supplies built-in transormation codes or handling the most common
customer modiications. Changing the owner o a table, renaming a table, or
renaming a column within a table is easily conigured. Other custom
transormations can be represented by a user-supplied PL,SQL unction that takes
the source data type as input and returns an object o the target data type.
\hen a transormation is used, eery eent or the speciied object is manipulated
using the transormation. 1ransormations can be perormed as eents are placed
into or remoed rom the staging area. A transormation during capture modiies
the message beore inserting it into the staging area. lor example, a company may
want to replicate a table that contains a column with conidential inormation that
should not exist at any other site. Using a transormation during capture, the
column can be eliminated rom the eent or LCR. As a result, no other site will see
this restricted inormation. 1ransormations can also be conigured or
propagation, which may be useul or ormatting the message beore it is sent to
subsequent remote sites. linally, a transormation can be speciied as the eent is
consumed with the apply process, which can be useul or ormatting a message in
a manner appropriate or a speciic destination.
USING ORACLE STREAMS
Oracle Streams proides a lexible architecture that supports a wide ariety o
inormation sharing and data proisioning requirements. A ew o the most
common uses include the ollowing:
Replication
Adanced Queuing
Integration with non-Oracle data stores
Proisioning data in a Grid enironment
Aailability during database or application upgrade
Using OracIe Streams for RepIication
1he ollowing igure demonstrates the streams architectural elements as used in
replication. Oracle Streams replication captures changes rom a source database,
stages and propagates those changes to one or more remote databases, and then
consumes or applies the changes at each target database.

Queue
-----
LCRs
EM P
Update EM P set
stateCA`
where
empid100;
Redo Log
Capture
Queue
------
LCRs
EM P
Apply
Propagation
Update EM P set
stateCA`
where
empid100;

1he igure shows an Update statement that changes the state or a row in the LMP
table representing an employee whose employee id ,empid, is 100. As usual, the
change is recorded in the redo log. 1he capture process, preiously conigured to
collect changes made to the LMP table, retriees the changes rom the redo log,
ormats the inormation into logical change records, and places the LCR into the
staging area at the local database. 1his LCR is propagated rom the staging area ,or
queue, at this source database and deliered to another database that has
subscribed to the changes on the LMP table. In addition, the apply engine at this
second database is conigured to receie the changes on the LMP table. Once the
change has been propagated to the new site, the local deault apply process at this
second database automatically applies the change to the database.
Configuring a RepIication Environment
Oracle Streams proides an easy way to instantiate replicated objects at the target
sites, using Oracle export and import utilities or the RMAN duplicate database
eature. 1he instantiation is perormed at the target database without aecting any
existing sites in the Streams coniguration. All sites continue to process their own
work while instantiation to new sites is in progress. Ater a new object is prepared
at the source site to capture changes or replication, the Streams replication
metadata or the object is marked with the appropriate SCN, to ensure no changes
are lost. As copies o the objects are created at the target site using export and
import, the system will note the source SCN o the copied data, and will begin
applying any changes that committed ater the object was copied.
1o simpliy coniguration, administration and monitoring o Oracle Streams
enironments, Oracle proides a Streams tool within the Oracle Lnterprise
Manager Database Control. 1he Streams tool proides wizards that you can use to
conigure a Streams replication enironment. \ou can also use this Streams tool to
generate scripts, which you can then modiy to meet your speciic requirements.

A customized API, tailored or replication, is proided to help users easily
conigure common replication scenarios. Using commands in the
DBMS_S1RLAMS_ADM package, a database administrator can quickly
implement a replication enironment at the table, schema, or database leel. 1his
package perorms multiple coniguration steps or the administrator depending on
the type o Streams process speciied, including the automatic generation o rules
or the process. lor example, the ollowing command conigures replication rom a
local database to the target database, N\C, identiied by the database link N\C:
DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS(
schema_names=>'HR',
source_directory_object=>null,
destination_directory_object=>null,
source_database=>null,
destination_database=>'NYC',
bi_directional=>FALSE,
Include_ddl=>TRUE,
instantiation=>
DBMS_STREAMS_ADM.INSTANTIATION_SCHEMA_NETWORK
);
Issuing this simple command results in the creation o a uni-directional replication
enironment, which will replicate DML and DDL changes rom the local database
to the target, N\C. 1he source and destination directory object parameters are set
to null, because Oracle is using the network option o Data Pump to perorm the
initial instantiation o the replicated site. All o the coniguration, including queue
creation, rule generation, and initial data loading is perormed automatically with
this command. 1he administrator can urther customize this coniguration, i
desired, using other packages and procedures related to rules and Streams
processing.
ConfIict ResoIution
\hen Oracle Streams is used to support replication, both the source and
destination databases are ully aailable to end-users or reading and writing during
any replication actiity. Because users can update dierent copies o the same table
anywhere, it is possible or changes made at dierent database sites to update the
same data element at the same time, resulting in an update conlict. 1he deault
apply mechanism will detect these conlicts as incoming replication changes are
applied. Oracle proides built-in conlict resolution routines, such as "latest
timestamp" or "oerwrite", to automatically resole potential conlicts. users can
choose dierent resolution methods or dierent tables. Users also hae the option
to create their own routines to employ resolution rules tailored to their particular
business needs. Any unresoled conlicts are logged in the database or special
handling or re-execution ater the conlict is resoled manually.
Using OracIe Streams for Message Queuing
Streams proides a robust message queuing capability called Oracle Streams
Adanced Queuing. 1his eature allows user applications to enqueue messages into
the staging area, propagate messages to subscribing staging areas, notiy user
applications that messages are ready or consumption, and dequeue messages at the
destination. It supports all the standard eatures o message queuing systems
including multi-consumer queues, publish and subscribe, content-based routing,
Internet propagation, transormations, and gateways to other messaging
subsystems.
Oracle Streams Adanced Queuing is useul or building message queuing
applications. Ater an administrator creates the staging area, applications can
explicitly enqueue messages into the source database. Applications can use strongly
typed queues, as has been characteristic o the queues in preious releases o the
database, or can use the Streams AnyData queues. AnyData queues can hold
messages o dierent types, so it is possible to enqueue dierent types o messages
into a single staging area. Lnterprise Manager Database Control proides a simple
management tool or Oracle Streams Adanced Queuing.

1he DBMS_S1RLAMS_ADM package includes procedures that help users easily
conigure common messaging scenarios. Using these customized procedures,
coniguration o the rules and rule set that goern the queue contents is simpliied.
In addition, new procedures in the DBMS_S1RLAMS_MLSSAGING package
proide a simple interace or enqueuing and dequeuing messages rom the staging
area. 1hese procedures simpliy the application deelopment process.
lor example, assume that you hae created a table called ORDLR_LVLN1 that
has the ollowing ormat:
CREATE OR REPLACE TYPE order_event_type AS OBJECT (
order_number NUMBER(10),
part_number VARCHAR2(10),
status VARCHAR2(10),
delivery_date DATE
);
/

1he ollowing command sets up a rule to apply only those orders that hae been
entered with appropriate part numbers:
BEGIN
DBMS_STREAMS_ADM.ADD_MESSAGE_RULE(
message_type => 'DEMO.ORDER_EVENT_TYP',
rule_condition => ':msg.part_number is not null',
streams_type => 'APPLY',
streams_name => 'apply_w_msghdlr',
queue_name => 'strmadmin.streams_queue');
END;
/
Event Management with OracIe Streams
Business eents are aluable communications between applications or organizations
,internal and external,. 1hey require the highest degree o reliability, integrity, and
security. Oracle Streams message queues are stored in the Oracle database, and are
retained ater consumption. 1his allows Oracle Streams Adanced Queuing to be
used as a business eent management system. Adanced Queuing stores all
messages in the database in a transactional manner, where they can be automatically
audited and tracked. 1his audit trail can be used to extract intelligence about the
business operations.
1he key to using Streams as a business eent management system is retention in the
staging area. As with message queuing, a staging area is created to stage business
eents that are explicitly enqueued by applications. Business eents can be
consumed locally ia an application explicitly dequeuing the eent, or they can be
propagated to other staging areas and then consumed by applications. All staging
areas will retain messages, een ater they are consumed, proiding an audit trail
critical or managing business eents.
Event Notification with OracIe Streams
Inormation oerload makes it diicult to ind the data that is important. A new
class o applications is used to monitor data and notiy interested parties o releant
data. Oracle Streams Adanced Queuing supports eent notiication, where
changes to an underlying database are captured and then sent to other applications
or deices that subscribed to that change eent. Streams includes a scalable and
sophisticated rules engine that can ealuate captured changes and orward them on
to the appropriate subscribers.
Coniguring Streams or Lent Notiication requires setting up the capture process
to capture the eents o interest, be they DML, DDL, or explicitly enqueued
messages. 1hese eents are published and subsequently consumed by subscribing
applications. Rules are used to restrict consumption to eents o interest. 1he
consuming application can then take action, which may include an email
notiication, or passing the message to a wireless gateway or transmission to a cell
phone or pager.
Using OracIe Streams in Heterogeneous Environments
Oracle Streams is an open inormation sharing solution, supporting heterogeneous
replication between Oracle and non-Oracle systems. Using a database gateway,
changes initiated at Oracle databases can be applied to non-Oracle platorms. Only
DML changes can be replicated to non-Oracle platorms.
In order to meet the needs o integrating with legacy applications, the messaging
gateway is proided to automatically propagate messages between Oracle queues
and IBM \ebsphere MQ and 1IBCO Rendezous queues.
OracIe to Non-OracIe Capture/AppIy
1o implement capture and apply o DML changes rom an Oracle source to a non-
Oracle destination, an Oracle system unctions as a proxy and executes the apply
engine that would normally be done at an Oracle destination site. 1he Oracle
system then communicates with the non-Oracle system ia a database gateway. 1he
changes are dequeued in an Oracle database itsel and a local Oracle apply process
applies the changes to a non-Oracle system across a network connection through a
database gateway speciic to the non-Oracle database.
1he ollowing igure illustrates how heterogeneous propagation o DML statements
work.
G
a
t
e
w
a
y
N on-O racl e D B
O racle D B
Staging
A r ea
A pp ly
Pr ocess
D est inati on
Tabl e
LCRs
Sourc e
Tabl e


Non-OracIe to OracIe Capture/AppIy
Users who want to propagate changes rom a non-Oracle database to an Oracle
database must write an application to capture the changes made to the non-Oracle
database. 1he application can capture the changes by reading rom transaction logs
or by using triggers. 1he application is then responsible or assembling and
ordering these changes into transactions, conerting them into an LCR ormat and
publishing them into the target Oracle database staging area.
N o n - O r a c l e
D B
S o u r c e
T a b l e
U s e r
A p p
S t a g i n g
A r e a
A p p l y
P r o c e s s
D e s t i n a t i o n
T a b l e
C h a n g e
C a p t u r e
Integrating with Legacy AppIications

1he message gateway unctionality o Oracle integrates Oracle database
applications with other message queuing systems such as IBM \ebsphere MQ
,ormerly called MQ Series, and 1IBCO Rendezous. Since many legacy
applications on mainrames communicate with \ebsphere MQ, there is a need or
integrating these applications into an Oracle enironment. 1he message gateway
makes non-Oracle message queues appear as i they were Oracle queues, and
automatically propagates messages between Oracle queues and IBM \ebsphere
MQ or 1IBCO Rendezous queues.
Using OracIe Streams for Provisioning Data in a Grid Environment
Oracle Real Application Clusters ,RAC, is a key component o Oracle`s grid
solutions. RAC distributes a single database across multiple serers in a grid,
enabling on-demand proisioning o CPU resources or a database workload.
Oracle Database 11g enhances the Streams support or RAC enironments with
the ability to mine the actie online log iles or DML and DDL, realizing the
adantages o low latency capture, propagation, and apply along with the many
other beneits o RAC. Streams processes run rom a single instance o a RAC
cluster, identiied as the primary instance or the Streams queue and processes. An
alternatie instance can be speciied as the secondary instance in case the primary
becomes unaailable. In the eent the primary instance ails, the Streams processes
will automatically be restarted on the secondary instance. Upon the recoery o the
primary instance, the Streams processes will return to the primary instance. 1hus,
Streams will exhibit the same unbreakable behaior as other database eatures when
used in a RAC enironment, without need or DBA interention
Many o the same eatures o Oracle Streams that are useul or inormation
sharing in a distributed enironment are equally useul or data proisioning in a
grid enironment. lor example, suppose you hae a production database, and you
need to perorm some analysis. In a grid enironment, you could simply choose to
add nodes to your production RAC database to proide the additional CPU
capacity needed or the analysis. loweer, it`s possible that may not be easible.
Maybe there are departmental restrictions that prohibit running the analysis against
the production database. Maybe you are not running RAC, or maybe you do not
hae any more suitable nodes on the proper network and SAN to allocate-but
you do hae nodes on another network or SAN. Using the data proisioning
eatures o Oracle Database 11g, you can transport the tablespaces containing the
inormation you plan to analyze, instantiate a Streams replica o the data in on
another system, and perorm the analysis on that system.
Leeraging the Oracle 1ransportable 1ablespaces and Oracle Streams, the Oracle
database oers an eicient way or migrating applications to the grid. \ith a single
command, the database administrator can identiy a set o tablespaces rom one
database, ship the tablespace set to another database een i the second database is
on a dierent operating system or platorm, and plug this set into the second
database. During this time, both the source and destination databases are open and
aailable or any user actiity. Meanwhile, Oracle Streams has begun to capture any
changes rom the source database that occur during the tablespace copy to the
replica database. Ater the tablespace set is aailable at the replica database, the
replica database is synchronized by Oracle Streams with the changes rom the
source database. All o this is done with a single command with no downtime
required.
Minimizing Downtime during Upgrades
Using the eatures o Oracle Streams, users can perorm the ollowing database
maintenance operations with little or no downtime:
Upgrading the ersion o the database rom Oracle9i Release 2 or later to a
later release, such as Oracle11g
Migrating the database to a dierent operating system or character set
Migrating to a new ersion o an application
Applying an Oracle sotware patch
Ordinarily, these operations might require considerable database downtime to
complete. Using Oracle Streams, howeer, users simply conigure a replica o the
source database, which will be used to perorm maintenance operations, while the
original database remains ully operational.
1he ollowing general steps outline the operations that must be completed in order
to perorm a database maintenance operation while remaining online:
1. Create a new, empty database.
2. Use Oracle Streams to conigure a replication enironment, where this
new database is the destination database, and the original database is the
source database. Ater instantiating ,populating, the destination database
,with Lxport,Import or RMAN,, Oracle Streams will automatically ensure
that DML and DDL changes occurring at the source database are
ultimately applied at the destination database.
3. Perorm the desired maintenance operations on the destination database.
During this time, the original database remains aailable online with
Streams conigured, but not started.
4. Ater completing the maintenance operations, use Oracle Streams to apply
changes made at the source database to the destination database.
5. Once these changes hae been successully applied at the destination, take
the source database oline and make the destination database aailable or
applications and users.
ExampIe Streams Configuration
Oracle Streams is designed or maximum lexibility to satisy customer inormation
sharing requirements in a ariety o markets. lor example, customers can use
Oracle Streams to create Messaging and Lent Management, Lent Notiication,
Replication, Data \arehouse Loading, and Data Proisioning solutions. O course,
all customers can utilize the ull power o Oracle Streams, and create conigurations
that seemingly span multiple markets, enabling new classes o applications. In
addition, all deployments and their associated meta-data are compatible. lor
example, a replication installation can easily be extended to load a data warehouse
or enable bi-directional replication-a complete reconiguration is not required.
1he lexibility o Oracle Streams is demonstrated in the ollowing example. A
corporate I1 organization is charged with maintaining data aailability around the
clock or a critical global application. 1heir strategy is to maintain three
geographically distinct databases with all the requisite data or this high proile
application. Additional requirements include a reporting database containing the
most current inormation or the analysts in the company headquarters oice in
New \ork to perorm ad-hoc querying as well as a disaster recoery database
separately maintained rom their New \ork oice. A inal requirement is to share
data with existing applications that are hosted on a Sybase database.
Tokyo
NY
London
DR Report
Gateway
Sybase
OracIe Streams Usage ExampIe

Oracle Streams is used to replicate data in an N-way coniguration consisting o
three regional sites: New \ork, London, and 1okyo. At each o these sites, Streams
log-based capture will capture any changes that occur or subscribed tables in each
local region, and will stage them locally in the queue. All changes captured in each
region will be then orwarded to each o the other region's databases with the goal
that all changes made at each site will be relected at eery other site, proiding
complete data or the subscribed objects throughout the world.
Since the updates will be automatically applied when receied at each regional
database, the Oracle Streams deault apply engine is used to apply the changes. As
updates are applied, Oracle Streams checks or conlicts, and resoles any conlicts
that are detected. Streams can also be used to exchange data or particular tables
with non-Oracle databases. Utilizing the Oracle Database Gateway or Sybase, the
Streams apply engine will apply the changes to a Sybase database using the same
mechanisms as it does or Oracle databases.
1he databases or reporting and disaster recoery are hosted rom the New \ork
database site. 1he reporting database is a ully unctional Oracle database that has a
read-only copy o the releant application tables. 1he reporting site will not be
conigured to capture changes on these application tables. Streams will impose no
restrictions on the coniguration or usage o this reporting database.
CONCLUSION
Oracle Streams simpliies sharing data between databases and database clusters,
with its reolutionary concept o uniying message queuing and data replication
capabilities. \ith Streams, the basic elements o capture, staging, and consumption
in combination with user-deined transormations and heterogeneous
interoperation produce more sophisticated replication, messaging, and notiication
solutions than eer beore possible.
1his resilient technology proides the coniguration lexibility required to handle
the real world situations encountered in modern global corporations. Streams
technology is the premier eature or sharing and proisioning data in complex
distributed database and grid computing enironments.

OracIe Database 11g: OracIe Streams
JuIy 2007
Author: Patricia McEIroy, Maria Pratt
Contributing Authors:

OracIe Corporation
WorId Headquarters
500 OracIe Parkway
Redwood Shores, CA 94065
U.S.A.

WorIdwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracIe.com

Copyright 2007, OracIe. AII rights reserved.
This document is provided for information purposes onIy 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 oraIIy or impIied
in Iaw, incIuding impIied warranties and conditions of merchantabiIity
or fitness for a particuIar purpose. We specificaIIy discIaim any
IiabiIity with respect to this document and no contractuaI obIigations
are formed either directIy or indirectIy by this document. This document
may not be reproduced or transmitted in any form or by any means,
eIectronic or mechanicaI, for any purpose, without our prior written permission.
OracIe is a registered trademark of OracIe Corporation and/or its affiIiates.
Other names may be trademarks of their respective owners.

TWP Streams 11gr1 134658

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

TWP Streams 11gr1 134658

Caricato da

Copyright:

Formati disponibili

Oracle Database 11g: Oracle

OracIe Database 11g: OracIe Streams Page 19

Integrating with Legacy AppIications

OracIe Streams Usage ExampIe

Potrebbero piacerti anche