DBA和開發同事的一些代溝(五)

陸陸續續寫了四篇和開發同事的代溝，從最開始的吐槽到後面的例行總結，整個過程也是總結經驗，看似很小的問題對於DBA來說就是莫大的改進，或者在開發嚴重越不過去的坎兒在DBA來看就是修改一個簡單的配置就可以搞定，這個過程中都是互幫互助，大家互相體諒，才是共贏。
   最近順手幫開發同事解決了幾個小問題，也可以暴露出來一些問題。簡單總結一下。
資料庫連線的問題
  首先是資料庫連線的問題，這兩天四個同事遇到了同樣的問題，但是問題原因也是五花八門。
  ORA-12514連線資料庫的問題

之前一個開發同事幫我解決了一個安卓軟體的問題，當時他隨口一問知道我是DBA，就簡單在lync上打了個招呼，說以後有資料庫問題可以找我。最近還真碰 到資料庫問題了，這種幫忙當然是義不容辭，他反饋的問題是連線資料庫的時候報錯ORA-12514，是windows中使用plsqdev去連線本地的一 個資料庫，看這個錯誤感覺就是網路配置的問題。
  xxxx[9:59]:
  ORA-12514
  監聽程式當前無法人別連線描述中的請求的服務
  還是解析不了監聽
然後他帶著電腦過來了，我簡單看了下，監聽也啟動了，按照他所說，資料庫服務也配置了，他使用了netmgr和netca中的圖形配置，看起來這個問題是 不是windows上的某些奇怪的問題，按照他所說，這些配置都完成了，但是資料庫就是連線不了，我使用cmd進入命令列，如果是linux可以直接執行 一個ps -ef|grep smon來看看資料庫的一些簡單配置，但是windows下檢視還是不夠直接，怎麼看呢，我直接在cmd裡執行services.msc進行服務列表，查 看啟動的oracle服務看看例項到底是哪一個，結果找了一圈，沒找到，最後反覆確認，發現原來這個同事沒有使用dbca建立資料庫例項，當然我給他簡單 解釋了一下，然後直接進入dbca介面幫他建立，看著sysdba可以正常連線到例項，這個問題的解決就告一段落了。透過這個可以反映出開發人員對於資料 庫例項的概念還是不夠清晰。
   ORA-12154的問題

這是另外一個開發同事反饋的，也是在lync上他找到我說，資料庫現在連線有個問題，想讓我幫忙看看。當然這個環境不是本地的，而且要訪問他們的環境非常困 難，所以可以使用遠端桌面來做。最開始的猜測是網路的埠的問題，因為對於應用來說，開放的埠都是指定的。他在本地給我簡單復現了這個問題，我說直接看 tnsnames.ora的配置。
然後查詢了一番，找到了這個配置

這個時候一眼就看出了問題，這是配置的問題，這個同事折騰了好半天，這個Host的配置沒有正常結尾，所以補全之後問題就解決了。當然解釋了一通，最終說鍵值對他馬上就理解了。
   第二個ORA-12154的問題
   然後在下午的時候，另外一個開發同事找到我說，有一個資料庫配置比較奇怪，怎麼都弄不好，還說感覺裡面的一個資料庫配置會影響到另外一個，一直也沒找到解決方法。讓我幫忙看看。
當然這個問題也是在內網環境，也是遠端協助，看到她復現了一遍問題，發現是tnsnames.ora裡面的一個配置多了一項配置。
比如test的配置資訊如下：

她那邊的配置資訊為：
test=(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = xxxxxx)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = test)（sd=e)))
這與最後的sd=e是怎麼來的，她也記不清了，我可以猜出來以前應該是sid=test可能最後不知道怎麼修改成了現在的模樣了。當然這個問題看起來非常簡單，但是能夠折射出對於資料庫層面的一些知識，開發還是不夠了解。
  最後一個是jdbc連線資料庫的問題。開發有個同事反饋說有一個備庫連線的時候報了錯誤。然後提供了以下的錯誤資訊，而且還誠意滿滿附了日誌，我開啟日誌的瞬間就後悔了，因為這個日誌好幾十M，其實這個問題確定ip就可以基本判定問題。

當然後面確認了IP，發現這個問題的原因在於這個是10gR2的環境，備庫是在mount狀態，平時有一些大查詢需要在凌晨開放給一些應用，但是這個備庫 最近重新做了系統，所以原有的crontab 沒有正式執行，也就意味著凌晨的查詢視窗沒有開啟，所以這個問題簡單確認了一下就明白了問題的原委，當然後續我也提出了一些更多的建議。
   說完資料庫的連線問題，再來看兩個小案例，這個其實也可以和開發的同學好好聊聊。
   我收到了一個開發同事的工單，說需要給一個表增加一個列，看起來需求很簡單也很明確，而且給出了完整的語句和環境。看起來剩下的就是DBA來執行了。語句型別下面的形式

這個需求看起來還是比較簡單的，但是我已檢視錶user_details的情況，裡面有近10億的資料，這樣一個大表而且還沒有分割槽的情況下做一個欄位的 新增，影響還是非常大的。在exadata上做了一個類似的測試發現這種場景都很讓人頭痛。所以我們的建議是最好不要加。如果一定要加，需要申請維護時間 來做。線上操作就是給自己找虐。當然和開發溝通之後他們內部也做了調整。
   然後還有一個問題是一個查詢需求，開發提供了一個語句，讓我們幫忙檢視一下一個統計表中的資料分佈情況。
提供的語句類似下面的形式。

這樣一個查詢，表裡的資料是非常大的，而且分析表的情況，發現regdate有一個索引欄位，但是根據這個查詢似乎效能也好不到哪裡去。
所以這個語句可以簡單調整一番，變成下面的形式。語句的效能就會好很多。

當然這個部分其實還是可以和開發溝通一下，這些看似非常值得注意的小細節如果在開發中引起重視，那麼後期的sql問題也會大大減少。