记一次oracle crs无法重启事故

今天在修改了数据库参数后,关闭数据库及crs,然后重新启动了服务器,服务器启动完成之后,发现数据库无法启动,过程如下:

step1:重启数据库

$ su - grid
$ srvctl stop database -d {DB_NAME} 

$ su - root
# cd /grid/11.2.0/grid/bin
# ./crsctl stop crs  #所有节点执行

step2:重启服务器:

xxxdb1#[/root]reboot

等服务器重启完成,发现crs起不来:

xxxdb1$[/home/grid]crs_stat -t
CRS-0184: Cannot communicate with the CRS daemon.

根据以前的经验,服务器起来后5分钟左右,crs即可启动完成。然而等待了15分钟,依然无法启动。

step3:于是请求协助,通过手动启动crs,发现crs启动了。

su - root
# cd $ORACLE_HOME/bin
# ./crsctl start crs
CRS-4123: Oracle High Availability Services has been started.

经过大概4分钟的等待,数据库的资源起来了,这个过程较久,需要耐心等待

xxxdb1$[/home/grid]crsctl status res -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.ARC.dg
               ONLINE  ONLINE       xxxdb1
               ONLINE  ONLINE       xxxdb2
ora.DAT.dg
               ONLINE  ONLINE       xxxdb1
               ONLINE  ONLINE       xxxdb2
ora.INX.dg
               ONLINE  ONLINE       xxxdb1
               ONLINE  ONLINE       xxxdb2
ora.LISTENER.lsnr
               ONLINE  ONLINE       xxxdb1
               ONLINE  ONLINE       xxxdb2
ora.OCRVOTE.dg
               ONLINE  ONLINE       xxxdb1
               ONLINE  ONLINE       xxxdb2
ora.asm
               ONLINE  ONLINE       xxxdb1                   Started
               ONLINE  ONLINE       xxxdb2                   Started
ora.gsd
               OFFLINE OFFLINE      xxxdb1
               OFFLINE OFFLINE      xxxdb2
ora.net1.network
               ONLINE  ONLINE       xxxdb1
               ONLINE  ONLINE       xxxdb2
ora.ons
               ONLINE  ONLINE       xxxdb1
               ONLINE  ONLINE       xxxdb2
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
      1        ONLINE  ONLINE       xxxdb1
ora.cvu
      1        ONLINE  OFFLINE
ora.xxxdb.db
      1        ONLINE  ONLINE       xxxdb1                   shutdown immediate
      2        ONLINE  ONLINE       xxxdb2                   shutdown immediate
ora.xxxdb1.vip
      1        ONLINE  ONLINE       xxxdb1
ora.xxxdb2.vip
1        ONLINE  ONLINE       xxxdb2
ora.oc4j
      1        OFFLINE OFFLINE
ora.scan1.vip
      1        ONLINE  ONLINE       xxxdb1                              

step4:启动数据库实例

srvctl start instance -d {oracle_name} -i {instance_name}

到这里,数据库是起来了,为什么开机crs未启动的原因还没找到,经过查看crs自启动参数,发现自启动为不可用(disable)状态

xxxdb1#[/grid/11.2.0/grid/bin]./crsctl config has
CRS-4622: Oracle High Availability Services autostart is disabled.

将其改为enable:

xxxdb1#[/grid/11.2.0/grid/bin]./crsctl enable crs

再次查看:

xxxdb1#[/grid/11.2.0/grid/bin]./crsctl config crs
CRS-4622: Oracle High Availability Services autostart is enabled.

OK,crs无法自启动的问题解决完成。

原文地址:https://www.cnblogs.com/lijiaman/p/8443207.html

时间: 2024-10-04 02:42:54

记一次oracle crs无法重启事故的相关文章

记一次ORACLE无法启动登陆事故

打开XSHELL 登陆ORACLE用户 1.sqlplus scott/scott 提示登陆失败 2.sqplus / as sysdba 启动数据库提示 3.查找日志 操作日志:$ORACLE_HOME/startup.log 启动日志:$ORACLE_BASE/diag/rdbms/ora11g/ora11g/trace/alert_ora11g.log (ora11g为SID值) 启动日志如果查找不到,请到trace目录下执行 ls -alcr | grep alert (c时间排序.r倒

记一次Oracle Clusterware成功安装后的故障处理

记一次Oracle Clusterware安装成功后的故障处理 1. 环境 [[email protected] rac1]$ cat /etc/issue Red Hat Enterprise Linux Server release 5.8 (Tikanga) Kernel \r on an \m 2. 问题描述在安装RAC的过程中, 成功安装好grid (clusterware) 后关闭了各节点. 在下次开启各节点后, 检查crs资源状态, 出现如下错误: [[email protecte

Oracle CRS/GI 进程介绍

转自:http://blog.itpub.net/31444259/viewspace-2151582/ 在 10g和11.1,Oracle的集群称为CRS(Oracle Cluster Ready Service), 在11.2,Oracle的集群称为GI(Grid Infrastructure). 对于CRS/GI,他们的一些核心进程的功能基本类似,但是在11.2,新增了很多新的Deamon进程. 10.2 CRS:$ ps -ef|grep crs/binroot      4373  3

记一次Oracle冷备恢复的过程

一.故障来临 某日中午,市电意外中断,机房UPS电源由于负载过重而未接管供电,所有服务器全部重启...... 待所有服务器重启后,正在逐一检查设备和业务运行情况时,意外发生了.一台年代久远的HP PC Server无法启动了,主机工程师确认为主板故障,要命的是,这台服务器上运行着重要的业务数据库.要知道,对该数据库的备份仅仅是在每日凌晨用exp生成的dump文件而已 ...... 万幸的是,该数据库的所有文件都保存在阵列上,并且通过另外一台服务器可以访问到这些数据,这样就可以通过冷备份恢复的方式

Oracle断电后重启异常

这是我的第一篇博客~ 2017-06-23,我所在的项目现成由于机房断电,导致项目所在的一台数据库服务器挂掉了.早上重启后发现切换Oracle用户异常,显示这个界面 初步分析是:用户还在,但是挂载有问题. 于是开始调整挂载: vim /etc/mtab 增加/dev/sda3 /media/CRM ext4 rw 0 0 vim /etc/fstab 增加/dev/sda3 /media/CRM ext4 defaults 0 0 至于这两个挂载文件的作用和关系 ------一无所知      

VCS引起的oracle数据库异常重启一例

1. 环境描述 操作系统版本:SUSE Linux Enterprise Server 10 sp2 (x86_64) 数据库版本:Oracle 11.1.0.7.16 VCS版本:5.1 blog地址:http://blog.csdn.net/hw_libo/article/details/41171561 2. 问题现象及分析 凌晨3:46左右,手机短信收到数据库异常告警. (1)查看数据库alert日志 Sun Nov 16 03:46:51 2014 Stopping backgroun

oracle crs中监听资源状态异常(ora.LISTENER.lsnr)

一:版本信息 操作系统版本:AIX 61009 数据库版本:11.2.0.3.11(RAC) 二:错误描述 1) crsctl stat res -t命令查看crs资源状态的时候,发现"ora.LISTENER.lsnr"资源状态异常: ora.LISTENER.lsnr ONLINE OFFLINE ****1 ##实例1 ONLINE OFFLINE ****2 ##实例2 2)检查监听状态正常 lsnrctl LSNRCTL for IBM/AIX RISC System/600

记一次Oracle 10g数据恢复事件

事实证明,不作死就不会死,这次Oracle崩溃,花费了我两天的时间,只因为我装了些莫名的安卓模拟器之后又卸载了. 卸载之后,发现oracle数据库用不了了,心一凉,因为自己存了进两年的数据全在里面,近70个g.于是赶紧进Net Manager,进不去了,需要输入配置文件的路径!这绝对是ORAACLE_HOME没了...于是在环境变量中添加一个ORACLE_HOME变量,地址指向E:\oracle\product\10.2.0\db_1.再进Net Manager,没问题了,却发现报错ora-12

记生产服务器频繁死机重大事故

硬件环境:曙光天阔I620Vmware ESXI 6.5虚机机操作系统:centos 6.9raid 5 问题现象:系统陆续出现断续无法访问的现象:nginx虚机.mysql虚机阶段性频繁宕机:无Dump日志,kernel日志无异常, message无错误信息: 问题排查过程最开始我们怀疑是因为软件程序的问题,所以最先查看了linux系统日志,可是日志中并没有留下任何蛛丝马迹. 然后我们又分析了nginx的access日志和error日志同样一无所获,之后根据访问量打印出了top url,收集宕