Oracle Streams Basics: How to capture processes

In the previous chapter we practiced a streams synchronization of a single table, it looks very simple is not (if you feel complex, it is not because the streams itself is complex, but to configure the streams earlier preparation is more complex), in fact it is very simple, from small to see big, We should also see from the example above that streams's operation is capturing (capture)-> propagation (propagation)-> application, whether it's a table, a schema or a database, Follow this procedure, the following one describes capture propagation and application process, I do as far as possible clear and simple straightforward, but limited to personal understanding and their own level, such as the description of the wrong please identify yourself:). In addition, the text described in this chapter more, the content is relatively boring, before reading to prepare, such as direct access to more advanced practical configuration, you can skip this section, browse the second part.

Capture (Capture)

As we all know, database modification operations will be recorded in the Redolog (table dead end, I mean usually), so that in the event of errors, there is a way to amend. The capture process as a background process for Oracle is inherently capable of reading redolog, so it has the ability to capture dml,dll modification operations.

The capture process converts the modified format into the specified format to the message defined as LCRS and place it in the queue. Because the capture process in run automatically captures modifications based on its own rules, it is also called an implicit capture (implicit capture).

Hint: what is LCR

The capture process captures the operations of the database, such as table/schema or even the entire database modification. These changes are recorded in redo, and the capture process is saved as a message based on the modifications and formatting in the Redolog Analysis database, which is called the logical Change Record (LCR). The capture process uses the defined rule to determine which modifications will be captured, and these captured modifications are called captured messages.

So: messages->lcrs->captured message

Lcrs are also divided into two types:

A>.row LCR: Includes modification information that is generated by DML operations, and note that because a single DML SQL statement can also trigger changes to multiple records, a DML modification operation can produce multiple row LCR, as well as a change to a large segment type in one line, such as Long, LOB may also produce multiple row LCR;

Each ROWLCR is encapsulated into a Lcr$_row_record object type that contains the following properties:

N source_database_name: Database that triggers the modification operation

N Command_type: The type of command that triggers the modification operation, such as INSERT, UPDATE, DELETE, LOB ERASE, LOB WRITE, or lob TRIM.

N Object_owner: Object owner

N object_name: Object name

N Tag: Tags that can be used to track LCR

N transaction_id: Transaction ID of the DML statement that triggered the modification

N SCN: SCN at the time of modification (System change number)

n OLD_VALUES:DML the value before the modification, but note that different DML operations produce different values, such as the old value of update or delete is the value before the modification, and for inserts the column is empty

n NEW_VALUES:DML the modified value, for the same reason, different DML operations also produce different values, such as the value of update or INSERT, which is the modified value, and the delete operation is empty

B>. DDL LCR: Includes object modification information generated by DDL operations, and DDL LCR includes the following information:

N Source_database_name: Same ROWLCR

N Command_type: Same ROWLCR

N Object_owner: Same ROWLCR

n object_name: Same ROWLCR

N object_type: Object type, such as Table/view/package

N Ddl_text: Executed DDL statements

N logon_user: Users executing DDL statements

N Current_schema: Schema to execute DDL statements

N Base_table_owner: Base table owner (if there is, of course, not usually, but for some actions, such as trigger-triggered modifications, the base table is a touch-publish)

N base_table_name: Base table name, other ibid.

N Tag: Same ROWLCR

N transaction_id: Same ROWLCR

N SCN: Same ROWLCR

Tips:

Whether the Rowlcrs or DDL Lcrs includes the source database name, Oracle recommends that you do not arbitrarily modify the source database name to avoid problems with propagation or apply.

1. Capture Mode

Capture processes can be captured locally, either locally capture processes (local capture process) or at remote other databases, that is, downstream capture processes (downstream capture process). The database that performs the download capture is also known as the downstream database, and can even configure both local and downstream capture.

Local capture is relatively simple, meaning that the capture process runs locally, as shown in the figure:

Downstream capture is a bit more complicated because it involves sending locally generated redologs to the remote execution capture database, when it comes to sending redologs to recall standby yes, yes, it does have something to do with standby, The technology to send redologs applications is the same (just take this opportunity to review), so downstream capture has to be divided into two categories:

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/database/Oracle/