Oracle数据库启动失败：ORA-29701、ORA-01565、ORA-17503故障处理记录_20260429

数据库服务器重启后，Oracle Grid/HAS 未正常恢复，ASM 磁盘组未挂载，导致数据库未能自动启动。

一、故障背景

Oracle 服务器重启，数据库无法正常启动。登录服务器后，首先检查文件系统空间，发现磁盘空间正常，并没有出现根目录、Oracle 目录或备份目录空间满的情况。

df -h

结果显示 /oracle、/backup 等目录空间都比较充足，因此基本可以排除磁盘空间不足导致数据库无法启动的问题。

随后切换到 Oracle 用户，检查监听状态：

su - oracle
lsnrctl status

返回如下错误：

TNS-12541: TNS:no listener
TNS-12560: TNS:protocol adapter error
TNS-00511: No listener
Linux Error: 111: Connection refused

初看像是监听器没有启动，但继续检查数据库实例时，发现问题并不只是监听器。

执行：

sqlplus / as sysdba

连接后提示：

Connected to an idle instance.

说明数据库实例当前并未启动。

尝试启动数据库：

startup

结果报错：

ORA-01078: failure in processing system parameters
ORA-01565: error in identifying file '+SYSTEM/mesdb/spfilemesdb.ora'
ORA-17503: ksfdopn:2 Failed to open file +SYSTEM/mesdb/spfilemesdb.ora
ORA-29701: unable to connect to Cluster Synchronization Service

---

二、故障现象分析

这几个错误信息很关键。

1. ORA-01078

ORA-01078: failure in processing system parameters

表示数据库在读取启动参数时失败。

2. ORA-01565 和 ORA-17503

ORA-01565: error in identifying file '+SYSTEM/mesdb/spfilemesdb.ora'
ORA-17503: ksfdopn:2 Failed to open file +SYSTEM/mesdb/spfilemesdb.ora

说明数据库启动时需要读取 spfile 文件：

+SYSTEM/mesdb/spfilemesdb.ora

但是这个文件不是放在普通文件系统中，而是放在 ASM 磁盘组 +SYSTEM 里面。

也就是说，数据库启动前，ASM 必须先正常运行，并且 SYSTEM 磁盘组必须已经挂载。

3. ORA-29701

ORA-29701: unable to connect to Cluster Synchronization Service

这个错误才是关键。

它说明数据库无法连接到 CSS，也就是 Cluster Synchronization Service。

在使用 ASM 的环境中，CSS 是基础组件。CSS 没起来，ASM 就无法正常工作；ASM 没起来，磁盘组就无法挂载；磁盘组无法挂载，数据库自然无法读取放在 ASM 中的 spfile。

所以这次问题的真正链路是：

HAS / Grid Infrastructure 未正常启动
        ↓
CSSD 未正常运行
        ↓
ASM 未启动
        ↓
+SYSTEM 磁盘组未挂载
        ↓
数据库无法读取 spfile
        ↓
数据库启动失败

因此，最开始的 TNS:no listener 只是表象，不是根因。

真正的问题不是监听，也不是数据库文件损坏，而是 Grid / HAS / ASM 没有正常启动。

---

三、排查过程

首先查看相关进程：

ps -ef | egrep "ohasd|ocssd|crsd|evmd|asm_pmon|pmon|tnslsnr" | grep -v grep

最初只看到：

/bin/sh /etc/init.d/init.ohasd run

但没有看到以下关键进程：

ohasd.bin
ocssd.bin
asm_pmon_+ASM
tnslsnr
ora_pmon_mesdb

这说明 Oracle Restart / Grid 相关组件并没有正常起来。

继续查看 Grid Home：

cat /etc/oracle/olr.loc

返回：

olrconfig_loc=/oracle/app/11.2.0/grid/cdata/localhost/rezha174.olr
crs_home=/oracle/app/11.2.0/grid

由此确认 Grid Home 为：

/oracle/app/11.2.0/grid

检查 HAS 状态：

/oracle/app/11.2.0/grid/bin/crsctl check has

返回：

CRS-4639: Could not contact Oracle High Availability Services

说明 HAS 没有正常启动。

---

四、故障处理过程[重点]

使用 root 用户启动 HAS：

/oracle/app/11.2.0/grid/bin/crsctl start has

启动后再次检查：

/oracle/app/11.2.0/grid/bin/crsctl check has

返回：

CRS-4638: Oracle High Availability Services is online

说明 HAS 已经恢复正常。

继续检查资源状态：

/oracle/app/11.2.0/grid/bin/crsctl stat res -t

刚开始看到 ASM 还处于启动过程中：

ora.asm    ONLINE  OFFLINE  Instance Shutdown, STARTING

此时说明 HAS 和 CSSD 已经起来，但 ASM 还没有完全启动成功，数据库仍然不能启动。

随后继续观察，ASM 进程已经出现：

ps -ef | egrep "asm_pmon|asm_smon|asm_lgwr|ohasd|ocssd|evmd|tnslsnr" | grep -v grep

可以看到：

asm_pmon_+ASM
asm_lgwr_+ASM
asm_smon_+ASM

说明 ASM 已经正常启动。

最终再次查看资源状态：

/oracle/app/11.2.0/grid/bin/crsctl stat res -t

状态恢复正常：

ora.DATA.dg       ONLINE  ONLINE
ora.DGGRID01.dg   ONLINE  ONLINE
ora.LISTENER.lsnr ONLINE  ONLINE
ora.RECOVERY.dg   ONLINE  ONLINE
ora.SYSTEM.dg     ONLINE  ONLINE
ora.asm           ONLINE  ONLINE  Started
ora.cssd          ONLINE  ONLINE
ora.evmd          ONLINE  ONLINE
ora.mesdb.db      ONLINE  ONLINE  Open

再使用 grid 用户检查 ASM 磁盘组：

su - grid
export ORACLE_HOME=/oracle/app/11.2.0/grid
export PATH=$ORACLE_HOME/bin:$PATH
asmcmd lsdg

结果显示所有磁盘组均已挂载：

DATA       MOUNTED
DGGRID01   MOUNTED
RECOVERY   MOUNTED
SYSTEM     MOUNTED

其中 SYSTEM 磁盘组已经挂载，数据库也就可以读取：

+SYSTEM/mesdb/spfilemesdb.ora

最终数据库资源显示：

ora.mesdb.db ONLINE ONLINE Open

说明数据库已经正常打开。

---

五、为什么一开始无法启动数据库？

这次数据库一开始启动失败，根本原因是：

Oracle High Availability Services 没有正常启动，导致 CSSD、ASM 和 ASM 磁盘组都没有正常工作。

而数据库的 spfile 文件存放在 ASM 磁盘组中：

+SYSTEM/mesdb/spfilemesdb.ora

当 ASM 没起来时，数据库无法读取 spfile，所以执行 startup 就会报：

ORA-01078
ORA-01565
ORA-17503
ORA-29701

所以本次故障不是普通的数据库启动问题，也不是简单的监听器问题。

正确理解应该是：

监听没起来，是现象；
数据库 idle，是结果；
ASM 没起来，是直接原因；
HAS/CSSD 没起来，是根因。

---

六、正确恢复顺序

这类使用 ASM 的 Oracle 数据库，推荐按照下面顺序恢复。

1. root 用户启动 HAS

/oracle/app/11.2.0/grid/bin/crsctl start has

2. 检查 HAS 状态

/oracle/app/11.2.0/grid/bin/crsctl check has

3. 检查资源状态

/oracle/app/11.2.0/grid/bin/crsctl stat res -t

重点关注：

ora.cssd
ora.asm
ora.SYSTEM.dg
ora.DATA.dg
ora.LISTENER.lsnr
ora.mesdb.db

4. 如果数据库未自动启动，使用 srvctl 启动数据库

su - oracle
srvctl status database -d mesdb
srvctl start database -d mesdb
srvctl status database -d mesdb

5. 最后进入数据库验证

sqlplus / as sysdba

执行：

select instance_name,status from v$instance;
select name,open_mode,database_role from v$database;

---

七、经验总结

本次故障处理的关键点是：不要被监听器错误误导。

虽然一开始看到的是：

TNS-12541: TNS:no listener

但真正导致数据库启动失败的原因，是 Grid / HAS / ASM 没有正常起来。

对于使用 ASM 的 Oracle 数据库，启动顺序应该是：

HAS / Grid
    ↓
CSSD
    ↓
ASM
    ↓
ASM 磁盘组
    ↓
Listener
    ↓
Database

如果跳过前面的基础组件，直接进入数据库执行 startup，数据库就无法访问 ASM 里的 spfile、控制文件、数据文件等资源，自然会启动失败。

本次处理完成后，HAS、CSSD、ASM、磁盘组、监听和数据库均恢复正常，数据库状态为 Open。

---

八、最终结论

本次 Oracle 数据库无法启动的根因是：

Oracle High Availability Services 未正常运行，导致 CSSD、ASM 及 ASM 磁盘组未正常启动，数据库无法访问 ASM 中的 spfile 文件，从而启动失败。

处理方式是：

使用 root 用户启动 HAS，使 CSSD、ASM 和磁盘组恢复 online，随后数据库资源自动恢复 open。

核心恢复命令如下：

/oracle/app/11.2.0/grid/bin/crsctl start has
/oracle/app/11.2.0/grid/bin/crsctl check has
/oracle/app/11.2.0/grid/bin/crsctl stat res -t

如果数据库未自动启动，再执行：

su - oracle
srvctl start database -d mesdb

一句话总结：

这不是监听器单点故障，也不是数据库文件损坏，而是 Grid/ASM 基础组件没起来。先救 Grid，再救 ASM，最后数据库自然就能打开。