提供综合数据库运维服务与优化方案(不限Oracle MySQL PG GaussDB GoldenDB OceanBase等), 微信/Tel:(+86)134-365-60330
oracle一体机
Recently, for one of our customers’ XD system, a cell node automatically restarted. The reason was due to disk control. However, after the restart, it was discovered that there was an automatic operation to delete the ASM disk in the log, and this was not an intentional human action. Simply record this feature.
前段时间一套Oracle Exadata X5环境遇到了严重的IO问题，从AWR top event IO延迟相当高，问题前虽然IO性能并不是很好，但这次突然的性能减半，影响对于cell multiblock physical read和direct path write，cell smart table scan wait avg ms翻倍，甚至达到100ms以上，对于oracle环境是无法接受的，当然通过分析问题在硬件层，更换RAID卡电池后恢复，10几年前遇到过因为RAID卡电池没电，影响无法使用RAID cache导致IO性能衰减的问题
最近有个客户的Oracle Exadata x8 数据库主机操作系统总是频繁的重启，重启前在DB,CRS层没有任何错误信息， 当时的OS负载也比较低，仅从exawatcher的mpstat能发现在重启前15s左右部分CPU core sys使用达100%。 操作系统有配置kdump生成了dump信息，发现在CPU在等待Watchdog detected hard LOCKUP on cpu 11， 堆栈调用中包含rds_send_remove_from_sock，简单记录。
前段时间一套Oracle Exadata的环境， 2个ib做的private network和cell存储网络，但总有一条存储链路从db server到cell server ping不通，但是ibstat ibping rds-ping都正常， 因为一个IB链路出问题同样影响IO，无法做到高可用。后分析发现是出于安全检查只是从内存级修改了rp_filter值为1启用了严格的反向路径校验，禁用rp filter后恢复正常。
最近有个客户的某业务其中一条insert into txxxx values(seq.nextval, xx, xx ,xx);的SQL从Oracle Exadata X5迁移到X8上以后，sql性能有几百ms的差异，因该SQL是应用APP界面中登录写日志的一个SQL, 比较影响体验的一个关键SQL, 希望找到其中的原因，是否其它SQL存在相同的问题?
最近一个Oracle Exadata x5 2节点RAC 11.2.0.4环境，每个节点中有2套DB实例。 Node1正常运行，计划性重启Node 2后，CRS启动正常，主机上1个db的 instance 2启动正常， 但另1个db的node2 db instance启动失败，提示下面的错误：
ORA-01105: mount is incompatible with mounts by other instances
ORA-01154: database busy. Open, close, mount, and dismount not allowed now
最近1 Oracle Exadata X7客户ora instance 2被驱逐后，重启db instance 2启动挂起，影响另一实例instance 1, 随后终止启动，实例1运行正常。分析db instance 2启动时在等待control file enqueue超时，OS 日志显示“RDS/IB: conn <192.168.*.3,192.168.*.6,4> racing for more than 1s, retry”
近日一客户Exadata Machine节点总是会不定理重启，在DB和GI层无错误日志，类突然断电或无响应重启， 分析OS message日志显示如下信息。
WARNING: CPU: 2 PID: 0 at net/sched/sch_generic.c:334 dev_watchdog+0x228/0x22c
Apr 7 12:49:37 xd08anbob03 kernel: Modules linked in: oracleacfs(PO) oracleadvm(PO) oracleoks(PO) ipmi_poweroff scsi_transport_iscsi
去年的blog《如何在 Linux 上诊断高 Sys CPU》 记录过%sys CPU高与oracle相关常见的2个情况 ， 这次刚好遇到了因OS内核参数配置的kernel.sem信号量产生CPU高的案例，记录一下现象。 环境Oracle Exadata X8。
上周遇到几例Oracle Exadata Machine上的故障，简单记录一下问题现象，涉及db 实例重启失败报措OS资源相关skgxpcnclrpc， 与内存耗尽后进程系统失败，IO hang/error , 及cell 存储节点坏盘日志的输出。
抛开政治， 就这环境，要啥分布式! 省点机房机位租金和电费不好吗？ DB Name DB Id Unique Name Role Edition Release RAC CDB ANBOB 6666666 anbob PRIMARY EE 12.2.0.1.0 NO NO Instance Inst Num Startup Time anbob 1 27-Jun-20 21:06 Host Name Platform CPUs Cores Sockets Memory (GB) localhost Linux x86 64-bit 224 112 4 754.52 Snap Id Snap Time Sessions Cursors/Session Begin … Read more
在从Oracle Exadata工程系统迁移至非Exadata环境，或配置Data Guard时需特别注意，某些功能属于Exadata专属特性。例如，采用EHCC（Exadata混合列式压缩）的表对象，在备用库查询或使用Data Pump进行迁移过程中，可能会遇到如下错误：
在 DataGuard 环境中，默认情况下，当使用密码文件时，SYS 用户的密码用于验证重做传输会话。但出于安全原因，您可能不希望仅将如此高特权的用户用于重做传输。为了克服这个问题，Oracle 实现了 REDO_TRANSPORT_USER 初始化参数。
REDO_TRANSPORT_USER是在DATAGUARD环境中用于 redo transport 远程密码认证指定数据库用户名，
环境Oracle Exadata Machine(x7)环境， 节点1异常重启后无法启动，另他节点运行正常，从日志显示是gipc进程启动失败，清理network socket 文件启动成功。
Oracle ILOM服务快照工具用于收集Oracle服务人员使用的数据来诊断系统问题，除非Oracle Service要求收集，否则平时我们不用使用该工具。
cell03存储主机的文件系统异常，导致ASM Hang,数据库实例crash, 虽然是NORMAL级别的冗余，但是数据库实例此时不能于ASM通信，重启CRS进程恢复，可使用剩余的2条CELL继续为数据库提供服务。 在延长了disk_repair_time时间后，等待时间后强置重启CELL03主机操作系统后，一切恢复。