提供综合数据库运维服务与优化方案(不限Oracle、MySQL、PG及国产数据库), 微信/Tel:(+86)134-365-60330
weejar zhang 环境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数据库中不同的操作。
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)，