enq: JI - contention等待事件
2011-08-08 19:43
656 查看
Sessions waiting on this event are waiting on locks held during materialized view operations (such as refresh, alter) to prevent concurrent operations on the same materialized view.
Solutions
A materialized view cannot be fast refreshed more than once in a given period because it is serialized during the commit phase. Ensure that only one session at a time is performing the refreshes. If there is more than one session, the first session will work normally but the subsequent sessions will wait on "enq: JI - contention".
Waits on this event can also be caused by on-commit time logic within the materialized view. Normally when a session updates record 1 and commits and then another session updates record 2 and commits, they do not have to wait for each other. However, when using an on commit-time fast refreshable materialized view on top of the table, we do have to wait when two sessions do totally unrelated transactions concurrently against the same table. This is not a problem when the table is modified infrequently or only by a single session, but it can be a big problem when applied to a table that performs a lot of modifications concurrently. Be sure to use on commit-time fast refreshable materialized views for implementing business rules only on tables that are not concurrently accessed or infrequently changed.本文出自 “Ask Maclean Liu Oracle” 博客,请务必保留此出处http://maclean.blog.51cto.com/2923249/1277916
Solutions
A materialized view cannot be fast refreshed more than once in a given period because it is serialized during the commit phase. Ensure that only one session at a time is performing the refreshes. If there is more than one session, the first session will work normally but the subsequent sessions will wait on "enq: JI - contention".
Waits on this event can also be caused by on-commit time logic within the materialized view. Normally when a session updates record 1 and commits and then another session updates record 2 and commits, they do not have to wait for each other. However, when using an on commit-time fast refreshable materialized view on top of the table, we do have to wait when two sessions do totally unrelated transactions concurrently against the same table. This is not a problem when the table is modified infrequently or only by a single session, but it can be a big problem when applied to a table that performs a lot of modifications concurrently. Be sure to use on commit-time fast refreshable materialized views for implementing business rules only on tables that are not concurrently accessed or infrequently changed.本文出自 “Ask Maclean Liu Oracle” 博客,请务必保留此出处http://maclean.blog.51cto.com/2923249/1277916
相关文章推荐
- oracle 11g enq: JI – contention等待事件
- enq: JI - contention等待事件
- enq TX row lock contention 锁等待事件解决案例一起
- enq: TX - row lock contention“等待事件的处理
- enq: HW - contention等待事件
- Oracle “enq: TX - row lock contention 等待事件 ”
- 事务上的等待事件 —— enq: TM - contention
- 等待事件enq TX row lock contention分析
- enq: TX - row lock contention 等待事件
- resetlogs开库遇到enq: DM - contention 等待事件
- enq: TM - contention TM 等待事件的原因及模拟(表外键约束无索引导致)
- enq: TT – contention等待事件
- enq: TX - row lock contention 等待事件
- enq: TX - row lock contention 等待事件
- enq: TM - contention等待事件
- ORACLE等待事件:enq: TX - row lock contention
- 事务上的等待事件 —— enq: TX - contention
- enq: TT - contention等待事件
- enq: TX - row lock contention 等待事件
- 事务上的等待事件 —— enq: UL - contention