Oracle数据文件自动增长频繁导致死锁?

[LiuTaiYe]

初始空间大小是7GB。在高并发的测试环境下,数据文件增长的非常快。当实际使用的空间超过7GB后，过一定时间就看到死锁。如果一开始就分配一个20GB的表空间，同样的测试(例子和时间)就不会遇到死锁。
我感觉应该是Oracle在申请磁盘空间的过程，导致一个DDM的请求(insert etc)的资源得不到满足，从而导致死锁。不过我没有找到这方面的资料，向大家求助， 谢谢！

[ngx20080110]

关注。我也偶尔遇到死锁的情况

[Dave]

[Quote=引用楼主 liutaiye 的回复:]
初始空间大小是7GB。在高并发的测试环境下,数据文件增长的非常快。当实际使用的空间超过7GB后，过一定时间就看到死锁。如果一开始就分配一个20GB的表空间，同样的测试(例子和时间)就不会遇到死锁。
我感觉应该是Oracle在申请磁盘空间的过程，导致一个DDM的请求(insert etc)的资源得不到满足，从而导致死锁。不过我没有找到这方面的资料，向大家求助， 谢谢！
[/Quote]

个人理解， 对于表空间，我们会开启它的自动增加功能，但是这只是保险，以防唯一空间满了，而导致数据库hang住了。 当表空间使用率超过90%的时候，我们会手动在加一个数据文件。

根据楼主描述的情况，猜测，因为数据增常较快，而自动增加的速度有限。 在超过7G的时候，数据就无法写入磁盘文件，然后进程就不停的在那等待数据的写入。 造成了死锁现象。 这个也算是数据库hang住了。 所以当表空间超过90%的时候，我们最好就给它加一个数据文件，或者开始把表空间就设大点。



------------------------------------------------------------------------------
Blog： http://blog.csdn.net/tianlesoftware
网上资源： http://tianlesoftware.download.csdn.net
相关视频：http://blog.csdn.net/tianlesoftware/archive/2009/11/27/4886500.aspx
Q Q 群：62697716

[LiuTaiYe]

[Quote=引用 2 楼 tianlesoftware 的回复:]
引用楼主 liutaiye 的回复:
初始空间大小是7GB。在高并发的测试环境下,数据文件增长的非常快。当实际使用的空间超过7GB后，过一定时间就看到死锁。如果一开始就分配一个20GB的表空间，同样的测试(例子和时间)就不会遇到死锁。
我感觉应该是Oracle在申请磁盘空间的过程，导致一个DDM的请求(insert etc)的资源得不到满足，从而导致死锁。不过我没有找到这方面的资料，向大家求助， 谢谢！


个人理解， 对于表空间，我们会开启它的自动增加功能，但是这只是保险，以防唯一空间满了，而导致数据库hang住了。 当表空间使用率超过90%的时候，我们会手动在加一个数据文件。

根据楼主描述的情况，猜测，因为数据增常较快，而自动增加的速度有限。 在超过7G的时候，数据就无法写入磁盘文件，然后进程就不停的在那等待数据的写入。 造成了死锁现象。 这个也算是数据库hang住了。 所以当表空间超过90%的时候，我们最好就给它加一个数据文件，或者开始把表空间就设大点。


------------------------------------------------------------------------------
Blog： http://blog.csdn.net/tianlesoftware
网上资源： http://tianlesoftware.download.csdn.net
相关视频：http://blog.csdn.net/tianlesoftware/archive/2009/11/27/4886500.aspx
Q Q 群：62697716
[/Quote]

谢谢关注！
因为这个问题在生产环境中发生的可能性很小，除非DBA都放假了。我们后续也是通过分配大的数据空间来解决这个问题。

问题是这是在测试时QA遇到的问题，现在开发需要一份权威的解释。所以仅仅是猜测是不行的。我也想提供更多的数据来描述这个问题。但出于公司保密条款，我只能给这些信息。

你说的很好，如果你有这方面的官方文档资料介绍，请分享。

[Dave]

没有官方的资料.. 如果你有metalink 帐号，可以找Oracle问问。



------------------------------------------------------------------------------
Blog： http://blog.csdn.net/tianlesoftware
网上资源： http://tianlesoftware.download.csdn.net
相关视频：http://blog.csdn.net/tianlesoftware/archive/2009/11/27/4886500.aspx
Q Q 群：62697716

[LiuTaiYe]

[Quote=引用 4 楼 tianlesoftware 的回复:]
没有官方的资料.. 如果你有metalink 帐号，可以找Oracle问问。


------------------------------------------------------------------------------
Blog： http://blog.csdn.net/tianlesoftware
网上资源： http://tianlesoftware.download.csdn.net
相关视频：http://blog.csdn.net/tianlesoftware/archive/2009/11/27/4886500.aspx
Q Q 群：62697716
[/Quote]

恩，我有这个帐号，不过自从Oracle升级Support系统后，我还一次都没用过，谢谢你提醒。

[jdsnhan]

需要提供OS及ORACLE的版本

[crazylaa]

学习

[中泽三郎]

创建表空间时对每次自增的大小进行设定，AUTOEXTEND ON NEXT 500M，设置一个很大的值应该就不会出现这种情况了吧

[wh62592855]

[Quote=引用 8 楼 liutaiye 的回复:]
补充一个错误log:

ORA-08007: Further changes to this block by this transaction not allowed

我加大了DML_LOCKS数值，可是还是会报此类错误。


[/Quote]
ORA-08007: Further changes to this block by this transaction not allowed
Cause: Max locks have been reached for this transaction in this block

Action: Commit changes

[wh62592855]

DML_LOCKS这个参数指定的是在一个事务中对某个表所持有锁的最大量

而根据上面的那个错误提示
这里问题在于在block上的锁达到了最大数量

可以适当增加提交的频率看看

[LiuTaiYe]

补充一个错误log:

ORA-08007: Further changes to this block by this transaction not allowed

我加大了DML_LOCKS数值，可是还是会报此类错误。

[LiuTaiYe]

[Quote=引用 11 楼 wh62592855 的回复:]
DML_LOCKS这个参数指定的是在一个事务中对某个表所持有锁的最大量

而根据上面的那个错误提示
这里问题在于在block上的锁达到了最大数量

可以适当增加提交的频率看看
[/Quote]
恩。对这个J2EE系统来说，每个事务都被提交，但是很难确定时间和控制事务提交的频率。所以，你的建议很难应用。

我已经开了一个Oracle support case，就等Oracle的回复了。我会更新这个帖子的和散分的。

[LiuTaiYe]

[Quote=引用 9 楼 liuguanju 的回复:]
创建表空间时对每次自增的大小进行设定，AUTOEXTEND ON NEXT 500M，设置一个很大的值应该就不会出现这种情况了吧
[/Quote]

根据测试人员的结果，只要是表空间会自动扩展，这个问题就会出现。有时会更早出现。如果瓶颈是在文件分配上。显然分配一个文件越大，时间开销越多，问题出现的机率也大。

[wh62592855]

有个问题
楼主你确定是死锁吗?还是只是数据库停在那里反应慢而已

[LiuTaiYe]

[Quote=引用 14 楼 wh62592855 的回复:]
有个问题
楼主你确定是死锁吗?还是只是数据库停在那里反应慢而已
[/Quote]
我解释一下，严格地讲不是数据库死锁。我最先帖子的描述和后续的帖子有出入，请以后续帖子为准。

我同事已经在MetaLink上开了case。有确定回复之后，我将更新给大家。谢谢大家的关注！