Oracle Streams enables
the propagation and management of data, transactions and events in a data
stream either within a database, or from one database to another. The stream
routes published information to subscribed destinations. The result is
a new feature that provides greater functionality and flexibility than
traditional solutions for capturing and managing events, and sharing the
events with other databases and applications. As users' needs change, they
can simply implement a new capability of Oracle Streams, without sacrificing
existing capabilities.
Overview
Oracle Streams
provides a set of elements that allow users to control what information
is put into a stream, how the stream flows or is routed from node to node,
what happens to events in the stream as they flow into each node, and how
the stream terminates. By specifying the configuration of the elements
acting on the stream, a user can address specific requirements.
The architecture
of Oracle Streams is very flexible. As shown in the above diagram, Streams
contains three basic elements.
-
Capture
-
Staging
-
Consumption
Capture
Oracle Streams
supports capture of events (database changes, and application generated
messages) into the staging area. These events are captured in two ways.
With implicit capture, the server captures DML and DDL events at a source
database. Explicit capture allows applications to explicitly generate events
and place them in the staging area.
With implicit
capture, the capture process retrieves change data extracted from the redo
log, either by hot mining the online redo log or, if necessary, by mining
archived log files. After retrieving the data, the capture process formats
it into a Logical Change Record (LCR) and places it in a staging area for
further processing. The capture process can intelligently filter LCRs based
upon defined rules. Thus, only changes to desired objects are captured.
User applications
can explicitly enqueue user messages representing events into the staging
area. These messages can be formatted as LCRs, which will allow them to
be consumed by the apply engine, or they can be formatted for consumption
by another user application.
Staging
Once captured,
events are placed in a staging area. The staging area is a queue that provides
a service to store and manage captured events. Staging provides a holding
area with security, as well as auditing and tracking of LCR data.
Subscribers
examine the contents of the staging area and determine whether or not they
have an interest in an event. A subscriber can either be a user application,
another staging area, usually on another system, or the default apply process.
Propagation
If the subscriber
is another staging area, the event is propagated to the other staging area,
either within the same database or in a remote database, as appropriate.
To simplify network routing and reduce WAN traffic, events need not be
sent to all databases and applications. Rather, they can be directed through
staging areas on one or more systems until they reach the subscribing system.
For example, an event may propagate via a hub database that does not actually
apply the event. A single staging area can stage events from multiple databases,
simplifying setup and configuration.
Consumption
Events 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 flexible apply engine, that allows use of a standard
or custom apply function. This enables data to be transformed when necessary.
Support for explicit dequeue allows application developers to use Oracle
Streams to notify applications of changes to data, while still leveraging
the change capture and propagation features of Oracle Streams.
Default Apply
The default apply
engine applies DML changes and DDL changes represented by implicitly or
explicitly captured LCRs. The default apply engine will detect conflicts
where the destination row has been changed and does not contain the expected
values. If a conflict is detected, then a resolution routine may be invoked.
User-Defined Function
Apply
The apply engine
can pass the LCR or a user message to a user-defined function. This provides
the greatest amount of flexibility in processing an event. A typical application
of a user-defined function would be to reformat the data represented by
the LCR before applying it to a local table, for example, field format,
object name and column name mapping transformations. A user-defined function
could also be used to perform column subsetting, or to update other objects
that may not be present in the source database.
Explicit Dequeue
User applications
can explicitly dequeue LCRs or user messages from the receiving staging
area. This allows a user application to efficiently access the data in
a Streams' staging are. Streams can send notifications to registered PL/SQL
or OCI functions, giving the applications an alternative to polling for
new messages. Of course, applications can still poll, or even wait, for
new subscribed messages in the staging area to become available.
Rules
Streams lets users
control which information to share and where to send it by specifying rules.
At the highest level, users can indicate if they want to capture, propagate
or apply changes at the table, schema, or global (database) level. For
more complex requirements, for example, to apply only a particular subset
of data at a given location, users can specify a rule condition similar
to the condition in the WHERE clause of a SQL query. If necessary, related
rules can be grouped into rule sets.
Transformations
A transformation
is a change in the form of an object participating in capture and apply
or a change in the data it holds. Transformations can include changing
the datatype representation of a particular column in a table at a particular
site, adding a column to a table at one site only, or including a subset
of the data in a table at a particular site.
A transformation
can be specified during enqueue, to transform the message to the correct
type before inserting it into the staging area. It can also be specified
for propagation, which may be useful for subsetting data before it is sent
to a remote site. Finally, it can be specified at dequeue or local apply,
which can be useful for formatting a message in a manner appropriate for
a specific destination.
Heterogeneous Support
Oracle Streams
is an open information sharing solution. Each element supports industry
standard languages and standards. Streams supports capture and apply from
Oracle to non-Oracle systems. Changes can be applied to a non-Oracle system
via a transparent gateway or generic connectivity. Streams also includes an API to allow non-Oracle data sources to easily submit or receive change
records, allowing for heterogeneous data movement in both directions. In
addition, messages can be sent to and received from other message queuing
systems such as MQ Series and Tibco via the Message Gateway.
Manageability
Several tools are
available for configuring, administering, and monitoring a Streams environment.
The primary interface to Streams is a collection of Oracle-supplied PL/SQL
packages. To help users configure, administer, and monitor their Streams
environments, Oracle provides a Streams tool in the Oracle Enterprise Manager
Console. Users can also use the Streams tool to generate Streams configuration
scripts, which they can then modify and run to configure their Streams
environment. Additionally, Streams data dictionary views keep users informed
about their Streams environment.
Deployment for
Specific Markets
Oracle Streams
satisfies customer's information sharing requirements in a variety of markets.
For example, customers can use Oracle Streams to create Event Notification, Replication, and Data Warehouse Loading
solutions. Oracle also provides features built on Streams that extend its capabilities for tasks. Advanced Queuing is built on Oracle Streams and provides robust message queuing functionality integrated with the Oracle9i Database. Of course, all customers can utilize the full
power of Oracle Streams, and create configurations that seemingly span
multiple markets, enabling new classes of applications. In addition, all
deployments and their associated meta-data are compatible. For example,
a replication installation can easily be extended to load a data warehouse
or enable bi-directional replication--a complete reconfiguration is not
required.
Oracle Streams--Single,
Unified Solution
Oracle Streams
satisfies the most demanding information sharing requirements using a common
infrastructure. Complex distributed environments benefit from a single
solution that satisfies their information sharing requirements. As an organization
grows, developers and administrators can be confident that Oracle Streams
has the flexibility to meet their changing requirements.
| KEY
FEATURES |
Single,
Unified Solution
-
Satisfies all data
sharing needs with a single solution.
-
Supports deployment
of a variety of configurations:
-
Replication
-
Message Queuing
-
Data Warehouse
Loading
-
Allows data to
be transparently shared between both Oracle and non-Oracle data stores.
Integrated
Feature of Oracle9i Database
-
No additional software
to install. No special commands to learn.
-
Takes advantage
of reliability and security provided with Oracle9i Database.
Manageable
-
Provides maximum
flexibility for configuration and administration with Oracle-supplied PL/SQL
packages.
-
Provides wizards
and monitoring capabilities for ease of use with Streams tool in Oracle
Enterprise Manager.
-
Keeps users informed
about their environment through Data dictionary views.
|
Flexible
-
Capture
-
Implicitly captures
both DML as well as DDL changes.
-
Filters captured
changes based on user-defined rules.
-
Lets applications
explicitly enqueue user messages into staging area.
-
Staging/Propagation
-
Provides secure
holding area with auditing and tracking of captured data.
-
Allows data to
be routed through staging areas before being applied.
-
Supports transformation
of data as it is enqueued into or dequeued from the staging area, or prior
to propagation.
-
Consumption
-
Automatically detects
and resolves conflicts before applying changes using default apply mechanism.
-
Gives user complete control over how data is modified and applied
with user-defined apply mechanism.
-
Allows applications
to directly access data in Stream's staging area using explicit dequeue.
Performance
-
Hot mining of the
online redo log reduces the latency of data capture.
-
Parallel capture
and apply processes ensure maximum throughput for concurrent events.
|
| |
|
Top
of Page |Copyright and Corporate Info
|
Bookmark
