深入探究表空间extent prellocation：1.表空间extentprellocation开启的条件：

datafile的autoextend=on 且 _ENABLE_SPACE_PREALLOCATION=3

2. 表空间extent prellocation相关参数：

_ENABLE_SPACE_PREALLOCATION：3：开启预分配功能；0：关闭预分配功能。

_kttext_warning：将扩展占整个表空间的百分比，对扩展起一定指导作用，扩展一般>= _kttext_warning。

3.  表空间extent prellocation在PA实践过程中遇到的问题:

1) 文件卷快速撑满的问题：

_kttext_warning的默认值是5%，此值对PA的一些应用来说，成为了非常大的威胁。

文件系统架构的DB，单个卷是2T(新规则可以到4T)，报警处理阀值是80%，剩余400G左右时发起扩容流程和处理。

如8T以上的表空间,8T*5%=400G，一次预分配行为可能导致文件卷撑爆。之前nba4ot就碰到了这个问题，非常危险。

2)性能问题：

_kttext_warning的默认值是5%，8T以上的表空间，一次扩展400G左右会严重影响DB IO性能。

产生buffer busy waits等等待，导致DB异常。

3) BIG TABLESPACE + tablespace prellocation缓慢，阻塞insertappend等等待高水位的操作。

由于big tablespace只有一个数据文件，因此文件头长时间锁定，会导致后续等待空间分配的进程阻塞。

经过生产实践和确认，BIG TABLESPACE进行tablespace prellocation时异常缓慢，扩展速度基本都在1-3GB每分钟。

参考1GB/min的速度，对20TB以上表空间。扩展1T，需约18个小时，严重阻塞insert append等等待高水位的操作。

4.   PA个性化后的tablespace extent prellocation:

鉴于上述问题发生导致了一系列的问题，PA深入分析tablespace extent prellocation机制后，采取如下调整：

1) 关闭所有big tablespace DB的tablespaceprellocation(_ENABLE_SPACE_PREALLOCATION=0)

2) 调整所有11g和后续版本DB的tablespace prellocation阀值为1%(_kttext_warning=1)

5.  调整tablespace prellocation阀值过程中遇到的问题：

1) 测试在线调整_kttext_warning=1是否生效:

经过新建表空间数据模拟，发现当满足预扩展的时候，tablespace还是按照5%预扩展。

难道_kttext_warning参数需要重启才生效?这对几百个生产DB的生产环境来说是不可接受的。

经过反复模拟测试，确认此参数需在再次打开tablespaceextent prellocation才会加载生效。

即该参数的调整需配合(_ENABLE_SPACE_PREALLOCATION=0+ _ENABLE_SPACE_PREALLOCATION=3)

2)  自动预扩展发生的时间点：

根据现有文档的记录，自动预扩展会在负载高之后的下一个周期内发生。

从我们实际测试的结果确认，当tablespace 使用率100%,   伴随一次常规extent自动扩展的还有自动预扩展。

即2GB的tablespace开启自动扩展，每次扩100M。在使用率100%时发生的扩展为200M(2000M*5%+100M)

也即tablespace extentprellocation的发生取决于system monitor analysis result,而非固定周期。

以上两点是Oracle文档也没有的，属于PA的黑科技。