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

本文介绍了解决Oracle RAC环境中,一个节点重启后无法启动实例的问题。通过检查和手动挂载磁盘组DG1和RCY1,最终成功启动实例。

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

深蓝的blog:http://blog.youkuaiyun.com/huangyanlong/article/details/41480075

 

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

实验案例:

实验环境:CentOS 6.4、Oracle 11.2.0.1

现象重演:
1. 重启第二节点服务器
2. 手工启动第二节点实例,报错
[root@node2 ~]# su - oracle
[oracle@node2 ~]$ 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用户下,查看磁盘组状态
[root@node2 ~]# su - grid
[grid@node2 ~]$ 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的实例
[root@node2 ~]# su - oracle
[oracle@node2 ~]$ 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.youkuaiyun.com/huangyanlong/article/details/41480075

 

转载于:https://www.cnblogs.com/andy6/p/6063779.html

<think>我们正在处理一个Oracle11gRAC备库第二节点启动时出现ORA-01017错误的问题。这个错误通常表示无效的用户名或密码。在RAC环境中,备库的启动可能会涉及到集群资源的管理以及各节点间的协调。以下是针对此问题的详细排查步骤:###1.**检查密码文件**-在RAC环境中,每个节点都应该有一个密码文件,且必须相同。确保两个节点上的密码文件(通常位于`$ORACLE_HOME/dbs`目录下)都存在且内容一致。-检查密码文件的权限和属主。通常,密码文件应该由oracle用户和dba组拥有,权限为640。例如:```bash$ls-l$ORACLE_HOME/dbs/orapw<ORACLE_SID>```如果节点2的密码文件丢失或不同,从节点1复制一份到节点2。###2.**验证环境变量**-确保在启动实例时,节点2的环境变量设置正确,特别是`ORACLE_SID`和`ORACLE_HOME`。在RAC环境中,备库的实例名可能与主库不同,需要确认是否正确设置。-检查节点2的`.bash_profile`或相关shell配置文件,确保没有错误的覆盖。###3.**检查监听器和tnsnames.ora配置**-确保备库两个节点的监听器都正常运行,并且`tnsnames.ora`文件中配置的服务名正确指向备库实例。-使用`tnsping`测试从节点2连接到备库实例的服务名,确保网络连接正常。###4.**检查集群资源状态**-使用crsctl检查备库资源的状态:```bash$crsctlstatres-t```确认备库资源(通常以`ora.<db_name>.<instance_name>.inst`形式命名)在节点2上的状态是ONLINE。如果资源离线,尝试启动它:```bash$srvctlstartinstance-d<db_unique_name>-i<instance_name>```如果启动失败,查看相关日志。###5.**检查告警日志**-查看节点2的备库实例的告警日志,通常在`$ORACLE_BASE/diag/rdbms/<db_name>/<instance_name>/trace/alert_<instance_name>.log`。在日志中搜索ORA-01017,可能会提供更具体的错误原因。###6.**尝试手动启动**-尝试在节点2上手动启动备库实例:```sql$sqlplus/assysdbaSQL>startupnomount;```如果手动启动也出现ORA-01017,则问题很可能出在密码文件或权限上。###7.**重建密码文件**-如果以上步骤无效,可以尝试重建节点2的密码文件:```bash$orapwdfile=$ORACLE_HOME/dbs/orapw<ORACLE_SID>password=<sys_password>entries=10```注意:确保使用正确的SID和密码。###8.**检查RAC相关参数**-在RAC环境中,还需要检查一些集群参数是否设置正确,例如`cluster_database`参数应该设置为`TRUE`(在备库上通常也是TRUE,因为它是RAC)。```sqlSQL>showparametercluster_database;```###9.**检查数据库链路和DG配置**-如果备库是通过主库的DG配置创建的,检查主备库之间的数据库链路是否使用正确的认证方式。在RAC环境中,确保两个节点都能与主库通信。###10.**MOS文档参考**-参考Oracle官方文档:ORA-01017DuringStartupofStandbyDatabase(DocID785878.1)。该文档提到在备库启动时,如果密码文件丢失或损坏,或者使用了不正确的SYS密码,会导致此错误。###总结ORA-01017错误在备库启动时通常与密码文件问题相关。在RAC环境中,需要确保所有节点的密码文件一致且可用。按照上述步骤逐一排查,特别是密码文件和环境变量部分。§§相关问题§§1.OracleRAC环境中如何同步密码文件?2.除了密码文件,还有哪些原因可能导致ORA-01017错误?3.在OracleDataGuard中,如何诊断备库启动失败问题?4.如何验证Oracle数据库密码文件的有效性?</think>### Oracle 11g RAC备库第二节点启动ORA-01017错误排查指南 #### 1. **密码文件问题(首要检查项)** - **检查密码文件存在性** 确认节点2的`$ORACLE_HOME/dbs`目录下存在密码文件(如`orapw<ORACLE_SID>`)。若缺失,需从节点1复制并重命名: ```bash # 从节点1复制到节点2 scp node1:$ORACLE_HOME/dbs/orapw<primary_SID> $ORACLE_HOME/dbs/orapw<standby_SID> ``` > **注意**:RAC环境中密码文件必须**每个节点独立存在**且与实例SID匹配[^1]。 - **验证密码文件权限** 权限应为640(属主oracle,组dba): ```bash ls -l $ORACLE_HOME/dbs/orapw* # 正确示例:-rw-r-----. 1 oracle dba 1536 Jun 10 14:00 orapwstdb2 ``` 若权限错误,执行:`chmod 640 orapw<standby_SID>` - **重建密码文件(必要时)** 使用`orapwd`重建: ```bash orapwd file=$ORACLE_HOME/dbs/orapw<standby_SID> password=<sys_password> entries=10 ``` #### 2. **环境变量与实例配置** - **检查节点2的ORACLE_SID** 确认环境变量设置正确: ```bash echo $ORACLE_SID # 应返回备库节点2的SID(如stdb2) ``` 错误的SID会导致连接时用户名/密码不匹配。 - **验证监听配置** 在节点2执行: ```bash lsnrctl status ``` 确认监听器注册了备库实例,且`tnsnames.ora`中服务名配置正确(如`STDB2 = (ADDRESS=(PROTOCOL=TCP)(HOST=node2-vip)(PORT=1521))`)。 #### 3. **Data Guard Broker配置(如启用)** - **检查Broker状态** 若使用DG Broker,节点间配置需一致: ```sql DGMGRL> SHOW CONFIGURATION; ``` 修复不一致项: ```sql DGMGRL> EDIT CONFIGURATION SET PROPERTY StaticConnectIdentifier='node2:stdb2'; ``` #### 4. **集群资源验证** - **检查CRS资源状态** 在节点2执行: ```bash crsctl stat res -t -w "NAME co ora.stdby.db" # 替换stdby为实际资源名 ``` 若资源离线,尝试启动: ```bash srvctl start instance -d <standby_db_name> -i <node2_instance_name> ``` #### 5. **深入诊断步骤** - **查看告警日志** 定位节点2的告警日志: ```bash cd $ADR_BASE/diag/rdbms/<standby_db_name>/<node2_sid>/trace tail -f alert_<node2_sid>.log ``` 搜索ORA-01017相关上下文,常见附加错误: - `ORA-19909: Data Guard broker configuration mismatch` - `ORA-12547: TNS:lost contact`(权限问题) - **测试本地连接** 在节点2尝试直接连接: ```bash sqlplus sys/<password>@node2_vip/stdb2 as sysdba ``` 若失败,验证TNS: ```bash tnsping node2_vip/stdb2 ``` #### 6. **解决方案总结 | 故障原因 | 解决措施 | |-------------------------|------------------------------------------| | 密码文件缺失/权限错误 | 复制重建+权限修复 | | ORACLE_SID配置错误 | 修正`.bash_profile`或`/etc/oratab` | | Broker配置不一致 | `DGMGRL`中重置静态连接标识符 | | 监听未注册实例 | 重启监听或验证`listener.ora` | | 集群资源状态异常 | `srvctl`启动实例或`crsctl`修改资源配置 | > **关键提示**:在RAC环境中,节点间配置的**一致性**是避免ORA-01017的核心[^2]。完成修复后,建议重启节点2的集群服务: > ```bash > crsctl stop res ora.stdby.db -f > crsctl start res ora.stdby.db > ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值