Oracle 12cR1, Shutdown abort of a PDB seems to perform commit ，a bug?
看到一篇笔记 Oracle 12cR1, Shutdown abort of a PDB seems to perform commit 提到在12r1 存在一个奇怪的现象，shutdown abort 在当前会话会执行隐式提交， 这有点颠覆我们之前版本中的理论， 我们都知道shutdown abort 应该是rollback 当前未提交的事务
weejar zhang
sql patch和sql profile 解决Index join SQL性能故障
前面的方法我们还原了问题现象，因为CBO使用错误的统计信息，使用了INDEX_JOIN的方式， 现在尝试如何快速的解决该问题，也就是禁用INDEX_JOIN或使用我们指定的执行计划。
Index join SQL性能故障 之 通过恢复统计信息还原SQL问题
SQL涉及表的所有字段都有索引，不过分布在两个索引上，ORACLE 优化器会选择了使用index join的执行计划，避免了对table的访问路径， 因当时cpu过高，查询慢没成功记录两个索引的分区信息..
How to release still “killed“ status session in v$session? (释放killed的session) (二)
前几日发现有套数据库的连接数有些异常，查看当时的session时发现还存在大量的”killed”状态的会话存在v$session 视图中，确认几个小时前有从数据库做过alter system kill session
The “abnormal” table column , Function index ，VIRTUAL column，unused column （说说那些sys_开头的列名)
有时从dba_tab_cols看到的表名是奇怪的sys_开头，有时在desc table时不显示，这里记录一下 Function index \VIRTUAL column \ unused column对列的影响,除了unsed column会把列搞的很“不一般” ，还有一些特殊场景。
2015年个人年终总结
2015已跑远，在春节放假前一天，交上迟到2015年个人考卷，长话短说简单总结一下：
anbob@life>select things from time where year=2015;
Shell: To delete listener log file contains text and xml format (自动清理监听日志)
整理的一个清理Oracle数据库监听日志的脚本，可以部署到监听进程的owner用户的crontab中(RAC通常是grid, 单实例通常是oracle), 实现的是监听日志大于1GB时，归档监听日志文本格式的文件如listener.log ，自动压缩保存， 后期循环自动覆盖， 11G 引入的ADR, XML格式的文件19c前也无法自动清理，这个shell 目前是自动rm 7前天的， 关于19c 的日志自动清理后期会分享
Tuning: Temporary table don’t collect statistics (临时表不要收集统计信息)
对于临时表不应该收集统计信息，TEMP TABLE是会话级数据，因为每个进程可以填充的数据不一样， 手动收集的统计信息如果不在insert的会话为0 ，影响了CBO生成正确执行计划
How to restore database only have previous datafile and archive log Rman backupset？(只有数据文件和归档日志备份集的恢复)
元旦期间帮一朋友恢复了套数据库, 情景是这样的，25号0时有做RMAN 0级备份含datafile和当时的archivelog，25号白天删除了一个非常重要的表空间， 现在需要恢复那个表空间，是一套单实例的11.1.0.6 的WINDOWS平台的数据库， 接手时只有上面的6个备份集文件(只有DATAFILE AND ARCHIVELOG)和软件,和当前的control file
Why do drop tablespace completes the space is not available as free yet in ASM Diskgroup?（删除tablesapce后, ASM空闲空间没变）
前天有套库发现表空间分了很大但是使用的非常少，想收回多余浪费的空间放回ASM，删了两个表空间应该可以释放1T左右的空间，但是ASM DISKGROUP的free space时，并没有增长， 也就是删除的空间没有释放， 开始以为遇到了BUG， 其实原因很简单， 只是在这简单记录这个问题的提个醒。
Sessions remains and increase cumulatively never close if you use DEDICATED with XA transaction + shared dblink.
A web application using Tuxedo always keep 50 long connection to local database which then issues a SELECT from local db to remote db over shared db link(it’s created last weekend). But to run for a period of time after the found the remote db sessions become full(ora-18)
Troubleshooting ORA 600 [ktspfmdb:objdchk_kcbnew_3] 案例
前段时间数据库出现了几次ORA 600 [ktspfmdb:objdchk_kcbnew_3]错误，引起该错误的是一条insert sql.
Troubleshooting these are too many scheduler jobs(owner sys) name like KWQICPOSTMSGDEL_nn in DB 11g
I faced a very interesting question today, An oracle database 11.2.0.3 RAC database ON hpux one had to many scheduler jobs , And the job’s owner is sys, All jobs name all like ‘KWQICPOSTMSGDEL_’, All these jobs has no start date as well no interval.
How to estimate the cost if partition table missing partition level statistics ?（缺失分区表级统计信息如何计算多分区扫描的COST）
首先查看表的统计信息，分区表的统计信息分global stats(DBA_TABLE)和partition stats(DBA_TAB_PARTITION),发现该分区表是global stats 有，partition stats全为空， 查看该SQL发现有两个子游标有不同的执行计划
Troubleshooting ORA-600 [k2srec: should be another instance]
Problem Key: ORA 600 [k2srec: should be another instance]
Error: ORA-600 [k2srec: should be another instance] [2] [] [] [] [] [] [] [] [] [] [][00]
with the following stack :k2srec <- k2serv <- opiodr <- ttcpip
The Oracle Listener ofen restart and ora.net1.network check fails on HPUX (监听频繁重启)
上个月有套库的listener总是自动stop， 因为是crs的资源又被agent重新拉起，前几次的监听故障中都提到过listener依赖于network资源， 以前也处理过网络打嗝可能会导致监听频繁重启的案例，本次参照该案例修改弱依赖的方式无法避免该问题
The FG(server process) and remote node LMSn process communication over the interconnect?(用户进程会和另一节点的LMS进程直接通信么?)
应该存在local SERVER process和remote LMS process通信， 原厂的工程师给我看了他们的白皮书来证明应该只有LMS和LMS通信，究竟是什么情况， LMS会不会直接和远程的SERVER进程通信？
如果listener.log 不可写会怎样？ DBGRL Error: SLERC_OERC, 48180
listener会记录通过监听访问数据库的信息在listener.log，包括tnsping 监听的，但是如果listener.log不可写，监听会不会挂？ 前几天清理目录发现了这个有个目录增长比较快，在listener的trace 目录下(11g的 ADR目录diag/tnslsnr/anbob1/listener/trace)生成了一些奇怪的trace文件如下
‘latch: cache buffers chains’ & Don’t underestimate the rownum = 1
CPU + Wait for CPU CPU 21.64 41.99
log file sync Commit 21.63 41.97
enq: TX – row lock contention Application 19.71 38.23
buffer busy waits Concurrency 5.86 11.36
latch: cache buffers chains Concurrency 5.30 10.29
Performance tuning ‘wait for a undo record’ event
前几日一个数据库的负载非常高，查看数据库的活动会话发现大部分session在等待’wait for a undo record’的事件， 该事件通常发生在fast-start parallel rollback, 该特性通常是在SMON进程发现存在一个长时间的事务需要回滚，或遇到PARALLE DML需要回滚时，超过一定量的回滚任务时自动启动多个server process的并行回滚