oradbm的博客

环境描述：Redhat7.9 11.2.0.4 RAC 双节点。

-登陆grid用户，检查并修改asm_diskstring参数。--检查并修改spfile参数，并重启ASM。

# 如果用户已存在，可以用以下语句更新用户组信息（oracle-database-preinstall-19c会自动创建用户oracle）查看服务提供的iscis盘情况：tgtadm --lld iscsi --mode target --op show。10.23.126.97-10.23.126.99和1.1.1.1-1.1.1.3 ---3节点集群。执行完后查看udev_info 和 99-oracle-asmdevices.rules，内容如下。– 数据库中的所有段分配的存储。

某天，某库两节点实例先后发生重启，实例重启前alter日志同时出现IPC Send timeout detected IPC超时。操作系统：AIX 7100-04-07-1845(SP07)数据库版本：oracle 11.2.0.4.0 两节点RAC。

Oracle系统中有一类参数称之为隐藏参数 (hidden parameters) ，这些参数在所有 Oracle 官方提供的文档中都没有介绍，他们的命名有一个共同特征就是都以 '_' 作为参数的首字符。当然这部分的参数是不建议用户进行修改的，除非你对ORACLE的整体架构相当熟悉，对整个参数修改所带来的影响有个清晰的认识。示例：如果想查看_db_block_hash_buckets的参数值col ksppinm for a50col ksppstvl for a50col ksppdesc for

某天，某库两节点实例先后发生重启，实例重启前alter日志同时出现IPC Send timeout detected IPC超时。操作系统：AIX 7100-04-07-1845(SP07)数据库版本：oracle 11.2.0.4.0 两节点RAC。

5.34.2. 5.34.2. 修改存放审计记录默认表空间 修改存放审计记录默认表空间。5.35.2. 5.35.2. 修改存放审计记录默认表空间 修改存放审计记录默认表空间。在 19.1 之前版本，由于 Bug 27576342 ，即使修改表空间和按日分区，5.35.5. 5.35.5. 部署统一审计自动清理任务 部署统一审计自动清理任务。5.34.3. 5.34.3. 修改审计记录按日分区 修改审计记录按日分区。5.35.3. 5.35.3. 修改审计记录按日分区 修改审计记录按日分区。

2）gpnpd守护进程被启动，gpnpd开始读取本地节点的gpnp profile，之后和远程节点的gpnpd守护进程通信，以便获得集群中最新的gpnp profile信息。4）gipcd守护进程被启动，从gpnpd守护进程获得集群的私网信息，并和远程节点的gipcd守护进程通信，最后开始监控本地节点的私网。原因5：集群的私网网卡出现问题，这会导致gipcd无法和其他节点的gipcd进行通信或者集群没有可用的私网进行通信。

前几天客户有套19C的需求调整，需要将原先的地址跨网段修改IP地址，包括public_ip，vip，scan_ip等。之前在11g版本也多次实施过网络调整，所以一开始也就完全按照11g的过程来调整IP地址，经过实战后发现还是和11g的版本在个别命令上有所区别。那么今天我就在虚拟机环境上，把19C的网络地址修改实验过程做一个完整的记录，供大家学习参考💖💖。

oracle 19c修改私网/公网/虚拟IP/scanip 的网段和ip版本：oracle 19C。

使用oifcfg命令在线添加新的网卡接口，在还没有配置bond1的条件下也是可以添加成功的。

数据库已经配置和IPV6和 IPV4双线协议，需要重新配置IPV6。

0#success。

确认集群状态正常，19crac补丁除了OVJM，GI和DB在opatchauto apply方式允许与集群服务并行运行，在打补丁期间集群服务、数据库服务、其他相关服务会自动重启。

从数据库的alert日志可以看出，当使用crsctl stop crs 直接关闭CRS集群时，数据库实例是以abort方式关闭的，这种方式过于暴力，除非数据库完全hang死，否则一般不建议使用这种方式，有可能会引起数据库故障；看到收集的信息，立马就知道了故障原因。现场同事在安全关闭计算节点dm01dbadm01上的数据库实例阶段，前4个数据库实例都正常关闭，业务系统未受到任何影响，但关闭PPO这个数据库实例后，业务部门很快就反映，业务系统无法连接到数据库，PPO这个数据库是核心库，它会影响到所有的业务。

集群健康监视器的一部分，由 Oracle 支持作为 RAC 问题调试的工具。Eviction due to OLOGGERD High CPU (文档 ID 1636942.1)登录上OS使用top发现消耗系统资源较多的进程是ologgerd。Oracle Ologgerd进程占用过多CPU资源。Ologgerd 是。

t. （那个认为补丁已经打上了，但是oneoffs目录里面没有。将安装包文件的权限全部改成777.就继续执行了上述命令 ，此时使用opatch lsinv也是报错 ，在正常执行opatchauto apply。1 创建目录，存放补丁包，并赋予权限。于是使用如下命令对补丁进行回滚。

总结：rman在对ASM存储的文件进行恢复的时，不是按照原来文件的名字进行重新创建的，而是修改了按照对应的磁盘组，修改了数据文件name。我们发现在还原数据库时，最后报错磁盘组ORADATA1空间不足，就很差异，因为原来欢迎。合计大小也就才3T，而新环境的ORADATA1配置的5T为啥还会不足？于是在pfile中将参数修改为空，重启数据库，重新进行restore，正常了。发现大部分的文件原来是ORADATA2也创建在了ORADATA1就很差异。1 拷贝参数文件并将集群的一些参数进行修改。

#####################迁移arch#####################################################3。#################迁移votedisk###################################################迁移ocr文件#######################################

近日有系统要迁移到19C oracle 集群系统，需要其他业务进行配合。查询连接数据库是否畅通，需要开通网络策略，于是业务层面进行网络申请时，只申请了scan ip的连接，但是数据库无法正常连接。4类地址，但是连接数据库只需要使用scan ip既可以进行连接。telnet public ip 1521 --不通。telnet scan ip 1521 --通。telnet vip 1521 --不通。19C集群主要的ip地址有。

1 使用oifcfg删除老的配置 ，添加需要的配置。2 关闭集群3 配置BOND并启动bond。4 由于VIP信息未调整，VIP以下相关资源启动异常，调整VIP以及network资源。5 重启集群。1 使用oifcfg删除老的配置 ，添加需要的配置。2 关闭数据库集群。3 配置bond，启动bond。4 启动数据库集群5 查看GIPC日志 网卡日志是否正常。1 oracle 19C集群 网络分为3种，2 集群已经启动双栈协议，IPV6地址可以直接调整public ip和VIP.

磁盘组编号 磁盘名称 磁盘状态 别名 磁盘路径 粗盘组名称。3 使用oracleasm scandisks命令扫描磁盘，node1， node2 都要做。2 使用oracleasm createdisk创建ASM磁盘。1 使用fdisk对磁盘进行分区，不做文件格式。

为了提高心跳网络的可用性，需要将心跳网卡由单网卡模式改成bonding模式。对应转换关系如下：项原始状态优化后状态操作系统版本Oracle版本网卡eth3eth0eth3设备名eth3bondha整个变更，只是将eth0和eth3进行绑定，IP地址不发生变化，对于RAC而言，集群的心跳设备需要更新，变更大致思路如下：手动备份ocr信息；查看集群的接口信息并做记录以root用户添加一个新的接口；检查集群的接口信息并做记录；关闭集群；系统进行bonding；

首先我的测试环境是这样的：[[emailprotectedglobalpublic。

对于网络的管理可以采用oifcfg和srvctl命令进行管理。

1 确认公网资源ora.net1.network正常工作。4 使用ifconfig命令和 /etc/hosts信息确认OS层面的公网配置，并通过oifcfg getif -global。2 确认DNS可以正常工作使用nslookup VIP/SCAN VIP .3 使用ping或者traceroute nlslookup查看到占用。查看OCR配置信息。

位于GI_HOME/crs/init/*.pid文件执行了其他运行中的进程 node1.pid./etc/oracle/ocr.loc指向了错误的OCR文件。集群私网出现问题，从而导致crsd.bin无法与远程节点通信。GI_HOME/bin/crsd.bin文件权限错误或者损坏。代理进程对应的二进制文件损坏或者丢失。OCR损坏或者丢失。

1 ocssd.bin被cssdagent代理进程启动。2 ocssd.bin访问gpnp profile，以便能够获取集群的名称，私网信息,VF搜索路径等基本信息。3 ocssd.bin在VF路径中索索周到足够的VF，并在VF的租借快中续租本地节点的节点编号，同时将本地节点信息添加在VF中，并开始和VF进行磁盘心跳。4 根据GPNP PROFILE中的信息和GIPCD进程通信，获取集群之间通信所需要的信息（endpoint）5 向集群的其他节点发送消息，建立连接。

CHANGESCAUSESOLUTION。

116为netmask。

绑定(RAC的两个节点都要执行)，把得到记录追加到/etc/udev/rules.d/99-oracle-asmdevices.rules。原文链接：https://blog.youkuaiyun.com/m15217321304/article/details/112236321。绑定前记录/etc/udev/rules.d/99-oracle-asmdevices.rules 文件内容。首先要创建ASM磁盘组，然后在此基础上创建ASM卷，最后才能创建ACFS。因为要安装RAC的ogg，这里先安装ACFS。

本周因为众所周知的原因，不能做操作变更，但是下周就要时间紧张的进行IPv6改造并迎接检查，所以本周的一大任务就是做好数据库IPv6改造的准备。技术向，知道写了些啥。

strace srvctl start listener -l listener 未跟踪到任何有用信息。我们知道listener使用grid用户管理的。1 使用scan地址无法连接数据库。且listener为启动状态。2 连接数据库报错，无法提供堆栈程序错误，数据库连接数未达到上线。strace lsnrctl start 跟踪到对应信息如下。1 将节点1 监听进程使用kill -9命令删除。3 但是启动节点1的listener发现如下报错。1 使用strace命令进行跟踪发现问题所在。

Alter system kill session ‘sid,serial#,@sid_number’ immediate;Select * from v$active_instances2 资源管理Alter database add logfile group 5; --当前实例Alter database add logfile instance ‘orcl2’ group 6 --- orcl2Alter system archive log instance ‘orcl2’Alter syste

（1）故障分析知识点 11 数据库进程和occd通信是通过IPC来实现的，也就是说需要嵌套字来进行通信，那么OS层面关于嵌套字参数设置会导致连接OCCD失败。2用户进程无法将自己注册到CSS的组上，所有IOcapacity的进程都需要把自己注册到CSS上。3 OS性能问题导致进程hang死，进而导致丢失本地心跳，节点或者数据库重启。4occsd进程是以RT模式获取cpu...

1图在手，RAC我有

背景说明：1、Oracle12.2RAC+ASM Normal Redendancy 模式，数据库存储采用双存储冗余架构，规避单存储故障导致服务中断及数据丢失；2、 ASM DiskGroup 设计2个 Failgroup(FG)，1个FG磁盘全部存储在1#存储；1个FG全部磁盘存储在2#存储中；3、期望任意存储故障或断电，数据库实例不受影响，数据不丢失，故障存储上线后数据自动同步。在实际高可用测试中，拔掉1个存储，发现如下现象：1.CRS集群不受影响，ocr/votedisk自动

1 在存储管理软件中为主机添加4T存储。2 使用hot_add命令进行更新存储信息 。存储信息如下[root@gzrac01 ~]# upadminUltraPath CLI #0 >show vlun----------------------------------------------------------------------------------------------------------------------------------------------

临时关闭存活节点发现故障节点就可以启动，即只能一个节点启动，矛头再次指向集群通信问题；后通过将果/var/tmp/.oracle下的socket文件清空，重启集群软件，恢复正常。因此可以推断是前期加盘导致IO异常时强制关机导致了/var/tmp/.oracle下的socket文件异常（正常情况下集群软件启动时会重建此处的socket文件).————————————————版权声明：本文为优快云博主「还不算晕」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链

故障现象某天下午16点左右，该案例中的数据库出现严重性能故障，主要表现为大量业务SQL无法正常运行，同时订单表无法正常插入数据，严重影响业务的正常运行。最终通过重启数据库并开启一个节点运行后，恢复正常。故障分析以下是截取问题时段(16:00-17:00)crm2db两节点AWR报告部分信息：节点1上DB Time是Elapsed时间的211倍，说明节点1处于极其繁忙的状态。而节点2上DB Time/Elapsed时间更是达到了276倍，远远高于数据库可用CPU数128，同.