数据库表空间告警,用下面的语句检查发现有几张表占用的空间比较大。
但实际这几张表的数据量并不多,所以准备用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数据的实时性要求不是很好,否则这次就闯大祸了。看来生产环境的任何操作都要小心啊。