從問題的處理方式感悟學習方法

有時候當你碰到一些問題一籌莫展的時候，如果能夠看到某個文章的問題和你碰到的剛好一緻，那種欣喜的感覺真是難以形容。

但是有些問題盡管發生的錯誤一緻，處理的方式卻不同，舉一個例子。

客戶回報某個應用報出了連接配接錯誤。

對于這個問題，咱可以調侃一下，從幾個不同的層面來分析一下。

   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求助，部落格求助等等，幫别人解決問題是一種很好的學習方式，這比自己漫無目的的看書學習效果要好。