Dataguard 环境中做shrink带来的影响

数据库表空间告警，用下面的语句检查发现有几张表占用的空间比较大。
但实际这几张表的数据量并不多，所以准备用shrink来收缩一下。

SQL>SELECT SEGMENT_NAME, SEGMENT_TYPE, SUM(BYTES) / 1024 / 1024 MB
    FROM USER_SEGMENTS
    GROUP BY SEGMENT_NAME, SEGMENT_TYPE
   
--开启行迁移功能
alter table table_name enable row movement ;

-- 收缩表与相关索引 
alter table table_name shrink space cascade;

脚本写好后，在中午业务不忙的时候执行了shrink动作。

执行完shrink后，检查表空间使用率，发现表空间得到了释放。

但事情到此并没有结束，只是刚刚开始。

由于shrink是通过DML操作来降低HWM的，所以会产生大量redo。随之而来的还
有undo表空间的不断增大，归档日志不断增加，归档的切换频率增大。如果数
据库的undo足够用，归档空间足够用顶多会对性能带来点影响。还好中午的时
候没什么人用系统，undo，归档也都够用，也没有性能问题。

但是下午发现两个备库上的数据与生产的数据相差很多，检查数据同步情况。发
现由于shink操作，产生的大量的归档。导致主库与备库之间的数据同步有差异。
由于归档量比较大，网络也不是很给力，最终导致很多归档文件没能及时传递过
去。从而导致了Primary和Phyical Standby之间数据差异较大。还好这些归档日
志能自动的补传过去。

还好对standby数据的实时性要求不是很好，否则这次就闯大祸了。看来生产环境的任何操作都要小心啊。