(SAP索引重组技术.docVIP

SAP索引重组技术?? 2012-07-24 16:52:31|??分类： 默认分类 |??标签：sap索引重组技术?? |字号大中小?订阅 随着时间的推移,SAP系统内的业务数据一般是以上抛物线(x^2=2py)的方式进行增长.旧有的数据与新的数据大量的,不连续的分布在数据库硬件存储中.这种不连续的分布,产生的结果是数据库读取的数度越来越慢,这个时候我们就需要用一种廉价的性能提升解决方案,那就是----数据库重组. 数据库重组的原理主要是:停止前端业务,把数据库里表的数据放到磁盘的空闲空间上.删除原有的表或索引,重建空的表或索引后,再把数据导入新表或索引中.这个过程无误即数据库重组成功.但也有导入数据失败的情况.所以数据库重组的风险也比较大.而SAP的手册也十分明确的指出单就释放磁盘空间角度出发,数据库重组的风险价值远大于购买磁盘硬件的价值. 数据库重组可分为: ①索引的重组.②单表的重组.③表空间的重组.表重组与表空间重组需要停SAP应用,只运行数据库,而且必须用专门的工具进行重组,这个有点超出SAP系统范畴,不是我们今天讨论的重点,我们今天主要讲可以在线进行的索引重组. 1.???? 使用程序RSANAORA ,如下图所示: ? ? 选择索引单选按钮,在对象对话框中输入需要重组的索引名称,格式为 “表名+~(符号)+索引名”,如MSEG~0,MSEG~ZI1.下边函数选项中,选择改变索引重建. 然后点击 运行(F8)或选择 后台运行(F9) 即可. ? 此处扩展说明一下:也可以选择下边的Alter Inder Rebuild Online.这两个选项的区别在于.改变索引重建即英文中的 Alter Inder Rebuild,是需要阻塞DML操作,即该操作会为数据库加锁,而Alter Inder Rebuild Online是在rebuild的期间不阻塞DML,但是在开始和结束阶段还是会阻塞其他进程的DML的(我们知道，DML操作一般要加两个锁，一个是对表加模式为3的TM锁，一个是对数据行的模式为6的TX锁。只要操作的不是同一行数据，是互不阻塞的。rebuild index online在开始和结束的时候是需要对表加一个模式为4的TM锁的).但是要注意: 虽然rebuild index online在执行期间只持有模式2的TM锁，不会阻塞DML操作，但在操作的开始和结束阶段，是需要短暂的持有模式为4的TM锁的，这段会阻塞表上的所有DML操作。我们在做rebuild index online的时候，一定要在开始和结束阶段观察系统中是否有长事务的存储，对于并发量较大的系统，最严重的后果，可能在这两个关键点导致数据库产生大量锁等待，系统负载飙升，甚至宕机。 ? 2.?????? 查看索引优化效果 查看可以用事务代码DB02OLD,4.6C以下的是DB02.-详细的分析(输入索引名回车)-详细的分析-索引分析(选择索引质量),不过通过程序RSORATAD比较方便,如下图所示: ? 在SEG_NAME中输入需要查询的索引名称,格式为 “表名+~(符号)+索引名”,如MSEG~0,MSEG~ZI1,OWNER中输入SAP在ORACLE中的用户名,也可不输入,直接抓取当前的,下边的选项无意义,随便选一个即可,运行(F8),运行结果如下: ? ? 可以看出当前索引的数据库占用及存储分布情况,最下边的是系统经过计算得到的索引效率,一般来说索引效率小于70%就有必要进行数据库索引重组. ? 实战展示: 某系统索引AUFK~0 ? 重组前: ? ? 占用空间 64016 KB,占用BLOCKS 8002 个,占用扩展EXTENTS 41 个. ? ? 索引质量为51%,算是比较低的了,需要重组. ? 重组进行中…… ? 重组后: ? ? ? 占用空间 20512 KB,占用 BLOCKS 2564 个,占用扩展EXTENTS 5 个. ? ? 索引质量为91%.(那是“相当”好了). ? 重组总结统计:空间与BLOCKS占用减小了68%,EXTENS占用由41个变为5个,仅为原来的12%.这说明数据库索引重组释放了大量的数据库空间,索引文件存储更加连续,这样也会进一步提升硬件I/O速度.索引的命中质量从51%上升到91%. 经过实际程序检测SELECT速度也明显提高,优化成功! ? 说明: ???? 1.数据库索引重组虽然风险比较小,但是也存在一定的风险,操作的时候一定要慎重.重组有风险,操作需谨慎. ???? 2.数据库索引重组的时候,虽然不需要停SAP服务,但是对应的表访问会暂停,并且也会使用TEMPTABLESPACE(需要保证TEMPTABLESPACE的可用度),所以对于一些大表的索引重组,需要在系统比较空闲