Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1097315
  • 博文数量: 276
  • 博客积分: 10077
  • 博客等级: 上将
  • 技术积分: 2513
  • 用 户 组: 普通用户
  • 注册时间: 2007-08-24 20:31
文章分类

全部博文(276)

文章存档

2020年(1)

2015年(5)

2012年(2)

2011年(6)

2010年(7)

2009年(224)

2008年(31)

我的朋友

分类: Oracle

2008-12-18 15:01:21

Hidden parameter for 10g2R Streams
My database alert log.
================================================
Tue Dec 16 08:51:14 2008
C001: large txn detected (14306 LCRs), xid: 0x000a.015.00058191
Tue Dec 16 08:56:15 2008
Propagation Schedule for (STRMADMIN.STREAMS_QUEUE, MRPC64.SAE.COM.HK) encountered following error:
ORA-25307: Enqueue rate too high, flow control enabled
================================================
   this error is caused by large transaction, it should be seted the hidden parameter to prevent this error,
but the most importment to avoid the large transaction.
   Long-running transactions are open transactions with no activity( ie, no new change records , rollback
or commit ) for an extended period (20 minutes).  Large transactions are open transactions with a large number
of change records.The alert log will report the fact that a long-running or large transaction hasbeen seen
every 20 minutes.  Not all such transactions will be reported - only 1 per 20 minute period.  When the commit
or rollback is received, this fact will be reported in the alert log as well.
1)TXN_LCR_SPILL_THRESHOLD
the default values is 10,000. If the reader server of an apply process has the specfied number of
messages in memory for a particular transaction, when it detects the next message for this
transaction, it spill the messages from memory to hard disk. So, the apply process applies messages
from hard disk and the last messages from memory. Message spilling occures at the transaction
level. It can query the DBA_APPLY_SPILL_TXN for the information about transactions spilled by an
apply process.
2)_TXN_BUFFER_SIZE
large transaction means having many row changes within a single transaction [100000's] and
parallelism > 1, consider reducing the transaction buffer size even lower.
3)_DYNAMIC_STMTS
For 10gR2 with a workload consisting of  many UPDATE transactions that modify less than half of the columns 
for any  given row, consider using the hidden apply parameter _DYNAMIC_STMTS.  This parameter setting may
reduce redo generation as well as improve apply performance.
4)_HASH_TABLE_SIZE
(all releases) In an mixed (Insert/UPdate/Delete) or heavy update workload that results in a large number
 of dependency waits (WAIT_DEPs) on replicated tables with many constraints , consider increasing the size
 of the dependency hash table  with the hidden parameter_HASH_TABLE_SIZE.  Set the value of this parameter
 to a large number.
 
5)_RESTRICT_ALL_REF_CONS

exec dbms_apply_adm.set_parameter('STRMADMIN_APPLY', 'TXN_LCR_SPILL_THRESHOLD', 100000);
exec dbms_apply_adm.set_parameter('STRMADMIN_APPLY', '_TXN_BUFFER_SIZE', 2);
exec dbms_apply_adm.set_parameter('STRMADMIN_APPLY', '_HASH_TABLE_SIZE', 1000000);
exec dbms_apply_adm.set_parameter('STRMADMIN_APPLY', '_RESTRICT_ALL_REF_CONS','N');
exec dbms_apply_adm.set_parameter('STRMADMIN_APPLY','_SGA_SIZE','100');
exec dbms_apply_adm.set_parameter('STRMADMIN_APPLY','PARALLELISM','4');
exec dbms_apply_adm.set_parameter('STRMADMIN_APPLY','DISABLE_ON_ERROR','N');
 
releated dictionary
======================
select * from  SYS.STREAMS$_APPLY_PROGRESS;
select * From sys.STREAMS$_APPLY_SPILL_MESSAGES;
select * From SYS.STREAMS$_APPLY_SPILL_TXN;
select * from dba_apply_spill_txn;
select * from dba_apply_parameters;
======================
select * from sys.streams$_process_params;
 
阅读(2961) | 评论(0) | 转发(0) |
0

上一篇:Hidden Parameter

下一篇:show block usage

给主人留下些什么吧!~~