微信号:gh_18bb53bd7791

介绍:平安科技数据库技术部公众平台

oracle秘境探索之11g tablespace prellocation

2016-07-19 21:26 汪泗龙

简介:
众所周知,oracle11g后引入了tablespace prellocation特性,该特性是space prellocation特性的组成之一。
Oracle 11g Enterprise PRD在默认启用的是extent层级的tablespace prellocation特性。

相关后台进程:
extent的预分配和预扩展任务主要由SMCO(spaceManagement Coordinator Process)和W00n(Slvae)一起完成。
简单介绍下SMCO和W00n:
SMCO:
角色:调度进程,管理任务队列和salve进程池。
主要工作:在任务队里中移动任务,清理过期任务,动态分配salve(W00n),监控slave。
重要度:该进程是实例级别的(RAC的每个节点都有一个SMCO进程,交互协调工作),非fatal进程,kill需酌情。
W00n:
角色和工作:一组slave进程,执行者,启动后在就绪队列中寻找任务并执行。

深入探究表空间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的黑科技。

    至此,oracle 11g的tablespace extent prellocation特性探究告一段落。关于space prellocation其他特性会后续和大家分享。


 
平安科技数据库技术部 更多文章 【投票】平安数据库审计平台即将来到你的身边 PostgreSQL中BRIN索引的使用(三) 【案例分享】redis audit内存分析工具在redis cluster中的应用 PostgreSQL中BRIN和BTREE索引的使用(二) PostgreSQL中BRIN索引的存储结构
猜您喜欢 别学框架,学架构 奇点理论是关于人工智能的科学理论,还是垃圾科学? 解读2015之大数据篇:大数据的黄金时代 PHP程序员最常犯的11个MySQL错误 2015年 Docker 采用调查