有时候当你碰到一些问题一筹莫展的时候，如果能够看到某个帖子的问题和你碰到的刚好一致，那种欣喜的感觉真是难以形容。
但是有些问题尽管发生的错误一致，处理的方式却不同，举一个例子。
客户反馈某个应用报出了连接错误。
对于这个问题，咱可以调侃一下，从几个不同的层面来分析一下。
step1:问题一般都会反馈到开发这一层面
step2:开发经过分析，发现报错是数据连接问题，简单修改配置就能够解决。如果没有发现更多的信息，就会向中间件部分求助。
step3:问题到了中间件这一层，通过调节连接池等等问题就解决了，如果没有解决就会反馈到数据库层面
step4:问题就直接到了数据库层面，dba查看数据库中的session情况，发现是由于Linux内核参数设置不当导致的，
step5:问题就这样到了unix team这一层,最后发现这些内核参数需要重启数据库
step6:问题就这样反馈到了管理层，领导综合评估决定这个问题的影响范围不足以重启服务器，对业务造成重大影响，决定临时停掉相关的应用或者禁用
step7:问题就这样到了开发层面。。。。
所以同样一个问题总是会有各种不同的可能性，当被一个看似很简单的问题搞的精疲力尽的时候，最后发现可能解决的方式会很简单，甚至很让人无奈。
当你碰到了同样的问题的时候，从各种渠道查看问题的相关信息的时候，确实需要一定的耐心和自己的判断来和自己碰到的问题来联系，是不是相关，问题就是这样反反复复。
我们把问题再细化一下，就聚焦在第4步 " 问题就直接到了 数据库 层面，dba查看数据库中的session情况，发现是由于Linux内核参数设置不当导致的，"
dba收到邮件分析问题的时候，就可能有以下几种方式。
可能会求助同事或者小组领导来帮助分析。
查看数据库日志
查看数据库负载
同时可能也会忙不迭的去各大网站，论坛，博客关联搜索这个错误。
可能通过qq去求救技术圈的朋友。
可能通过电话直接求救。
去metalink上去查查相关的技术文章
所以一个简单的问题就能引申出这么多的章节和流程来，如果流程出现了问题，问题的解决效率就会大打折扣。
自己花了不少的功夫从一个简单的连接问题来说明了这么多，就是想说明问题的处理流程和方式是如何重要。
这些东西都很难从论坛，博客中得到最直接的帮助信息，每个人碰到的问题可能都是冰山一角，问题发生在自己身上的时候，那种无形的压力只有自己知道，如果能够从流程上大家都能够有条不紊的开展工作。可能就不会把有些问题拖很久。
我的感悟就是
形成自己的一套知识体系，
很多问题都是特定的场景中发生的，如果在事后来看待问题处理的每一步，就会发现或多或少都走了不少的弯路。如果有自己的一套知识体系，问题处理就会得心应手。
比如你自己可以根据工作的实际情况来编写一些方便工作的脚本，这些没有人来要求你强迫你，但是对你自己有益。只要能够实际解决问题才是真的好。
比如你可以对一些问题的处理进行邮件整理，保留一些关键部分的邮件，在问题再次发生的时候，这封邮件就能让大家都免去很多的无用功。
抛弃一些细致末节，这样可能不会让你偏离方向
很多人总是感觉学得不够深，时间也花了不少，也喜欢研究一些看似高大上的东西。给我们上课的老师曾经说过一句话，自己感触很深，他说学习oracle就是一个过程，如果你花了大把大把的时间去钻研某一个版本中的某一个bug,或者特定环境中的某一个问题，这对自己的个人成长其实没有太大的好处，如果你能够花同样的时间来分析一个比较通用的问题，是基于数据库的理论体系之中的，那么你的所得要更多。这个可以举个例子来说明。
在10gR2的早期版本中搭建RAC的时候，在创建好clusterware之后需要在各个节点中运行一套脚本，但是在10g这个版本中总是会报一些奇怪的错误，我花了大把大把的时间，认真分析了脚本的执行情况，最后才得知是有一个bug，在后续已经做了修复。等到我自己实际安装11g RAC的时候，发现11g中的RAC架构已经和10g有了很大的不同。这个时候回味起老师的那句话觉得确实有道理。
最后花了些时间来分析一下数据库的体系结构，分析sql调优中的细致末节，自己也写了一些脚本，在10g，11g中都是通用的，我相信在12c版本中也差不离。
所以学习一种技术或者学问对我们每个人都是很有限的，说这么多大概意思就是抛弃一些细致末节，这样可能不会让你偏离方向。
和别人分享
在技术圈中的人都是单纯的，我也时不时会接到朋友的电话求助，qq求助，博客求助等等，帮别人解决问题是一种很好的学习方式，这比自己漫无目的的看书学习效果要好。
但是有些问题尽管发生的错误一致，处理的方式却不同，举一个例子。
客户反馈某个应用报出了连接错误。
对于这个问题，咱可以调侃一下，从几个不同的层面来分析一下。
step1:问题一般都会反馈到开发这一层面
step2:开发经过分析，发现报错是数据连接问题，简单修改配置就能够解决。如果没有发现更多的信息，就会向中间件部分求助。
step3:问题到了中间件这一层，通过调节连接池等等问题就解决了，如果没有解决就会反馈到数据库层面
step4:问题就直接到了数据库层面，dba查看数据库中的session情况，发现是由于Linux内核参数设置不当导致的，
step5:问题就这样到了unix team这一层,最后发现这些内核参数需要重启数据库
step6:问题就这样反馈到了管理层，领导综合评估决定这个问题的影响范围不足以重启服务器，对业务造成重大影响，决定临时停掉相关的应用或者禁用
step7:问题就这样到了开发层面。。。。
所以同样一个问题总是会有各种不同的可能性，当被一个看似很简单的问题搞的精疲力尽的时候，最后发现可能解决的方式会很简单，甚至很让人无奈。
当你碰到了同样的问题的时候，从各种渠道查看问题的相关信息的时候，确实需要一定的耐心和自己的判断来和自己碰到的问题来联系，是不是相关，问题就是这样反反复复。
我们把问题再细化一下，就聚焦在第4步 " 问题就直接到了 数据库 层面，dba查看数据库中的session情况，发现是由于Linux内核参数设置不当导致的，"
dba收到邮件分析问题的时候，就可能有以下几种方式。
可能会求助同事或者小组领导来帮助分析。
查看数据库日志
查看数据库负载
同时可能也会忙不迭的去各大网站，论坛，博客关联搜索这个错误。
可能通过qq去求救技术圈的朋友。
可能通过电话直接求救。
去metalink上去查查相关的技术文章
所以一个简单的问题就能引申出这么多的章节和流程来，如果流程出现了问题，问题的解决效率就会大打折扣。
自己花了不少的功夫从一个简单的连接问题来说明了这么多，就是想说明问题的处理流程和方式是如何重要。
这些东西都很难从论坛，博客中得到最直接的帮助信息，每个人碰到的问题可能都是冰山一角，问题发生在自己身上的时候，那种无形的压力只有自己知道，如果能够从流程上大家都能够有条不紊的开展工作。可能就不会把有些问题拖很久。
我的感悟就是
形成自己的一套知识体系，
很多问题都是特定的场景中发生的，如果在事后来看待问题处理的每一步，就会发现或多或少都走了不少的弯路。如果有自己的一套知识体系，问题处理就会得心应手。
比如你自己可以根据工作的实际情况来编写一些方便工作的脚本，这些没有人来要求你强迫你，但是对你自己有益。只要能够实际解决问题才是真的好。
比如你可以对一些问题的处理进行邮件整理，保留一些关键部分的邮件，在问题再次发生的时候，这封邮件就能让大家都免去很多的无用功。
抛弃一些细致末节，这样可能不会让你偏离方向
很多人总是感觉学得不够深，时间也花了不少，也喜欢研究一些看似高大上的东西。给我们上课的老师曾经说过一句话，自己感触很深，他说学习oracle就是一个过程，如果你花了大把大把的时间去钻研某一个版本中的某一个bug,或者特定环境中的某一个问题，这对自己的个人成长其实没有太大的好处，如果你能够花同样的时间来分析一个比较通用的问题，是基于数据库的理论体系之中的，那么你的所得要更多。这个可以举个例子来说明。
在10gR2的早期版本中搭建RAC的时候，在创建好clusterware之后需要在各个节点中运行一套脚本，但是在10g这个版本中总是会报一些奇怪的错误，我花了大把大把的时间，认真分析了脚本的执行情况，最后才得知是有一个bug，在后续已经做了修复。等到我自己实际安装11g RAC的时候，发现11g中的RAC架构已经和10g有了很大的不同。这个时候回味起老师的那句话觉得确实有道理。
最后花了些时间来分析一下数据库的体系结构，分析sql调优中的细致末节，自己也写了一些脚本，在10g，11g中都是通用的，我相信在12c版本中也差不离。
所以学习一种技术或者学问对我们每个人都是很有限的，说这么多大概意思就是抛弃一些细致末节，这样可能不会让你偏离方向。
和别人分享
在技术圈中的人都是单纯的，我也时不时会接到朋友的电话求助，qq求助，博客求助等等，帮别人解决问题是一种很好的学习方式，这比自己漫无目的的看书学习效果要好。
