Oracle Streams Replication

Oracle Database 11g: Oracle
Streams Replication

.v Oracte !bite Paer
]vt, 200

OracIe Database 11g: OracIe Streams RepIication Page 2
Oracle Database 11g: Oracle Streams Replication
Lxecutie Oeriew.......................................................................................... 3
Oracle Streams Oeriew................................................................................. 3
Unique Databases ......................................................................................... 4
Directed Networks ....................................................................................... 5
Oracle Streams Architecture............................................................................ 5
Capture ........................................................................................................... 5
Logical Change Records.......................................................................... 5
Log Based Capture................................................................................... 6
Mining the Redo Log............................................................................... 6
Synchronous Capture...............................................................................
Staging ............................................................................................................ 8
Propagation............................................................................................... 8
Consumption................................................................................................. 9
Deault Apply............................................................................................ 9
Customized Apply.................................................................................... 9
Oracle Streams Replication............................................................................ 10
Coniguring a Replication Lnironment ................................................. 11
Conlict Resolution..................................................................................... 13
Comparing 1able Data............................................................................... 13
Streams Adisor .......................................................................................... 13
Customizing Oracle Streams Replication .................................................... 14
Rules ............................................................................................................. 14
lorizontal and Vertical Subsetting...................................................... 15
1ransormations.......................................................................................... 16
leterogeneous Lnironments.................................................................. 16
Oracle to Non-Oracle Capture,Apply................................................ 16
Non-Oracle to Oracle Capture,Apply................................................ 1
Lxample Streams Coniguration................................................................... 18
Oracle Streams Usage Lxample................................................................ 18
Application,Platorm Migration Lxample.............................................. 19
Conclusion........................................................................................................ 20

Oracle Database 11g: Oracle Streams Replication
EXECUTIVE OVERVIEW
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 replicate inormation in the
Oracle 11g database.
ORACLE STREAMS OVERVIEW
Oracle proides a number o technologies that support the goal o inormation
consolidation, but there can be compelling business requirements that dictate
sharing inormation. lor example, some remote locations may not hae good
connectiity to the primary site or may preer to maintain site autonomy. In other
cases, the data may be consolidated, but the applications may need a method o
communicating with one another. 1here are nearly as many dierent reasons or
needing to share inormation between locations or applications, as there are
businesses. lortunately, Oracle Database 11g proides a single, uniied solution or
inormation sharing-Oracle Streams. It is the lexibility o Oracle Streams that
allows it to sole each o these disparate inormation-sharing needs. Len i it`s not
possible to create a single, uniied database, it is still possible or the data to appear
uniied to the end-user.
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.
Although, as described aboe, Oracle Streams can be used to implement a ariety
o inormation sharing solutions, the ocus o this paper is on using Oracle Streams
in a replicated enironment.
Unique Databases
Databases replicated 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. In addition to
supporting user-deined transormations, Oracle proides easy to use declaratie
transormations or the most common transormations, such as changing the name
o a column or table.
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.
ORACLE STREAMS ARCHITECTURE
1here are three basic elements o Oracle Streams: capture, staging, and
consumption.

Capture
Oracle Streams supports capture o eents into the staging area. 1hese eents can
be captured either explicitly or implicitly. Lxplicit capture allows applications to
explicitly generate eents and place them in the staging area. Implicit capture
automatically captures changes to a table using one o the ollowing techniques:
log-based capture or synchronous capture \ith log-based capture, the serer
captures DML and DDL eents or a source database by mining the source redo
logs, log buer, and archie logs locally. Alternatiely, the serer can mine the redo
logs 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.
LogicaI Change Records
Oracle Streams uses logical change records, or LCRs, to 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.
Log Based Capture
One o the key eatures o Oracle Streams replication is support or log-based
capture. Log-based capture 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 logs 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 can
mine the inormation and delier change data to the capture process. 1ables
identiied or replication with Oracle Streams must log supplemental inormation
into the redo stream, such as primary key columns, to acilitate the deliery o this
inormation.
1he capture process consists o the ollowing components: a reader serer, one or
more prepare serers, and one builder serer. 1he reader serer reads the redo log
and diides the redo log into regions. 1he prepare serers scan the regions deined
by the reader serer in parallel and perorm preiltering o changes ound in the
redo log. 1he capture process can intelligently ilter LCRs based upon deined rules.
1hus, only changes to desired objects are captured.
1he builder serer merges redo records rom the preparer serers and passes the
merged redo records to the capture process. 1he capture process then ormats the
change into a logical change record. I the LCR is ound to satisy the deined rules
it then enqueues the LCR into the staging area or urther processing. Lach reader
serer, preparer serer, and builder serer is a parallel execution serer. 1he capture
process is an Oracle background process.
Mining the Redo Log
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 proides the ability to capture changes or a source database at a dierent
serer. Redo transport serices uses the log writer process ,LG\R, at the source
database to send redo data to the downstream database asynchronously. At the
same time, the LG\R records redo data in the online redo log at the source
database. 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 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 the standard Oracle tools, you can conigure a protection
leel that is appropriate to your enironment. A single remote serer can be used
to capture changes or multiple source databases.
Oracle supports real-time mining o production redo logs at a downstream database
ia standby redo logs. Although Oracle supports only one real-time downstream
capture process at a downstream database, this real-time process can co-exist with
multiple downstream archied-log processes.
Synchronous Capture
In contrast to log-based capture, synchronous capture captures changes to a table
as they happen. Synchronous capture is useul in situations where you need to
replicate only a small subset o tables that change inrequently in a highly actie
database or in conigurations where capture rom the redo is not aailable.
Synchronous capture uses an eicient internal mechanism to capture DML changes
to speciied tables while the transaction is in progress. \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 persistent staging area ,queue,.
Synchronous capture oers the same tagging capabilites 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
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 within 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. \ith Oracle Streams replication, you can choose to use either the deault
apply procedure, or to create custom apply procedures as needed.
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 declaratie or user-written 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 declaratie transormations or user-supplied unctions to transorm changes
to the correct ormat or name or each LCR.
Changes rom multiple databases should be sent to multiple destination staging
areas. Multiple apply engines can then be used to apply the changes rom each
source database concurrently. Lach apply engine only applies changes rom one
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.
Customized AppIy
Streams proides the database administrator total control oer the apply process.
User-supplied PL,SQL procedures can be registered with Streams to customize the
apply processing. \ith custom apply, the apply engine passes the LCR or user-
enqueued message to the registered user-supplied 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:.: DDL
handlers or managing replicated DDL, Message handlers or processing non-LCR
messages: commit handlers to enable post-processing o the transaction as part o
the transaction commit, 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.
ORACLE STREAMS REPLICATION
1he ollowing illustration 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.

1he lower let side o the igure shows user DML actiity on one or more database
tables , or example, 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. Note that although in this example, the capture
process is shown at the source database, or perormance reasons, you may choose
to run the capture process at another location. 1he captured LCR is then
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, proides another way to 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 dependant on the type o Streams process
speciied including the automatic generation o rules or the process. lor example,
the ollowing API call conigures a Streams enironment that replicates changes
made to the lR schema between the local database ,source_database~null, and
N\C database:
DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS(
schema_names=>'HR',
source_directory_object=>null,
destination_directory_object=>null,
source_database=>null,
destination_database=>'NYC',
bi_directional=>TRUE,
instantiation=>
DBMS_STREAMS_ADM.INSTANTIATION_SCHEMA_NETWORK
);
Issuing this simple command results in the creation o a bi-directional replication
enironment, which will replicate DML changes between two sites. 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.
1he Data Pump export,import operation uses the Streams pool at the replication
sites. 1he Streams pool is a portion o memory in the System Global Area that is

used by Streams replication to proide memory or the capture and apply
processes. 1he size o this pool is automatically managed by Oracle's Automatic
Shared Memory Management eature when the SGA_1ARGL1 initialization
parameter is set to a nonzero alue.
As described in the ollowing section, the speciication o conlict resolution
routines in a bi-directional replication enironment is strongly recommended. 1he
administrator can perorm each o these steps indiidually, i desired, using other
packages 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. Dierent
resolution methods can be chosen 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.
Comparing TabIe Data
\hen sharing data in multiple locations, eriying data consistency between
databases is essential. 1he Oracle database includes a package to compare table
data between databases, DBMS_COMPARISON. 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.
Comparisons can be made between tables, iews, or materialized iews by creating
a comparison deinition. 1he deinition identiies the two objects ,tables, iews, or
materialized iews, or comparison and their location, either within the same
database or residing in dierent databases. Ater the deinition is established, the
data can be compared.
Streams Advisor
A Streams enironment typically includes multiple databases. Streams includes
dictionary iews that proide a comprehensie iew o the entire Streams topology.
1his topology identiies indiidual streams o messages and the Streams
components ,queue, capture, propagation, apply, conigured in each stream. 1he
topology inormation is determined using the Streams Perormance Adisor
package.
1he Streams Perormance Adisor also reports perormance measurements or a
Streams topology, including throughput and latency measurements. 1he Streams
Perormance Adisor also identiies any potential bottlenecks in a Streams topology
so that they can be managed eectiely.
CUSTOMIZING ORACLE STREAMS REPLICATION
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. Oracle Streams supports a ariety o
declaratie transormations, such as renaming a table, schema or column, or adding
a column to or remoing a column rom a table at a particular site. Oracle Streams
also supports user-supplied transormations. 1hese custom transormations are
represented by PL,SQL unctions that take the source data type as input and return
an object o the target data type.
\hen either a declaratie or custom transormation is used, eery eent or the
speciied object is manipulated using the transormation. Custom transormations
can be perormed as eents are placed into or remoed rom the staging area.
Declaratie transormations are perormed only during capture. 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. Custom
transormations can also be conigured or propagation, which may be useul or
ormatting the message beore it is sent to subsequent remote sites. linally, a
custom 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.
Heterogeneous Environments
Oracle Streams is an open inormation sharing solution, supporting heterogeneous
replication between Oracle and non-Oracle systems. Using a transparent 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 \ebsphere MQ and 1ibco 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 transparent 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 transparent gateway speciic to the non-Oracle database.

1he ollowing igure illustrates how heterogeneous propagation o DML statements
work.

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.


EXAMPLE 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 replication to create n-way master or directed network
conigurations, to implement data proisioning solutions, or to proide high
aailability during a platorm or application migration. 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
G atew ay
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.
AppIication/PIatform Migration ExampIe
Because the three sites in this example are participating in an N-way replication
enironment, it is possible to perorm an application or platorm migration at any
or all o these sites without requiring any downtime. As each site is upgraded, users
can be re-routed to the two remaining sites. \hen the migration at a site is
complete, it can be made aailable again or updates. Changes made at the other
locations will automatically be propagated to the site once the migration is
complete.
1his eature is useul een or locations not currently participating in a Streams
replication enironment. \ou can easily perorm an application or platorm
upgrade at a site without incurring any downtime by irst creating a temporary
replica o the site. Oracle Streams one-step API`s, described earlier in this
document, greatly simpliy this process. 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 one-step procedures, pre_instantiation and
post_instantiation, 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.
CONCLUSION
Oracle Streams simpliies sharing data between databases and database clusters,
with its reolutionary concept o uniying message queuing and data replication
capabilities. \ith Oracle Streams replication, the basic elements o capture, staging,
and consumption in combination with user-deined transormations and
heterogeneous interoperation produce more sophisticated conigurations than eer
beore possible. 1his resilient technology proides the coniguration lexibility
required to handle the real world situations encountered in modern global
corporations. Oracle Streams replication technology is the premier eature or
sharing data in complex distributed database enironments.

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

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, JD Edwards, and PeopIeSoft are registered trademarks of
OracIe Corporation and/or its affiIiates. Other names may be trademarks
of their respective owners.

Oracle Streams Replication

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oracle Streams Replication

Uploaded by

Copyright:

Available Formats

Oracle Database 11g: Oracle

You might also like