ANBOB™

当私网出过网络问题恢复后，多次遇到过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,这里简单的记录。

Queries that do “full table scan” are the ones that don’t use indexes. However, it is more suitable to use a full table scan for small tables, and it will not cause performance problems. Or when the data on the large table is seriously skewed and a large proportion of data records need to be returned, a full table scan will also be better than an index scan.

enq:CR – block range reuse ckpt 出现该问题时分析等待链通常是前台进程等待CKPT进程在完成checkpoint, 通常是在DBWR进程在争用CPU或I/O 性能时，通常该event会非常短暂，如果该event已经在AWR dbtime中占据了较大占比时，需要引起关注。通常还伴随enq: RO – fast object reuse event, 当时如果做select 在内的DML SQL可能还出现library cache lock，等待ckpt进程。

最近有个datapump跨数据库迁移数据时，提示”ORA-39002: invalid operation”错误， 排除过目录文件权限和语法兼容问题，后来发现是目标库的Timezone Version低于源库的TZ version. 需要升级目标库的TZ VERSION

最近有个客户的表空间使用率使用50%左右就出现了ora-1653，我们知道ora-165N是空间无法扩展，这么多的free空间还无法扩展，其中有可能是存在碎片，也就是数据文件中不连续的”洞”free space， 在申请一个比较大的extents时，无法匹配连续空间而失败， 你是否想过查看数据文件上的段分布？或表空间的碎片情况？或move 哪个对象可以让datafile resize更小？

因为使用dblink需要分配undo段来标示分布式事务，如果在循环中使用dblink并commit，每次会分配新的undo段，同时undo retention如果保留时间较常，那可能会导致undo自动扩展很大(autoextent on )， 或者会出现undo段争用，从未过期的undo段偷窃， 就会影响正常的DML事务