启动节点报错：
[grid@racdb1 ~]$ srvctl start instance -d nauecard -i nauecard1 PRCR-1013 : 无法启动资源 ora.nauecard.db PRCR-1064 : 无法在节点 racdb1 上启动资源 ora.nauecard.db CRS-5017: The resource action "ora.DATA.dg start" encountered the following error: ORA-15032: not all alterations performed ORA-15017: diskgroup "DATA" cannot be mounted ORA-15063: ASM discovered an insufficient number of disks for diskgroup "DATA" ORA-15080: synchronous I/O operation to a disk failed ORA-15080: synchronous I/O operation to a disk failed . For details refer to "(:CLSN00107:)" in "/grid/product/11.2.0/log/racdb1/agent/crsd/oraagent_grid/oraagent_grid.log". CRS-2674: Start of 'ora.DATA.dg' on 'racdb1' failed
日志附后，谢谢
所以你是在节点2上把表空间增加到节点2本地磁盘中了吗？那一定会出现问题的。
另外，看上传的AWR分析，大量IO相关的告警
系统缓慢，跟磁盘子系统性能不佳直接相关。但是目前还不能判断是由于磁盘本身有故障（比如盘阵cache电池亏电），还是由于有大量的IO操作导致磁盘子系统超负荷运行。
无论如何，建议先检查磁盘系统，先剔除硬件问题。
评论
有用 0https://cs.enmotech.com/inspection/reportView/27932
在以上巡检报告中显示从3月3日开始有巨幅的物理IO增量。故障是从3日开始的吗？是由于业务有大幅度的增长吗？或者是新上线了什么业务
评论 有用 0感谢Kamus。
问题1，您看图片，这个当时CCEN空间不足了，我加了ccen02.ora（也就是第2个）。
这个应该是在asm上吧？（当时节点1应该就是挂掉的状态）。
问题2，我们这边检查下业务！谢谢
评论 有用 0你初始提问时候的报错信息是在尝试启动节点1时候的报错，虽然从截图上看你先加入的数据文件确实是在ASM磁盘组中，但是这个+DATA磁盘组下的磁盘很可能是在节点1上无法正常访问（虽然在节点2上可以访问，这在使用共享存储时候经常会由于一些不当配置所导致），因为无法访问这些磁盘，所以在节点1上也无法正常拉起磁盘组，因此Oracle数据库实例也无法正常启动。这是连锁的。
多提一句，如果你们尝试拉起节点1，是期望说，一个节点应对应用比较慢，是不是两个节点就能快了？那么，很可惜，你们现在遇到的性能问题，很可能是无法通过增加RAC节点来解决的。甚至说你拉起节点1以后，性能还会更差也是有可能的。
评论 有用 0感谢指导！
这套系统已经运行了接近3年（其中去年10月份因为存储故障整体重启过一次，节点1估计就是那时候出的故障，但是从10月到现在一直都是运行正常的）。直到这几天开始出现高峰期很卡（具体前面您已经指出了，从3月3号突然开始的）。
我们和应用那边沟通过，说没有做过变更，并且这套sql在全国很多地方在用，也没出现过问题。所以现在很头疼，完全没有头绪去排查了。
存储工程师也到现场看过了，存储是正常的，没有报错或者磁盘异常。
能否指点下现在应该往哪个层面去排查？
感谢
评论 有用 0看了一下IO的情况，基本都消耗在直接路径读上。读了500多G的数据，如果磁盘本身没有问题，很可能是这样大量的读取消耗掉了所有的IO能力，导致整体IO非常缓慢。
然后这些IO基本上100%都消耗在了REC_BANKREC这个表上，而且子对象看名字似乎对应了2016到2019的所有分区。建议你们对照一下应用，看看什么操作在读取这个表的这么多年的分区。
评论 有用 0
墨值悬赏