Bigfile tablepsace+pre-allocation cause issue

很多新特性,在设计之初是好的,但是在实际使用的过程中,往往会遇到各种问题。如在11g中的pre-allocation的新特性,有SMCO进程swap出Wnnn进程,来对空间进行预分配。

在这里有2个隐含参数:

但是,当预分配的特性遇到big file tablespace的时候,就会出问题了。

如,我们一个big file tablespace有20TB,扩展5%为1TB,根据生产环境预扩展的速度为每分钟1~3GB,如果按照每分钟1GB计算,约需要18小时。而在这18小时中,session都会遇到各种堵塞,如insert append会被堵塞,如buffer busy wait等待,如cursor pin S wait on X等待,除了这些等待,还会影响IO性能,撑爆文件系统卷等风险。这些问题,对于一个生产系统来说,是不可接受的。

所以,我们如果是big file tablespace,就不建议启用预扩展的特性,建议_enable_space_preallocation=0进行关闭。

如果是small table tablespace,我们也可以适当调小_kttext_warning,如调成_kttext_warning=1,这样就只预扩展1%,缩短预扩展的时间,也就缩短了阻塞的时间。

这里值得注意的是,在线修改_kttext_warning能否生效?

平安的DBA研究了这个问题,经过多次测试,反复验证,结论是需要_kttext_warning+_enable_space_preallocation配合使用。

即:
设置_kttext_warning=1后,需要_enable_space_preallocation=0关闭预扩展一次,再_enable_space_preallocation=3打开预扩展。这样1%的在线修改就生效了。

参考
Doc ID 1459097.1
Doc ID 743773.1

相关文章

2条评论

  1. 是否预先分配好,设置最大的数据文件,关闭扩展off ,也可以避免这个问题。

    当然对于大文件就不可以这样的。

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据