ORA-15149: another ASM instance found running on the host

本文记录了一次Oracle Automatic Storage Management (ASM) 实例启动失败的问题排查过程。问题表现为尽管ASM实例已在运行,但尝试通过SQL*Plus连接时却提示连接到了空闲实例。最终发现是由于环境变量ORACLE_SID的大小写设置错误导致。

问题现象

[grid@localhost ~]$ echo $ORACLE_SID
+asm
[grid@localhost ~]$ echo $ORACLE_HOME
/u01/app/11.2.0/grid
[grid@localhost ~]$ sqlplus / as sysasm

SQL*Plus: Release 11.2.0.1.0 Production on Fri Oct 18 22:35:03 2013

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> startup
ORA-15149: another ASM instance found running on the host
SQL>

问题分析

已存在一个运行的 ASM 实例,为什么还会提示连接到空闲实例?

查看进程:

[grid@localhost ~]$ ps -ef | grep asm_ | grep -v grep
grid      2009     1  0 21:44 ?        00:00:00 asm_pmon_+ASM
grid      2011     1  0 21:44 ?        00:00:07 asm_vktm_+ASM
grid      2015     1  0 21:44 ?        00:00:00 asm_gen0_+ASM
grid      2017     1  0 21:44 ?        00:00:00 asm_diag_+ASM
grid      2019     1  0 21:44 ?        00:00:00 asm_psp0_+ASM
grid      2021     1  0 21:44 ?        00:00:00 asm_dia0_+ASM
grid      2023     1  0 21:44 ?        00:00:00 asm_mman_+ASM
grid      2025     1  0 21:44 ?        00:00:00 asm_dbw0_+ASM
grid      2027     1  0 21:44 ?        00:00:00 asm_lgwr_+ASM
grid      2029     1  0 21:44 ?        00:00:00 asm_ckpt_+ASM
grid      2031     1  0 21:44 ?        00:00:00 asm_smon_+ASM
grid      2033     1  0 21:44 ?        00:00:00 asm_rbal_+ASM
grid      2035     1  0 21:44 ?        00:00:00 asm_gmon_+ASM
grid      2037     1  0 21:44 ?        00:00:00 asm_mmon_+ASM
grid      2039     1  0 21:44 ?        00:00:00 asm_mmnl_+ASM
grid      2069     1  0 21:45 ?        00:00:00 asm_asmb_+ASM
[grid@localhost ~]$
进程已全部启动,那是为什么呢?

[grid@localhost ~]$ echo $ORACLE_SID
+asm
[grid@localhost ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Fri Oct 18 23:47:27 2013

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> exit
Disconnected
[grid@localhost ~]$ export ORACLE_SID=+ASM
[grid@localhost ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Fri Oct 18 23:47:41 2013

Copyright (c) 1982, 2009, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Automatic Storage Management option

SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Automatic Storage Management option
[grid@localhost ~]$
找出问题的原因了:ORACLE_SID 写错了,应该是 +ASM 而不是 +asm,大小写敏感。

问题解决

编辑 grid 用户的 .bash_profile 文件

[grid@localhost ~]$ vi /home/grid/.bash_profile

export ORACLE_SID=+asm --> 修改为 +ASM

<think>首先,用户的问题是关于Oracle数据库错误ORA-27091和ORA-15078的解决方案。这些错误涉及ASM(Automatic Storage Management)磁盘组的问题,具体是I/O队列无法排队导致磁盘组强制卸载。 从系统级指令中,我需要: - 所有行内数学表达式用$...$格式。 - 独立公式用$$...$$格式并单独成段。 - LaTeX语法正确。 - 使用中文回答。 - 生成相关问题。 - 在回答中引用的段落末尾添加引用标识,如[^1]。 用户提供的引用包括: - [^1]: ASM错误堆栈,提到ORA-27091和ORA-15078。 - [^2]: ASM PST心跳延迟导致磁盘组卸载。 - [^3]: 进程发起磁盘离线。 - [^4]: Oracle 11g bug的恢复步骤,包括挂载磁盘组。 用户意图是解决这些错误。我需要基于这些引用和一般知识提供解决方案。 结构化回答: 1. **理解错误**:解释ORA-27091和ORA-15078的含义。 2. **原因分析**:基于引用,可能的原因包括ASM PST心跳延迟、I/O问题或bug。 3. **解决方案**:提供步骤来解决问题,如引用[^4]中的mount操作,以及其他可能的方法。 4. **预防措施**:建议如何避免类似问题。 5. **相关问题**:生成相关问题。 确保回答真实可靠,基于Oracle文档和常见实践。 关键点: - ORA-27091: unable to queue I/O – 通常与I/O子系统问题相关。 - ORA-15078: ASM diskgroup forcibly dismounted – 磁盘组被强制卸载。 - 引用[^2]提到心跳延迟导致卸载。 - 引用[^4]提供恢复步骤:挂载磁盘组。 解决方案步骤: 1. 检查ASM和数据库日志。 2. 验证磁盘组状态。 3. 尝试挂载磁盘组(如引用[^4])。 4. 检查I/O子系统(如存储、网络)。 5. 应用补丁(如果是bug)。 生成相关问题: 1. 如何诊断ASM磁盘组问题? 2. ORA-27091的常见原因有哪些? 3. 如何优化ASM性能以避免I/O问题? 回答用中文。</think>### ORA-27091 unable to queue I/O 和 ORA-15078 ASM diskgroup forcibly dismounted 解决方案 这些错误通常发生在Oracle ASM(Automatic Storage Management)环境中,涉及磁盘组的I/O操作失败和强制卸载。基于您提供的引用和Oracle最佳实践,我将逐步解释错误原因并提供解决方案。关键问题包括:ORA-27091(I/O队列无法排队)和ORA-15078(ASM磁盘组被强制卸载),可能与ASM PST心跳延迟、存储子系统问题或Oracle bug相关[^1][^2]。 #### 1. **错误原因分析** - **ORA-27091**:表示ASM无法将I/O请求排队到磁盘,通常由存储层问题(如HBA卡、SAN网络或磁盘I/O瓶颈)或ASM内部资源争用引起。例如,ASM PST心跳延迟(默认15秒)可能导致磁盘组在正常或高冗余模式下被强制卸载[^2]。 - **ORA-15078**:表示ASM磁盘组被意外强制卸载,可能由于I/O超时、磁盘故障或Oracle bug(如引用中提到的Oracle 11g bug)[^1][^4]。 - 常见触发场景: - 存储性能问题(I/O延迟或带宽不足)。 - ASM磁盘心跳超时(外部冗余磁盘组可能忽略此问题)[^2]。 - 特定Oracle版本bug(如11g,需应用补丁)[^4]。 - 进程如`_dbw0_`发起磁盘离线操作[^3]。 #### 2. **解决方案步骤** 以下步骤基于引用内容和Oracle官方文档。**操作前务必备份ASM和数据库,并在维护窗口执行**。使用`grid`用户或`sysasm`权限操作。 ##### 步骤1: 检查ASM和数据库日志 - 查看ASM alert日志(位于`$ORACLE_BASE/diag/asm/+asm/+ASM/trace/alert_+ASM.log`),定位错误详情: ```bash tail -f alert_+ASM.log | grep -E 'ORA-27091|ORA-15078' ``` - 确认是否有类似引用[^3]的进程离线磁盘消息(如`process _dbw0_+asm1 initiating offline of disk`)。 - 检查数据库日志,排除应用层问题。 ##### 步骤2: 验证磁盘组状态并尝试挂载 - 使用`sqlplus`连接ASM实例: ```bash su - grid sqlplus / as sysasm ``` - 查询磁盘组状态: ```sql SELECT name, state FROM v$asm_diskgroup; ``` - 如果状态为`DISMOUNTED`,尝试挂载(如引用[^4]的恢复操作): ```sql ALTER DISKGROUP <diskgroup_name> MOUNT; -- 例如:ALTER DISKGROUP OCRVDISK MOUNT; ``` - 如果挂载失败,检查磁盘路径和权限: ```sql SELECT path, mount_status FROM v$asm_disk; ``` ##### 步骤3: 处理I/O和存储问题 - **检查存储子系统**: - 使用OS工具(如`iostat`或`sar`)监控I/O负载:$iostat -x 5$(每5秒采样)。 - 验证SAN/HBA配置:确保无链路故障或带宽瓶颈。 - 测试磁盘I/O性能:使用`dd`命令测试读写速度。 - **调整ASM参数**(临时缓解): - 增加ASM PST心跳超时时间(需谨慎,默认15秒): ```sql ALTER SYSTEM SET "_asm_heartbeat_timeout"=20 SCOPE=SPFILE; -- 单位:秒 ``` - 重启ASM实例生效。 - 减少I/O队列争用:优化`asm_power_limit`参数。 ##### 步骤4: 应用补丁和长期修复 - **针对Oracle bug**:如引用[^4]提到的11g bug,需应用最新补丁集: - 下载Oracle补丁(参考MOS文档ID 1488997.1)。 - 执行Opatch更新。 - **重建磁盘组**(如果挂载失败): - 卸载磁盘组:`ALTER DISKGROUP <diskgroup_name> DISMOUNT;` - 使用`asmcmd`强制删除并重建(确保有备份): ```bash asmcmd dropdg -r <diskgroup_name> asmcmd mkdg <diskgroup_config_file> ``` ##### 步骤5: 监控和预防 - 启用ASM监控:使用`asmcmd lsdsk --statistics`查看磁盘健康。 - 定期检查存储:确保冗余配置正常(高冗余磁盘组更易受心跳延迟影响)[^2]。 - 优化数据库:减少大型I/O操作,如分批处理事务。 #### 3. **关键注意事项** - **风险**:强制挂载可能导致数据不一致,建议先使用`RMAN`验证备份。 - **性能公式**:ASM I/O队列性能可建模为排队系统,其中平均等待时间$W_q$与到达率$\lambda$和服务率$\mu$相关:$$W_q = \frac{\lambda}{\mu(\mu - \lambda)}$$,优化$\mu$(服务率)可减少ORA-27091[^1]。 - **引用依据**:解决方案综合了引用中的恢复操作(如挂载磁盘组)[^4]、心跳延迟分析[^2],以及进程离线事件处理[^3]。 如果问题持续,收集AWR报告或联系Oracle支持,提供完整错误堆栈。 ### 相关问题 1. 如何诊断ASM磁盘组心跳超时问题? 2. ORA-27091错误有哪些常见存储层原因? 3. 在Oracle 11g中,如何预防ASM磁盘组强制卸载的bug?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值