Scripts: Tablespace Report for Oracle 12c Multitenant Database
You can use this SQL script to report tablespace space details in 12c Multitenant database.
weejar zhang
Wait Event: buffer deadlock
Buffer Deadlock is very typical wait event and not so much seen in database. But when you are encountering with this mysterious wait then you would see the effect of wait and performance bottleneck of the server.
Troubleshooting sqlplus logon instance slow and Swap usage high even memory is 50% free
A few days ago, I encountered a case, a 11.2.0.4 three-node Oracle RAC database on RHEL 6.6 , when trying to login to the database instance using sqlplus “/ as sysdba” on the third node, It’s very slow, and vmstat show that there is a very large swap in and out, but there is still a lot of memory free space
Troubleshooting Out-Of-Memory(OOM) killer db crash when memory exhausted
If kernel can not find memory to allocate when it’s needed, it puts in-use user data pages on the swap-out queue, to be swapped out. If the Virtual Memory (VM) cannot allocate memory and canot swap out in-use memory, the Out-of-memory killer may begin killing current userspace processes.
Oracle12c R2注意事项： Active DataGuard logon fail with ORA-00604& ORA-04024
一套12c R2 4-nodes Oracle RAC on RHEL 7的环境，已安装0417 RU。 该库有一套Phyical DataGard， 同时也是GoldenGate的target端，存在一个replicat 进程同步数据，因为OGG的认证导致ADG hang最终使归档删除失败。
MySQL 5.7 使用diagnostics() Procedure生成”AWR” Report
Oracle Database有强大的AWR报告分析整体的服务器性能问题， 但是MySQL之前是没有的，需要自定义大量的脚本生成监控数据， 从MySQL 5.7 (5.7.9)开始，可以使用sys.diagnostics()存储过程依赖于PERFORMANCE_SCHEMA，生成类似于Oracle AWR一样的MySQL性能报告。
Troubleshooting Internal error ora-600 [kxspoac : EXL 1] after enable 10503 event
简单记录一下这个内部错误 ora-600 [kxspoac : EXL 1], 环境11.2.0.3 RAC on hpux ia, 这是一个并行查询相关的错误，当启了10503 event后并行查询带绑定变量的SQL时有可能会出现此错误。
query dba_free_space(tablespace usage) slow after upgrade 12c R2
前不久有个下线EXADATA并同时从11g R2 升级12C R2的案例，反应升级12c后明显感觉原来查询表空间使用率的脚本时间比升级前长了很多, 要花好几分钟， 这种情况时通常是因为recyclebin$回收站中的对象太多，清理回收站解决， 但是这次的回收站并无多少对象(<100)， 这是一个50 TB左右的数据库，有350个左右的数据文件。
Oracle12c R2注意事项： SCM0进程的CPU使用率高
本篇是12c版本中cpu high的第三种情况: scm0进程占用较高的cpu使用率,(Distributed Lock Management )DLM Statistics Collection and Management从属（SCM0）后台进程负责收集和管理全局入队服务（GES）和全局缓存服务（GCS）的统计信息。如果在数据库中启用了DLM统计信息收集此进程（scm0）才会存在…
Oracle12c R2注意事项： 多个”/usr/bin/ssh -o StrictHostKeyChecking… /sbin/ifconfig -a”进程导到CPU使用高
为了当分析节点重启和节点驱逐故障时，避免因缺少网络和操作系统级信息无法定位，引入diagsnap并与GI集成，diagsnap是12.1.0.2 GI引入的新进程，CHM的osysmod管理diagsnap资源，该资源收集弥补CHM通常不收集的其他OS统计信息…
Oracle12c R2注意事项： 大量crsctl.bin进程cpu使用率高，等待crs call completion
前不久遇到的一个问题，一套12.2的RAC环境， CPU使用率高，使用top可以看到有大量crsctl.bin进程导致， sys cpu占用了大部分， 如果从数据库内查看等待会伴随着wait event “crs call completion”,
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都无法生成。
Alert : 当在AIX 7.1/7.2使用AIX Flash Cache 读写/dev/pfcdd0时System crashes
这次预警主要是因为AIX的新特性Flash cache device相关的bug引起的ORACLE 数据库可用性风险， 虽然坑是AIX挖的，但是对于装数据库和巡检(RDA），DBA及客户就是直接受害者。 OracleDBA在使用RDA巡检运行在AIX 7.1 、7.2上使用了ASM 的数据库时可能会把库查死
Oracle19c新特性: hint report
在oracle 19c引入了新的format option “hint report”, hint report 显示我们sql文本中使用的hint, report body中会显示hint对应查询块hint是否使用， display_xplan的TYPICAL默认只是显示无效的hint.
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小时运行测试。这种对稳定性的关注远不止核心数据库功能
Troubleshooting 12C node2 CRS start fail with ORA-12547 and ORA-15077 in Flex ASM 案例
在12c以前的版本数据库实例使用操作系统认证连接ASM实例，因为ASM CLIENT(DB INSTANCE)和ASM Server总是在同一个主机上， 从12c版本开始引入的FLEX ASM架构允许数据库实例可以和ASM运行在不同的主机中
浅谈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 相关