ORA-01215报错咋整，CREATE CONTROLFILE后线程缺失导致数据库崩溃远程帮忙修复

ORA-01215报错咋整，CREATE CONTROLFILE后线程缺失导致数据库崩溃远程帮忙修复

（引用来源：墨天轮社区“ORA-01215: ???? CREATE CONTROLFILE ??????”用户讨论帖）

ORA-01215这个错误，简单来说就是数据库启动时，发现控制文件里记录的某个“线程”处于启用状态，但实际在数据库系统中这个线程又找不到了，导致数据库自己跟自己打架，启动失败，这种情况经常发生在一种特定操作之后，那就是你用了CREATE CONTROLFILE ... RESETLOGS这个命令来重建控制文件，但在重建过程中可能不小心漏掉了某个线程的配置，尤其是在RAC（多节点集群）环境下，或者你的数据库曾经是RAC后来改成单机了，但痕迹没处理干净。

想象一下控制文件就像是数据库的“总目录”或者“大脑”，它记录着所有数据文件、日志文件的位置和当前状态，而“线程”这个概念，在单机数据库里基本可以理解为就是一组日志文件，通常只有一个线程（线程1），但在RAC环境下，多个实例可以同时工作，每个实例都有自己的日志组，这些日志组就属于不同的线程（比如线程1给实例1用，线程2给实例2用）。

当你因为某种原因（比如所有控制文件都损坏了）不得不重建控制文件时，你需要根据数据库的结构手动写一个创建脚本，问题就出在这里：如果你曾经是RAC环境，或者配置文件里还残留着RAC的设置，但你现在是以单机方式运行，那么在重建控制文件的语句中，如果你没有明确指定NORESETLOGS或者错误地处理了线程信息，就可能埋下隐患。

（引用来源：Oracle官方支持文档“ORA-01215 during startup after recreate controlfile”故障说明）

具体到报错场景,通常是这样的：

1. 你的数据库可能之前是RAC,现在改成了单机，或者你的pfile（参数文件）里还留着cluster_database=true这样的参数。
2. 控制文件全部丢失或损坏,你迫不得已，按照网上或文档的指导，通过CREATE CONTROLFILE ... RESETLOGS命令重建了一个新的控制文件。
3. 重建命令可能类似于：CREATE CONTROLFILE REUSE DATABASE "ORCL" RESETLOGS ARCHIVELOG ...，注意这里的RESETLOGS，它会重置日志序列号，相当于让数据库从新的日志开始记录。
4. 命令执行成功,你很高兴，然后马上用ALTER DATABASE OPEN RESETLOGS;打开数据库，也成功了。
5. 但当你下次重启数据库时,噩梦来了，启动到mount阶段就卡住了，报警告日志里赫然写着ORA-01215: thread # string enabled in controlfile but no thread(s) available，意思是控制文件里说线程#X是启用的，但现实中根本找不到这个线程。

为什么会这样？因为在重建控制文件时，如果参数cluster_database被设置为TRUE，或者你重建时从旧的控制文件/参数文件中继承了一些隐含信息，新的控制文件可能会默认认为应该有多个线程（比如线程1和线程2），你用RESETLOGS方式打开数据库时，它可能只初始化了线程1的日志文件，但控制文件内部仍然“惦记”着那个不存在的线程2，并将其状态标记为“启用”，下次启动，系统检查一致性时，发现线程2“名存实亡”，就直接报错拦住了。

（引用来源：ITPUB论坛资深版主对于ORA-01215的根因分析及修复方案总结）

那咋整呢？远程帮忙修复的思路核心是：让控制文件里的线程状态和数据库实际的线程状态达成一致，既然现实是我们只有一个线程（线程1），那就去控制文件里把其他线程“禁用”掉，因为数据库现在还打不开，我们无法用正常的SQL命令去修改，所以需要让数据库进入一种特殊的“维修模式”——归档模式下的挂载状态，然后执行一条修改内部信息的命令。

以下是具体的修复步骤,远程协助时通常会指导用户一步步操作：

第一步：确保有备份，任何对数据库底层的重要操作之前，如果条件允许，一定要备份当前的数据文件和控制文件，虽然现在数据库挂了，但数据文件很可能是好的，备份是为了防止修复操作不当导致更坏的情况。

第二步：检查参数文件（pfile或spfile），这是非常关键的一步，你需要检查cluster_database这个参数的值，如果它是TRUE，必须把它改成FALSE，因为你现在是单机运行。

• 如果用的是pfile（文本文件），直接用文本编辑器打开init<SID>.ora，找到cluster_database=TRUE这一行，改成cluster_database=FALSE，然后保存。
• 如果用的是spfile（二进制文件），比较麻烦，因为数据库没起来，可以尝试用CREATE PFILE FROM SPFILE;命令（在nomount状态下可能可以）先导出一个pfile，修改后再用CREATE SPFILE FROM PFILE;重建spfile，或者更直接点，如果记得参数，可以直接CREATE SPFILE='...' FROM PFILE='...';指定路径来重建。

第三步：以非加载模式启动数据库，连接到sqlplus，以sysdba身份执行： STARTUP NOMOUNT; 这一步只启动实例，不加载控制文件和数据文件。

第四步：将数据库置于归档模式的挂载状态，这是修复的关键前提，执行： ALTER DATABASE MOUNT; 如果上一步参数文件修改正确，这一步应该能成功将数据库挂载起来，如果还报错，回头仔细检查cluster_database参数。

第五步：执行禁用缺失线程的命令，假设报错信息是线程2缺失，那么执行： ALTER DATABASE DISABLE THREAD 2; 这条命令的作用就是告诉控制文件：“别再惦记那个不存在的线程2了，把它标记为禁用状态。” 执行成功后，会提示“数据库已变更”。

第六步：正常打开数据库，由于之前是用RESETLOGS方式打开的，这次还需要用同样的方式： ALTER DATABASE OPEN RESETLOGS; 如果一切顺利，数据库就应该能正常打开了，你会看到提示“数据库已更改”。

第七步：立即进行全库备份！因为RESETLOGS操作创建了一个新的数据库化身（incarnation），之前的备份对于这个新化身可能已经无效，必须立即做一个全新的完整备份，以确保你的恢复链条是连续的。

远程修复过程中,指导方会非常关注告警日志（alert_.log）的实时输出，每一步操作后都要检查告警日志是否有新的错误信息，整个过程需要操作者非常细心，敲命令时不能有错别字，如果对Oracle内部命令不熟悉，这种操作风险很高，这也就是为什么通常需要“远程帮忙”的原因，修复成功后，还需要提醒用户彻底检查一下数据库为何会走到需要重建控制文件这一步，避免根本问题再次发生。