很多新特性，在设计之初是好的，但是在实际使用的过程中，往往会遇到各种问题。如在11g中的pre-allocation的新特性，有SMCO进程swap出Wnnn进程，来对空间进行预分配。
在这里有2个隐含参数：
|
1 2 |
1. _enable_space_preallocation 在11g中默认值是3，它可以使表空间在接近100%进行扩展，。 2. _kttext_warning 默认值为5。表示扩展的大小为当时表空间大小的5% |
但是，当预分配的特性遇到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条评论
是否预先分配好，设置最大的数据文件，关闭扩展off ，也可以避免这个问题。
当然对于大文件就不可以这样的。
可以，但是那样就不是big file tablespace的用法了。