尝试oracle表的rebuild操作

本文介绍了一个短信发送表因大量数据插入及删除导致查询性能下降的问题。通过对表进行统计信息收集和重建,显著提升了查询速度。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

生产系统中有个短信发送表,平均每个月会大批量发送一次群体短信(30~90万条记录),日常应用是一些即时短信,每天发送量在1000条~10000条左右。前几天突然发现查询很慢(在PL/SQL Developer工具中查出第一页要1秒左右,select * from tox.sm_send_sm_list,而一般的表只需0.01秒左右)。

经检查,发现表上没有收集统计信息。查看表统计信息的查询语句如下:

SELECT *
FROM All_All_Tables t
WHERE 1 = 1
AND t.owner = 'TOX'
AND t.table_name = 'SM_SEND_SM_LIST'

于是调用ANALYZE TABLE tox.sm_send_sm_list ESTIMATE STATISTICS;收集统计信息,统计了(NUM_ROWS BLOCKS EMPTY_BLOCKS AVG_SPACE CHAIN_CNT AVG_ROW_LEN AVG_SPACE_FREELIST_BLOCKS NUM_FREELIST_BLOCKS)等几个关键的指标。其中BLOCKS=19201, EMPTY_BLOCKS=4251,块大小为8K。现在查询,耗时在0.415秒左右。

第二天,找到DBA,在他的帮助下对表进行了重建。重建后,查询出第一页只需0.015秒,恢复正常。可以看出,对于这种短信发送表,经常大批量插入记录,并逐行删除到空记录,收缩性很强,会导致占用很多的块,以及空闲块。可能需要阶段性的将表重建一下,光靠统计信息收集还不太管用。

附录A:重建表的脚本(在TOAD for Oracle 8.6.0.38中,点击rebuild table按钮,自动生成脚本)
注意:重建时,要充分考虑主键/外键,表中数据,权限,依赖项重边缘,trigger等,所以个人推荐用Toad的脚本自动生成功能。

SET LINESIZE 200
-- 
--  Make backup copy of original table
ALTER TABLE TOX.SM_SEND_SM_LIST RENAME TO SM_SEND_SM_LIST_X ;

-- Drop all user named constraints
-- (none)

--  Recreate original table
CREATE TABLE TOX.SM_SEND_SM_LIST
(
  SERIALNO            NUMBER,
  SERVICEID           VARCHAR2(50 BYTE),
  SMCONTENT           VARCHAR2(1000 BYTE),
  SENDTARGET          VARCHAR2(20 BYTE),
  PRIORITY            NUMBER,
  RCOMPLETETIMEBEGIN  DATE,
  RCOMPLETETIMEEND    DATE,
  RCOMPLETEHOURBEGIN  NUMBER,
  RCOMPLETEHOUREND    NUMBER,
  REQUESTTIME         DATE,
  ROADBY              NUMBER,
  SENDTARGETDESC      VARCHAR2(100 BYTE),
  FEEVALUE            FLOAT(126),
  LINKID              VARCHAR2(100 BYTE),
  PAD1                VARCHAR2(50 BYTE),
  PAD2                VARCHAR2(100 BYTE),
  PAD3                VARCHAR2(200 BYTE),
  PAD4                VARCHAR2(500 BYTE),
  PAD5                VARCHAR2(1000 BYTE)
)
TABLESPACE TS_SMS
PCTUSED    0
PCTFREE    10
INITRANS   1
MAXTRANS   255
STORAGE    (
            INITIAL          64K
            MINEXTENTS       1
            MAXEXTENTS       2147483645
            PCTINCREASE      0
            BUFFER_POOL      DEFAULT
           )
LOGGING
NOCOMPRESS
NOCACHE
NOPARALLEL
NOMONITORING;
 
--  Copy the data from the renamed table 
INSERT /*+ APPEND */
INTO TOX.SM_SEND_SM_LIST INS_TBL
(SERIALNO, SERVICEID, SMCONTENT, SENDTARGET,
PRIORITY, RCOMPLETETIMEBEGIN, RCOMPLETETIMEEND, RCOMPLETEHOURBEGIN,
RCOMPLETEHOUREND, REQUESTTIME, ROADBY, SENDTARGETDESC,
FEEVALUE, LINKID, PAD1, PAD2,
PAD3, PAD4, PAD5)
SELECT
SERIALNO, SERVICEID, SMCONTENT, SENDTARGET,
PRIORITY, RCOMPLETETIMEBEGIN, RCOMPLETETIMEEND, RCOMPLETEHOURBEGIN,
RCOMPLETEHOUREND, REQUESTTIME, ROADBY, SENDTARGETDESC,
FEEVALUE, LINKID, PAD1, PAD2,
PAD3, PAD4, PAD5
FROM TOX.SM_SEND_SM_LIST_X SEL_TBL ;
 
Commit ;
 
-- Drop all other user named indexes
-- (none)

--  Recreate Indexes, Constraints, and Grants

ALTER TABLE TOX.SM_SEND_SM_LIST ADD (
  PRIMARY KEY
 (SERIALNO)
    USING INDEX
    TABLESPACE TS_SMS
    PCTFREE    10
    INITRANS   2
    MAXTRANS   255
    STORAGE    (
                INITIAL          64K
                MINEXTENTS       1
                MAXEXTENTS       2147483645
                PCTINCREASE      0
               ));

GRANT DELETE, INSERT, SELECT, UPDATE ON  TOX.SM_SEND_SM_LIST TO CALLCENTER;
GRANT INSERT, SELECT ON  TOX.SM_SEND_SM_LIST TO JSKM;
GRANT ALTER, DELETE, INDEX, INSERT, REFERENCES, SELECT, UPDATE, ON COMMIT REFRESH, QUERY REWRITE, DEBUG, FLASHBACK ON  TOX.SM_SEND_SM_LIST TO TA;
GRANT INSERT, SELECT ON  TOX.SM_SEND_SM_LIST TO WEB;
 
--  There are no FKeys that reference the new table to recreate.
 
--  Recompile any dependent objects
ALTER PACKAGE  "TA"."SMSSERVICE" COMPILE PACKAGE ;
ALTER PACKAGE  "TOX"."SMSSERVICE" COMPILE PACKAGE ;
ALTER PROCEDURE "TA"."P_NAVSMS" COMPILE ;
ALTER PROCEDURE "TA"."P_SENDSMS" COMPILE ;
 
--  Rebuild triggers for the new table.
--  *** WARNING *** WARNING *** WARNING *** WARNING *** WARNING ***
--  ***
--  *** You may need to run the 'create trigger'
--  *** statements as the table owner!

DROP TRIGGER TOX.BFINSERT_SM_SEND;

CREATE OR REPLACE TRIGGER TOX."BFINSERT_SM_SEND" BEFORE
INSERT ON "SM_SEND_SM_LIST"
    FOR EACH ROW
begin
  select SendSNo.nextval into :new.serialno from dual;
end;
/
SHOW ERRORS; 

一、重建索引的前提 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、付费专栏及课程。

余额充值