STREAMS笔记(9) 大事务 & 长事务

大事务提交时，会在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/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/8242091/viewspace-763700/