rac 11g_第二个节点重启后无法启动实例:磁盘组dismount问题

原创作品,出自 “深蓝的blog” 博客,欢迎转载,转载时请务必注明以下出处,否则追究版权法律责任。

深蓝的blog:http://blog.csdn.net/huangyanlong/article/details/41480075

rac第二个节点重启后无法启动实例:磁盘组dismount问题

实验案例:

实验环境:CentOS 6.4、Oracle 11.2.0.1

现象重演:
1. 重启第二节点服务器
2. 手工启动第二节点实例,报错
[[email protected] ~]# su - oracle
[[email protected] ~]$ sqlplus ‘/as sysdba‘

SQL*Plus: Release 11.2.0.1.0 Production on Sun Nov 23 15:11:04 2014

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

Connected to an idle instance.

启动数据库报错如下:
SQL> startup
ORA-01078: failure in processing system parameters
ORA-01565: error in identifying file ‘+DG1/xcky/spfilexcky.ora‘
ORA-17503: ksfdopn:2 Failed to open file +DG1/xcky/spfilexcky.ora
ORA-15056: additional error message
ORA-17503: ksfdopn:DGOpenFile05 Failed to open file +DG1/xcky/spfilexcky.ora
ORA-17503: ksfdopn:2 Failed to open file +DG1/xcky/spfilexcky.ora
ORA-15001: diskgroup "DG1" does not exist or is not mounted
ORA-06512: at line 4
根据上面的错误,锁定到ORA-15001错误,这是代表有磁盘组没有mount,于是按照这个思路进行查看。

3. grid用户下,查看磁盘组状态
[[email protected] ~]# su - grid
[[email protected] ~]$ sqlplus ‘/as sysdba‘

SQL*Plus: Release 11.2.0.1.0 Production on Sun Nov 23 15:27:04 2014

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 Real Application Clusters and Automatic Storage Management options

SQL> select name,state from v$asm_diskgroup;

NAME                           STATE
------------------------------ -----------
CRS                            MOUNTED
DG1                            DISMOUNTED
RCY1                           DISMOUNTED
可以发现,DG1、RCY1磁盘组处于dismounted状态,于是手工启动到mount状态,如下操作:

4. 启动磁盘组到mount状态
需要注意,对磁盘组操作时,需要使用sysasm用户,该用户有对磁盘组操作的权限,如下:
SQL> conn /as sysasm
Connected.

SQL> select name,state from v$asm_diskgroup;
NAME                           STATE
------------------------------ -----------
CRS                            MOUNTED
DG1                            DISMOUNTED
RCY1                           DISMOUNTED

SQL> alter diskgroup DG1 mount;
Diskgroup altered.

SQL> alter diskgroup RCY1 mount;
Diskgroup altered.

SQL> select name,state from v$asm_diskgroup;
NAME                           STATE
------------------------------ -----------
CRS                            MOUNTED
DG1                            MOUNTED
RCY1                           MOUNTED
至此,完成了将全部磁盘组启动到mount状态。

5. 再次启动节点2的实例
[[email protected] ~]# su - oracle
[[email protected] ~]$ sqlplus ‘/as sysdba‘

SQL*Plus: Release 11.2.0.1.0 Production on Sun Nov 23 15:31:11 2014

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

Connected to an idle instance.

SQL> startup
ORACLE instance started.

Total System Global Area  730714112 bytes
Fixed Size                  2216944 bytes
Variable Size             557845520 bytes
Database Buffers          167772160 bytes
Redo Buffers                2879488 bytes
Database mounted.
Database opened.
SQL>  select status,instance_name from gv$instance;
--查询整个集群环境,可以看到两个节点都已经启动了
STATUS       INSTANCE_NAME
------------ ----------------
OPEN         xcky2
OPEN         xcky1

至此,由于磁盘组处于dismount状态引起的单节点实例无法启动问题,解决。

原创作品,出自 “深蓝的blog” 博客,欢迎转载,转载时请务必注明以下出处,否则追究版权法律责任。

深蓝的blog:http://blog.csdn.net/huangyanlong/article/details/41480075

时间: 2024-10-12 14:39:56

rac 11g_第二个节点重启后无法启动实例:磁盘组dismount问题的相关文章

rac_第二个节点重启后无法启动实例:磁盘组dismount问题

原创作品,出自 "深蓝的blog" 博客,欢迎转载,转载时请务必注明以下出处,否则追究版权法律责任. 深蓝的blog:http://blog.csdn.net/huangyanlong/article/details/41480075 rac第二个节点重启后无法启动实例:磁盘组dismount问题 实验案例: 实验环境:CentOS 6.4.Oracle 11.2.0.1 现象重演: 1. 重启第二节点服务器 2. 手工启动第二节点实例,报错 [[email protected] ~]

RAC由于归档表空间满而无法启动实例的解决

今天想测试点东西,登录测试库:发现实例是关闭的: SQL> startupORACLE instance started. Total System Global Area 2722467840 bytesFixed Size                  2231472 bytesVariable Size            1476395856 bytesDatabase Buffers         1241513984 bytesRedo Buffers            

记一次因网卡心跳故障引发RAC节点重启故障分析

数据库与CRS版本:10.2.0.4 down机过程分析 序号 节点 时间 动作 日志源 1 二 Jul 4 22:48:15 XXdb2 kernel: NETDEV WATCHDOG: eth1: transmit timed out bnx2: fw sync timeout, reset code = 1020015 OS 2 二 Jul 4 22:48:29 -- Jul 4 22:49 CRS-1612:node XXdb1 (1) at 50% heartbeat fatal, e

ORACLE ASM diskgroup在主机重启后启动失败

环境:RHEL 6.4 + Oracle 11.2.0.3 + ASM单实例 1.重启主机后,+DATA diskgroup启动不成功,现象如下: [[email protected] ~]$ crsctl stat res -t -------------------------------------------------------------------------------- NAME TARGET STATE SERVER STATE_DETAILS --------------

11gR2 RAC重启后只能起单节点

11gR2 RAC重启后只能起单节点 问题背景: 将11gR2 RAC正常部署完成之后执行两节点重启操作发现其中有一个节点的集群资源无法启动,遂再次重启该无法启动集群资源的节点,还是不可.随即将正常节点重启发现原故障节点资源起来了,待重启完毕后原正常节点资源无法启动. 集群环境: OS:RedHat EnterPrise5.8 x86_x64 DB:Oracle EnterPrise Database 11.2.0.4.0 x86_x64 GRID:Oracle Grid Infrastruct

rac节点挂掉后,vip飘到别的节点,但是业务连接不上报 no listener问题处理

客户一套rac系统,三节点,其中一个节点的p260主机主板有问题(经常机器重启,好像是这个型号的通病,主板被炒到20W),临时把故障节点的vip作为业务地址用. 首先,查看确定故障节点vip飘到那个节点了: crsctl stat res -t ifconfig -a 接下来使用静态监听注册vip地址,来监听业务,添加,11.2 GI的LISTENER 监听器配置默认受到11.2新引入的endpoints_listener.ora配置文件的管理. 注意:使用 endpoints_listener

RAC一个节点的数据库无法启动:ORA-00600: internal error code, arguments: [4:kgstmLdiToMicroTs], [1], [], [], [], [

一个客户的RAC节点硬件发生了变动,主机重启后数据库实例无法启动,远程登陆查看ALERT日志发现大量报错: Writing to the above trace file is disabled for now on... Errors in file /oracle/app/diag/rdbms/XXXX/XXXX2/trace/XXXX2_ora_184464.trc: ORA-00600: internal error code, arguments: [4:kgstmLdiToMicro

ORACLE 11G RAC ASM磁盘组全部丢失后的恢复

一.环境描述(1)Oracle 11.2.0.3 RAC ON Oracle Linux 6 x86_64,只有一个ASM外部冗余磁盘组--DATA:(2)OCR,VOTEDISK,DATAFILE,CONTROLFILE,SPFILE全部位于这个磁盘组上:二.故障描述(1)存储故障导致ASM磁盘丢失.(2)CRS因为OCR和VOTEDISK的丢失,除了OHAS还联机外,CLUSTERWARE服务都已经停止.三.备份情况(1)RMAN备份:包括controlfile,database,spfil

orcle 11g rac crs状态正常,节点2数据库未启动

orcle 11g rac crs状态正常,节点2数据库未启动 安装完oracle11g R2 rac后,在节点1上查看数据库状态: [[email protected] ~]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on Wed May 17 18:56:34 2017 Copyright (c) 1982, 2013, Oracle.  All rights reserved. Connected to: Or