XStream consists of Oracle Database components and application programming interfaces (APIs) that enable client applications to receive data changes from an Oracle database and send data changes to an Oracle database.

These data changes can be shared between Oracle databases and other systems. The other systems include non-Oracle databases, non-RDBMS Oracle products, file systems, third party software applications, and so on. A client application is designed by the user for specific purposes and use cases.

XStream consists of two major features: XStream Out and XStream In. XStream Out provides Oracle Database components and APIs that enable you to share data changes made to an Oracle database with other systems. XStream Out can retrieve both data manipulation language (DML) and data definition language (DDL) changes from the redo log and send these changes to a client application that uses the APIs, as shown in the following figure.

XStream In provides Oracle Database components and APIs that enable you to share data changes made to other systems with an Oracle database. XStream In can apply these changes to database objects in the Oracle database, as shown in the following figure.

XStream uses the capture and apply features of the Oracle database. These features enable the following functionality for XStream:

• The logical change record (LCR) format for streaming database changes

  An LCR is a message with a specific format that describes a database change. If the change was a data manipulation language (DML) operation, then a row LCR encapsulates each row change resulting from the DML operation. One DML operation might result in multiple row changes, and so one DML operation might result in multiple row LCRs. If the change was a data definition language (DDL) operation, then a single DDL LCR encapsulates the DDL change.

• Rules and rule sets that control behavior, including inclusion and exclusion rules

  Rules enable the filtering of database changes at the database level, schema level, table level, and row/column level.

• Rule-based transformations that modify captured data changes

• Support for most data types in the database, including LOBs, LONG, LONG RAW, and XMLType

• Customized configurations, including multiple inbound streams to a single database instance, multiple outbound streams from a single database instance, multiple outbound streams from a single capture process, and so on

• Full-featured apply for XStream In, including apply parallelism for optimal performance, SQL generation, conflict detection and resolution, error handling, and customized apply with apply handlers

Some customers, especially Independent Software Vendors (ISVs) and partners, need access to the Oracle database as a platform for their own information sharing products, such as file-level replication, middle-tier caches or even to support replication between Oracle and non-Oracle data stores. XStream provides these customers with fast, real-time access to changes made in the Oracle database.

XStream is a programmatic interface that allows client applications to connect to the Oracle database and attach directly into the database capture or apply process. A client application can take advantage of a high performing capture mechanism by attaching to the XStream outbound server to directly access the stream of changes from an Oracle database. XStream Out streams logical change records (LCRs) to the client application in committed transaction order.

To apply changes to the Oracle database, a client application can hook directly into the XStream inbound server. The application provides the inbound server with LCRs in transactional order and can take advantage of the high performance of the database apply engine to apply the changes to the Oracle database.

There are several common XStream use cases.

XStream provides a flexible infrastructure for sharing information between Oracle data sources and non-Oracle data sources. You can use XStream to meet the data and informational sharing needs of various organizations.

Each XStream use case in this section contains three main elements:

• A general description of the use case as it applies to both XStream Out and XStream In

• A specific scenario for XStream Out

• A specific scenario for XStream In

In each XStream Out use case, the following components and actions send Oracle Database changes to a client application:

• A capture process captures data changes made to an Oracle database.

• XStream Out sends these changes, in the form of logical change records (LCRs), to an outbound server.

• The outbound server sends the LCRs to a client application.

How the client application processes the LCRs is different for each use case.

In each XStream In use case, the following components and actions send Oracle Database changes to an inbound server:

• A client application gathers data changes from an external data source and sends them to an inbound server in the form of LCRs.

• The inbound server receives the LCRs from a client application.

• The inbound server can apply the data changes to database objects in an Oracle database. The inbound server can also process the LCRs in a customized way.

How the client application gathers the data changes is different for each use case.

• Replicating Data Changes with Non-Oracle Databases
  Replication is generally used to improve availability and to improve performance by spreading the network load over multiple regions and servers.
• Using Files to Store Data Changes
  Some environments use files to store data changes.
• Sharing Data Changes with a Client-Side Memory Cache
  Some environments cache data in memory to improve performance.

$ORACLE_HOME/rdbms/demo/xstream/fbr

Meet prerequisites before using XStream.

With XStream, you can implement the security model that best fits with your organization's requirements.

XStream supports two modes of security:

• XStream Trusted User Model

  An XStream administrator configured with the trusted user model can manage any XStream configuration, has more database privileges than an untrusted counterpart, and can monitor XStream with DBA_ views.

  The trusted user model is easier to implement than the untrusted user model, especially in an environment with multiple XStream configurations.

• XStream Untrusted User Model

  An XStream administrator configured with the untrusted user model (also referred to as the minimum privilege model) can only manage XStream configurations owned by the untrusted user administrator. This model offers fine-grained administrative security because you can designate different untrusted user administrators to access different resources in the XStream environment. You can configure one or more XStream untrusted users and each of these users only has the minimum privileges required for the tasks that they are assigned. This strategy gives you the ability to isolate access and privileges to certain XStream resources. The untrusted administrator can monitor XStream with ALL_ views

  For example, you might want to use the untrusted user model for situations where the capture process requires more privileges than the client process. You can then assign a different user for the client process that only has the privileges it requires.

  Government and commercial organizations implement a variety of software and hardware security architectures to protect and control access to data and applications. Compliance with industry-specific service level agreements (SLAs), audits, security laws and regulations may require a separation of duties and responsibilities, and controlled access to data. These types of security criteria and restrictions suit the untrusted user model where you can designate different users and privileges to secure resources.

• XStream Tasks
  You complete common tasks with XStream.
• XStream Tools
  You use a set of tools to complete tasks with XStream.