ANBOB™

数据库运行过程中在错误日志或SQL运行时报错难以避免，oracle预制了好多错误代码，也有不确定性的会在ora-600 700 7445中， 所以Oracle DBA通常是先看ORA-xxxxx编号的错误，确认是否与数据库层相关，oracle database提供了一个命令行工具oerr工具查看错误代码的message和一些很友善action简单的处理建议。 好奇其它两个主流开源数据库有没有相同的工具？这里简单的记录

最近某客户一套Oracle19c RAC 环境，在负载相对空闲时也面临一个常见的问题”log file sync”， 数据库存储已经是较快的SSD设备， 下面记录一下容易忽略的RAID配置，居然对数据库的影响如此之大的案例。

前段时间有个客户每天凌晨会有根据前一日多表关连生成临时表CTAS 批量SQL任务， 数据量每天相差并不大，平时时间也基本相同，有一日同一批次中的1个SQL 运行时间从原来半小时左右增加了近3个小时，最终是SQL的table创建成功，需要分析当时的原因。环境oracle 11g 4-node RAC on Linux

一客户的一套ORACLE RAC 2-nodes on AIX, 年迈的大块头25G memory, 平时反馈就非常慢，一日因存储故障实例重启后，有1实例无法启动而另1实例正常，检查启动日志在ASM 实例正在starting后报错， 手动启动ASM 超时报错，ORA-00445: background process “LMD0” did not start after 120 seconds ，这是一个比较古老且常见的问题，

一套oracle 12c physical casecade dataguard 多租户环境，a–>b –>c， 用户在登录B standby数据库时间隔性提示ora-1017密码错误， 并且发现只是其中一个Pdb 存在这样的问题，如连续多次登录中其中有部分登录成功。

一客户oracle 19c（19.9） RAC环境在尝试expdp导出时提示ora-31626然后中断，然后找到我，之前已做过一些尝试包括重建了数据库datapump组件(dpload.sql), 确实问题比较隐蔽， 下面简单的记录该问题。

在查看AWR时LOGONS每秒实际比listener log中的每秒创建连接高出很多倍，同时AWR中还有另一个指标user logons比较接近，”Logons” 和 “User logons” 是有区别的，用于诊断连接风暴是应该使用users logons.

数据库维护过程中难免会遇到一些不正常的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有部分存储链路问题，硬件工程师维修过。