行迁移检测及解决一例

行迁移(row migration):由于在table的pctfree设置过小,在update这个table并使其行长增大的时候,就有可能因为块的剩余空间不够存储该行,oracle会把该行数据迁移到另外一个有足够空闲空间的block中,此即发生了行迁移;发生行迁移时,行rowid并不变,原先存储该行的地方增加了一个新的指针,该指针指向迁移后的block id,所以我们在访问发生了行迁移的行时,会要读取迁移前和迁移后的2个block,一个表如果有大量的行发生了row migration,那么就有必要查看该table的storage设置了,看看pctpree是否可以调整的更大一点。
链接(row chained):和行迁移相对应的是行链接row chained,行连接常发生在行很大的情况下,如有long,raw,lob列,当insert一条新的记录时,一个block空间不够容纳一条记录,oracle会链接若干个block用来存储此记录,此即称为行链接;行链接是应为行的长度太长,要想避免,只能增加爱block size,在oracle9i之前,创建好数据库后您无法修改block size,要求你在建库的时候就要规划好,在oracle9i,提供了多块大小的技术,您可以设置2k,4k,8k,16k,32k大小的block,若想使用,您还必须设置相应的db_nk_cache_size缓冲池的大小。

下面是应用中客户维表行迁移的检测和消除步骤
检查user_tables信息
Select table_name,pct_free,num_rows,blocks,chain_cnt From user_tables Where table_name='CUST_DIMT0';
TABLE_NAME PCT_FREE NUM_ROWS BLOCKS CHAIN_CNT
------------------------------ ---------- ---------- ---------- ----------
CUST_DIMT0 20 363338 8846 7449

利用oracle自带的脚本utlchain.sq,新增表chained_rows,用于存储发生行迁移记录信息
SQL> @ $ORACLE_HOME/rdbms/admin/utlchain.sql

Table created.
SQL> grant all on chained_rows to dwh;
Grant succeeded.

用analyze命令分析该表
SQL> analyze table cust_dimt0 list chained rows into sys.chained_rows;
Table analyzed

Chained_rows用于存放产生行迁移的记录信息,其中head_rowid表示产生行迁移记录的rowid;
从该表中任意找一个head_rowed,看看行迁移消除前的执行计划
SQL> set autotrace traceonly;
SQL> select * from cust_dimt0 where rowid='AAAF9UAARAAAAWGAA3';
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT ptimizer=CHOOSE (Cost=1 Card=1 Bytes=172)
1 0 TABLE ACCESS (BY USER ROWID) OF 'CUST_DIMT0' (Cost=1 Card=1 Bytes=172)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
2 consistent gets
0 physical reads
0 redo size
1467 bytes sent via SQL*Net to client
275 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client

可以看到,取一条记录需要2个consistent read ;

接下来,来消除该表上的行迁移
修改表的pct_free,增大为25,日后需再观察,是否有大量的行迁移情况,如有,则说明还需要调整该参数。
SQL> alter table cust_dimt0 pctfree 25;

建立临时表,存放发生行迁移的记录
CREATE TABLE CUST_DIMT0_080331 AS SELECT * FROM CUST_DIMT0 WHERE ROWID IN (SELECT HEAD_ROWID FROM SYS.CHAINED_ROWS WHERE TABLE_NAME='CUST_DIMT0');

查看是否有外键约束应用于此表上,如果有。则先禁用此约束,操作结束后再启用
SQL> select constraint_name,constraint_type,r_owner,r_constraint_name from dba_constraints where table_name='CUST_DIMT0' and wner='DWH';
CONSTRAINT_NAME CONSTRAINT_TYPE R_OWNER R_CONSTRAINT_NAME
------------------------------ --------------- ------------------------------ ------------------------------
CUST_DIMT0_PK P
SYS_C006476 C
SYS_C006477 C
SYS_C006478 C
SYS_C006479 C

SQL>
SELECT * FROM DBA_CONSTRAINTS WHERE R_CONSTRAINT_NAME='CUST_DIMT0_PK';

未选定行
如有相关表建有外键指向该表,需要先禁用约束
alter table xxx disable constraint yyyy


删除发生行迁移的记录
SQL> DELETE CUST_DIMT0 WHERE ROWID IN (SELECT HEAD_ROWID FROM SYS.CHAINED_ROWS WHERE TABLE_NAME='CUST_DIMT0');

从临时表中重新插入记录
SQL> INSERT INTO CUST_DIMT0 SELECT * FROM CUST_DIMT0_080331;

看看执行行迁移消除后的执行计划
SQL> select * from cust_dimt0 where rowid='AAAF9UAARAAAAWGAA3';
未选定行
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT ptimizer=CHOOSE (Cost=1 Card=1 Bytes=172)
1 0 TABLE ACCESS (BY USER ROWID) OF 'CUST_DIMT0' (Cost=1 Card=1 Bytes=172)

Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
1 consistent gets
0 physical reads
0 redo size
1222 bytes sent via SQL*Net to client
234 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processed

可以发现,执行行迁移消除后,consistent gets为1个block了。

最后,drop临时表
SQL> drop table CUST_DIMT0_080331;

Table dropped


注:行迁移主要是由于update的时候,块剩余空间满足不了而导致的,对于行迁移的消除,除了上面介绍的方法外,采用exp/imp ,先把表导出,然后再导入,或者采用move命令,同样,可以达到行迁移消除的目的。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值