好長的文檔，週末看了100多頁，記錄些概念
XStream 由DB組件和API接口組成，能讓客戶端應用接收源DB數據變化併發送至目標端，目標端可以是非oracle，例如sqlserver/pg/文件系統/第三方軟件應用等。
XStream是一個程序接口，允許客戶端應用連接到oracle數據庫並且之間訪問db capture process或apply process
XStream 有兩個主要部分：XStream Out 和 XStream In
XStream Out在源端，從redolog中接收源端的DML,DDL語句，並將變化情況通過接口發送至客戶端應用，也可以選擇將變化情況存儲到memory cache或指定文件中
XStream In在目標端，apply從客戶端應用接收到的數據變化情況，使目標庫同步源庫數據。
實現基礎：
- 數據變化情況使用 logical change record (LCR) 格式存儲
一條dml語句可能會操作多行，因此可能會對應產生多條row LCR記錄；如果是ddl語句，則會對應產生一條DDL LCR記錄.
- 規則和規則集用於控制XStream行爲，規則包括inclusion and exclusion rules，支持在DB級、schema級、表級、行/列級設置。
- 基於規則的數據變化會被捕獲
- 支持DB中衆多數據類型，包括LOBs,
LONG,LONGRAW, andXMLType - 支持配置一對多、多對一等情況
- 支持並行apply、sql生成、衝突檢測和解決、錯誤處理、使用apply handlers定製apply
使用前提
有oracle DB相關知識
有分佈式數據庫相關知識
有sql和plsql知識
有應用編程知識，需要使用OCI或JAVA API創建客戶端應用並與XStream交互
XStream安全模型
XStream支持兩類安全模式：XStream Trusted User Model（可管理XStream配置，有更多DB權限，可通過DBA_視圖監控XStream運行情況，更易實現）、XStream Untrusted User Model（只能管理XStream配置，可通過ALL_視圖監控XStream運行情況）
- XStream相關概念
主要有以下幾項
- Logical Change Records (LCRs)
- Rules and Rule Sets
- Rule-Based Transformations
- XStream and the Oracle Replication Performance Advisor
- XStream and SQL Generation
Logical Change Records (LCRs)
LCR是一種有特定格式的用於模式DB變化情況的消息（An LCR is a message with a specific format that describes a database change.），它是XStream中描述數據變化的基本單位（ an LCR is the basic unit of information that describes a database change）
在XStream Out 配置中，capture process 會捕獲LCR信息並將它們發送到 outbound server， outbound server再將LCR發送到客戶端應用
在XStream In 配置中，客戶端應用將LCR發送到inbound server，inbound server可以將LCR發送到DB直接進行apply，也可以對LCR進行客製化處理
LCR有三種類型： row LCRs, DDL LCRs, and sequence LCRs（包含序列值的row LCR）
LCR都有LCRID，用於標誌和排序LCR，通過它可以確定哪些LCR和事務已被接收和應用
row LCR 的類型爲LCR$_ROW_RECORD，有以下屬性：
|
Attribute |
Description |
|
source_database_name |
The name of the source database where the row change occurred. If the LCRs originated in a multitenant container database (CDB), then this attribute specifies the global name container where the row change occurred. |
|
command_type |
The type of DML statement that produced the change, either INSERT, UPDATE, DELETE, LOB ERASE, LOB WRITE, or LOB TRIM. |
|
object_owner |
The schema name that contains the table with the changed row. |
|
object_name |
The name of the table that contains the changed row. |
|
tag |
A raw tag that you can use to track the LCR. |
|
transaction_id |
The identifier of the transaction in which the DML statement was run. |
|
scn |
The system change number (SCN) at the time when the change was made. |
|
old_values |
The old column values related to the change. These are the column values for the row before the DML change. If the type of the DML statement is UPDATE or DELETE, then these old values include some or all of the columns in the changed row before the DML statement. If the type of the DML statement is INSERT, then there are no old values. For UPDATE and DELETE statements, row LCRs created by a capture process can include some or all of the old column values in the row. |
|
new_values |
The new column values related to the change. These are the column values for the row after the DML change. If the type of the DML statement is UPDATE or INSERT, then these new values include some or all of the columns in the changed row after the DML statement. If the type of the DML statement is DELETE, then there are no new values. For UPDATE and INSERT statements, row LCRs created by a capture process can include some or all of the new column values in the row. |
|
position |
A unique identifier of RAW data type for each LCR. The position is strictly increasing within a transaction and across transactions. LCR position is commonly used in XStream configurations. |
|
root_name |
If the LCR originated in a CDB, then this attribute specifies the global name of the root in the CDB. If the LCR originated in a non-CDB, then this attribute is the same as the source_database_name attribute. |
額外屬性
|
Attribute |
Description |
|
commit_scn |
The commit system change number (SCN) of the transaction to which the LCR belongs. |
|
commit_scn_from_position |
The commit system change number (SCN) of a transaction determined by the input position, which is generated by an XStream outbound server. |
|
commit_time |
The commit time of the transaction to which the LCR belongs. |
|
compatible |
The minimal database compatibility required to support the LCR. |
|
instance_number |
The instance number of the database instance that made the change that is encapsulated in the LCR. Typically, the instance number is relevant in an Oracle Real Application Clusters (Oracle RAC) configuration. |
|
lob_information |
The LOB information for the column, such as NOT_A_LOB or LOB_CHUNK. |
|
lob_offset |
The LOB offset for the specified column in the number of characters for CLOB columns and the number of bytes for BLOB columns. |
|
lob_operation_size |
The operation size for the LOB column in the number of characters for CLOB columns and the number of bytes for BLOB columns. |
|
long_information |
The LONG information for the column, such as NOT_A_LONG or LONG_CHUNK. |
|
row_text |
The SQL statement for the change that is encapsulated in the row LCR. |
|
scn_from_position |
The SCN of the LCR. |
|
source_time |
The time when the change in an LCR captured by a capture process was generated in the redo log of the source database, or the time when a persistent LCR was created. |
|
xml_information |
The XML information for the column, such as NOT_XML, XML_DOC, or XML_DIFF. |
DDL LCR 的類型爲LCR$_DDL_RECORD，有以下屬性：
Table 2-3 Attributes Present in All DDL LCRs
|
Attribute |
Description |
|
source_database_name |
The name of the source database where the DDL change occurred. If the LCRs originated in a CDB, then this attribute specifies the global name of the container where the DDL change occurred. |
|
command_type |
The type of DDL statement that produced the change, for example ALTER TABLE or CREATE INDEX. |
|
object_owner |
The schema name of the user who owns the database object on which the DDL statement was run. |
|
object_name |
The name of the database object on which the DDL statement was run. |
|
object_type |
The type of database object on which the DDL statement was run, for example TABLE or PACKAGE. |
|
ddl_text |
The text of the DDL statement. |
|
logon_user |
The logon user, which is the user whose session executed the DDL statement. |
|
current_schema |
The schema that is used if no schema is specified for an object in the DDL text. |
|
base_table_owner |
The base table owner. If the DDL statement is dependent on a table, then the base table owner is the owner of the table on which it is dependent. |
|
base_table_name |
The base table name. If the DDL statement is dependent on a table, then the base table name is the name of the table on which it is dependent. |
|
tag |
A raw tag that you can use to track the LCR. |
|
transaction_id |
The identifier of the transaction in which the DDL statement was run. |
|
scn |
The system change number (SCN) at the time when the change was made. |
|
position |
A unique identifier of RAW data type for each LCR. The position is strictly increasing within a transaction and across transactions. LCR position is commonly used in XStream configurations. |
|
edition_name |
The name of the edition in which the DDL statement was executed. |
|
root_name |
If the LCR originated in a CDB, then this attribute specifies the global name of the root in the CDB. If the LCR originated in a non-CDB, then this attribute is the same as the source_database_name attribute. |
額外屬性
Table 2-4 Additional Attributes in DDL LCRs Captured by a Capture Process
|
Attribute |
Description |
|
commit_scn |
The commit system change number (SCN) of the transaction to which the LCR belongs. |
|
commit_scn_from_position |
The commit SCN of a transaction determined by the input position, which is generated by an XStream outbound server. |
|
commit_time |
The commit time of the transaction to which the LCR belongs. |
|
compatible |
The minimal database compatibility required to support the LCR. |
|
instance_number |
The instance number of the database instance that made the change that is encapsulated in the LCR. Typically, the instance number is relevant in an Oracle Real Application Clusters (Oracle RAC) configuration. |
|
scn_from_position |
The SCN of the LCR. |
|
source_time |
The time when the change in an LCR captured by a capture process was generated in the redo log of the source database, or the time when a persistent LCR was created. |
Extra Information in Row LCRs and DDL LCRs
In addition to the information discussed in the previous sections, row LCRs and DDL LCRs optionally can include extra information (or LCR attributes).
The extra attributes in LCRs are described in the following table.
Table 2-5 Extra Attributes in LCRs
|
Attribute |
Description |
|
|
The rowid of the row changed in a row LCR. This attribute is not included in DDL LCRs or row LCRs for index-organized tables. |
|
|
The serial number of the session that performed the change captured in the LCR. |
|
|
The identifier of the session that performed the change captured in the LCR. |
|
|
The thread number of the instance in which the change captured in the LCR was performed. Typically, the thread number is relevant only in an Oracle Real Application Clusters (Oracle RAC) environment. |
|
|
The name of the transaction that includes the LCR. |
|
|
The name of the current user who performed the change captured in the LCR. |
You can use the INCLUDE_EXTRA_ATTRIBUTE procedure in the DBMS_CAPTURE_ADM package to instruct a capture process to capture one or more extra attributes.
Sequence LCR是包含序列值的row LCR
可以通過如下方法捕獲
DB層：將capture_sequence_nextval 和apply_sequence_nextval 參數設爲y
OCI接口：use the OCILCRNew function and the OCILCRHeaderSet function with the OCI_ROWLCR_SEQ_LCR flag.
JAVA接口： use the DefaultRowLCR constructor and setSequenceLCRFlag method
如何定位LCR流順序
每個LCR都有position屬性，用於標誌該LCR在LCR流和事務中的順序
position屬性有以下特點：
每個LCR的position屬性是唯一的
position屬性是RAW data type.
Position隨LCR流和事務嚴格遞增
- The position is byte-comparable, and the comparison results for multiple positions determines the ordering of the LCRs in the stream.
- The position of an LCR remains identical when the database, the client application, or an XStream component restarts.
- The position is not affected by any rule changes that might reduce or increase the number of LCRs in the stream.
XStream Out only sends committed data, and XStream In only receives committed data.
LCRID用於在XStream Out中唯一標誌LCR的位置，它同樣是嚴格遞增的。
從12.2開始，the LCRID is versioned。當創建或新增outbound server時，可以選擇使用的版本。要使用version 2，DB版本必須高於12.2。低於12.2版本默認會使用version 1,12.2開始默認使用version 2。如果源庫版本爲12.2或以上，目標庫版本低於源庫，可能需要手動設置該參數。
outbound server創建或添加完成後，不能再修改LCRID version，如果要改，只能drop該outbound server重建。如果outbound server正在發送LCR到inbound server，還需要drop該inbound server重建。
相同的DB變化在version 1和version 2中有不同的值，可以使用DBMS_XSTREAM_ADM 包可用於比較不同版本的LCRID（使用COMPARE_POSITION 函數）或將一個版本的LCRID轉爲另一個版本（使用CONVERT_POSITION 函數）
規則與規則集
Rules and Rule Sets Defined
規則是一個數據庫對象，定義客戶端執行某種動作的條件。在XStream配置中，規則標誌哪些LCRs會被傳送到另一個組件
A rule is a database object that enables a client to perform an action when an event occurs and a condition is satisfied. In an XStream configuration, rules identify which LCRs to stream from one component to another.
Capture processes, propagations, outbound servers and inbound servers都可以配置規則，規則適用於dml和ddl語言。
規則集是規則的集合，可以配置positive rule set and a negative rule set ，並且negative rule優先
Rule Sets and XStream Components
當database change符合規則時，XStream component會執行指定的任務
如果redolog中的change符合爲capture process設置的規則，它會被捕獲，如果不滿足則被略過。
如果捕獲到的LCR滿足爲propagations設置的規則，它會被髮送，如果不滿足則被略過。
如果被髮送的LCR滿足爲outbound servers設置的規則，它會被髮送到客戶端應用，如果不滿足則被略過。
如果inbound servers接收到的LCR滿足爲其設置的規則，它會被apply，如果不滿足則被略過。
如果不設置規則，所有的database changes都會被捕獲、發送、apply
System-Created Rules and XStream
A system-created rule is created by the DBMS_XSTREAM_ADM package.
Table 2-6 XStream System-Created Rule Procedures
|
Procedure |
Capture Process |
Propagation |
Outbound Server |
Inbound Server |
|
CREATE_OUTBOUND |
Yes |
No |
Yes |
No |
|
ADD_OUTBOUND |
No |
No |
Yes |
No |
|
ALTER_OUTBOUND |
Yes |
No |
Yes |
No |
|
ADD_GLOBAL_RULES |
Yes |
No |
Yes |
Yes |
|
ADD_GLOBAL_PROPAGATION_RULES |
No |
Yes |
No |
No |
|
ADD_SCHEMA_RULES |
Yes |
No |
Yes |
Yes |
|
ADD_SCHEMA_PROPAGATION_RULES |
No |
Yes |
No |
No |
|
ADD_GLOBAL_RULES |
Yes |
No |
Yes |
Yes |
|
ADD_SUBSET_OUTBOUND_RULES |
No |
No |
Yes |
No |
|
ADD_SUBSET_RULES |
Yes |
No |
Yes |
Yes |
|
ADD_SUBSET_PROPAGATION_RULES |
No |
Yes |
No |
No |
|
ADD_TABLE_RULES |
Yes |
No |
Yes |
Yes |
|
ADD_TABLE_PROPAGATION_RULES |
No |
Yes |
No |
No |
system-created rule可以設置爲Subset 級、表級、schema級、global級（對整個DB生效）。Subset 級僅對錶中部分行生效，類似where語句，需要開啓Supplemental logging才能使用。
多租戶環境中的system-created rule
Table 2-7 Key Procedure Parameters for System-Created Rules in a CDB
|
Parameter |
Description |
|
source_database |
The global name of the source database. In a CDB, specify the global name of the container to which the rules pertain. The container can be the CDB root, a PDB, an application root, or an application PDB. The following are examples: mycdb.example.com or hrpdb.example.com. |
|
source_root_name |
The global name of the CDB root in the source CDB. The following are examples: mycdb.example.com. |
|
source_container_name |
The short name of the source container. The container can be the CDB root, a PDB, an application root, or an application PDB. The following are examples: CDB$ROOT or hrpdb. |
Table 2-8 Local Capture and XStream Out Container Rule Conditions
|
source_database Parameter Setting |
source_container_name Parameter Setting |
Description |
|
NULL |
NULL |
XStream Out captures and streams changes made in any container in the local CDB, including the CDB root, all PDBs, all application roots, and all application PDBs. |
|
non-NULL |
NULL |
XStream Out captures and streams changes made in the specified source container of the local CDB. The source container can be the CDB root, a PDB, an application root, or an application PDB. The DBMS_XSTREAM_ADM procedure queries the CDB_PDBS view and CDB_PROPERTIES view to determine the source_container_name value. |
|
NULL |
non-NULL |
XStream Out captures and streams changes made in the specified source container of the local CDB. The source container can be the CDB root, a PDB, an application root, or an application PDB. The DBMS_XSTREAM_ADM procedure queries the CDB_PDBS view and CDB_PROPERTIES view to determine the source_database value. |
|
non-NULL |
non-NULL |
XStream Out captures and streams changes made in the specified source container of the local CDB. The source container can be the CDB root, a PDB, an application root, or an application PDB. If the prefix of the source_database value is different from the source_container_name value, then the resulting rules include a condition for the source_database value, and an internal table maps the source_database value to the source_container_name value. |
Downstream Capture and XStream Out Container Rule Conditions
|
source_database Parameter Setting |
source_container_name Parameter Setting |
Description |
|
NULL |
NULL |
XStream Out captures and streams changes made in any container in the remote source CDB, including the CDB root, all PDBs, all application roots, and all application PDBs. |
|
non-NULL |
NULL |
XStream Out captures and streams changes made in the specified source container of the remote source CDB. The source container can be the CDB root, a PDB, an application root, or an application PDB. The DBMS_XSTREAM_ADM procedure derives the source_container_name value from the prefix of source_database value. |
|
NULL |
non-NULL |
The DBMS_XSTREAM_ADM procedure raises an error. |
|
non-NULL |
non-NULL |
XStream Out captures and streams changes made in the specified source container of the remote source CDB. The source container can be the CDB root, a PDB, an application root, or an application PDB. If the prefix of the source_database value is different from the source_container_name value, then the resulting rules include a condition for the source_database value, and an internal table maps the source_database value to the source_container_name value. |
Rule-Based Transformations
rule-based transformation是對符合positive 規則的LCR進行指定的轉換。這個轉換最好是放在客戶端應用處理，如果實在不願意放，db端也可以對DML LCR進行些簡單轉換。
Declarative Rule-Based Transformations
You specify (or declare) such a transformation using one of the following procedures in the DBMS_XSTREAM_ADM package:
- ADD_COLUMN either adds or removes a declarative transformation that adds a column to a row LCR.
- DELETE_COLUMN either adds or removes a declarative transformation that deletes a column from a row LCR.
- KEEP_COLUMNS either adds or removes a declarative transformation that keeps a list of columns in a row LCR. The transformation removes columns that are not in the list from the row LCR.
- RENAME_COLUMN either adds or removes a declarative transformation that renames a column in a row LCR.
- RENAME_SCHEMA either adds or removes a declarative transformation that renames the schema in a row LCR.
- RENAME_TABLE either adds or removes a declarative transformation that renames the table in a row LCR.
By default, Oracle Database performs declarative transformations in the following order when the rule evaluates to TRUE:
- Keep columns
- Delete column
- Rename column
- Add column
- Rename table
- Rename schema
In addition to declarative rule-based transformations, a row migration is an internal transformation that takes place when a subset rule evaluates to TRUE.
You can use the DBMS_XSTREAM_ADM.ADD_SUBSET_RULES procedure to add subset rules. If both types of transformations are specified for a single rule, then Oracle Database performs the transformations in the following order when the rule evaluates to TRUE:
- Row migration
- Declarative rule-based transformation
User-Specified Declarative Transformation Ordering
If you do not want to use the default declarative rule-based transformation ordering for a particular rule, then you can specify step numbers for each declarative transformation specified for the rule.
使用 rule-based transformations時需考慮項
只會對符合positive rule的LCR生效
rule-based transformations與使用DBMS_TRANSFORM 包進行轉換是不同的
如果在XStream In中有大量row LCRs 需要轉換，可以使用DML handlers，當然最好還是放在客戶端應用模塊進行處理
XStream and the Oracle Replication Performance Advisor
Oracle Replication Performance Advisor 由一系列數據字典視圖組成，用於監控XStream性能
Performance Advisor tracks the following types of components in an XStream environment:
- QUEUE
- CAPTURE
- PROPAGATION SENDER
- PROPAGATION RECEIVER
- APPLY
Performance Advisor 能幫忙尋找組件瓶頸並找到最忙的組件，可以通過DBA_STREAMS_TP_PATH_BOTTLENECK 視圖ACTION_NAME 列查看，一般最忙的會是客戶端應用，對應ACTION_NAME爲EXTERNAL
XStream Out Apply Subcomponents
There are several XStream Out apply subcomponents types.
The following subcomponent types are possible:
PROPAGATIONSENDER+RECEIVERfor sending LCRs from a capture process to an outbound server where the capture process and outbound server are in different databases.APPLYREADERfor a reader server.APPLY READERreceives LCRs from the capture process, organizes them into transactions, does dependency calculations, and passes the LCRs to the apply coordinator.APPLYCOORDINATORfor a coordinator process. It takes the transactions from the capture process, uses the dependency information to determine how to schedule the transactions and sends the LCRs to the apply server.APPLYSERVERfor an apply server. It delivers the LCRs to the client application.
XStream In Apply Subcomponents
There are several XStream In apply subcomponents types.
The following subcomponent types are possible:
APPLYREADERfor a reader server. It takes the LCRs from client application converts them into transactions, checks the transactional order and does dependency calculations.APPLYCOORDINATORfor a coordinator process. It takes the transactions from the reader server, uses the dependency information to determine how to schedule the transactions and sends the LCRs to the apply server.APPLYSERVERfor an apply server. It applies the LCRs to an apply handler. If the LCR cannot be applied, it is placed into an error queue.
Performance Advisor可以跟蹤組件級統計信息
The Performance Advisor tracks the following component-level statistics:
- The MESSAGE APPLY RATE is the average number of LCRs applied each second by the apply process, outbound server, or inbound server.
- The TRANSACTION APPLY RATE is the average number of transactions applied by the apply process, outbound server, or inbound server each second. Transactions typically include multiple LCRs.
Performance Advisor還能跟蹤 LATENCY component-level statistics
LATENCY is defined in the following ways:
- For apply processes, the LATENCY is the amount of time between when the LCR was created at a source database and when the LCR was applied by the apply process at the destination database.
- For outbound servers, the apply LATENCY is amount of time between when the LCR was created at a source database and when the LCR was sent to the XStream client application.
- For inbound servers, the apply LATENCY is amount of time between when the LCR was created by the XStream client application and when the LCR was applied by the apply process.
You can collect XStream statistics with the UTL_RPADV package
Run the utlrpadv.sql script in the rdbms/admin directory in ORACLE_HOME to load the UTL_RPADV package
exec UTL_RPADV.COLLECT_STATS
exec UTL_RPADV.START_MONITORING
The SHOW_STATS procedure in the UTL_RPADV package displays the statistics that the Performance Advisor gathered and stored.
Use the path_stat_table parameter to specify the table that contains the statistics.
SELECT SHOW_STATS_TABLE FROM STREAMS$_PA_MONITORING;
或
SET SERVEROUTPUT ON SIZE 50000
BEGIN
UTL_RPADV.SHOW_STATS(
path_stat_table => 'STREAMS$_PA_SHOW_PATH_STAT');
END;
/
The SHOW_STATS_HTML procedure in the UTL_RPADV package creates an HTML report that contains the statistics that the Performance Advisor gathered and stored.
XStream and SQL Generation
SQL generation is the ability to generate the SQL statement required to perform the change encapsulated in a row LCR.
XStream outbound servers and XStream inbound servers can use SQL generation to generate the SQL statement necessary to perform the insert, update, or delete operation in a row LCR.
SQL generation能利用row LCR反向解析出sql語句，可以爲 inline values格式和帶綁定變量的格式，支持大部分數據類型
You can use the following interfaces to perform SQL generation:
- The PL/SQL interface, which uses the
GET_ROW_TEXTandGET_WHERE_CLAUSEmember procedures for row LCRs - The OCI for XStream
- The Java interface for XStream
Part II XStream Out
主要有以下五部分
- XStream Out Concepts
Become familiar with concepts related to XStream Out. - Configuring XStream Out
You can configure the Oracle Database components that are used by XStream Out. - Managing XStream Out
You can manage XStream Out components and their rules. - Monitoring XStream Out
You can monitor an XStream Out configuration. - Troubleshooting XStream Out
You can diagnose and correct problems with an XStream Out configuration.
XStream Out Concepts
XStream Out can capture transactions from the redo log of an Oracle database and send them efficiently to a client application.
Capture Processes
A capture process is an optional Oracle background process that scans the database redo log to capture DML and DDL changes made to database objects.
When a capture process captures a database change, it converts it into a specific message format called a logical change record (LCR). In an XStream Out configuration, the capture process sends these LCRs to an outbound server.
可以通過V$XSTREAM_CAPTURE的STATE 列查看其狀態。
When a capture process runs on its source database, the capture process is a local capture process.
You can also capture changes for the source database by running the capture process on different server. When a capture process runs on a remote database, the capture process is called a downstream capture process, and the remote database is called the downstream database
3.2.2.1 ID Key LCRs
An ID key LCR is a special type of row LCR. ID key LCRs enable an XStream client application to process changes to rows that include unsupported data types.
XStream Out does not fully support the following data types in row LCRs:
ROWID- Nested tables
- The following Oracle-supplied types:
ANYTYPE,ANYDATASET, URI types,SDO_TOPO_GEOMETRY,SDO_GEORASTER, andExpression.
Local Capture and Downstream Capture
You can configure a capture process to run locally on a source database or remotely on a downstream database.
Local Capture
Local capture means that a capture process runs on the source database.
Configuration and administration of the capture process is simpler than when downstream capture is used.
A local capture process can scan changes in the online redo log before the database writes these changes to an archived redo log file.
Downstream Capture
Downstream capture means that a capture process runs on a database other than the source database.
有兩種類型: real-time downstream capture and archived-log downstream capture.由downstream_real_time_mine 參數設置
real-time 類型優點在於實時性高，不需要等db change寫入redolog和archivelog即可捕獲。
archived-log類型優點在於允許downstream database有多個源庫。它需要將歸檔日誌copy到downstream database，可以用自帶的DBMS_FILE_TRANSFER 包，也可以直接用ftp傳
A real-time downstream capture process and one or more archived-log downstream capture processes can coexist（共存） at a downstream database. With downstream capture, the redo log files of the source database must be available at the downstream database.
The following are the advantages of using downstream capture:
捕獲change佔用源庫資源更少，因爲基本是在downstream庫中完成的
使得多源庫的數據同步更簡單
將歸檔數據copy到downstream庫相當於給源庫多做了一份歸檔備份，可用於數據恢復
提高了靈活性和可擴展性
The following are operational requirements for using downstream capture:
- The source database must be running at least Oracle Database 10g Release 2 (10.2).
- The XStream Out downstream capture database must be running Oracle Database 11g Release 2 (11.2.0.3) or later and the source database must be running Oracle Database 10g Release 2 (10.2) or later.
- The operating system on the source and downstream capture sites must be the same, but the operating system release does not need to be the same. In addition, the downstream sites can use a directory structure that is different from the source site.
- The hardware architecture on the source and downstream capture sites must be the same. For example, a downstream capture configuration with a source database on a 64-bit Sun system must have a downstream database that is configured on a 64-bit Sun system. Other hardware elements, such as the number of CPUs, memory size, and storage configuration, can differ in the source and downstream sites.
Capture Process Subcomponents
The capture process subcomponents are a reader server, one or more preparer servers, and a builder server.
A capture process is an optional Oracle background process whose process name is CPnn, where nn can include letters and numbers. A capture process captures changes from the redo log by using the infrastructure of LogMiner. XStream configures LogMiner automatically. You can create, alter, start, stop, and drop a capture process, and you can define capture process rules that control which changes a capture process captures.
When capture process parallelism is greater than 0, the capture process consists of the following subcomponents:
- One reader server that reads the redo log and divides the redo log into regions.
- One or more preparer servers that scan the regions defined by the reader server in parallel and perform prefiltering of changes found in the redo log. Prefiltering involves sending partial information about changes, such as schema and object name for a change, to the rules engine for evaluation, and receiving the results of the evaluation. You can control the number of preparer servers using the parallelism capture process parameter.
- One builder server that merges redo records from the preparer servers. These redo records either evaluated to
TRUEduring partial evaluation or partial evaluation was inconclusive for them. The builder server preserves the system change number (SCN) order of these redo records and passes the merged redo records to the capture process.
The capture process (CPnn) performs the following actions for each change when it receives merged redo records from the builder server:
- Formats the change into an LCR
- If the partial evaluation performed by a preparer server was inconclusive for the change in the LCR, then sends the LCR to the rules engine for full evaluation
- Receives the results of the full evaluation of the LCR if it was performed
- Discards the LCR if it satisfies the rules in the negative rule set for the capture process or if it does not satisfy the rules in the positive rule set
- Enqueues the LCR into the queue associated with the capture process if the LCR satisfies the rules in the positive rule set for the capture process
Capture Process Checkpoints and XStream Out
A capture process tries to record a checkpoint at regular intervals called checkpoint intervals.
- Required Checkpoint SCN
The system change number (SCN) that corresponds to the lowest checkpoint for which a capture process requires redo data is the required checkpoint SCN. - Maximum Checkpoint SCN
The SCN that corresponds to the last physical checkpoint recorded by a capture process is the maximum checkpoint SCN. - Checkpoint Retention Time
The checkpoint retention time is the amount of time, in number of days, that a capture process retains checkpoints before purging them automatically.
SCN Values Related to a Capture Process
Specific system change number (SCN) values are important for a capture process.
You can query the ALL_CAPTURE data dictionary view to display these values for one or more capture processes.
- Captured SCN and Applied SCN
The captured SCN is the SCN that corresponds to the most recent change scanned in the redo log by a capture process. The applied SCN for a capture process is the SCN of the most recent LCR processed by the relevant outbound server. - First SCN and Start SCN
The first SCN and start SCN are important for a capture process.
Outbound Servers
An outbound server is an optional Oracle background process that sends database changes to a client application.
Specifically, a client application can attach to an outbound server and extract database changes from LCRs. A client application attaches to the outbound server using OCI or Java interfaces.
A client application can create multiple sessions. Each session can attach to only one outbound server, and each outbound server can serve only one session at a time. However, different client application sessions can connect to different outbound servers or inbound servers.
Change capture can be performed on the same database as the outbound server or on a different database. When change capture is performed on a different database from the one that contains the outbound server, a propagation sends the changes from the change capture database to the outbound server database. Downstream capture is also a supported mode to reduce the load on the source database.
An outbound server consists of a reader server, a coordinator process, and an apply server.
A reader server that receives LCRs from the outbound server's capture process. The reader server then returns the assembled transactions to the coordinator process.視圖V$XSTREAM_APPLY_READER
A coordinator process that gets transactions from the reader server and passes them to apply servers. The coordinator process name is APnn 視圖V$XSTREAM_APPLY_COORDINATOR
An apply server that sends LCRs to an XStream client application. The apply server is a process. If the apply server encounters an error, then it then it records information about the error in the ALL_APPLY view.視圖 V$XSTREAM_APPLY_SERVER
The reader server and the apply server process names are ASnn
未完待續
參考