记一次高水位引发的ORA-01555错误的处理过程

                                                                  --2024/04/19

--1 收到提单故障，

附件Q.webp信息

--2 寻找故障，

快照太老，通常是SELECT语句引发，该故障发生时，会被记录在数据库的告警日志里，因此，需要联系上客户，拿到数据库的告警日志来查找，，，

根据提单日期，在告警日志文件里，寻找该时间点附近的出现ORA-01555错误的信息，

问了下提单人，确认是该时间点遇上的故障，也就是，就是此DELETE 语句，引发了提单中ORA-01555错误，

--3 分析故障，

   查了下该表，有60多万的记录，但尺寸却达314738兆，初步怀疑高水位问题引起？

但是，该表里有3个NCLOB字段，若这些字段存在坏行时，也会引发ORA-01555错误，

--4 检查故障，

   为避免是这些字段引起的ORA-01555错误，需要跑一段脚本来查询该表的这几个字段，是否存在坏行：

经检查，这3个字段的数据都正常（ corrupt_lobs 表里没数据）。

4.2 此外，又检查这3个大字段对应段的尺寸：发现这些字段基本不占空间，

至此，可以确定是表的高水位引起的ORA-01555错误，

--5 修复故障，

   5.1、要降低其高水位，需要消除表的数据段里的空闲块（磁盘碎片），有两种办法：

5.1.1、使用 MOVE 操作，把表的数据，迁移到其他磁盘的其他位置；数据迁移结束后，原来的数据段将被删除。此举的风险是：MOVE 开始前，ORACLE将对表附加上排它锁；MOVE 期间，无法对其做增删改操作；MOVE结束后，还需要重建其失效索引；因为表的尺寸较大，全表扫描将比较耗时，很可能会引起长时间的锁堵塞，因此，此方法不合适上班时间使用。

5.1.2、使用在线重定义的方法，将数据复制到新表中，复制期间，不影响原始表的QDML操作，只有在交换两表名时（原表名给新表使用，新表名给原表使用），才会临时锁表，此耗时较短，对业务影响较小，故，选择在线重定义的方法。

   5.2、但使用重定义的方法，复制数据时，也出现了意外：也报了ORA-01555错误，证实了客户的故障场景，确实是因为该表的高水位引起，

   5.3、思考了一下，判断复制过程，也就是INSERT INTO SELECT * ，，，操作，语句执行了24分钟，耗时太久引起，此时，需要缩短查询耗时，为此，考虑使用并行，加快此操作，

5.4、情况如上面的预判，把源表的并行度改成4后，再次COPY数据，3分21秒完成，

--6、检查重定义后的数据指标:

    6.1、重定义后源表和新表的数据量：

   6.2、重定义前后，源表和新表的尺寸：

   6.3、节省出来的磁盘空间：

--7、复盘故障原因及应对举措。

从6.1步骤的截图可以看出，原表是2017年创建，由于长期的DML操作，表的高水位逐渐被推高，即便没多少数据，也占用了大量的磁盘空间，导致了此次的故障；对此，需要定期降低其高水位：可以编写脚本：MOVE该表的数据，然后重建失效索引；并配置成定时作业，放在下班后空闲时段执行。