Shrink操作的注意事项

对大表做shrink之前应该分为两步:

 

alter table "BAAN"."TTFGLD495200" shrink compact;

alter table "BAAN"."TTFGLD495200" shrink space;

这样会先调整数据块,然后再调整高水位线.

但昨天,出现这样一个小问题,我再做shrink table的同时,也对它的index做了shrink

而且我分别在两个instance做的,这样不但出现了shrink lock等待事件,集群之间也出现了等待事件

过了一段时间以后,bdump目前出现这样的核心错误文件:

cdmp_20080506180835       cdmp_20080506215541       cdmp_20080507012914       cdmp_20080507050238
cdmp_20080506181154       cdmp_20080506215653       cdmp_20080507013113       cdmp_20080507050347
cdmp_20080506181505       cdmp_20080506215804       cdmp_20080507013221       cdmp_20080507050455
cdmp_20080506181615       cdmp_20080506215914       cdmp_20080507013327       cdmp_20080507050603
cdmp_20080506181723       cdmp_20080506220027       cdmp_20080507013432       cdmp_20080507050713
cdmp_20080506181829       cdmp_20080506220141       cdmp_20080507013538       cdmp_20080507050821
cdmp_20080506181935       cdmp_20080506220253       cdmp_20080507013642       cdmp_20080507050930
cdmp_20080506182043       cdmp_20080506220406       cdmp_20080507013747       cdmp_20080507051040
cdmp_20080506182152       cdmp_20080506220522       cdmp_20080507013852       cdmp_20080507051148
cdmp_20080506182300       cdmp_20080506220633       cdmp_20080507013958       cdmp_20080507051257
cdmp_20080506182409       cdmp_20080506220744       cdmp_20080507014102       cdmp_20080507051405
cdmp_20080506182518       cdmp_20080506220856       cdmp_20080507014209       cdmp_20080507051515
cdmp_20080506182629       cdmp_20080506221007       cdmp_20080507014314       cdmp_20080507051631
cdmp_20080506182736       cdmp_20080506221118       cdmp_20080507014419       cdmp_20080507051739
cdmp_20080506182847       cdmp_20080506221229       cdmp_20080507014524       cdmp_20080507051847
cdmp_20080506182954       cdmp_20080506221341       cdmp_20080507014630       cdmp_20080507051954
cdmp_20080506183101       cdmp_20080506221455       cdmp_20080507014736       cdmp_20080507052101
cdmp_20080506183211       cdmp_20080506221606       cdmp_20080507014938       cdmp_20080507052210
cdmp_20080506183321       cdmp_20080506221717       cdmp_20080507015137       cdmp_20080507052318
cdmp_20080506183430       cdmp_20080506221828       cdmp_20080507015241       cdmp_20080507052427
cdmp_20080506183539       cdmp_20080506221939       cdmp_20080507015347       cdmp_20080507052535
cdmp_20080506183647       cdmp_20080506222050       cdmp_20080507015552       cdmp_20080507052642
cdmp_20080506183756       cdmp_20080506222201       cdmp_20080507015658       cdmp_20080507052750
cdmp_20080506183905       cdmp_20080506222314       cdmp_20080507015901       cdmp_20080507052856
cdmp_20080506184017       cdmp_20080506222424       cdmp_20080507020006       cdmp_20080507053003
cdmp_20080506184126       cdmp_20080506222535       cdmp_20080507020112       cdmp_20080507053110
cdmp_20080506184233       cdmp_20080506222644       cdmp_20080507020219       cdmp_20080507053218
cdmp_20080506184341       cdmp_20080506222754       cdmp_20080507020423       cdmp_20080507053325

 

我cancel掉alter index index_name shrink space的语句后,alter table shrink space操作完成,再次alter index shrink space也很快完成,由于会调整rowid,index也会改变,table就等待shrink lock,导致长时间等待

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

转载于:http://blog.itpub.net/175005/viewspace-261623/

<think>好的,用户问的是Oracle中如何收缩含有大字段(LOB)的表,也就是使用SHRINK命令处理有大字段的表。首先,我得回忆一下Oracle的SHRINK SPACE操作。记得这个命令是用来回收碎片和释放未使用空间的,但LOB字段的处理可能和普通表不同。 首先,要确认用户是否了解SHRINK的基本使用,比如普通表的收缩步骤。可能需要先介绍常规操作,再讲LOB的特殊情况。因为LOB数据通常存储在单独的段中,可能使用ASSM(自动段空间管理),所以收缩时可能需要分开处理。 接下来,考虑用户可能的场景:他们的表有大量LOB数据,导致表空间占用过大,想要通过收缩来释放空间。但LOB字段可能无法像普通数据那样轻易移动,需要特定的方法,比如开启ROW MOVEMENT,或者单独处理LOB段。 然后,需要检查Oracle的版本是否支持LOB段的收缩。可能从10g或11g开始支持?需要确认具体的版本要求。另外,ALTER TABLE SHRINK SPACE CASCADE是否会自动处理LOB段,或者是否需要单独对LOB列进行操作。 还可能需要注意,收缩操作需要表支持行移动,并且可能引起索引的重建,这会导致锁表,影响业务。所以需要提醒用户在维护窗口操作,并做好备份。 另外,要提到DBA_LOBS视图,用来查询LOB字段所在的表空间和段信息,帮助用户确认LOB的存储位置。可能还需要使用DBMS_REDEFINITION在线重定义表,如果直接收缩不可行的话。 用户可能遇到的问题包括:收缩后空间未释放,可能是因为LOB数据未被有效处理,或者HWM(高水位线)未调整。需要解释HWM的概念,以及如何通过MOVE或SHRINK来降低HWM。 最后,整理步骤:先开启行移动,收缩表级,再处理LOB段,可能需要CASCADE参数,或者单独执行ALTER TABLE MODIFY LOB (...) (SHRINK SPACE)。还要提醒空间是否返回给表空间,取决于存储参数和是否启用了自动扩展。 需要确保回答结构清晰,分步骤说明,注意事项和可能的问题,帮助用户全面理解操作过程和潜在风险。</think>在Oracle数据库中,对大字段(LOB)表进行空间收缩需要特殊处理。以下是分步骤说明: ### 1. 收缩前的准备工作 - **开启行移动**(Row Movement): ```sql ALTER TABLE 表名 ENABLE ROW MOVEMENT; ``` 这是SHRINK操作的前提条件,允许Oracle物理重组行位置。 - **确认LOB存储类型**: ```sql SELECT table_name, column_name, tablespace_name, segment_name FROM dba_lobs WHERE table_name = '表名'; ``` 确认LOB字段是否存储在独立段(BASICFILE/SECUREFILE)中。 ### 2. 普通表收缩(非LOB字段) ```sql ALTER TABLE 表名 SHRINK SPACE COMPACT; -- 仅碎片整理 ALTER TABLE 表名 SHRINK SPACE; -- 释放空间并重置HWM ``` ### 3. LOB字段的特殊处理 - **方法1:级联收缩**(CASCADE) ```sql ALTER TABLE 表名 SHRINK SPACE CASCADE; ``` 该命令会级联收缩: - 表段(TABLE) - 索引段(INDEX) - LOB段(LOBSEGMENT) - LOB索引段(LOBINDEX) - **方法2:单独收缩LOB列** ```sql ALTER TABLE 表名 MODIFY LOB(LOB字段名) (SHRINK SPACE); ``` ### 4. 验证收缩效果 ```sql SELECT segment_name, bytes/1024/1024 MB FROM dba_segments WHERE segment_name IN ('表名', 'LOB段名'); ``` ### 注意事项 1. **版本兼容性**: - 需要Oracle 11g及以上版本才支持LOB字段的SHRINK操作 - SECUREFILE类型LOB支持更高效的压缩 2. **锁机制**: - 操作期间会获取表级排他锁(TM) - 建议在维护窗口操作 3. **空间回收限制**: - 无法回收已分配给表空间的未使用空间(需配合数据文件resize操作) - LOB字段的碎片化空间可能无法完全回收 4. **性能影响**: - 会产生大量重做日志(建议开启NOLOGGING模式) - 可能触发全表扫描和行迁移 ### 替代方案 对于超大型LOB表,推荐使用: ```sql ALTER TABLE 表名 MOVE TABLESPACE 新表空间 LOB(字段名) STORE AS (TABLESPACE LOB表空间); ``` 通过物理迁移重组存储结构,更彻底地回收空间。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值