每天工作中会碰到一些问题，圈内朋友也会有各种问题，解决问题总是能够带来很大的成就感，有时候感觉在做两份工作。：）
帮助别人的意义就在于别人碰到的坑，你可能也会碰到，别人遇到的坎，也可能是以后你会面临的，坑填平了，坎越过去了，对己对人都是好事，知道那些坑，自己就会绕过去尽量规范，不要去犯；有哪些坎，出了问题之后，自己也知道该怎么处理，所以说是双赢，何乐而不为。
当然了，帮助别人，本职工作是保证。本职工作也要不断改进优化，其实你没意识到的问题，其他人可能早就用更高级的方法来做了。
###问题1
比如之前自己使用脚本批量对防火墙赋予权限，思路就是通过代理服务器来生成批量的脚本，然后把一个预先写好的脚本拷贝到所有的DB服务器上，就是图中1号的标示，然后在每个DB端都相应执行防火墙开启的脚本，当时这个过程差不多400多个这样的操作大概需要10多分钟。详细的可以参见。http://blog.itpub.net/23718752/viewspace-1815276/ http://yangjianrong1985.blog.163.com/blog/static/789687201591411656609/ 里面有更详细的介绍。

不过虽然工作更高效了，但是今天和同事讨论发现还是有很大的改进空间，比如db服务器有3台，对2个客户端开启防火墙权限，那么这种组合方式就有2*3=6种。
如果按照之前的设想，应该是生成6个脚本，也就意味着每次调用都需要重新ssh连接执行同样的脚本，然后断开，可以考虑把这个处理过程打包，像3台DB服务器对2个客户端开启防火墙权限，可以精简为生成3个脚本，直接ssh到不同的DB服务器上，然后一次性执行两个客户端的处理，这样ssh反复连接的问题可以减少近一半，而且效率也会提高差不多一半。
如果把这个过程放入到成千上万台服务器中，这种处理方式就会高效的多，所以还是得有工匠精神，不断细化自己的工作。自己也在琢磨是否有必须要把这个过程嵌入到Html页面中，目前还没有成果。

#问题2
下午有个朋友发了一个问题，说是awr生成失败，无法调取近一天的快照信息，最开始看到这个问题，感觉应该是一个很简单的问题，即这是一个新库，还没有任何快照信息，这个时候为了简单验证，查看一个awr基表即可。我就随便抓取了一个基表，sys.wrh$_event_name
结果这位兄弟反馈说有数据的，但是就是得不到快照信息。而且这个库已经使用了一段时间了。经过这位兄弟同意，贴出几个相关的操作。
首先查看了awr的设置，发现都是默认值，这个地方没有变动。

让他来复现一下问题，可以看到仅一天的快照显示为空。

当然最主要的是ora-600的错误。这个错误不在数据库日志中出现，但是在操作中会报出。

所以针对这个问题，原来还怀疑是否为人工误删除快照表导致，现在看来不大可能，从错误来看，似乎不是一个很容易解释清楚的问题，查看了metalink竟然没有这个错误参数的解释。
而这个问题确确实实出现了，所以还是求助于google.
发现两个相关的讨论，第一个问题中这位兄弟的讨论结果是存在awr rep的损坏，需要重建awr来修复。这个错误的结果比较可靠的一个原因就是错误的行数都是完全一致。
??SQL> exec dbms_workload_repository.create_snapshot;
BEGIN dbms_workload_repository.create_snapshot; END;
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [kewrose_1], [600], [ORA-00600:
internal error code, arguments: [ktspgfb-1], [], [], [], [], [], [], [], [],
[], [], []
], [], [], [], [], [], [], [], [], []
ORA-06512: at "SYS.DBMS_WORKLOAD_REPOSITORY", line 99
ORA-06512: at "SYS.DBMS_WORKLOAD_REPOSITORY", line 122
ORA-06512: at line 1
然后继续查找，另外一个讨论中也碰到了类似的错误。
从这个人的反馈来看，问题确实是因为awr rep的损坏，重建之后问题就得到了解决。
贴出相关的讨论分析
ORA-00600 [kewrose_1] ORA-00600 [ktsplbfmb-dblfree] on 11.2.0.3
------------------------
Today, ORa-0600 kewrose_1 and ktsplbfmb-dblfree erros are produced on a customer using 11.2.0.3 on Exadata X2-2.
After investigating the incident, I found the following sql was the cause the error produced.
{INSERT INTO wrh$_sql_plan sp (snap_id, dbid, sql_id, plan_hash_value, id, operation, options, ....
I made a search on Oracle Support and found a few documents that addresses this bug. One of the document actually addresses our situation as it s written for 11.2.0.1 and does not include any fix or workaround.
As a workaround I suggest my collegue(who ise responsible for this site) rebuild the AWR repository, because the wrh$.. table is an awr table.
We will see if rebuilding the AWR will fix the error.
Yes, Rebuilding the AWR repository fixed the issue..
至于难点重建awr,metalink上是有相关的文章说明的。