最近一周遇到了好几个case，简单的总结一下，跟大家分享.


CASE 1.


某客户的一套9208的库，在跑批处理的时候，异常crash了，其中alert 信息如下：

从上面的Bad header found during preparing block for write 信息可以看出，dbw0进程在写数据库的时候，
发现这个block header信息异常。我们知道 tail=scn后4位+flg+seq 根据这个规则来看，很明显信息不对。

单从这个ora-600错误来看，metalink也有相关的文档解释，总的来说就是bug，这里根据
16831000 为10进制，首先转换为16进制，然后再转换为 file 4 和 block 53784，即得到上面的坏块号。
metalink 文档，大家可以参考ORA-600 [kcbzpb_1] [ID 139011.1] 其中提到的

bug 6401576 9.2.0.8.P22 OERI[ktbair1] / ORA-600 [6101] index corruption possible

跟我这里遇到的情况基本上一致，对于这种逻辑错误，根据oracle的解释，startup实例即可消除问题。


CASE 2.


某客户的其中一套10203 rac(asm)的某个节点出现ora-600错误，alert信息如下：

从其中的某个trace文件，我发现了如下内容：

其中找了两篇比较有价值而且比较靠谱的文章，如下：

Getting Ora-600 [kdsgrp1] On A Select [ID 429746.1]
After Upgrade To 10203 ,Select * From Gv$Aq Returns Ora-00600[kdsgrp1] Or [Qertbfetchbyrowid] [ID 603095.1]

最开始看ORA-600 [kdsgrp1] [ID 285586.1] 这篇文档的时候，我感觉这个问题很可能就是bug，然而看了上面2篇文章以后，
感觉不见得一定就是bug，另外还看了好几篇文档，都是与index相关或CR相关的，所以我断定这个问题是index和table之间
的数据不一致导致的。

其中Getting Ora-600 [kdsgrp1] On A Select [ID 429746.1] 这篇是最有价值的，提供了一个解决思路：

首先根据ora-600错误提到的file和block号，定位到具体的对象：

然后从trace中搜索 Plan Table，找到执行计划，根据前面查到的对象，然后确定到具体的index名称。

最后drop和recreate该index即可解决该问题。
补充：从别的trace中，还发现了update语句出现该错误，如下：

从而我确定是表pagelayout上的某个index出现问题。


CASE 3.


上周出差到吉林某客户，巡检时发现某套rac的awr居然没有生成，而且手工创建快照也没反应。总之说来，
比较怪异，而且还发现某个节点的/oracle 一共20g，oracle本身才8G左右，另外的12g不知道被什么东西
占据了，ls -ltr居然无法看见，经主机工程师检查，发现是diag进程占据了12g的磁盘空间。

在操作之前，我做了一个systemstate dump，对该dump我简单的分析了一下，发现了如下有用信息：

2929152/3600/24=33天左右。换句话说，pmon进程在1个月前就出现异常了，同事也说5月26号的时候重启过，
后来似乎就有问题了，掐指一算，时间似乎刚刚对上。

最后我在中午申请了一点停机时间，我们进行了处理，首先我kill了diag进程，12g的磁盘空间得到了释放，
最开始我断定是lck进程导致的，于是kill了该进程，结果直接导致该节点重启了，不过还好的是，23s就重启完成了。


CASE 4.


这个是昨天的一天case，某个客户方工程师的一套hp 9204系统（HA）环境，记得是我以前部署的。
客户工程师给listener设置密码以后，用脚本来启动监听，发现报错，非常的奇怪，信息如下：
TNS-01169: The listener has not recognized the password

当时他的脚本如下：

但看脚本，似乎没啥问题，最后我才发现是有问题，那也是折腾1个小时之后才发现的，几个同事一起看，都没发现问题的所在。
老实说，我也偶然发现的，记得快下班的时候，想起了老白的一句话: 像oracle一样思考

想到这句话，突然另我茅塞顿开，我当时是这样认为的：

==> 既然我们要对listener设置密码，那么必然是为了安全性；
==> 通过set password roger 加到脚本中来启动，要是有读权限的用户不就能看到密码了吗？那还谈何安全性呢？
很明显，这里就自相矛盾了；

于是我尝试将脚本修改为如下：

再次执行，发现居然ok了，最后我又想，既然是要输入加密后的密码而不是明文，那么metalink文档应该有明确的说明啊；
记得在开始遇到这个问题之后，我也看了metalink文档

How To Start/Stop A Password Protected Listener From A Script [ID 361919.1]

但是只是扫了一眼，没有引起重视，最后解决问题以后，我再次看了下，原来如此:
set password encrypted_password — 其实文档是明确说了，要输入加密后的密码

这当然说明了我当时太马虎了，不过也确实容易忽略。

补充一下，如果在10g中进行类似的测试，本机操作需要设置参数LOCAL_OS_AUTHENTICATION_为off。