ORA-19955报错导致数据库ID修改受限，远程协助解决故障全过程分享

ORA-19955报错导致数据库ID修改受限，远程协助解决故障全过程分享 来源：根据某金融公司DBA的故障处理记录整理）

那天下午，我正准备下班，突然接到一个紧急电话，是另一个城市的业务部门同事打来的，电话那头的声音非常焦急，说他们的一套重要测试数据库出了大问题，尝试修改数据库ID（DBID）时，系统弹出了一个从来没见过的错误“ORA-19955”，操作被完全卡住，后续的很多测试流程都无法进行，由于他们团队缺乏有经验的Oracle DBA,希望我能远程协助解决。

我立刻打开电脑，通过安全的VPN通道连接到了他们的跳板机，再登录到出问题的数据库服务器，我让同事复现一下操作和报错，他们使用的是nid（Change Database ID Utility）工具，命令刚执行不久，就清晰地看到了报错信息：ORA-19955: 无法标记回滚段为脱机，紧接着还有更详细的提示ORA-01545: 指定的回滚段不可用。

（来源：现场复现的Oracle错误日志）

看到这两个错误代码，我心里大致有了方向，ORA-01545是关键线索，它直接指向了回滚段（一种用于保证数据一致性的内部结构）的问题，而ORA-19955是nid工具在准备阶段遇到01545错误后抛出的上层报错,根本原因在于回滚段状态不正常。

我首先检查了数据库的当前状态和回滚段信息，输入命令select tablespace_name, segment_name, status from dba_rollback_segs;后，结果一目了然，我发现有几个非系统回滚段的状态是NEEDS RECOVERY（需要恢复），还有一个甚至是PARTLY AVAILABLE（部分可用），这显然不正常，正常情况下，在修改DBID之前，数据库应该处于一个干净、稳定的状态。

（来源：通过SQL*Plus查询dba_rollback_segs视图的结果）

问题根源找到了：这些处于异常状态的回滚段阻碍了nid工具的初始化流程，工具需要确保所有事务都已结束，所有回滚段都能被安全地处理，但这些“生病”的回滚段让它无法正常工作。

接下来的任务就是清理这些异常的回滚段，我向同事解释，我们需要先删除这些有问题的回滚段，因为它们在当前环境下很可能是之前某些未完成事务遗留下来的“僵尸”段,已经不再需要了。

删除回滚段是一个需要谨慎的操作,我让他先执行了以下步骤：

1. 创建一个新的回滚表空间，比如叫做UNDOTBS_NEW，作为备用,这是为了防止删除旧回滚段后系统没有可用的回滚空间。
2. 将数据库的默认回滚表空间切换到新创建的UNDOTBS_NEW，命令是：alter system set undo_tablespace=UNDOTBS_NEW;。
3. 等待一段时间，确认原来的旧回滚表空间（比如UNDOTBS1）中没有活动的事务，通过查询v$transaction视图可以确认。
4. 最关键的一步：逐个删除处于NEEDS RECOVERY和PARTLY AVAILABLE状态的用户回滚段，命令格式是：drop rollback segment "回滚段名称";，在执行这个命令时，其中一个回滚段删除时又报了一个小错误，提示无法删除活动事务中的回滚段，这说明还有极少数残余事务在占用它，我们通过查询找到并强制结束了相关会话后,最终成功将其删除。
5. 我们删除了空的旧回滚表空间UNDOTBS1,以释放资源。

（来源：处理过程中执行的系列SQL命令和系统操作）

清理工作完成后，我让同事再次尝试运行nid命令，这次，屏幕上没有再出现刺眼的ORA-19955错误，工具顺利地进入了下一个阶段，提示需要关闭并重新启动数据库到MOUNT状态以完成最终的DBID修改，我们按照提示，执行了shutdown immediate和startup mount，然后再次运行nid工具,指定了新的DBID。

整个过程非常顺利，屏幕上滚动着各项检查通过的提示，最后显示“数据库的ID已更改”，为了验证成功，我们重启数据库后，使用select dbid from v$database;查询，确认DBID已经变成了我们指定的新号码，业务同事在电话那头长舒了一口气,连连道谢。

（来源：成功修改DBID后对v$database的查询结果）

这次远程排障历时大约一个半小时，ORA-19955只是一个表面现象，其背后的ORA-01545才是真凶，根源在于回滚表空间的管理不善，遗留了异常的回滚段，解决思路并不复杂，就是清理这些“路障”，为nid工具创造一个干净的操作环境，这次经历也提醒我们，在进行任何重要的数据库变更前，一定要对数据库的整体健康状况进行一次全面的检查,防患于未然。