Oracle12c R2注意事项: 多个”/usr/bin/ssh -o StrictHostKeyChecking… /sbin/ifconfig -a”进程导到CPU使用高

为了当分析节点重启和节点驱逐故障时,避免因缺少网络和操作系统级信息无法定位,引入diagsnap并与GI集成,diagsnap是12.1.0.2 GI引入的新进程,CHM的osysmod管理diagsnap资源,该资源收集弥补CHM通常不收集的其他OS统计信息…

How to release still “killed“ status session in v$session? (释放killed的session) (四)

继续一个killed无法释放的案例, 环境是11.2.0.4 2nodes-RAC on SELS11, 开始是数据库突然出现了非常高的负载wait event是“enq: SV – contentio”,“row cache lock”,“enq: SQ – contention ”, 因为这个事件KILL了一批进程,后期发现有个进程始终是KILLED状态,并且同时影响后期的AWR都无法生成。

Oracle19c新特性: 自动索引(Automatic indexing)

Automatic index是有索引管理后台进程TASK调用, 可以自动的create, rebuild , drop 索引。后台进程是每15分钟调用一次,(是有j001进程执行_AUTO_INDEX_TASK_INTERVAL参数控制15分钟)。也是基于传统手动优化SQL的思路,基于SQL中的列使用识别可以创建的索引,然后验证自动索引对性能的影响,然后按预设的值去创建索引,只不过整个过程是自动的,并且整个过程都有审核报告。

浅谈Oracle Database 19c

Oracle Database 19c是大多数客户将其升级目标定位的版本,Oracle已将稳定性作为此版本的核心目标。 在Oracle Database 19c中,开发人员专注于修复已知问题,而不是添加新功能。 这导致了数百人年的测试和数千台服务器每天24小时运行测试。这种对稳定性的关注远不止核心数据库功能

浅谈Oracle GoldenGate 18c

2018年的10月份发布了oracle goldengate最新版本 18c(18.1),下载时分别对于oracle db就两种安装文件: 传统Classic 架构和微服务Microservices架构

2018年终总结

每年都习惯性的记录当年的“足迹”, 今年是开BLOG的第10个年头, 显然我已到了喝水都要放枸杞的年纪,没有了年轻时的时间和精力, 但未忘初心,坚持不易,希望给大伙分享更多的”锦鲤”。 数了一下目前已记录了845篇笔记,不算多也不算少。 环顾2018年,或许欢乐,或许忧伤, 经历些许还未准备好又是中年该面对的问题,曾一个小同事开玩笑说如果他像我经历的今年事一样,可能就去报复社会了,(_o_)!。 我的2018: 跟医院还是少不了的交集,希望各位及家人新的一年都能有个好身体 跟公司去认识了一下越南(北越) 现在带娃出门就跟搬家似的,活动也少了 睡个懒觉就跟过年似的,时间可贵,报了快一年的驾照,科目1才刷了1个课时 天天劳碌无休止就跟判了无期徒刑似的,而且今年还加刑了 年中意外从堆积的邮件里发现了2月前的一个ORACLE 给的一个ACE -A的消息 经历了繁重的装修过程,今年也算是高于段落,乔迁新居算是一喜事 家里没矿,工作一刻不能停歇, 换了一新东家 一些忘了的事…   新的一年,祝愿各位在“猪”年, 每觉睡到自然醒。 我们 “佩奇”一家给您拜年。   好嗨哟,感觉人生已经到达了高潮,感觉人生已经到达了巅峰…  

Troubleshooting “latch: row cache objects” case and Event 10089 to do.

“row cache objects”是序列化latch,用于保护对SGA中dictionary cache的访问。 只要是参考dictionary cache中的元数据对象,就会获取此latch。 Row Cache Objects Latch 是 shared pool latch 相关。”row cache objects”是序列化latch,用于保护对SGA中dictionary cache的访问。 只要是参考dictionary cache中的元数据对象,就会获取此latch。 Row Cache Objects Latch 是 shared pool latch 相关

Troubleshooting ORA-600 issue related to memory curruted when using DBLINK

前段时间的一个案例,突然好几个数据库出现了ora-600 坏块相关的错误, 但是幸运的是使用rman, dbv, analyze table validate structure 都没有实际的坏块, 也就是说很可能只是出现在memroy 中,目标和源都是11.2.0.3.7 2nodes RAC, 最终是确认了为Procedure中使用了DBLINK触发

ORACLE SCN issue Best Practice (最佳实践)

Recently, we have faced a very serious problem with Oracle SCN. The SCN with a production env ORACLE RDBMS grows very fast, the SCN rate is more than 30k per second . In theory, there should not be such a high transaction volume. The environment is a 11.2.0.3 2-nodes RAC ON AIX 6.1 platform, and have applied PSU11.2.0.3.7 .

Oracle12c R2注意事项: 因BUG生成大量的trace file 包含KRB: (rman module)

升级了Oracle 12cR2的同学,尤其是安装了2018 4月RU的版本(12.2.0.1.180417), 遇好检查下你的trace目录下是否生成了超大量的trace file,或单个超大的trace file文件,因为在这个版本下有两个原因很可能生成这些trace:
1. Trace files generation with message “AUTO SGA: kmgs_parameter_update_timeout gen0 0 mmon alive 1”.
2. Trace files generated from RMAN module with KRB messages.

Oracle12c R2注意事项:DB password file in ASM (DataGuard环境重建PWD)

2C中为了在不同实例间统一的密码管理, 支持把DB密码(ASM password same)存储到ASM DISKGROUP中,这样在维护DG环境时,当同步密码文件时就要先确认一下密码的位置, 同样DG端也可以把密码存储到ASM中,然后使用srvctl modify database修改pwd路径. 这个案例通过在标准化DG配置中因密码不一致产生了各种错误

How to delete SYS.KUPC$ service after kill datapump job

本11.2.0.4 2-nodes RAC, 现象是service_name 参数出现了一些SYS.KUPC$ 的service, 监听上同样有,且停节点1 ,service会漂到节点2, 重启双实例后同样存在, 手动修改service_name可以临时解决,但是重启实例还是会存在,虽然是新增service, 监听上看着乱,其它没什么影响, 这类服务常见于datapump 自动增加的…

Troubleshooting ora-600[ktecgsc:kcbz_objdchk]&ora-600[qesmaGetTblSeg1] when inserting and ora-7445 [kss_first_child] when granting

又近年末,各种事情忙的不可开交, 但最近的BUG又突然接二连三, 争取把在2018年的最后几天习惯性简单的总结了结, 这篇简单的记录一下上个月一套11.2.0.4 2-ndes RAC的案例, 问题发生的第二天说有个表还是不能insert和grant, insert报ora-600[qesmaGetTblSeg1]  和grant 报 ora-7445 [kss_first_child] ,得知事前有对该表做truncate, 这是一个HASH分区表, 相同的表结构在用其它表名一切正常,但是rename tabler后问题又能重现, 包括把表删了重建问题依旧。 下面来还原这个问题: SQL> CREATE TABLE ANBOB.LOC_ANBOB_VARLOG 2 ( “OID” NUMBER(14,0) NOT NULL ENABLE, 3 “VARIABLEID” VARCHAR2(32) NOT NULL ENABLE, 4 “SQLBANDVAL” VARCHAR2(256), 5 “RUNTIME” VARCHAR2(32) NOT NULL ENABLE, 6 “INTIME” DATE DEFAULT sysdate 7 ) PARTITION BY HASH (“OID”) … Read more