ANBOB™

某客户一套Oracle 11.2.0.4 4-node RAC ON RHEL 7.6 环境 ，ASM High冗余Diskgroup 有600TB存储(没错是个超级大库)， 其中有1个1TB的ACFS DG. 一日突然节点1个节点ASM和DB实例crash, 重启后正常, 分析当时的日志是ASM 实例的VDBG后台进程出现的ora-4030错误，目前需要分析一下原因。 简单记录。

近日1客户环境的oracle 12cR2 6-nodes RAC多个节点脑裂后无法启动加回cluster, 分析日志又是经典的“has a disk HB, but no network HB“， 最近安全加固需求颇多，当心过度封锁影响到了RAC 间的interconnect 通信。 这里简单记录一下case现象的分析方法。

在创建表时，如果相同的列类型，不同表列的顺序是否会影响数据库占用空间大小？使用oracle、mysql或postgresql是不是相同的表现呢？ 不是的Postgresql近期发现空间使用会因为columns的顺序而占用不同的大小，当然也和实际的数据有关，简单的测试。

某客户一套linux container环境（LinuxOne大机）中的Oracle 19c RAC， 在启动阶段总是因为CTSS资源无法启动，导致Crs重启后需要手动干预， 通过kill local node gipcd.bin进程可以启动成功。多套环境有这问题，看来可能是Oracle软件在该环境存在缺陷，简单记录处理方法。

数据库运行过程中在错误日志或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有部分存储链路问题，硬件工程师维修过。

像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)，

AUTO_INCREMENT机制用于 InnoDB表， AUTO_INCREMENT必须将列定义为某个索引的第一列或唯一列，可以对表执行等效的索引 SELECT MAX(ai_col) 查找以获得最大列值。上AUTO_INCREMENT列h索引没有要求必须是是 PRIMARY KEY 或 UNIQUE，但为了避免 列中的重复值，建议使用这些索引类型。在一些情况下MySQL5.7中会产生重复值duplicate-key error, 8.0有所改变。

有时跟踪 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 中断、内核参数配置错误等