最近让我焦灼的四个问题(有解) (r7笔记第76天)

之前写了一篇 《最近让我焦灼的四个问题》，既是感慨，也是无奈，既是记录问题，也是鞭策自己，当然只是吐槽，抱怨是没有任何意义的，所以我更新第二篇，这些问题在近些天都得到了基本解决。当然一波问题解决了，另外一波又来了，继续努力。 首先来说说第一个问题，是关于dataguard,最近碰到一个有些奇怪的问题，主库使用了ASM,备库使用了普通文件系统,从理论和实践来看，这都是可 行的，但可能不是最佳实践。但是我碰到了一个奇怪的问题，就是备库搭建完成之后，也能正常接收归档，dg broker的配置和以往的配置并没有什么变化，但是备库会报出奇下面的ora错误。 Reading datafile '/home/U01/app/oracle/oradata/testbi/datafile/mbi_data.274.899314747' for corruption at rdba: 0x024bdc8c (file 9, block 777356) Reread (file 9, block 777356) found same corrupt data (no logical check) Hex dump of (file 9, block 777483) in trace file /home/U01/app/oracle/diag/rdbms/stestbi/testbi/trace/testbi_pr04_11007.trc Corrupt block relative dba: 0x024bdd0b (file 9, block 777483) Completely zero block found during media recovery Reading datafile '/home/U01/app/oracle/oradata/testbi/datafile/mbi_data.274.899314747' for corruption at rdba: 0x024bdd0b (file 9, block 777483) Reread (file 9, block 777483) found same corrupt data (no logical check) Hex dump of (file 9, block 796276) in trace file /home/U01/app/oracle/diag/rdbms/stestbi/testbi/trace/testbi_pr04_11007.trc Corrupt block relative dba: 0x024c2674 (file 9, block 796276) Completely zero block found during media recovery Reading datafile '/home/U01/app/oracle/oradata/testbi/datafile/mbi_data.274.899314747' for corruption at rdba: 0x024c2674 (file 9, block 796276) Reread (file 9, block 796276) found same corrupt data (no logical check) 然后会刷很多屏，对于这个问题，自己分析了各种场景，前前后后做了不下十多种测试，基本都排除了，重建了多次，都是同样的问题。 我发现一个地方不同，那就是主库是redhat 6.3,而备库是redhat 5.3，最后排除了一圈，唯一的差别就是这个了，最后反复验证，在另外一台机器上尝试搭建备库，那台机器是6.3，就没有任何问题。所以怀疑是不是这个原 因导致的，但是手头也没有更多的信息来论证，而且让我比较纠结的是我还确实看到过不少主备库，主库redhat 6,备库redhat 4照样也没有问题，这台主备环境原来也是有数据库实例在跑，最近是把旧环境清理掉，直接使用创建的备库，原来的那个库之前也没有问题。 解答：对于这个问题，也算是苦心积虑，尝试了各种方式和方法，推理测试，不下十多种方法，最终均宣告失败，最后的结论是一个bug， 可以从下面得日志来进行说明，在配置dg broker的时候，alert中会有大量的报警，提示密码错误，但是密码文件已经反复尝试验证，是没有问题的。 ORA-17629: Cannot connect to the remote database server ORA-17627: ORA-01017: invalid username/password; logon denied ORA-17629: Cannot connect to the remote database server ORA-17627: ORA-01017: invalid username/password; logon denied 当然找到了trace日志。会有下面的一段内容： Hex dump of (file 5, block 689264) Dump of memory from 0x0000000982E10000 to 0x0000000982E12000 982E10000 0000A200 014A8470 00000000 01010000 [....p.J.........] 982E10010 00000000 00000000 00000000 00000000 [................] Repeat 509 times 982E11FF0 00000000 00000000 00000000 00000001 [................] Corrupt block relative dba: 0x014a8470 (file 5, block 689264) Completely zero block found during media recovery Reading datafile '/home/U01/app/oracle/oradata/testbi/datafile/mbi_data.418.899225411' for corruption at rdba: 0x014a8470 (file 5, block 689264) Reread (file 5, block 689264) found same corrupt data (no logical check) Redo shipping client performing standby login *** 2015-12-31 17:18:40.617 4645 krsu.c Logged on to standby successfully Client logon and security negotiation successful! krsd_get_primary_connect_string: found pcs 'testbi' by FAL_SERVER lookup OCI error val is 1017 and errmsg is 'ORA-01017: invalid username/password; logon denied ' ORA-17627: ORA-01017: invalid username/password; logon denied ORA-17629: Cannot connect to the remote database server Hex dump of (file 7, block 722560) 然后在极为频繁的报错之后，会报出ora-600 ORA-00600: internal error code, arguments: [723], [134104], [167568], [memory leak], [], [], [], [], [], [], [], [] 其实仔细分析还是和大量的登入登出有关联 当然说是bug也是证据确凿，Bug 11809377 : AUTO BLOCK MEDIA RECOVERY IS CAUSING PASSWORD ERRORS ON PHYSICAL STANDBY 刚好我这个库比较特别，主库6.3+ASM,备库5.3+文件系统。和bug描述的oel 5的情况是一致的。 当然有个问题是为什么有那么多的坏块校验，这个其实还是11g的一个新特性，自动坏块修复，当然实际上是没有坏块的。 SQL> select * from V$DATABASE_BLOCK_CORRUPTION; no rows selected 有一个隐含参数 _auto_bmr来控制，默认是启用，当然带着侥幸心理常识了设置为false,不过还是没有成功。可见这个问题还不是修改一个参数就能够解决的。 第二个问题是对于物理数据空间的清理 比如一台服务器的分区 /u01有500G的空间，但是目前/u01只剩余2G,原因就在于里面的数据增长太快，数据文件都快写满了，和业务方的确认，对于这类热数据，可以保留 一定期限的即可，从这个角度来看，如果做清理就会清理掉近40%的空间，也就是500G的空间清理后剩余300G左右的空间。但是这部分空间逻辑上是释放 了，在文件系统级别就是对应数据文件，还没有释放。所以这个分区的使用率还是近100%，所以这种情况就比较纠结，你说释放空间吧，确实释放了，但是文件 系统级还没有释放，如果尝试resize数据文件，从目前的情况来看，很多的表都分散存储在多个数据文件中，文件级别的高水位线还是不好理，自己曾经尝试 把一个2G的数据文件resize成10M，可以参考之前写的文章http://blog.itpub.net/23718752/viewspace- 1651534/，但是在这个例子里面，自己也分析了一大圈，收效甚微，收缩的幅度很小。那么有没有其它的办法来把目前的状态能够稍微改进一下呢，因为这 种情况下，如果归档开始切换，很可能磁盘空间就马上回爆满，而添加新的磁盘空间从业务上也不好协调，因为我们已经清理了近40%的空间。 所以目前的临时改进方案可以暂时先缓解这个问题，可以把一部分的数据文件给move到/home分区下，这样/u01的空间也释放出来了。可能实现不太标 准，但是能够解决当前的问题，那么问题又来了，这个操作是否可以直接这么做，结果一查还发现了一些小问题，需要考虑备库的情况，这个路径映射一定得考虑周 全，要不很可能得重建备库，所以一个好几T的库如果被逼无奈搭建备库那就太让人郁闷了，所以，move数据文件也可以考虑，但是不是首选。 解答：这 个问题没有花费太多的时间，不过仔细评估了一下。发现rename datafile对于备库还是存在一定的影响，这个地方准备好好测试一下，当然为了解决当前的问题，还是使用resize的方式收缩了一部分的数据文件， 当然重点还是undo和temp和几个数据文件，一下子能够压缩出来50多G，后续会继续跟进。短期来看应该没有什么问题了。 第三个问题是最近在做硬盘巡检的时候发现有一台服务器的硬盘正在做rebuild，是有人动了硬盘，但是做了确认，没有任何人操作。但是看到进度还在不断刷新 # MegaCli -pdrbld -showprog -physdrv[32:6] -aALL Rebuild Progress on Device at Enclosure 32, Slot 6 Completed 4% in 8 Minutes. 自己也就没有太在意，但是今天再次查看发现问题依旧，那块硬盘又开始在做rebuild了。没有任何人操作怎么会出现这样的结果？ 解答：这个问题也有网友提供建议是硬盘背板的问题，不过和系统组的同事进行了确认，如果背板问题，可能会导致所有硬盘下线，发现这个rebuild其实已经持续很长时间了。 这个硬盘就在默默的进行着rebuild

/opt/MegaRAID/MegaCli/MegaCli64 -PDList -aALL|grep "Firmware state" Firmware state: Online, Spun Up Firmware state: Online, Spun Up Firmware state: Online, Spun Up Firmware state: Online, Spun Up Firmware state: Online, Spun Up Firmware state: Rebuild Firmware state: Online, Spun Up 但是当时的注意力在于磁盘坏块和坏盘的问题，在最近盘点ilo信息的时候给抓了出来。发现这个slot为6的硬盘总是在循环修复中。

当然今天对硬盘进行了更换，问题得以解决。也算是了却了一个心头的疙瘩。 第四个问题比较泛，可能会有一些争议，不过我还是简单提一下吧，有这么一个真实的案例，业务方在做一个查询的时候,某个业务的sql执行时间会根据统计信 息的误差产生多个子游标，所以看到一个sql语句有差不多近14个执行计划，而且每个都不太一样，现在他们发现一个流程处理很慢，大概需要18分钟才能执 行完，所以紧急求助我们，对于这种问题，如果sql语句比较长，而且不能在线修改语句的情况下， 使用sql profile着实是一个不错的选择，但是如果要使用sql profile稳定执行计划，理论上很简单，但是实践起来也不是谁都能搞的定，这个时候我借助sqlt来做这个事情，加单的几分钟就把执行计划给替换了过 来，然后从业务方的反馈，不到1秒就执行完成，从18分钟到1秒钟，提升的幅度还是比较大的，但是让我比较纠结的是，这个过程似乎也没什么技术含量，因为 最有技术含量的工作都已经让oracle做好了，同一件事情oracle有很多种解决方案都可以完成，所以这个时候我就在思考，到底该怎么去衡量使用工 具，这个度该怎么把握，其实当时在极短的时间内，让我重新去构建调试一个sql还是非常困难的，而且需要很多的知识储备，但是通过工具，也在很短的时间范 围内就能够轻松搞定这个问题。到底是工具驱动更强，还是技术分析驱动更强，因为从身边经历的很多的问题处理情况，感觉工具的分析已然非常成熟，我们是不是 也要升级了。把这些积累的知识储备转换一下。 解答： 其实我最近也在纠结到底是工具重要还是本身的技术基础更重要，因为之前做了一个测试，从测试结果来看，虽然问题解决了，但是我感觉心里更虚了，现在的问题 越来越复杂，自动化程度越来高，强大的工具对于复杂问题的分析真是如鱼得水，如果工具做到的程度跟我们当电影里的老板一样，各种优劣得失都分析得头头是 道，只需要排版用哪一个方案，这种工具真是太强大了，但是带给我们的应该是更高的要求，而不是满足于现状，因为实际情况就是原来的独门秘籍和法宝攻略在这 些强大的工具面前，其实是知识库中的一部分了，或者这些工具要设计的更全面，更周到，那么我们这个职位存在的意义就更显而易见了，我们需要关注更深入，更 多的知识点，我们来评判工具，改进工具，这些才是我们更有价值的地方，所以话说回来，工具虽好，但是离开工具，这些基础知识，基本功还是要扎实。