- 最后登录
- 2017-5-4
- 在线时间
- 81 小时
- 威望
- 999
- 金钱
- 2391
- 注册时间
- 2013-9-11
- 阅读权限
- 150
- 帖子
- 1124
- 精华
- 5
- 积分
- 999
- UID
- 1220
|
1#
发表于 2013-11-10 15:57:38
|
查看: 1757 |
回复: 0
1. What is the output for:
analyze table <owner>.TAB validate structure;
analyze table <owner>.TAB validate structure cascade;
analyze table <owner>.TAB validate structure;
analyze table <owner>.TAB validate structure cascade;
analyze index <owner>.PK_SMTACCDTLRECSUB validate structure;
2. If analyze reports no corruption then check if there are any chained rows on the table. If these exist then we may have an undetected corruption and the issue should reproduce whenever the SQL is run. Exporting the table will also detect this issue.
3. If the problem is a memory corruption, it can be simply worked around by flushing the buffer_cache:
ALTER SYSTEM FLUSH BUFFER_CACHE;
If the issue is in memory only we can try to immediately resolve the issue by flushing the buffer cache but remember to consider the performance impact on production systems:
alter system flush buffer_cache;
If we have an intermittent consistent read issue we can try disabling rowCR which is an optimization to reduce consistent-read rollbacks during queries by setting _row_cr=FALSE in the initialization files. However, this could lead to performance degradation of queries. Please check the ratio of the two statistics "RowCR hits"/"RowCR attempts" to determine whether the workaround is to be used. The ratio should be as close to 1 as possible, i.e. it's good to have as many hits as possible.
- set "_row_cr"=FALSE
alter system set "_row_cr"=FALSE scope=spfile;
- restart the instance
If this is a result of index corruption then we can drop and rebuild the index. Note that this will require a maintenance window on production systems. |
|