ANBOB™

数据库维护过程中难免会遇到一些不正常的SQL或会话进程正在占用系统大量资源，临时需要终止查询或kill会话，在Oracle, MySQL, Postgresql数据库中不同的操作。

The environment is Oracle 19.14 RAC 4-nodes, After the database was upgraded to 19c, there was a performance problem. From AWR, I saw a large number of library cache locks and library cache pins in the top event. namespace was OPTIMIZER EXPRESSION HEADER

系统资源的最大利用是系统优化的目标，但是过度”优化”系统的容错性就相对较差，如果出现丝毫的卡顿就会“雪崩”，前段时间分析的一个案例，号称是亚洲最好的一套HP小机配置，有Oracle原厂操刀调试的一套Oracle 12c R1环境，不过确实效率很高，突然有一天因RAC 节点之间的private network 高latency导致频繁的 gc 相关等待，从而导致性能问题。

近日一客户的4节点RAC,有三个节点CRS驱逐已crash（node 1,2,4），CRS无法启动，只有node 3目前实例还可以连接， 联系我时现场已经把1,2,4主机重启，问题依旧，先查检幸存节点是否正常， 登录node3 实例执行一些SQL查询hang挂起， 询问是否有过什么变更，答下午node3有部分存储链路问题，硬件工程师维修过。

像UNIX的PS1环境变量可以改变shell操作提示符， 在日常工作环境中可以提升一些效率可以防止一些误操作， 很多年前在看tom关于在练习oracle操作前的一些环境配置像login.sql， 还可以显示当前的用户或数据库名很是欣喜， 下面记录Oracle , MySQL, PostgreSQL三个主流数据库改变命令行提示符的方法。

当私网出过网络问题恢复后，多次遇到过gipc无法启动的问题， 当然有些场景可以尝试kill 生存节点的gipc或gpnpd.bin（不会导致GI重启）后，进程会自动重启动，可以尝试关闭问题节点CRS stack，再重启试试， 分析检查查看GI alert log和ocssd.trc,gipcd.trc等alert中提到的一些agent日志(eg.oracssdagent_root.trc)，

有时跟踪 Data Guard 后台服务很有帮助，因此我们可以查看匹配的 NSSn 和 RFS 跟踪。对于深入研究，我们还希望在 Data Guard 配置的两端运行 tcpdump 捕获，并且可能在中间的网络组件上运行。为了最大限度地减少设备上的处理开销和捕获文件中的噪音，我们希望数据包过滤器尽可能具体。

Linux中CPU负载高必须引起关注，通常需要先查看CPU使用类型，CPU使用分为us(用户进程)还是sy(内核调用)， sys通常不应该超过user , 数据库专用主机主要来自用户级的 CPU 时间（无论是“user”还是“nice”）。因此，当 CPU 时间的大部分时间花在内核（sys）中时，这表明出现了问题, %sys一般也不超过10%, 但是%sys超高这样的问题遇到好多次，原因有：NFS4 bug、 swap IO、安装了linux杀毒如卡巴斯基、3rd party modules、NUMA、cpu 中断、内核参数配置错误等

Recyclebin回收站是oracle数据库对于drop table的一种回退机制，可以使用flashback before drop特性闪回已drop还在recyclebin中的对象。纵观其他数据库像SQL Server也提供了类似功能， MySQL可以利用recycle_bin插件，但是作用在MySQL slave实例上，当在master实例上进行drop操作时，slave实例可以拦截drop操作，先进行数据备份再进行删除操作。 而在PostgreSQL中可以利用event trigger和pg_event_trigger_dropped_objects 来手动实现drop时 rename对象的方式变相实现recyclebin功能， 当然也可以使用一些插件如Pgtrashcan、postgresql-recycle-bin；在Opengauss中也增强了flashback的功能，但是需要注意更新方式是使用Ustore还是Astore, recyclebin不支持Ustore，只支持Astore,而且同样支持Truncate。

很多时候我们在安装配置oracle dataguard时，需要在standby db 增加standby log, 但是有一些限制，如standby log file size和主库的online redo log size相同， standby log每个thread要比主库的online redo log要多1组，为什么需要standby log?为什么会有这样的要求呢？

Oracle RAC众所周知通常需要PUBLIC和Interconnect network两个网络，当然从12c使用FLEX ASM可以增加ASM network, 而interconnect network也就是private network在11g r2后可以配置多个网卡，引入了haip实现了private networkIP的HA, 以169.254.*.*的随机IP绑定在private network网卡上。169.254因为是一个保留网段， ORACLE RAC在获取HAIP时有判断是否已使用防止IP冲突，但是最近一有个客户RAC一个节点CRASH后，private network无法互相ping通，结果发现private network安装初期使用的也是169.254.9.*。

环境oracle 12c， 大量session同1个SQL ID等待library cache lock，blocker session在频繁的变，并且last_call_et并不久，SQL id在v$sqlarea查询不到对应的SQL TEXT, 间隔性出现cursor: pin S wait on X和kksfbc child completion等待事件， library cache lock的P3值(namesapce+mode)为5373954, 这简单简单记录。

在kill crsd.bin后，listener上的public ip会立即自动消失， 当crsd.bin 自动启动后，public ip又会再次注册到listener上， 以上工作均有oraagent完成，无需任何操作，当 crsd 和 oraagent 进程自动重新启动时，应在 1 分钟左右注册丢失的 endpoint。 当然影响的不只是listener还有scan listener.

对于ORA-12nnn错误并不陌生，ORA-12154也是如配置tsnnames.ora 的alias错误常见，但是今天这个案例“若不是亲眼所见，我是万万不敢相信”， 在sqlplus中使用EZCONNECT尝试数据库时总时提示ora-12154, 而部分用户或jdbc应用使用相同用户可以正常链接，后分析密码中带了”@“符号导致。

今天在看MogDB的官方文档时看到一条关于分区的支持“Update操作时，支持数据跨分区移动（不支持Partition/SubPartition Key为List或Hash分区类型）” 也就是分区键更新， 那默认情况下Oracle、MySQL、PostGreSQL、MogDB(opengauss)横向对比一下表现，在rang\list partition update分区键在跨分区的表现。

有个客户的多套RAC节点总是频繁的重启， 故障并没有时间规律，环境Oracle RAC 11G r2 ON OEL 6.9 , 当然首先建议要排除一些硬件共性的配置，如是否电源电压不稳?机器所在区域空调是否差? 是否同一个宿主机上的VM? 硬件是否有报错？ 一线同学说都排查过也做了些调整并未解决。 下面分享一些处理建议。

Oracle Standby database容灾库有时因为一些原因缺少了Primary database的archivelog未应用而中断同步，如备库归档目录使用率100%,或主库未传输删除了归档等。重新搭建DATAGUARD对于较大的数据库可能是费时费力，通常可以采用增量备份的方式,最近刚好是在处理一个ogg不同步的问题时。

像v$archived_gap一样有时需要找出一些序列中跳过的数值，如1，2，4，6，10，需要找出3,5,7-9，在数据库中使用SQL可以有多种方法,以下列出几种供参考

当从Oracle Exadata工程系统迁移到非Exadata环境时，或配置Datagurad时需要注意，有些功能时Exadata专属特性，如EHCC (hybrid columnar compression )的表对象在standby 查询或使用datapump迁移时会遇到下面的错误
ORA-64307: hybrid columnar compression is only supported in tablespaces residing on Exadata storage

昨天遇到一个问题oracle 19c(19.10), 最近一段时间的RMAN备份任务都失败了，错误中有ORA-00230: operation disallowed: snapshot control file enqueue unavailable， 看着是cf的enqueue请求失败。 处理起来比较简单，找到blocker session就可以解决了， 之前的《Troubleshooting performance event ‘enq: CF – contention’》记录过一些分析方法，本次的案例当前还没有匹配的已知bug,这里简单的记录。