今天碰到的几个问题20151023(r6笔记第97天)

每天工作中会碰到一些问题，圈内朋友也会有各种问题，解决问题总是能够带来很大的成就感，有时候感觉在做两份工作。：） 帮助别人的意义就在于别人碰到的坑，你可能也会碰到，别人遇到的坎，也可能是以后你会面临的，坑填平了，坎越过去了，对己对人都是好事，知道那些坑，自己就会绕过去尽量规范，不要去犯；有哪些坎，出了问题之后，自己也知道该怎么处理，所以说是双赢，何乐而不为。 当然了，帮助别人，本职工作是保证。本职工作也要不断改进优化，其实你没意识到的问题，其他人可能早就用更高级的方法来做了。 ###问题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上是有相关的文章说明的。 How to Recreate The AWR ( AUTOMATIC WORKLOAD ) Repository ? (Doc ID 782974.1) ##问题3 第三个问题是前几天所做的一个调优分析。详细内容参见http://blog.itpub.net/23718752/viewspace-1815497/ 第一个图是前几天发现DB time有很大的抖动，发现后台任务在收集统计信息的时候总是失败，原因之一是因为表中存在datapump的临时表，清理之后，没有禁用后台job,第 二天的时候负载要高一些，不过这个也是自己希望的，因为这次后台的统计信息收集任务终于可以完成了，从此以后，就不会有大的负载，导致后台Job半途而为 了。可以看到后面的几天里DB time都在极低的一个值范围内。

查看删除datapump临时表后的第二天凌晨，归档次数每小时有近40次，说明当天确实做了不少的工作。自此问题便得以解决。