ANBOB™

之前记录过Frequent generate a lot of cdmp* directories contain *bucket trace in bdump ， 当时根据现象与该bug 很相似，该bug解决的只是不生成cdump还是会生成trace 文件，所以要分析生成trace的根本原因。之前数据库在诊断问题时也启用过相关trace event（见下面） ， 但是instance memroy 级别实例重启后不再生效

环境是一套11.2.0.3 2nodes RAC on hpux-ia31, alert中出现ora-32701 hangmgr错误， 从trace文件中发现是m000进程是mmon的辅助进程，用于flush AWR相关数据，有一个wait event: enq: WF – contention, 这也是flush AWR数据时相关的enqueue等待，但是blocker进程是not in wait

ORA-00600: internal error code, arguments: [kghstack_alloc], [define handles], [], [], [], [], [], [], [], [], [], []
***** Current SQL Statement for this session (sql_id=5udxh0ykgshkb) *****
select location_name, max(r.reg_id) from reg$ r left outer join gv$subscr_registration_stats

解决在虚拟环境中的RAC环境下，当虚拟物理机的public network 失败时，(虚拟主机网卡)virtual nic依然active, VIP 或 Scan IP未按预期发生Failover的问题。

前段时间配的一套11203 RAC ADG on EXADATA Machine的环境，在ADG 的standby side的node2 通过dblink查询时提示ora-1089错误，但是在node1 查询正常，DG的recover 进程是在node1 上..

最近有套库突然目录使用告警，发现TRACE 目录使用较高，发现在bdump 目录中每分钟都生成一个cdmp*目录，且每个目录中含大量的文件，这是一套oracle 11.2.0.3 rac on hpux 11.31的数据库，

该环境是主备两套11.2.0.3 2-NODES RAC ON EXADATA Machine ，存储在ASM， 数据库70TB 大小， 闲时每天1T归档日志， 忙时每天可达4T+归档， 之前朋友重建DG一直使用主机上一个shell 放后台，我查看了该shell 确实不算复杂，但是duplicate 一直hang在开始

10.2.0.4 2nodes Oracle RAC ON HPUX 平台的环境， 计划升级到10.2.0.5， 前期升级clusterware 软件非常顺序，可是在跑root102.sh时还没跑完主机突然reboot， 尝试启crs 报错：The clusterware daemons are running from . But you are patching /oracle/product/10.2.0/crs10g

在做一个普通的分区表（HEAP TABLE）收集统计信息时进程报错意外终止，后台日志未出现ora-600等内部错误，这是一套11.2.0.3.7 oracle RAC 2-nodes on HPUX-ia 11.31的运行环境，这里简单的记录一下排查过程。

SQL> exec DBMS_STATS.GATHER_TABLE_STATS (ownname => ‘ANBOB’ , tabname => ‘TAB_ERROR’ , cascade => true, estimate_percent => dbms_stats.auto_sample_size,method_opt=>’FOR TABLE FOR ALL COLUMNS SIZE REPEAT’, degree => 8,no_invalidate=>false);

*
ERROR at line 1:
ORA-20011: Approximate NDV failed: ORA-12801: error signaled in parallel query server P001, instance qdim1:im1 (1)
ORA-01722: invalid number

ORA-07445: exception encountered: core dump [LpxFSMSaxSE()+449] [SIGSEGV] [ADDR:0xFD26CFB5] [PC:0x400000001117F881] [Address not mapped to object] []
—– Current SQL Statement for this session (sql_id=6qt1f1pg1dkzs) —–
SELECT UPPER(XMLType(CHR(60) || CHR(58) || CHR(113) || CHR(120) ||

在OEL5.8 安装12C R2 beta1时 遇到ins-30131错误， 以前在OEL5装过12c R1,这个错误第一次见，错误日志有两个关键字
”[INS-13001] Environment does not meet minimum requirements.
[INS-30131] Initial setup required for the execution of installer validations failed.

看到一篇笔记 Oracle 12cR1, Shutdown abort of a PDB seems to perform commit 提到在12r1 存在一个奇怪的现象，shutdown abort 在当前会话会执行隐式提交， 这有点颠覆我们之前版本中的理论， 我们都知道shutdown abort 应该是rollback 当前未提交的事务

前面的方法我们还原了问题现象，因为CBO使用错误的统计信息，使用了INDEX_JOIN的方式， 现在尝试如何快速的解决该问题，也就是禁用INDEX_JOIN或使用我们指定的执行计划。

SQL涉及表的所有字段都有索引，不过分布在两个索引上，ORACLE 优化器会选择了使用index join的执行计划，避免了对table的访问路径， 因当时cpu过高，查询慢没成功记录两个索引的分区信息..

前几日发现有套数据库的连接数有些异常，查看当时的session时发现还存在大量的”killed”状态的会话存在v$session 视图中，确认几个小时前有从数据库做过alter system kill session

有时从dba_tab_cols看到的表名是奇怪的sys_开头，有时在desc table时不显示，这里记录一下 Function index \VIRTUAL column \ unused column对列的影响,除了unsed column会把列搞的很“不一般” ，还有一些特殊场景。

2015已跑远，在春节放假前一天，交上迟到2015年个人考卷，长话短说简单总结一下：

anbob@life>select things from time where year=2015;

整理的一个清理Oracle数据库监听日志的脚本，可以部署到监听进程的owner用户的crontab中(RAC通常是grid, 单实例通常是oracle), 实现的是监听日志大于1GB时，归档监听日志文本格式的文件如listener.log ，自动压缩保存， 后期循环自动覆盖， 11G 引入的ADR, XML格式的文件19c前也无法自动清理，这个shell 目前是自动rm 7前天的， 关于19c 的日志自动清理后期会分享

对于临时表不应该收集统计信息，TEMP TABLE是会话级数据，因为每个进程可以填充的数据不一样， 手动收集的统计信息如果不在insert的会话为0 ，影响了CBO生成正确执行计划

元旦期间帮一朋友恢复了套数据库, 情景是这样的，25号0时有做RMAN 0级备份含datafile和当时的archivelog，25号白天删除了一个非常重要的表空间， 现在需要恢复那个表空间，是一套单实例的11.1.0.6 的WINDOWS平台的数据库， 接手时只有上面的6个备份集文件(只有DATAFILE AND ARCHIVELOG)和软件,和当前的control file