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对此进行了更改,增加了自动回归。

‘transaction’ event 2 & How to find dead transaction?

6年前记录过这篇关于“transaction” eventTuning “transaction” & TX lock wait event ,speeding up rollback dead transaction,今天补充些取其它信息.如何找到哪个事务dead。

,

Oracle 11g R2 rman spin 产生大量aud trace

本地文件系统使用率告警,分析发现audit目录下不断的生成trace文件,该目录记录的是sys登录,目前以每秒800-900KB的速度生成写日志属于一种不正常现象,先增加crontab 周期清空日志,是当前版本的一个rman相关的bug,

,

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不是应该高可用吗?为什么死一个节点另外的节点也要跟着受影响?

,

Troubleshooting db instance start failed PRCR-1064 CRS-2643 or CRS-2717 CRS-0223 during patching

12c注意 instance terminal caused by ASMB process ORA-04031 init_heap_kfsg上篇提到了这个bug,在安装bug是不是很顺利分享一下。CRS-2717: Server ‘anbob2’ is not in any of the server pool(s) hosting resource ‘ora.stbydb.db’
CRS-0223: Resource ‘ora.stbydb.db’ has placement error.
clsr_start_resource:260 status:223
clsrapi_start_db:start_asmdbs status:22

, ,

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? (二)

When taking hot backups, the file header is frozen while the file is being copied. This means that each data file can have a different checkpoint in your backup set. To make the backup set consistent, all files need to be recovered until their SCNs match again and the fuzzy bits have been reset.

Oracle 19c hot backup mode? (一)

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

,

Downgrade Grid Infrastructure 12.1.0.2 to 11.2.0.4降级后crs无法启动 No voting files found

Last month, after a set of Exadata test environment of our customer environment was downgraded,Downgrade Grid Infrastructure 12.1.0.2 to 11.2.0.4, the downgrade operation was successful, but when starting the CRS, it prompted that the VD could not be found, and the VD checked that it exists.

,

Troubleshooting dbms_sqltune ORA-04068 ORA-04065 ORA-06508 ORA-06512 在做异常恢复后

前几日有个库sysaux和部分业务表空间数据文件损坏,在数据库强制异常恢复后, 提示dbms_sqltune使用sql profile无法使用,这个问题与对象的先后创建顺序或部分重建导致,错误信息如下,这里我还原一下问题和分享一下思路。

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], [], [], [], [], [], [], [], [], [], []