不要逃避，直面困难

工作上陆陆续续遇到很多技术问题，有些尝试着去解决却一直没有成功，当时觉得这些问题太难了，就拖着不想再去触碰。

列举最近的几个问题。

1. 自动化脚本setup Goldengate，时常会报错：Stale NFS file handle，乍看起来是NFS的问题，却又无从下手。直到某一天，发现报错愈发频繁，影响到测试环境的正常运转了。

2. OEM升级到Oracle 13C后，database的一些metric莫名其妙消失了，一些不想要的报警也没法disable，尝试着去解决也没有成效，只好放着。后来遇到核心数据库上average active session的metric disable不了只好blackout db的时候觉得再也不能这样了。

3. 参加hadoop学习小组，一直没有仔细地去看过文档、研究过。后来任务下来需要我给hadoop加node一拖再拖无法再拖的时候。

4. rman netbackup出现莫名的报错，ORA-19643:datafile 16: incremental-start SCN is too recent，调查了一番以后只有一篇metalink的文章比较契合，说是一个bug，心里就释然了，不能打补丁，就把问题放着了。直到一星期以后INFRA team的同事在jira里comment，问我是不是还在看这个问题。

终究来到这一天，没办法再逃避了，只好正视问题，发挥主观能动性，绞尽脑汁地解决它们。

1. Stale NFS file handle，找了一个大块的时间，给脚本加上调试信息的输出，反复验证终于定位到哪一句命令导致的时不时的报错，用手动mkdir子目录去替换ggsci下create subdirs解决问题。

2. OEM metric issue，花大量时间去调查，给EM OMS打了最新的PSU，最后运用完整的monitoring template去解决了问题。

3. hadoop adding node，找了一个周六的下午，不被打断地仔细研究了一下安装文档，wiki资料，发现其实很简单，很快就搞定了。

4. rman backup issue，后来又仔细看了一下metalink文章，Bug16622161 : ORA-19643: DATAFILE 11: INCREMENTAL-START SCN IS TOO RECENT，里面有一句

“Please check if STANDBY running with any delay parameters to apply the logs(i.e., is DELAY attribute set for LOG_ARCHIVE_DEST_n for standby at primary)，”虽然这一段并不适用于我们的环境，但是突然想到是不是因为之前standby有十几天的lag导致的，修复lag以后再让INFRA team一试，果然就好了。

最近的感触是，技术问题总是能解决的，需要的只是无路可退或是直面困难的勇气。最好还是从一开始就不畏惧，直面困难。

最近几年有两个问题一直困扰着我，断断续续地尝试去改善，一直没有很好的答案和解决方法，一直搁着。终于，上星期无意之中看到一本书，试着读了读，给了我很大的启发，我觉得再经过一段时间的练习，离问题解决也就不远了。

这里把两个困惑写下来，如果你们也有同样的困扰，可以去读读这本书，或许会有很大的启发。

困惑一：致用类书籍如何阅读。这里说的致用类的书籍是用来解决实际问题、训练提升能力、帮助优化决策。

困惑二：知识体系如何构成。面对平时收集的众多的零散的信息和知识，如何入手将它们形成体系；技术学习上如何形成体系，比如Oracle数据库体系。

愿大家都有进步。