Reorg rebuild 重建表和表上的索引

回收索引页上分配而未用的空间,删除前推行,或者根据所建聚簇索引(如果存在)重新将表中所有数据行写入新的页,使索引页的物理存放尽可能的连续,提高其访问效率。  
   
    例如,长期的表数据更新操作,使得包含索引数据的索引页的物理存放空间出现碎片,如同表的数据页空间碎片整理一样,可以通过该命令重建表上的索引,整理碎片,提高空间的存放和访问效率。  
   
  基本语法:  
   
  reorg   rebuild   table_name   [index_name]  
   
  例一,重建表tb1及其之上的所有索引:  
   
  1>   reorg   rebuild   tb1  
  2>   go  
  Beginning   REORG   REBUILD   of   'tb1'.  
  There   are   approximately   1   pages   to   be   processed.  
  Non-clustered   index   (index   id   =   2)   is   being   rebuilt.  
  REORG   REBUILD   of   'tb1'   completed.  
   
  例二,重建表tb1上的索引tb1_ind:  
   
  1>   reorg   rebuild   tb1   tb1_ind  
  2>   go  
  There   are   approximately   1   pages   to   be   processed.  
   
  注意:  
   
  重建索引的表的加锁模式只能是数据页锁(datapages)或数据行锁(datarows),不能是全部页锁(allpages),否则报错:    
  1>   reorg   rebuild   tb1  
  2>   go  
  Msg   11903,   Level   16,   State   3:  
  Line   1:  
  You   cannot   run   REORG   on   a   table   which   uses   allpages   locking.    
  重建表上的所有索引,包括可能有的聚簇索引和所有非聚簇索引,或指定某一个具体名字的索引。    
  重建索引之前,必须将表对应数据库的选项设置为“select   into/bulkcopy/pllsort”。    
  重建索引需要额外的磁盘空间,大小等于表和索引空间之和,可以通过系统存储过程   sp_spaceused   table_name[index_name]   查看实际占用空间。    
  重建索引以后,在转储数据库事务日志之前,应该转储数据库。    
  不能在事务内运行reorg命令。    
  不能在文本索引中运行reorg命令,因为在sysindexes中的名字与文本链关联。    
  Reorg   build的应用前提:  
   
  查询并没有象通常一样选择使用大I/O池,而且optdiag显示出数据页、数据行或索引页的聚簇比很低。    
 使用sp_chgattribute改变了exp_row_size、reserverpagegap或fillfactor空间管理设置中的一项或多项,并想让所有的改变不仅应用于未来数据,还要应用于已有的行和页。

 

Sybase数据库的碎片整理    
  对于像Sybase这样的大型DBMS系统而言,作为OLTP(联机事务处理)应用的基石,它需要能每天24小时,每年365天不间断运行。由于其应用程序每天对数据库进行大量的插入、更新、删除等操作,在数据库的物理存储介质上产生了大量存储碎片,从而影响了存储的效率以及数据库应用运行的速度。是否可以像Windows操作系统的“碎片整理”程序一样,整理这些碎片,从而优化数据库存储,提高数据库的运行速度呢?答案是肯定的。本文将介绍Sybase 数据库的碎片类型以及碎片整理方法。    
  碎片类型    
  由于Sybase是通过OAM页、分配单元和扩展页来管理数据的,所以对OLTP应用的Database   Server会十分频繁地进行数据删除、插入和更新等操作,时间一长就会出现以下几种情况:    
  1.   页碎片    
  即本来可以存放在一个页上的数据却分散地存储在多个页上。如果这些页存储在不同的扩展单元上,Database   Server就要访问多个扩展单元,因此降低了系统性能。    
  2.   扩展单元碎片    
  在堆表中,当删除数据链中间的记录行时,会出现空页。随着空页的累积,扩展单元的利用率也会下降,从而出现扩展单元碎片。带cluster   index的table也有可能出现扩展单元碎片。    
  当有扩展单元碎片存在,会出现以下问题:    
  ●   对表进行处理时,常常出现死锁;    
  ●   利用较大的I/O操作或增加I/O缓冲区的大小也无法改变较慢的I/O速度;    
  ●   行操作的争用。    
  3.   扩展单元遍历    
  带有cluster   index的table会由于插入记录而导致页分裂,但当删除记录后,页会获得释放,从而形成跨几个扩展单元和分配单元的数据,而要访问该数据就必须遍历几个扩展单元和分配单元。这将导致访问/查询记录的时间大大延长,开始时数据库的性能虽然较高,但使用一段时间后性能就会下降等问题。    
  实际上,数据在存储空间上排列得越紧密有序,Database   Server访问的速度就越快,消除碎片有助于提高系统的性能和更有效地利用数据存储空间。    
  碎片优化方法    
  处理碎片有多种方法,如重新定义table的填充因子,根据table的定义删除并重新创建索引、重建表等。    
  本文给出的方法是通过BCP实用程序将用户数据库的数据以文本形式导出,然后将用户数据库彻底清空、截断,再将文本数据导入到数据库,从而达到消除碎片的目的,具有通用性。    
  下面以Sun   Solaris   7操作系统下的Sybase   Adaptive   Server   Enterprise   11.5为例,说明整理数据库数据的具体方法。    
  1.   备份数据库    
  为防止在数据库碎片整理过程中出现不可预见的问题,有必要先备份数据库。    
  2.   创建bcp   out脚本并导出数据    
  ●   创建包含下列SQL语句的文件:    
  cre_bcp_out.sql    
  select   “bcp”   +   name   +   “out   ./”   +   name   +   “_out.txt   -Udboname   -Pdbopwd   -Ssys_name   -c”    
  from   sysobjects   where   type   =   ‘U’    
  order   by   name    
  go    
  ●   isql   -Udboname   -Pdbopwd   -Ssystemname   <   cre_bcp_out.   sql   >   b_out    
  ●   编辑输出文件,去掉文件第一行和最后两行无关的字符:vi   b_out    
  ●   执行脚本,将数据库的数据导出到文本文件:sh   b_out    
  3.   创建truncate   table脚本并截断数据库    
  ●   创建包含下列SQL语句的文件:    
  cre_trunc_out.sql    
  select   “truncate   table”   +   name   from   sysobjects   where   type   =   ‘U’    
  order   by   name    
  go    
  ●   isql   -Udboname   -Pdbopwd   -Ssystemname   <   cre_   trunc_out.   sql   >   trunc_out.   sql    
  ●   编辑输出文件,去掉文件第一行和最后两行无关的字符,并在最后一行加入   go构成完整的SQL语句:vi   trunc_out    
  ●   执行以下语句,清空数据库的数据:    
  isql   -Udboname   -Pdbopwd   <   trunc_out.   sql    
  4.   创建bcp   in脚本并导入数据    
  ●   创建包含下列SQL语句的文件:    
  cre_bcp_in.   sql    
  select   “bcp”   +   name   +   “in   ./”   +   name   +   “_out.txt   -Udboname   -Pdbopwd   -Ssys_name   -c”from   sysobjects   where   type   =   ‘U’    
  order   by   name    
  go    
  ●   isql   -Udboname   -Pdbopwd   -Ssystemname   <   cre_   bcp_in.   sql   >   b_in    
  ●   编辑输出文件,去掉文件第一行和最后两行无关的字符:vi   b_in    
  ●   从文本中导入数据:sh   b_in    
  5.   更新数据库状态    
  Sybase不自动维护索引的统计信息,当用truncate   table截断数据库时,索引并没有改变,所以必须用update   statistics来确保索引的统计信息对应当前表数据的统计。    
  ●   创建包含下列SQL语句的文件:    
  cre_upd_st.   sql    
  select   “update   statistics”   +   name   from   sysobjects   where   type   =   “U”   order   by   name    
  go    
  ●   isql   -Udboname   -Pdbopasswd   -Ssystemname   <   cre_upd_st.   sql   >   upd_st.   sql    
  ●   编辑输出文件,去掉文件第一行和最后两行无关的字符,在最后一行加入   go构成完整的SQL语句:    
  vi   upd_st.   sql    
  ●   更新数据库状态:    
  isql   -Udboname   -Pdbopasswd   -Ssystemname   <   upd_st.   sql    
 至此,基本上完成了数据库用户表的碎片整理工作。    
  小   结    
  在整理过程中,有以下两点需要注意:    
  1.   Tempdb的大小    
  当Sybase执行bcp   in脚本时,会占用导入数据2倍的tempdb空间,因此在执行前要仔细估计最大的table的大小,保证有足够的tempdb空间。当空间不够时,要考虑用分割table或删除陈旧数据的方法缩小table的大小,或者考虑增加tempdb的大小。    
  2.   数据库配置选项的设置    
  当数据库执行bcp   in脚本时会产生大量的log,为保证bcp   in进程不致因为log溢出而中断,应该设置database的选项“truncate   log   on   chkpt”为“true”。    
  虽然Sybase数据库是自优化的,但只要数据库是动态的,数据库碎片现象就会存在。在OLTP应用的场合,随着数据的不断增大,系统变得越来越缓慢,并且经常出现死锁时,应该检查数据库的碎片,并且采用以上方法进行优化。    
  实际上,应该定期做数据库的碎片整理,保证数据库的物理存储经常处于

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14855094/viewspace-555764/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/14855094/viewspace-555764/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
一、重建索引的前提 1、上频繁发生update,delete操作; 2、上发生了alter table ..move操作(move操作导致了rowid变化)。 二、重建索引的标准 1、索引重建是否有必要,一般看索引是否倾斜的严重,是否浪费了空间, 那应该如何才可以判断索引是否倾斜的严重,是否浪费了空间, 对索引进行结构分析(如下): SQL>Analyze index index_name validate structure; 2、在执行步骤1的session中查询index_stats,不要到别的session去查询。 SQL>select height,DEL_LF_ROWS/LF_ROWS from index_stats; 说明:当 查询出来的 height>=4 或者 DEL_LF_ROWS/LF_ROWS>0.2 的场合 , 该索引考虑重建 。 举例: (t_gl_assistbalance 26 万多条信息 ) SQL> select count(*) from t_gl_assistbalance ; 输出结果: COUNT(*) ---------- 265788 SQL> Analyze index IX_GL_ASSTBAL_1 validate structure; Index analyzed SQL> select height,DEL_LF_ROWS/LF_ROWS from index_stats; 输出结果: HEIGHT DEL_LF_ROWS/LF_ROWS ---------- ------------------- 4 1 三、重建索引的方式 1、drop 原来的索引,然后再创建索引; 举例: 删除索引:drop index IX_PM_USERGROUP; 创建索引:create index IX_PM_USERGROUP on T_PM_USER (fgroupid); 说明:此方式耗时间,无法在24*7环境中实现,不建议使用。 2 、直接重建: 举例: alter index indexname rebuild; 或alter index indexname rebuild online; 说明:此方式比较快,可以在24*7环境中实现,建议使用此方式。 四、alter index rebuild 内部过程和注意点 alter index rebuild 和alter index rebuil online的区别 1、扫描方式不同 1.1、Rebuild以index fast full scan(or table full scan) 方式读取原索引中的数据来构建一个新的索引,有排序的操作; 1.2、rebuild online 执行扫描获取数据,有排序的操作; 说明:Rebuild 方式 (index fast full scan or table full scan 取决于统计信息的cost) 举例1 SQL> explain plan for alter index IX_GL_ASSTBAL_1 rebuild; Explained SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT --------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost | --------------------------------------------------------------------- | 0 | ALTER INDEX STATEMENT | | 999K| 4882K| 3219 | | 1 | INDEX BUILD NON UNIQUE| IDX_POLICY_ID2 | | | | | 2 | SORT CREATE INDEX | | 999K| 4882K| | | 3 | INDEX FAST FULL SCAN | IDX_POLICY_ID2 | 999K| 4882K| | --------------------------------------------------------------------- 举例2 SQL> explain plan for alter index idx_policy_id rebuild; Explained SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT --------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost | --------------------------------------------------------------------- | 0 | ALTER INDEX STATEMENT | | 2072K| 9M| 461 | | 1 | INDEX BUILD NON UNIQUE| IDX_POLICY_ID | | | | | 2 | SORT CREATE INDEX | | 2072K| 9M| | | 3 | TABLE ACCESS FULL | TEST_INDEX | 2072K| 9M| 461 | 举例3 ( 注意和 举例1 比较 ) Rebuil online 方式 : SQL> explain plan for alter index idx_policy_id2 rebuild online; Explained SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT --------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost | ---------------------------------------------------------------------| 0 | ALTER INDEX STATEMENT | | 999K| 4882K| 3219 | | 1 | INDEX BUILD NON UNIQUE| IDX_POLICY_ID2 | | | | | 2 | SORT CREATE INDEX | | 999K| 4882K| | | 3 | TABLE ACCESS FULL | TEST_INDEX2 | 999K| 4882K| 3219 | 2 、rebuild 会阻塞 dml 操作 ,rebuild online 不会阻塞 dml 操作 ; 3 、rebuild online 时系统会产生一个 SYS_JOURNAL_xxx 的 IOT 类型的系统临时日志 , 所有 rebuild online 时索引的变化都记录在这个中 , 当新的索引创建完成后 , 把这个的记录维护到新的索引中去 , 然后 drop 掉旧的索引rebuild online 就完成了。 注意点: 1、 执行rebuild操作时,需要检查空间是否足够; 2、虽然说rebuild online操作允许dml操作,但是还是建议在业务不繁忙时间段进行; Rebuild操作会产生大量redo log ; 五、重建分区上的分区索引 重建分区索引方法: Alter index indexname rebuild partition paritionname tablespace tablespacename; Alter index indexname rebuild subpartition partitioname tablespace tablespacename; Partition name 可以从user_ind_partitions查找 Tablepace 参数允许alter index操作更改索引的存储空间; 六、索引状态描述 在数据字典中查看索引状态,发现有三种: valid:当前索引有效 N/A :分区索引 有效 unusable:索引失效 七、术语 1、高基数:简单理解就是中列的不同值多。 2、低基数:建单理解就是中的列的不同值少。 3、以删除的叶节点数量:指得是数据行的delete操作从逻辑上删除的索引节点 的数量,要记住oracle在删除数据行后,将 “ 死 “ 节点保留在索引中,这样做可以加快sql删除操作的速度,因此oracle删除数据行后可以不必重新平衡索引。 4、索引高度:索引高度是指由于数据行的插入操作而产生的索引层数,当中添加大量数据时,oracle将生成索引的新层次以适应加入的数据行,因此,oracle索引可能有4层,但是这只会出现在索引数中产生大量插入操作的区域。Oracle索引的三层结构可以支持数百万的项目,而具备4层或是更多层的需要重建。 5、每次索引访问的读取数:是指利用索引读取一数据行时所需要的逻辑I/O操作数,逻辑读取不必是物理读取,因为索引的许多内容已经保存在数据缓冲区,然而,任何数据大于10的索引都需要重建。 6、什么时候重建呢? 察看 dba_indexes 中的 blevel 。这列是说明索引从根块到叶快的级别,或是深度。如果级别大于等于4。则需要重建, 如下 :Select index_name,blevel from dba_indexes where blevel>=4. 另一个从重建中受益的指标显然是当该索引中的被删除项占总的项数的百分比。如果在20%以上时,也应当重建,如下 SQL>analyze index index_name validate structure SQL>select (del_lf_rows_len/lf_rows_len)*100 from index_stats where name= ’ index_name ’ 就能看到是否这个索引被删除的百分比。 7、什么样的重建方式更好? (1)、建索引的办法: 1.1、删除并从头开始建立索引。 1.2 、 使用 alter index index_name rebuild 命令重建索引。 1.3 、 使用 alter index index_name coalesce 命令重建索引。 (2)、下面讨论一下这三种方法的优缺点: 2.1、删除并从头开始建索引:方法是最慢的,最耗时的。一般不建议。 2.2、Alter index index_name rebuild 快速重建索引的一种有效的办法,因为使用现有索引项来重建索引,如果客户操作时有其他用户在对这个操作,尽量使用带online参数来最大限度的减少索引重建时将会出现的任何加锁问题,alter index index_name rebuild online。 但是,由于新旧索引在建立时同时存在,因此,使用这种技巧则需要有额外的磁盘空间可临时使用,当索引建完后把老索引删除,如果没有成功,也不会影响原来的索引。利用这种办法可以用来将一个索引移到新的空间。 Alter index index_name rebuild tablespace tablespace_name 。 这个命令的执行步骤如下: 首先,逐一读取现有索引,以获取索引的关键字。 其次,按新的结构填写临时数据段。 最后,一旦操作成功,删除原有索引树,降临时数据段重命名为新的索引。 需要注意的是alter index index_name rebuild 命令中必须使用tablespace字句,以保证重建工作是在现有索引相同的空间进行。 2.3、alter index index_name coalesce 使用带有coalesce参数时重建期间不需要额外空间,它只是在重建索引时将处于同一个索引分支内的叶块拼合起来,这最大限度的减少了与查询过程中相关的潜在的加锁问题,但是,coalesce选项不能用来将一个索引转移到其他空间。 八、其他 1、truncate 分区操作和truncate 普通的区别? 1.1、Truncate 分区操作会导致全局索引失效; truncate 普通索引没有影响; 1.2、Truncate 分区操作不会释放全局索引中的空间,而truncate 普通会释放索引所占空间; 2、rename 名操作对索引没有影响,因为rename操作只是更改了数据字典,中数据行的rowid并没有发生变化 总结: 1、判断是否需要重建索引: SQL>analyze index index_name validate structure; SQL> select height,DEL_LF_ROWS/LF_ROWS from index_stats; ( 或 Select index_name,blevel from dba_indexes where blevel>=4 ); 说明 : 当查询出来的 height>=4 或者 DEL_LF_ROWS/LF_ROWS>0.2 的场合 , 该索引考虑重建 ; 2 、重建索引方法 : 方法一、 Alter index index_name rebuild tablespace tablespace_name; 优点:是快速重建索引的一种有效的办法,可以用来将一个索引移到新的空间。 缺点:重建期间需要额外空间。 方法二、 alter index index_name coalesce; 优点:重建期间不需要额外空间。 缺点:coalesce选项不能用来将一个索引转移到其他空间。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值