Troubleshooting Performance event ‘control file sequential 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.

Oracle 12C新特性: Attribute Clustering

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

Troubleshooting DB load high wait ‘ON CPU’ by New ASH in 12c R2

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

,

Oracle数据库当遇到存储磁盘坏道时的处理(DBV-00102)

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

,

Oracle19c手动清理PDB SYSAUX中的大对象如WRI$_ADV_OBJECTS (ORA-65040)

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

Troubleshooting 19c RAC CRS resource db show “UNKNOWN” state , srvctl start instance CRS-2680

有套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 12c ora-4031 “ges resource dynamic” lot of FB resource cache

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,这里简单记录。

,

Oracle12c-19c如何防止安全检查查出弱密码?

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

Oracle19c使用USE_LARGE_PAGES可在LINUX平台的自动配置hugepage

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.

,

19c Flashback Standby after Flashback (resetlogs) on Primary In Dataguard Environment

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

,

Alert: 12c top-N fetch first错误的执行计划 19c已修复

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 19c RAC新特性 : Automatic Failback of a Service

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

Alert: In Oracle ADG, if the redo apply instance crashes, all other instances will from ‘OPEN’ to ‘Mount’

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

,

12c注意 instance terminal caused by ASMB process ORA-04031 init_heap_kfsg

上个月刚刚分享了一个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-4031 “init_heap_kfsg”占用大量内存 In 12c, 18c, 19c

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

,

12c R2 DB Alert Log频繁输出”An internal routine has requested a dump of selected redo”

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

,

19C: 非第一个节点执行 Root.sh 提示 “ERROR 4 OPENING DOM ASM/SELF IN 0xNNNN”

2020/08/10 16:02:13 CLSRSC-325: Configure Oracle Grid Infrastructure for a Cluster … succeeded
昨天一客户安装19c在非第一个节点运行root.sh时,提示下面的错误,但是检查实例状态都已启动正常。
Error 4 opening dom ASM/Self in 0x9e3add0 <------------- Domain name to open is ASM/Self <------------- Error 4 opening dom ASM/Self in 0x9e3add0

Troubleshooting ORA-04031: unable to allocate 13840 bytes of shared memory “ges resource dynamic” in 12C+

在12c 版本以后”ges resource dynamic”逐渐增长最终导致shared_pool可能会超过手动管理的shared pool size达到sga_max_size后出现ora-4031. 与之相关的oracle bug就好几个,这最近因为这个问题导致lmd hang堵塞了其它实例的前台进程,关掉了这个节点临时恢复,简单记录。

, ,

Oracle 19c hot backup mode? (一)

没有维护过oracle 8\9那个版本时,可能不会太接触这个热备份模式, 这个技术已经被RMAN所替代很多年,但是就是这个东西,让我们在最近一次19c 数据库故障中走了弯路, 数据库的内部某个机制触发了begin backup, 因为异常crash后又归档缺失,还尝试从备份做了恢复,最终还是使用bbed修改数据文件头异常恢复

,

Troubleshooting ORA-600 [KKZGPKORID] impdp from 11G to 19C

ORA-39014: One or more workers have prematurely exited.
ORA-39029: worker 1 with process name “DW00” prematurely terminated
ORA-00600: internal error code, arguments: [KKZGPKORID], [0], [], [], [], [], [], [], [], [], [], []