STREAMS筆記(9) 大事務 & 長事務

westzq1984發表於2013-06-10
筆記
大事務提交時，會在alert中顯示

2013-06-10 10:35:47.540000 +07:00

CP01: large txn committed (14063 LCRs), xid: 0x0004.008.0000033a (4.8.826)

 

每隔10分鐘左右，會檢查一次大事務

2013-06-10 10:43:58.367000 +07:00

CP01: large txn detected (235559 LCRs), xid: 0x0008.004.00000341 (8.4.833)

2013-06-10 10:53:58.821000 +07:00

CP01: large txn detected (608753 LCRs), xid: 0x0008.004.00000341 (8.4.833)

2013-06-10 11:04:03.818000 +07:00

CP01: large txn detected (1033409 LCRs), xid: 0x0008.004.00000341 (8.4.833)

 

每隔20分鐘，會檢查一次長事務

2013-06-10 16:02:40.705000 +07:00

CP01: long running txn detected, xid: 0x000a.01f.00000542 (10.31.1346)

 

但是注意，只報告一個事務，無論此時有幾個大事務/長事務在執行中

 

capture一旦發現事務，就開始傳播。apply端要接收到commit標籤，才開始應用日誌

 

Apply spill的記錄表是，STREAMS$_APPLY_SPILL_MSGS_PART，其同時也儲存發生錯誤的事務

Queue spill，應該是寫入到佇列表

向STREAMS$_APPLY_SPILL_MSGS_PART寫入資訊，是自己控制提交頻率，一直在寫入提交

 

由於大事務，需要先寫入STREAMS$_APPLY_SPILL_MSGS_PART，所以會極大的增加目標庫產生的REDO

 

Troubleshooting Long-Running Transactions in Oracle Streams [ID 783927.1]

描述了streams處理事務的習慣

 

長事務的壞處：

1.capture程式發生流控

2.apply程式發生spilling

3.增加stream_pool的記憶體消耗

 

9i

1.訊息只能發生queue spill，也就是說只在存在記憶體壓力時，buffer queue才發生spill

2.舊訊息一直保留在記憶體中，只有新訊息才發生spill。這將增加IO壓力

3.訊息只能按照入列順序出列，也就是說，只有提交的訊息才能出隊，未提交的事務，會阻礙後續訊息的出列

4.如果不是的流控指令碼，長事務和流控指令碼間，將發生死鎖

 

10.1

1.不再只在記憶體存在壓力時才發生spill，增加了時間壓力的情況。入隊超過5分鐘事務將spill

2.不再按照入隊順序出隊，長事務不再柱塞訊息出隊

3.spill了的事務，只有當其又有相關資訊被入隊，才會考慮被應用

 

10.2

1.增加了apply spill的機制。queue spill involves spilling messages to disk under memory pressure and time pressure, apply spill allows spilling to disk under time pressure and transaction size.

2.apply spill能比queue spill提供更高的效能，apply spill可以釋放記憶體給新的事務

3.超時時間10分鐘，事務超過5分鐘發生apply spill

4.超過TXN_LCR_SPILL_THRESHOLD大小的事務，發生apply spill。預設為10000個LCR

5.事務被放入錯誤佇列

 

Capture/Propagation 中未提交的事務

select streams_name "Streams Name",

streams_type "Streams Type",

xidusn||'.'||xidslt||'.'||xidsqn XID,

to_number (sysdate-last_message_time)*1440

"Time Since Last Message (min)"

from GV$STREAMS_TRANSACTION

-- where to_number (sysdate-last_message_time)*1440 >= 20

order by "Time Since Last Message (min)";

 

Apply中，發生了spill的事務

select Apply_name "Apply Name",

xidusn||'.'||xidslt||'.'||xidsqn XID,

first_scn "First SCN",

first_message_create_time "First Message Time",

message_count "Message Count",

spill_creation_time "Spill Time"

from DBA_APPLY_SPILL_TXN

order by "Spill Time";

 

忽略事務

9.2.0.5 to 10.1.0.x ，只能在capture端忽略

execute dbms_apply_adm.stop_apply('');

execute dbms_apply_adm.set_parameter('','_ignore_transaction','');

execute dbms_apply_adm.start_apply('');

 

10.2+，可以在apply端忽略，11g的引數為ignore_transaction

execute dbms_capture_adm.stop_capture('');

execute dbms_capture_adm.set_parameter('','_ignore_transaction','');

execute dbms_capture_adm.start_capture('');

 

存在一個BUG 5736709，可能導致被忽略的事務沒有purge其spill的記錄，需要進行清理

參考
How to Purge Apply Spilled Transactions in Streams Environment. [ID 472440.1]

 

STREAMS$_APPLY_SPILL_MSGS_PART的結構

  CREATE TABLE "SYS"."STREAMS$_APPLY_SPILL_MSGS_PART"

   (    "TXNKEY" NUMBER NOT NULL ENABLE,

        "SEQUENCE" NUMBER NOT NULL ENABLE,

        "SCN" NUMBER,

        "SCNSEQ" NUMBER,

        "CAPINST" NUMBER,

        "FLAGS" NUMBER,

        "FLAGS2" NUMBER,

        "MESSAGE" "SYS"."ANYDATA" ,

        "DESTQUEUE" VARCHAR2(66),

        "UBAAFN" NUMBER,

        "UBAOBJ" NUMBER,

        "UBADBA" NUMBER,

        "UBASLT" NUMBER,

        "UBARCI" NUMBER,

        "UBAFSC" NUMBER,

        "SPARE1" NUMBER,

        "SPARE2" NUMBER,

        "SPARE3" NUMBER,

        "SPARE4" VARCHAR2(4000),

        "SPARE5" VARCHAR2(4000),

        "SPARE6" VARCHAR2(4000),

        "POSITION" RAW(64),

        "SPARE7" DATE,

        "SPARE8" TIMESTAMP (6),

        "SPARE9" RAW(100)

   ) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255

  STORAGE(

  BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)

  TABLESPACE "SYSAUX"

 OPAQUE TYPE "MESSAGE" STORE AS BASICFILE LOB (

  ENABLE STORAGE IN ROW CHUNK 8192 RETENTION

  CACHE

  STORAGE(

  BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT))

  PARTITION BY LIST ("TXNKEY")

 (PARTITION "P0"  VALUES (0)

  PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255

 NOCOMPRESS LOGGING

  STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645

  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1

  BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)

  TABLESPACE "SYSAUX"

 LOB ("MESSAGE") STORE AS BASICFILE (

  ENABLE STORAGE IN ROW CHUNK 8192 RETENTION

  CACHE

  STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645

  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1

  BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)) )

 

這個表建立在SYSAUX表空間中，如果存在大事務，可能導致SYSAUX極度擴張

MESSAGE列使用anydata型別儲存資料

基於TXNKEY分割槽，一個spill的事務，一個分割槽

 

Query From SYS.STREAMS$_APPLY_SPILL_MSGS_PART Takes Long Time [ID 756049.1]

Explain TXN_LCR_SPILL_THRESHOLD in Oracle10GR2 Streams [ID 365648.1]

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/8242091/viewspace-763700/，如需轉載，請註明出處，否則將追究法律責任。

相關文章