ANBOB™

Oracle 希望在数据库主机CPU使用率枯竭时，尽可能让核心的几个后台进程可以最大优先级获取CPU, 当然CPU过高会导致I/O 响应时间变长和网络延迟增加，也会间接影响数据的整体性能, 使用ps -c在查看LMS时发现没有在RT模式引起了注意，在19c中 LMS还是有一些变化，下面简单的记录

Bugs fixed in each 19.0.0.0.0 Release Update and Releas […]

一天客户问有个SQL执行中好像是hang了，当前的session对应的v$session.event是‘gc current grant 2-way ’， 之前运行都是秒级，现在已经跑了1个小时还未结束，通常看到这个event会怀疑是GC出了问题，然后就走错了路， 下面看一下这个案例。

众所周知， 在oracle数据库中redo日志是非常重要的文件，oracle代码设计根据Write-Ahead-Logging预写协议，DBW不会在LGWR写入描述该块更改方式的redo之前将已更改的块写入磁盘, redo 日志文件中记录了所有的数据库变化，通常对于Select 查询类并不会修改数据，也不应该产生redo 记录，但是还是有几种特殊场景， 前几日一个客户提出疑问，他注意到在数据库SQLPLUS中set autotrace on中执行一条查询总是出现大量的redo和伴随physical read

前段时间整理过关于control file的一个等待《Troubleshooting performance event ‘enq: CF – contention’》， 这里再记录关于control file的另一个event( 这里没用等待), 此event只是通知类event，和db file sequential read类似为数据库的I/O类操作，但wait class并非USER I/O，而是SYSTEM I/O. 问题时段control file sequential read占到了AWR top 1 event, 占用约90%的DB TIME.

提起表的cluster factor集群因子可能都并不陌生，反映了表上数据分散的程度，Attribute Clustering这是Oracle数据库版本12.1.0.2中的一项新功能，该功能允许dba在将表记录在insert写到磁盘时能否保持顺序，保持较好的cluster factor，

本次数据库负载异常或故障突然CRASH，而AWR snapshot没有形成时，在12c后中的ASH每5分钟逐渐式flush disk，已不会刷新太频繁而增加系统负载，也不会等到AWR SNAPSHOT时间大粒度间隔而突然重启而ASH数据缺失无法分析。本次就是利用DASH中SQL两个时间段的SQL执行持续时间判断SQL变慢而导致的业务积压，而非SQL执行量增加，或执行计划变化。

数据库环境有时会因为硬件磁盘问题导致数据不可读，而硬盘“坏道”便是这其中最常见的问题， 当出现因为磁盘坏道里更加棘手，无法移动或跳过，更甚至因为有坏盘在换盘后RAID重组出现文件系统勘误导致文件为0bytes，增加恢复难度，例如使用dbv 检查时会出现如下报错：

近期一客户19c RAC CDB数据库的SYSAUX表空间增长超大，分析原因为Optimizer statistics advisor特性导致的WRI$_ADV_OBJECTS对象记录数变多， 以下为清理方法。

有套ORACLE 19c RAC在使用crsctl 查看db resource时显示“UNKNOWN”, 但是用sqlplus 可以启动db 实例，srvctl status instance显示not running. 手动启动instance 使用srvctl 显示如下错误

[oracle@~]$ srvctl start instance -d -i INTS1
PRCR-1013 : Failed to start resource ora..db
PRCR-1064 : Failed to start resource ora..db on node
CRS-2680: Clean of ‘ora..db’ on ” failed
CRS-5802: Unable to start the agent process

Troubleshooting ORA-04031: unable to allocate 13840 bytes of shared memory “ges resource dynamic” in 12C+ 记录过几个导致SGA中“ges resource dynamic”逐渐增大的问题，这里又在12c遇到了一个ora-4031问题，不太符合那里的描述和已知bug, 这里是在v$ges_resource中大量的FB资源的cache，这里简单记录。

ORACLE数据库在安全方面可靠度绝对完善，包括数据库用户的密码加密，在之前的老版本中如10G及以前，密码在dba_user.password显示密文， 由于使用的是DES加密，很容易从网上找到解密密文的方法，可以现在都12C–19C了，之前分享过《Oracle 12c 关于密码(password)的几个新特性小结》都已经引入了新的密码hash算法，怎么还经常能收到安全检查提示数据库用户有弱密码？ 他们还能解密12c以后的PBKDF2的SHA512哈希算法？ 那也太牛了吧，经常让DBA去改弱密码，DBA不能忍，于是研究一下怎么回事。

Hugepage是linux平台oracle数据库的建议配置，同样PostgreSQL等其它使用共享内存和多进程的系统都建议使用hugepage, 默认的4K配置带来的pagetables内存空间非常大。通常是修改LINUX内核参数sysctl.conf配置中hugepage大小和页个数，在oracle没有使用AMM时配置使用hugepage.在oracle数据库参数中与大页相关的参数为USE_LARGE_PAGES。在19c中可以使用auto_only值可以在OS未预先配置hugepage的情况下，oracle db实例启动时自动按需扩展linux kernel中分配hugepage.

有时需要应用版本上线做一些测试，希望做完数据库操作后利用restore point回滚点或做了基于时间点的恢复后，闪回数据库到修改以前时间点，然后standby继续应用日志恢复DG。因为在flashback后因为需要open resetlogs打开，在有dataguard的环境需要注意, 如果不想重建DG。同时oracle 19c引入了新特性，standby可以自动闪回数据库。

Oracle 12c new feature:OFFSET n FETCH n row-limit 7年前我尝试过12C新支持的TOP-n新语法，使分布代码看上去更简洁， 也是利用了一种窗口函数的方法，如果你在应用中使用了该语法，在19c的数据库前需要当前SQL的效率是否比之前的order by 子查询加 rownum的更差了。其实这是oracle在12c或18c版本中的bug, 在19C中已经解决，这也是建议升级19c而非12c跳过的一个小坑。

Oracle数据库服务的高可用性一直是RAC，其它关系型数据库不可匹敌的功能。应用配置TFA,当数据库实例发生故障时，以该实例为首选实例的服务将故障转移到另一个可用实例。不幸的是，实例再次启动后，服务并没有故障切换回原始实例。dba必须重新ralocate service服务。Oracle数据库19c对此进行了更改,增加了自动回归。

今天在一套11 G r2版本的2节点RAC adg环境，节点1因为硬件原因异常crash（apply redo 节点）， 但是实例2也上的应用也都断开了（原来都是open），adg上是有连接一些只读业务，而且节点2 db alert log未发现明显手动close 实例的日志，并且是自动切换到了mount状态，RAC不是应该高可用吗？为什么死一个节点另外的节点也要跟着受影响？

上个月刚刚分享了一个ORA-4031 bug《Troubleshooting ORA-4031 “init_heap_kfsg”占用大量内存 In 12c, 18c, 19c》，那篇中还提到了这个bug, 没想到这么快就在客户遇到。12c R2还没有安装20年07月RU的注意。ORA-04031: unable to allocate 4120 bytes of shared memory (“shared pool”,”unknown object”,”init_heap_kfsg”,”ASM extent pointer array”)
USER (ospid: 20366): terminating the instance due to error 4031

上周刚分享了《Troubleshooting ORA-04031: unable to allocate 13840 bytes of shared memory “ges resource dynamic” in 12C+》， 在当前的新版本中又存在一个打击一片的BUG, 同样现ora-4031 占用最大的内存区为init_heap_kfsg

1套Oracle 12.2 4Nodes RAC ON SELS11的本地磁盘使用率告警，DIAG目录在不断的生成redo dump的trace file, db alert log也在不停的显示如下信息:
An internal routine has requested a dump of selected redo.
This usually happens following a specific internal error