在ASSM的LMT表空间中数据块就不存在争用了吗？

显示全部楼层 · 2005-4-5 09:18:50

问题如题？
我看了很多文档，无非都是说如果是在assm的LMT下块的争用有了明显的好转。但是一旦出现了如何解决呢？
修改sql语句吗？我感觉这个好象用处不大。
减少块的大小吗？
增加pctfree吗？
还有没有别的方法？

千问 · 2005-4-5 09:18:50

怎么我的提问的人越来越少了？
是我的问题没有实际的意义吗？
还是没有人感兴趣？
或者是没有人知道？

千问 · 2005-4-5 09:18:50

设想出来的问题,答案千奇百怪,没什么好答的,块争用一般就是buffer busy wait,这个在DML不是特别频繁的系统中,是不会出现的...

千问 · 2005-4-5 09:18:50

最初由 xzh2000 发布
[B]设想出来的问题,答案千奇百怪,没什么好答的,块争用一般就是buffer busy wait,这个在DML不是特别频繁的系统中,是不会出现的... [/B]
这可不是设想出来的问题，实际发生了的．上周五很奇怪，数据库的redo突然增加了10多倍，查看v$session_wait，buffer busy wait事件就很频繁．

千问 · 2005-4-5 09:18:50

那要先看 redo 为何增加，数据是否总是集中在少数block 。 bufferbusywait 只是一个表现，解决的根本应该看应用方面是不是有问题。

千问 · 2005-4-5 09:18:50

最初由 biti_rainy 发布
[B]那要先看 redo 为何增加，数据是否总是集中在少数block 。 bufferbusywait 只是一个表现，解决的根本应该看应用方面是不是有问题。 [/B]
是有人在手工地修改数据，操作集中在某个对象上．应该与正常应用的关系不大．

千问 · 2005-4-5 09:18:50

最初由 anchen211 发布
[B]
是有人在手工地修改数据，操作集中在某个对象上．应该与正常应用的关系不大． [/B]
如果这些人手工修改的数据总是被其他应用在访问，那应该是有关系的。
日志量增加了10倍是多大？具体点，1个g和10g ，与 1m 和10m是不一样的。
如果老等待，你还应该找出是哪些对象、那些 sql 或者 dml 相关，再去分析应用。光在数据库上找找什么杀手锏是没意义的。

千问 · 2005-4-5 09:18:50

最初由 biti_rainy 发布
[B]
如果这些人手工修改的数据总是被其他应用在访问，那应该是有关系的。
日志量增加了10倍是多大？具体点，1个g和10g ，与 1m 和10m是不一样的。
如果老等待，你还应该找出是哪些对象、那些 sql 或者 dml 相关，再去分析应用。光在数据库上找找什么杀手锏是没意义的。 [/B]
谢谢版主的关注：
下面是两个statspack的对比，收集间隔为20分钟
１　正常
Load Profile
~~~~~~~~~~~~
Per Second Per Transaction

--------------- ---------------

Redo size:
42,927.96
10,004.57

Logical reads:
35,934.17
8,374.64

Block changes:
144.69
33.72

Physical reads:
702.23
163.66

Physical writes:
10.71
2.50

User calls:
975.34
227.31

Parses:
338.47
78.88

Hard parses:
0.57
0.13

Sorts:
47.80
11.14

Logons:
0.52
0.12

Executes:
3,576.93
833.62

Transactions:
4.29
２　异常
~~~~~~~~~~~~
Per Second Per Transaction

--------------- ---------------

Redo size:
500,785.58
99,957.20

Logical reads:
284,534.20
56,793.25

Block changes:
3,392.31
677.11

Physical reads:
888.02
177.25

Physical writes:
161.47
32.23

User calls:
963.01
192.22

Parses:
291.28
58.14

Hard parses:
0.47
0.09

Sorts:
57.04
11.38

Logons:
0.26
0.05

Executes:
1,173.62
234.26

Transactions:
5.01
两个报告发生的时间段都是一样的
都是15:00--15:20
报告间隔是一天．
现在已经正常，我只是想知道下一次如果还出现我可以从哪些方面进行调整．
谢谢！

千问 · 2005-4-5 09:18:50

你看看你的 statspack 中的哪些sql 或者 dml 是多出来的。当然如果是没使用bindvar 可能比较麻烦一点，报告里面看不到，可以考虑 logmnr 分析归档日志。

千问 · 2005-4-5 09:18:50

最初由 biti_rainy 发布
[B]你看看你的 statspack 中的哪些sql 或者 dml 是多出来的。当然如果是没使用bindvar 可能比较麻烦一点，报告里面看不到，可以考虑 logmnr 分析归档日志。 [/B]
这条ＳＱＬ语句我是能知道的，所涉及到的表我也当时也通过dba_extents中找到了．
语句如下：
update table_name set column_1='****'
操作员忘了加条件（当然不是本人）直接执行了．
但这个表的记录有３０００多万条
造成了这个事故．