ANBOB™

前几天看了篇日志自己一直没注意的小细节，利用开会儿的功夫做了个测试，因为维护的环境数据库中存在数万数十万的分区表， 平时维护时确实应该注意。环境11.2.0.4 这里就展示两个内容
1， 表上不同的分区初始化segment大小，在split partition时的segment大小继承方式。
2， truncate partition 会使手动unusable的分区索引变为usable.

去年在排查SCN 天花板问题修改相关的几个参数时，发现了这个问题，尤其如果是从别人手中接手的数据库，通常从opatch lsinventory 检查数据库的版本和补丁信息，在12C 的版本中也可以使用DBMS_QOPATCH, 但是有一个库发现之前别人挖了个坑实际安装补丁时应试是出错了，但是从opatch lsinventory查看两节点并没有区别 .。。。

前两天一同事的数据库alert log不停的在刷出ora-600 [ktbdchk1: bad dscn]错误，影响的是一张table上的insert语句， 前不久该数据库存储出现过故障，从已知BUG中没有找到相似案例，这里只是简单的记录一下问题的处理过程。

前不久有个朋友从遇到了个问题，在数据库启动过程种出现ora-7445, 然后数据库CRASH, 环境11.1.0.7 windows 版本， 临时禁用了smon tx recovery打开数据库, 没有再继续跟踪，这里记录一下.
ORA-07445: exception encountered: core dump [intel_fast_memcpy.A()+18] [ACCESS_VIOLATION] [ADDR:0x19DC0000] [PC:0x52B428E] [UNABLE_TO_WRITE] []

前几日有11.2.0.3套库出现了性能问题，这里简单记录， 当时只是表现几个会话的同一条INSERT SQL语句出现了较高的latch: undo global data 等待，latch miss是 ktudba: KSLBEGIN ，同时还有BBS 等待

ORA-00600: internal error code, arguments: [ddfnetCFull-4], [Invalid Handle], [], [], [], [], [], [], [], [], [], []
—– Current SQL Statement for this session (sql_id=0wjqfgz9dqsjp) —–
select null from srp.interface_comm@srp1
where rowid = :plsqldev_rowid
for update nowait

之前记录过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过高，查询慢没成功记录两个索引的分区信息..