还不算晕的专栏

在数据库服务器上设置磁盘的权限，/etc/udev/rules.d/99-oracle-asmdevices.rules中添加如下内容（注意：其中mpath-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx改为实际新加的lun的uuid）在存储上划分LUN，并映射给数据库服务器，关闭HIS数据库集群1节点，并更改磁盘权限，待数据库节点1开机并数据库正常运行后，关闭HIS数据库集群2节点，并更改磁盘权限。至此，完成存储的迁移，新的磁盘已替换旧的磁盘。

一开始只是将数据库软件通过make -f ins_rdbms.mk rac_off 和 make -f ins_rdbms.mk ioracle关闭RAC模式；然后在启动数据库（sqlplus / as sysdba登录后startup时报错：ORA-00600: internal error code, arguments: [kgfz_getDiskAccessMode:ntyp], [0], [], [], [], [], [], [], [], [], [], []2.启动数据库实例时的报错。

4.尝试重新MOUNT磁盘组，以及修复OCR（NORMAL冗余）磁盘组中OFFLINE后超过REPAIR时间的DROP状态磁盘。2.检查操作系统的日志（linux /var/opt/message），确定出现了存储盘的IO报错（事后分析为链路问题）登陆系统查看，数据库实例异常关闭，日志指向ASM DISKGROUP异常；1.检查集群状态、ASM实例状态，发现ASM磁盘组已经DISMOUNT；3.目前检查测试，磁盘已经恢复；2.MOUNT 磁盘组报错的解决。3.处理DROP状态的ASM磁盘。

直到节点1完成了重配，节点1恢复正常。，持续到13:45:45分，节点1检查到节点2异常，开始进行实例的Reconfiguration，13:45:51时完成，系统即恢复正常。数据库alert日志显示，13:42:40秒开始出现LGWR进程无响应80秒，推算13:41:20秒出现问题，持续到13:45:45分，节点1检查到节点2异常，开始进行实例的Reconfiguration，13:45:51时完成，系统即恢复正常。3.在此期间，由于节点2异常，大量程序的进程都连接到节点1，加剧了节点一的性能问题。

近期，一个客户新安装的ORACLE 19C版本RAC；在重启主机测试高可用功能时，发现数据库集群无法正常启动。根据集群的运行机制，一步步分析日志，可以发现是CSSD进程启动异常。分析日志，问题在于CRS-1726: Process failed to run in real-time priority；之后CSSD进程异常。这个问题MOS文档CRS Will Not Successfully Restart After Node Reboot (Doc ID 2720950.1)有提到，将/etc/sy

在LINUX 7.5环境安装ORACLE 12.2.0.1版本RAC会有报错（在RHEL6.9环境安装12.2.0.1 RAC无此问题），因此通常思路是下载最新版的PSU。在RAC安装时直接使用-applyPSU参数，先打补丁再安装RAC的思路，即可以顺利完成安装。问题1：1.解压grid安装包2.更新opatch，注意版本与位数3.用先打补丁再开始安装[grid@rac01 grid]$ ./gridSetup.sh -applyPSU /home/grid/33290750/Prepari

近期，某用户在重启RAC一个节点的数据库实例时，发现启动速度非常慢。同时业务部门反馈连接RAC存活节点的业务也受影响。通过对日志的分析，在启动数据库时，Reconfiguration速度慢，Reconfiguration后报错IPC Send timeout detected. Sender: ospid 53884 [oracle@test2 (LMD0)]，从而出现了数据库实例组的节点驱逐；Wed Apr 13 19:28:02 2022Instance termination initiated

某用户遇到RAC数据库的一个节点，应用程序无法连接上数据库的问题。排查发现是数据库监听程序异常，无法建立连接。经一系列排查，发现为数据库安装时的一些参数设置不够合理，在系统长时间运行后，出现了些问题。[grid@rac-a ~]$ uptime --节点1启动时间长11:55:12 up 263 days, 2:38, 2 users, load average: 1.53, 1.73, 1.85[oracle@rac-b ~]$ uptime11:55:37 up 95 days, ...

近期，某用户环境出现集群数据库一个节点无法启动、加入集群的问题。集群版本为11.2版本，检查集群日志，问题比较明显，集群alert日志中让看CSSD进程日志，CSSD中显示无心跳网络:has a disk HB, but no network HB;按如下步骤排查处理：1.首先通过hosts文件确认了数据库心跳网络IP，并在操作系统层面确认心跳网卡状态正常并且可以互相PING通、SSH联通。2.通过gpnptool get确认集群使用的心跳网络即为上一步检查的。3.根据11.2集群组件功能，GI

DG环境的现在已经是一个基础常见的架构，整体架构成熟稳定，已经是公司的常规实施项目。近期，同事转来一个问题，DG搭建好后，报错ORA-16047: DGID mismatch between destination setting and target database。 这个报错看起来是DGID不匹配，通常配置log_archive_config='DG_CONFIG参数即可；本次问题排查发现，此参数设置正常，为何仍有此问题？接下来基于DG的配置原理出发，一步步排查此问题：1.根据报错，查看log

近期，某用户的RAC环境出现重启主机后未启动成功的问题。1.排查集群启动日志可以发现GPNP进程启动异常：2022-02-23 04:01:46.163 [EVMD(5243)]CRS-8500: Oracle Clusterware EVMD process is starting with operating system process ID 52432022-02-23 04:01:47.182 [GPNPD(5276)]CRS-8500: Oracle Clusterware G

近期日常检查中，发现一个用户的RAC环境出现有报错：*** 2022-02-22 19:34:58.672 Drop transient type: SYSTP2JW0acnAurDgU1sBqMBryw==查询ORACLE MOS网站，有文档说明的类似问题：Receiving ORA-21780 Continuously in the Alert Log and SMON Trace Reports "Drop transient type". (Doc ID 1081950....

1.hosts文件中设置#号注释192.200.54.41 test.hzhospital.com test192.200.54.42 test2.hzhospital.com test2173.168.1.1 test-priv.hzhospital.com test-priv173.168.1.2 test2-priv.hzhospital.com test2-priv#####192.200.54.240 test-vip1.hzhospital.com test-vip1#192.20

ACFS文件系统创建配置 创建操作系统中挂载点目录 如挂载点/oggdata两个集群节点都需要创建[root@syhis1 ~]# mkdir /oggdata[root@syhis2 datafile]# mkdir /oggdata[root@syhis1 ~]# /u01/app/grid/cfgtoollogs/asmca/scripts/acfs_script.shACFS file system /oggdata is mounted on nodes syhi

问题背景：某云环境，要安装12.2版本RAC，网络原因，心跳网络上的HAIP(169.254.*.*)在两台主机间无法通信，导致RAC的ASM/DB均只能启动一个节点，报错即典型的PMON……: terminating the instance due to error 481。处理办法：1.协调云厂商在后台虚拟化管理上放开HAIP(169.254.*.*)网络的通信，一直无法解决~~2.决定ASM/DB实例不使用HAIP，恢复到低版本原有的心跳地址模式(即HAIP功能在集群层面仍然是开启状态，if

近期安装hpux环境的12.2.0.1版本 rac时，在执行root.sh时有报错，提示Relinking rac_on failed.使用-x 模式及查看安装日志，可以较直观的发现如下报错：ld: Mismatched ABI (not an ELF file) for -ljavavm12, found /oracle/app/12.2/grid/lib//libjavavm12.a;看起来是JAVA相关的lib文件问题，在ORACLE MOS上搜索此信息，有相关文档说明了此问题：12.2 GI: In

一次gipc进程网卡状态问题的排查问题：客户联系我一个集群节点无法启动。连上后发现之前由于心跳网络问题，集群节点2 GRID自动重启，重启时依然报心跳网络异常，因此启动不成功。检查此时的心跳网络已经恢复，手动启动集群软件仍然未解决。最终解决后总结：这个问题的处理，主要需要对11G RAC的架构(几个AGENT管理不同资源)以及集群中不同进程管理的资源以及交互情况有了解，可以知道OCSSD进程认为心跳网络异常，心跳网络状态是GIPCD进程监控因此需要看GIPCD进程的日志。通过日志发现问题后，再尝试解决。

RAC加减节点，正常来说是一个较简单的动作，前期环境准备检查完成后，半小时内可以完成一个节点的增删动作。近期某客户出现了两套RAC环境均出现一台主机物理硬件损坏问题，需要通过删除故障节点、添加新节点方式来修复RAC，在操作过程中遇到一些问题，记录如下：1.前期环境检查阶段–主机名修改不规范，cluvfy stage -pre nodeadd -n node2检测能通过，但是后面会出问题，因此...

同事转来某客户待上线RAC集群异常宕机，需要进行分析并找到宕机原因。分析过程发现这个RAC重启有些不一样，不只是共享存储链路异常导致集群异常，还涉及了11gR2 RAC集群的新特性MemberKillEscalation，记录一下。 对RAC集群其中一节点宕机的原因分析如下：1.从RAC集群各个组件的日志分析可以发现，节点1在2017-05-16 12:29:02.255开始...

故障发生时间线：某次同事发来让协助分析的一个客户RAC重启的分析回复，供参考。数据库实例及GRID集群重启的时间线：1.实例2 ALERT日志：在16:39:11出现SWAP换页，核心进程LMS1 (ospid: 8389020) has not called a wait for 235 secs从ALERT日志中看实例2在问题发生前在持续进行LOGMNR操作2.数据库实例2日志...

问题：2019/12/12，某存储维护厂商对客户的LINUX+ORACLE 11.2.0.4 RAC环境进行ASM磁盘扩容，计划通过新加LUN方式，不重启数据库LINUX主机方式在线操作加盘。在实际操作过程中(未知如何操作的)导致数据库ASM磁盘IO报错，后强制重启主机；在主机重启后，发现GRID软件无法启动，紧急介入响应……分析：首先连入环境，通过crsctl stat res -t...

如下是另一次典型的由于网络心跳异常导致的RAC节点GRID软件重启分析(由于11gR2 新特性Rebootless Restart特性默认是重启GRID不重启主机，但是此问题由于当时私网IP被占用，发生了多次GRID重启，某次关闭时未正常关闭，所以触发了主机重启)，当时写给用户的故障分析报告，供参考。一、服务概述某客户CRM系统 RAC集群节点2异常重启问题；**工程师接到故障申报后，及时...

如下是一次典型的由于网络心跳异常导致的RAC节点GRID软件重启分析(由于11gR2 新特性Rebootless Restart特性默认是重启GRID不重启主机)，当时写给用户的故障分析报告，供参考。一、服务概述某银行近期遇到**系统数据库集群节点2的GRID异常重启，相应的数据库实例也发生了重启。**工程师接到故障申报后，及时进行响应，通过对相关日志等信息的深入分析，整理汇总此文档。...

近期一客户在数据库演练时要测试集群的高可用性，在两节点RAC集群中如下命令创建了服务，用以使业务系统正常情况下连节点1，节点1异常时连节点2. 本次演练就是要测试关闭节点1数据库后，服务自动切换到节点2，业务系统仍可以继续正常使用。srvctl add service -d crmsdb -s crmsprod -r crmsdb1 -a crmsdb2 -P basic -e session...

1.具体故障表现：在AIX 7100-04-03-1642版本操作系统上安装ORACLE 12.1.0.2版本GRID集群软件时，运行root.sh脚本正常构建集群；之后图形界面脚本之后的操作，在进行mgmt数据库创建时，遇到异常ORA-00449: background process 'MMON' unexpectedly terminated with error 448，具体日志如...

上个月遇到的一个故障；首先是用户反映有RAC环境中一个节点无法启动，需要进行处理。需要对集群中此节点无法启动的原因进行排查，同时需要排查为何出现了节点重启；故障分析结论是：RAC节点2异常，集群无法启动并报无法找到votingfile所需的共享磁盘，在此之前2017/01/17发生了集群及OS重启。对无法发现共享磁盘及集群重启的原因进行分析总结如下：1.2017/01/17 11:1...

Oracle Clusterware的心跳Oracle clusterware 使用两种心跳设备来验证成员的状态，保证集群的完整性;一是对votingdisk的心跳，ocssd进程每秒向votedisk写入一条心跳信息;二是节点间的私有以太网的心跳，两种心跳机制都有一个对应的超时时间，分别叫做 misscount和disktimeout：misscount 用于定义节点间心跳通信的

主要为了验证11gR2 RAC中ASM实例通过gpnp profile获得spfile信息来启动ASM实例，同时验证了gpnp profile的修改等内容；结论与实验如下：验证结论：1./u01/app/11.2.0/grid/gpnp/profiles/peer下的cat profile.xml内容是旧的，使用spset/spmove时均未被更新，一些文档说这个 profile.xm

测试将GRID_HOME下所有文件属组改变为ORACLE用户的，集群出现异常后的修复方式。参考MOS文档：Script to capture and restore file permission in a directory (for eg. ORACLE_HOME) (文档 ID 1515018.1)测试环境：LINUX-x64+oracle11gR2两节点RAC1.测试，修改节点

查看当前的CHM主、副节点[grid@bys5 bys5]$ oclumon manage -get masterMaster = bys5 Done [grid@bys5 bys5]$ oclumon manage -get replicaReplica =  Done 查看CHM收集的信息的保留时间段[grid@bys5 bys5]$ oclum

大部分转自DAVE，个人整理及增加了使用UDEV绑定ASM磁盘部分。ASM:Automatic Storage Management是Oracle 主推的一种面向Oracle的存储解决方案， ASM 和 RDBMS 非常相似，ASM 也是由实例和文件组成， 也可以通过sqlplus 工具来维护。  ASM 实例的创建和删除也可以用DBCA 这个命令来操作。在dbca 的

说明：通过在RAC中新增四个监听服务，来实现通过不同服务名连接到不同的实例。1.查看并使用srvctl来增加服务名[oracle@bysrac1 ~]$ crs_stat -t-bash: crs_stat: command not found[oracle@bysrac1 ~]$ su - gridPassword: [grid@bysrac1 ~]$ crs_s

1、PUBLIC和VIPOracle RAC中每个节点都有一个虚拟IP，简称VIP， 与公网PUBLIC  IP在同一个网段。vip 附属在public网口接口。VIP和PUBLIC IP最主要的不同之处在于：VIP是浮动的，而PUBLIC IP是固定的。在所有节点都正常运行时，每个节点的VIP会被分配到public NIC上；在linux下ifconfig查看，public网卡上是2

转自Dave一 集群环境下的一些特殊问题1.1 并发控制在集群环境中， 关键数据通常是共享存放的，比如放在共享磁盘上。 而各个节点的对数据有相同的访问权限， 这时就必须有某种机制能够控制节点对数据的访问。 Oracle RAC 是利用DLM(Distribute Lock Management) 机制来进行多个实例间的并发控制。1.2 健忘症(Amnesia)集群环境配置文

说明:测试RAC的cache fusion对数据块访问效率的影响第一步，创建测试表BYS@ bysrac1>create table test9 as select * from dba_objects;Table created.################################第二步：在节点1进行更新不提交并查询BYS@ bysrac1>conn /

课程目标学完本课后，应能完成以下工作：• 识别自动存储管理(ASM) 的功能• 为ASM 和数据库实例设置初始化参数文件• 使用ASM 文件名执行SQL 命令• 启动和关闭ASM 实例• 管理ASM 磁盘组• 使用RMAN 将数据库移植到ASM自动存储管理：概述• 可移植的高性能集群文件系统• 管理Oracle DB 文件• 数据分布到各个磁盘中以平衡负

1.查询RAC集群各种信息命令数据库名：bysrac实例名：bysrac1  bysrac1查集群状态：[grid@bysrac1 crsd]$ crsctl check clusterCRS-4537: Cluster Ready Services is onlineCRS-4529: Cluster Synchronization Services is onlin

在Oracle 11gR2 下的RAC，架构发生了变化。CRS的信息也是放在ASM 实例里的，所以要关asm,必须关闭crs, 如果还使用了acfs的话，一关crs那么acfs里的信息也不能访问了，所以一般不重启机器，不轻易关crs, 其他的service可以根据自己的需要去stop/start。1.整个集群的停止和启动集群方法一：用root用户，在Oracle11gR2中停止和启

在11g R2中，默认 oc4j和gsd资源是 disable 的；oc4j  是用于WLM 的一个资源, WLM在 11.2.0.2 才可用；gsd 是 CRS 用于跟 9i RAC 进行通信的一个模块,是为了向后兼容才保留的，不影响性能；建议不要刪除, 也不要尝试开启他们,  忽略即可。 crs_stat -t输出的列中，target是系统需要运行在的状态，stat

现象：在两个节点上做CRS的重启，这个实例都不能随CRS的启动而启动。CRS启动后做crs_start -all可以把没启动的资源起来，而且无报错。分析：去crsd.log中找原因，发现CRS根本就没有去尝试启动该instance以及相关的HA资源。用crs_stat -p把资源详细信息输出后发现该实例的所有资源的auto_start=2，意味着该资源不会自动启动解决：更新