ANBOB™

最近在测试oracle to postgreSQL项目中，计划使用oracle standby database做为数据库初始化的静态数据，这没有任何问题， 那是否可以从standby database捕捉变化呢？如配置ogg extract抽取进程。

近日分析一个数据库checkpoint long time 未完成的一个case时，本想分析dbwr trace file中看看是否有报错，发现dbwr的trace file并不存在，并且重启数据库后也并未生成，发现这并非个案，好多环境中dbwr trace不存在， 下面记录一种启用方式。

最近一套ORACLE 19C RAC 因一个节点主机故障重启后，其中1节点启动失败， 2节点正常启动，网络traceroute 、 ping 、多播测试均正常，幸存节点也有尝试重启、包括Kill gipc gpnp 进程，及重建过node 1的tmp 下的network soket临时文件， node1 依旧启动失败， 启动分析Init启动进程发现是gipcd启动后直接terminal中断

10多年前测试过10g的logmnr用于从redo或archivelog中分析DDL DML记录， 当做一些误操作无法flashback技术恢复或无备份时，可以尝试用来从redo log中恢复一些操作， 最近测试了一个19c多租户环境中的logmnr，记录如何恢复某个PDB中deleted 记录。

When CSSD process is unable to get real-time priority and is not running in real-time, it may lead to various HA issues. From 19c, this is treated as a fatal error.CSS cannot start normally if failed to get real-time priority.

环境Oracle 11g(11.2.0.4) on RHEL6.9， 文件存储在SATA SSD的文件系统，每秒redo 50-100MB， 存在部分时间段40多组2GB online redo logfile 同时”active”状态的现象，cpu使用率60%左右。除了优化checkpoint外发现有2个少见的TOP event， 查看FG top event为’free buffer waits’， BG top event为 ‘db file async I/O submit’。

ANSI/ISO SQL 标准定义了4 种事务隔离级别，对于相同的事务，采用不同的隔离级别分别有不同的结果。这些隔离级别是根据3 个“现象”定义的,在Oracle 中READ COMMITTED 则有得到读一致查询所需的所有属性，在其他数据库中的读READ COMMITTED 可能会有不同的答案， 最近有个客户在测试migrate oracle to postgreSQL测试发现一个批处理的结果并非一致，

在有些程序员开发习惯中，喜欢为了应用代码的简洁或复用，而在数据库创建一个复杂关连查询的VIEW，甚至是VIEW套VIEW嵌套使用， 这里就有个问题如果上线后如发现依赖的表字段类型或长度不足时，修复一个view依赖的table列时发现在oracle、mysql、postgresql（本篇等同pg）中有不同的表现， 尤其是使用postgresql的用户需要格外注意， 因为pg 不允许直接修改

某客户一套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数据库中不同的操作。