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 数据库，不建议一上来就直接执行：
startup更推荐按照下面顺序恢复。
1. root 用户启动 HAS
/oracle/app/11.2.0/grid/bin/crsctl start has2. 检查 HAS 状态
/oracle/app/11.2.0/grid/bin/crsctl check has3. 检查资源状态
/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.db4. 如果数据库未自动启动，使用 srvctl 启动数据库
su - oracle srvctl status database -d mesdb srvctl start database -d mesdb srvctl status database -d mesdb5. 最后进入数据库验证
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，最后数据库自然就能打开。