Oracle11G集群故障排错

问题现象：

集群好像不漂移IP了，全部会话连接数量只集中在某个节点上，这个节点断掉也不会自动连接到另外一个节点上；

问题排查：

在节点RAC1上执行集群状态检查命令（注意看红色字体部分）：

[email protected]:[/home/grid]crsctl stat res -t

--------------------------------------------------------------------------------

NAME           TARGET  STATE       SERVER                  STATE_DETAILS

--------------------------------------------------------------------------------

Local Resources

--------------------------------------------------------------------------------

ora.ARDATA.dg

ONLINE  ONLINE      rac01

ONLINE  ONLINE      rac02

ora.CLDATA.dg

ONLINE  ONLINE      rac01

ONLINE  ONLINE      rac02

ora.LISTENER.lsnr

ONLINE  ONLINE      rac01

ONLINE  ONLINE      rac02

ora.USDATA.dg

ONLINE  ONLINE      rac01

ONLINE  ONLINE      rac02

ora.USDATA01.dg

ONLINE  OFFLINE     rac01

ONLINE  ONLINE      rac02

ora.asm

ONLINE  ONLINE      rac01                    Started

ONLINE  ONLINE      rac02                    Started

ora.gsd

OFFLINE OFFLINE      rac01

OFFLINE OFFLINE      rac02

ora.net1.network

ONLINE  ONLINE      rac01

ONLINE  ONLINE      rac02

ora.ons

ONLINE  ONLINE      rac01

ONLINE  ONLINE      rac02

--------------------------------------------------------------------------------

Cluster Resources

--------------------------------------------------------------------------------

ora.LISTENER_SCAN1.lsnr

1        ONLINE ONLINE       rac02

ora.cvu

1        ONLINE  ONLINE      rac02

ora.oc4j

1        ONLINE  ONLINE      rac02

ora.rac01.vip

1        ONLINE  ONLINE      rac01

ora.rac02.vip

1        ONLINE  ONLINE      rac02

ora.racdb.db

1        ONLINE  OFFLINE                              Instance Shutdown

2        ONLINE  ONLINE      rac02                    Open

ora.scan1.vip

1        ONLINE  ONLINE      rac02

由此发现可能USDATA01卷组不能正常工作，尝试启动USDATA01卷组，发现继续报错。

[email protected]:[/home/grid]srvctl start diskgroup -g USDATA01

PRCR-1079 : Failed to start resource ora.USDATA01.dg

CRS-5017: The resource action "ora.USDATA01.dg start" encountered the following error:

ORA-15032: not all alterations performed

ORA-15017: diskgroup "USDATA01" cannot be mounted

ORA-15063: ASM discovered an insufficient number of disks for diskgroup "USDATA01"

. For details refer to "(:CLSN00107:)" in "/u01/app/11.2.0/grid/log/rac01/agent/crsd/oraagent_grid/oraagent_grid.log".

CRS-2674: Start of ‘ora.USDATA01.dg‘ on ‘rac01‘ failed

查看ASM磁盘卷组，发现USDATA01卷组无法正常识别，所以节点RAC1的状态不正常是因为无法正常识别该卷组的问题。

[email protected]:[/home/grid]asmcmd

ASMCMD> lsdg

State    Type    Rebal  Sector  Block       AU  Total_MB  Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Voting_files  Name

MOUNTED  EXTERN  N         512   4096  1048576    666603   332494                0          332494              0             N  ARDATA/

MOUNTED  EXTERN  N         512   4096  1048576     51207    50811                0           50811              0             Y  CLDATA/

MOUNTED  EXTERN  N         512   4096  1048576    512009   124302                0          124302              0             N  USDATA/

时间： 2024-10-13 19:09:25

Oracle11G集群故障排错的相关文章

蓝的成长记——追逐DBA（18）：小机上WAS集群故障，由一次更换IP引起

原创作品.出自 "深蓝的blog" 博客,欢迎转载,转载时请务必注明出处.否则追究版权法律责任. 深蓝的blog:http://blog.csdn.net/huangyanlong/article/details/47720043 [简单介绍] 个人在oracle路上的成长记录,当中以蓝自喻.分享成长中的情感.眼界与技术的变化与成长.敏感信息均以其他形式去掉,不会泄露不论什么企业机密,纯为技术分享. 创作灵感源于对自己的自省和记录.若能对刚刚起步的库友起到些许的帮助或共鸣,欣慰不已.

KVM部署LVS集群故障案例一则

一.故障现象 KVM部署LVS(Linux Virtual Server)集群后,能够单独以HTTP方式访问RS(Real Server)的实际IP,但无法通过VIP(Virtual IP)访问. 二.故障分析过程   1.简化架构   在原部署环境中,采用的架构是LVS的DR(Direct Return)模式,如下图所示: 为了便于故障排查,我们简化为 也就是在2台宿主机上,各保留一个虚拟机,角色分别是LVS的Director(调度器)和RS. 该架构中的服务器(及虚拟机)的IP和MAC地址如

couchbase failover 集群故障自动转移方案研究！

最近迷上Couchbase了,现在所有的站点全部试用Couchbase进行缓存及持久化,这样以来貌似风险比较大啊,缓存服务器挂了就完了. 看到有讲到Couchbase的集群方案很简单,于是照着教程做了下.参考文章(http://www.cnblogs.com/long-gengyun/p/3772504.html) 哥使用了两台服务器,分别部署Couchbase服务端,并模拟一台服务器挂了,看是集群的故障自动转移功能是否有效,测试中,发现死活不行,查遍了国内外资料,中文的太少了,英文的看不懂,难

使用pgpool管理数据库集群故障的问题

pgpool如何选举master角色 在pgpool启动的过程中通过对 pgpoo.conf配置文件中的数据库节点条目信息,对集群中的数据库节点从0开始一个个的遍历,并发送SQL语句"select pg_is_in_recovery();":根据返回的结构来判断哪个数据库节点是master. 在master节点故障后,其它节点由于没有发生故障切换而没有master节点,通过pgpool提供的端口9999仍然可以连接并提供读 操作,但是不能对为提供写操作. 在故障切换时选择master节

云计算之路-阿里云上-容器难容：容器服务故障以及自建 docker swarm 集群故障

3月21日,由于使用阿里云服务器自建 docker swarm 集群的不稳定,我们将自建 docker swarm 集群上的所有应用切换阿里云容器服务 swarm 版(非swarm mode). 3月22日,我们进行移除与重启节点的操作时引发了故障,详见 云计算之路-阿里云上-容器服务:移除节点引发博问站点短暂故障 . 3月24日,我们参考阿里云容器服务帮助文档-指定多节点调度通过给节点添加用户标签的方式成功移除了部分节点.我们是这么操作的,当时所有节点没有添加用户标签,给待移除节点之外的所有节

Redis的集群(故障转移)

Redis集群自身实现了高可用,当集群内少量节点出现故障时通过自动故障转移保证集群可以正常对外提供服务. 故障发现 1. 主观下线 当cluster-node-timeout时间内某节点无法与另一个节点顺利完成ping消息通信时,则将该节点标记为主观下线状态. 2. 客观下线 当某个节点判断另一个节点主观下线后,该节点的下线报告会通过Gossip消息传播.当接收节点发现消息体中含有主观下线的节点,其会尝试对该节点进行客观下线,依据下线报告是否在有效期内(如果在cluster-node-timeo

greenplum 集群故障(Sorry,too many clients already )排查：

故障现象: 1:所有业务调度任务执行失败: 2:手动测试无法连接数据库: 3:并没有收到集群的异常告警: 处理步骤: 1:首先登陆 gpcc 查看集群状态: 发现所有greenplum 节点及服务都正常,但是屏幕打印报错信息 :Sorry,too many clients already (alert) 2:在master节点通过gpstate -s和查看/usr/local/gpdata/gpmaster/gpseg-1/pg_log/gpdbxxxxxx.csv日志,都可以看到以下报错信息

mongodb集群故障转移实践

简介 NOSQL有这些优势: 大数据量,可以通过廉价服务器存储大量的数据,轻松摆脱传统mysql单表存储量级限制. 高扩展性,Nosql去掉了关系数据库的关系型特性,很容易横向扩展,摆脱了以往老是纵向扩展的诟病. 高性能,Nosql通过简单的key-value方式获取数据,非常快速.还有NoSQL的Cache是记录级的,是一种细粒度的Cache,所以NoSQL在这个层面上来说就要性能高很多. 灵活的数据模型,NoSQL无需事先为要存储的数据建立字段,随时可以存储自定义的数据格式.而在关系数据库里

ES集群故障排查记录

这两天线上的ES集群总是有问题,开始查找原因发现这段时间各个机器的负载都很高,本来希望通过jstack找到一些信息,但居然提示'Unable to open socket file: target process not responding or HotSpot VM not loaded',度娘提示应该是机器很久没有重启了,没办法,只能放弃这种方式.第一步就没有走通.继续查发现几台机器 cpu 内存 都很高, 但是硬盘不太对劲,有一台机器硬盘使用下降的厉害,而另外几台硬盘使用都是上升的,初步