SAP索引重组技术.doc

SAP索引重组技术2012-07-24 16:52:31|分类： 默认分类 |标签：sap索引重组技术 |字号大中小订阅 随着时间的推移,SAP系统内的业务数据一般是以上抛物线(x2=2py)的方式进行增长.旧有的数据与新的数据大量的,不连续的分布在数据库硬件存储中.这种不连续的分布,产生的结果是数据库读取的数度越来越慢,这个时候我们就需要用一种廉价的性能提升解决方案,那就是-数据库重组.数据库重组的原理主要是:停止前端业务,把数据库里表的数据放到磁盘的空闲空间上.删除原有的表或索引,重建空的表或索引后,再把数据导入新表或索引中.这个过程无误即数据库重组成功.但也有导入数据失败的情况.所以数据库重组的风险也比较大.而SAP的手册也十分明确的指出单就释放磁盘空间角度出发,数据库重组的风险价值远大于购买磁盘硬件的价值.数据库重组可分为: 索引的重组.单表的重组.表空间的重组.表重组与表空间重组需要停SAP应用,只运行数据库,而且必须用专门的工具进行重组,这个有点超出SAP系统范畴,不是我们今天讨论的重点,我们今天主要讲可以在线进行的索引重组.1. 使用程序RSANAORA ,如下图所示:选择单选按钮,在对象对话框中输入需要重组的索引名称,格式为 “表名+(符号)+索引名”,如MSEG0,MSEGZI1.下边函数选项中,选择.然后点击 运行(F8)或选择 后台运行(F9) 即可.此处扩展说明一下:也可以选择下边的.这两个选项的区别在于.即英文中的,是需要阻塞DML操作,即该操作会为数据库加锁,而是在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比较方便,如下图所示:在中输入需要查询的索引名称,格式为 “表名+(符号)+索引名”,如MSEG0,MSEGZI1,中输入SAP在ORACLE中的用户名,也可不输入,直接抓取当前的,下边的选项无意义,随便选一个即可,运行(F8),运行结果如下:可以看出当前索引的数据库占用及存储分布情况,最下边的是系统经过计算得到的索引效率,一般来说索引效率小于70%就有必要进行数据库索引重组.实战展示:某系统索引AUFK0重组前:占用空间 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