今天的内容可能会让大家失望了，是最近准备在着手解决的几个问题，目前都是无解，虽然问题有临时的解决方案，但是感觉还是快找到原因了，结果还是让我不够满意，有些问题刚刚碰到，还在观察之中，有些问题准备处理，但是老是感觉忙，CPU老是负载高，这个得反思工作效率，是不是在干有意义的事情。
今天心中更是内疚，最近几天，晚上回到家，闺女都睡了，早上上班，她还在熟睡之中，吻吻她的额头，这些天她可能都没有意识到我的存在，所以格外珍惜我们在一起的时光，时光如梭，干点有意义的事情，比如家庭团聚，比如解决技术，两者还是要做平衡。
首先来说说第一个问题，是关于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照样也没有问题，这台主备环境原来也是有数据库实例在跑，最近是把旧环境清理掉，直接使用创建的备库，原来的那个库之前也没有问题。

第二个问题是对于物理数据空间的清理
比如一台服务器的分区 /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数据文件也可以考虑，但是不是首选。

第四个问题是最近在做硬盘巡检的时候发现有一台服务器的硬盘正在做rebuild，是有人动了硬盘，但是做了确认，没有任何人操作。但是看到进度还在不断刷新
# MegaCli -pdrbld -showprog -physdrv[32:6] -aALL                                                                                    
Rebuild Progress on Device at Enclosure 32, Slot 6 Completed 4% in 8 Minutes.
自己也就没有太在意，但是今天再次查看发现问题依旧，那块硬盘又开始在做rebuild了。没有任何人操作怎么会出现这样的结果？

第四个问题比较泛，可能会有一些争议，不过我还是简单提一下吧，有这么一个真实的案例，业务方在做一个查询的时候,某个业务的sql执行时间会根据统计信息的误差产生多个子游标，所以看到一个sql语句有差不多近14个执行计划，而且每个都不太一样，现在他们发现一个流程处理很慢，大概需要18分钟才能执行完，所以紧急求助我们，对于这种问题，如果sql语句比较长，而且不能在线修改语句的情况下， 使用sql profile着实是一个不错的选择，但是如果要使用sql profile稳定执行计划，理论上很简单，但是实践起来也不是谁都能搞的定，这个时候我借助sqlt来做这个事情，加单的几分钟就把执行计划给替换了过来，然后从业务方的反馈，不到1秒就执行完成，从18分钟到1秒钟，提升的幅度还是比较大的，但是让我比较纠结的是，这个过程似乎也没什么技术含量，因为最有技术含量的工作都已经让oracle做好了，同一件事情oracle有很多种解决方案都可以完成，所以这个时候我就在思考，到底该怎么去衡量使用工具，这个度该怎么把握，其实当时在极短的时间内，让我重新去构建调试一个sql还是非常困难的，而且需要很多的知识储备，但是通过工具，也在很短的时间范围内就能够轻松搞定这个问题。到底是工具驱动更强，还是技术分析驱动更强，因为从身边经历的很多的问题处理情况，感觉工具的分析已然非常成熟，我们是不是也要升级了。把这些积累的知识储备转换一下。

其实最近碰到的问题不止这四个，能拿出来说的就是这四个了。看来还得浪费不少脑细胞来好好解决这些问题了。