oracle数据灾备故障处理
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
张贺，多年互联网行业工作经验，担任过网络工程师、系统集成工程师、LINUX系统运维工程师
个人网站：www.zhanghehe.cn
笔者微信：zhanghe15069028807,现居济南历下区
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
当工作中遇到当时无法解决的难题时，我们要做的并不是一上来就开始处理，而是应该先思考，思考当前的难题是否是自己应该负责？到底谁的责任？举个例子，假如有客户反应你们的网站打不开了，难道你立刻去检查网站所在的服务器吗？不是，要先搞清楚，是一个客户这样（如果只有一个客户这样，可能是客户的网络配置有问题），还是很多客户都这样，如果很多客户都不开你的网站 ，才能说明是你的网站有问题，你才要去网站所在服务器去排错，一个人要合理地承担属于自己的责任，当然，平时做好监控是非常重要的，争取在客户发生问题之前自己先发现问题。
2019年7月的时候，我们公司销售给某单位一整套灾备存储，主要用来做oracle数据库的异地灾备，结果在实施的时候出现了一个迟迟无法解决的问题，就是数据一直无法同步到灾备的存储上，但ping、telnet都是没有问题的，这很奇怪，灾备其实没有什么难做的，就是将本地的数据复制一份然后经过重重路由传递到灾备存储上上，按理说不应该出现这样的事情。客户以为是oracle数据库没有配置正常，DBA反复检查说oracle的配置没有问题，后来oracle的工程师来了，西装革履，那叫一个有范儿，来了之后一番“云山雾罩”的操作之后，说不是它们oracle数据库的问题，然后就走了，就走了……，走的时候为了说明不是它们的oracle数据库出了问题，他还特意抓了包，包上面显示oracle确实向远程的灾备存储发起了备份请求，但是被远程的灾备存储给拒绝了，远程的灾备存储发送了很多的[RST]reset（重置），客户也一口咬定，就是我们灾备存储的问题，我们也无法反驳，我们在oracle数据库端也抓了包，也看到了远程的灾备发送了很多的reset请求，导致了数据备份无法完成。
我们只能去查在灾备存储上的配置，检查了好几遍，没有发现我们灾备存储的配置有问题，而且我们在我们灾备存储这边抓包看的话，没有看到reset包，也就说reset包不是我们的存储设备发出来的，我们将这个结果给客户的信息科主任演示之后，人家也没有为难我们，知道了不是我们的责任，就没再追究。那oracle端收到的reset上显示就是我们存储设备的IP发出来的，这是怎么回事？很有可能是沿途经过的设备伪装成我们的的存储设备发出来的， 那如何定位到那台设备呢？老板要求我们要尽量帮客户解决问题，我突然想到，可以查看TTL值，TTL值有一个默认值，这个默认值每过一跳路由之后都会减去一，这样的话，我们只要看一下RST包里面的time to ive（TTL）就能逆向推算出是哪一个路由设备“搞的鬼”，我们看到了RST包里面的TTL值是62，那TTL一般默认是64，当前是62，那就是oracle服务器第二跳路由设备“搞的鬼”，客户只需要看看拓扑图就知道是哪台设备了，客户最终发现第二跳是防火墙，防火墙的策略设置有问题，将防火墙的策略修改之后，oracle的数据备份就正常了。
事后想了一下，这个问题其实有更好解决办法，并不用两头抓包的，我们只要看看RST包里面的TTL值和三次握手时的TTL值是不是一样，如果是一样的话，就说明RST包就是我们的存储发出来的，如果不是，那就是有路由设备在中间搞鬼，代理我们的存储发出RST报文。
