DBA和開發同事的代溝（二）

在上一篇中寫到了 DBA和開發同事的一些代溝(一) 可以參考 http://blog.itpub.net/23718752/viewspace-1837743/
有些朋友給我反饋了他們遇到的小故事，我後續再整理整理，看看有多少。
我還是繼續來分享我這邊碰到的一些小插曲，這些除非你確實碰到，想遍出來還著實需要想象力。
##和開發的博弈
在Oracle中有資源管理的概念，其中一個功能就是設定每個使用者可以使用的session數，即sessions_per_user,這個設定透過profile來完成。
一般的線上庫都還是有一定的配額設定，保證不會出現過量的資源使用情況，這一點也和開發達成了共識。如果違反了共識，那就需要博弈一番。
前段時間監控發現某一個環境的sessions_per_user使用有一些異常，經過和開發溝通，他們反饋說新增了一些客戶端，所以會需要一些額外的連線數，我說可以的，那能不能給我反饋一些資訊，比如增加了多少客戶端，大概需要增加多少連線數，開發的同學又說不出，只是知道應該增加，為了讓問題先解決，我就把資源管理先給關了，保證他們能夠連線進來，這樣也就不會收到額外的報警了，但是臨時解決之後，他們就不陪我玩了，沒有了任何反饋，這件事我首先短訊息提醒，發郵件提醒，郵件抄送提醒，都沒有任何反饋，無奈我只好繼續開啟資源管理，結果很快他們就主動找過來了，和我商量需要多少客戶端，大概需要多少連線數，他們領導也熱心給我解釋，問題就很快解決了。這個小案例只是說明一些地方開發可能不以為然，但是如果出了問題，這問題很自然就會落到DBA頭上，當初為什麼沒有提醒我，所以我也是先禮後兵。最終的目的就是解決問題。

##物化檢視日誌的增量重新整理
開發的同學最近找到我說，他們需要做一個需求，需要把一個大表中的增量資料透過時間欄位來抽取，同步到另外一個庫中，在這種情況下，如果表中發生了delete,update操作，那麼這類資料就會出現不一致的情況，但是在這一點上，開發同學也不能保證，對於這類資料的不一致之前也是勉強接受。認為也就只能這樣了。
這類需求，還是可以考慮用物化檢視的增量重新整理來做的，只要能夠確認目標庫中的資料不需要修改即可，物化檢視快速重新整理，在資料變更量不是很大的情況下，還是不錯的選擇，輕巧輕便。
他們也是半信半疑，還能夠把update,delete的操作給同步過來，而且在源庫中還不需要建立時間欄位相關的額外索引。


##需要注意的sql編寫規範
這個問題之前也提起過，透過ORA錯誤反思sql語句規範  http://blog.itpub.net/23718752/viewspace-1431617/
大體是這樣的意思，執行下面的語句沒有問題，但是單執行子查詢中語句就會報錯。
select *from test1_customer where customer_id in (select customer_id from test2_customer where cycle_code>100);
執行這個語句沒有錯誤。
81 rows selected.
但是執行子查詢中的語句卻報出了ORA-00904的錯誤。
select customer_id from test2_customer where cycle_code>100
                                             *
ERROR at line 1:
ORA-00904: "CYCLE_CODE": invalid identifier
對於這類問題，其實欄位cycle_code是在子查詢外的表test1_customer中的，這是在oracle解析的時候會預設去標記，還是寫sql語句的時候不夠規範，沒有用到別名這類的來標示，想想如果有有成百上千行，那麼出問題的時候排查那就是難上加難了。、

###防不勝防的資料變更
這個問題之前也提起過。使用閃回查詢備份資料 http://blog.itpub.net/23718752/viewspace-1226414/
大體的意思就是有一個update的變更，在測試環境中都沒有問題，資料，結果和預期都是一致的，但是到了生產環境中部署的時候執行的時候發現預期的變更條數和實際的就有了很大的差別，最後發現原來是過濾條件太大導致的全表update.對於這類問題，等我接到這種問題的救援時，優先能夠想到的就是山會查詢的功能了，結果硬生生嘗試把10多個G的表在變更之前的狀態給恢復了回來，對比之後發現，現網的資料變更其實沒有資料的損壞，最後也算是虛驚一場，不過對於這類變更也還是需要DBA來認真評估。真出了問題，也能夠及時恢復，看來DBA在這類變更操作中還是要給自己留點後路。儘管開發不要求備份，但是如果出現了差錯，還有儘快恢復的可能。

##sql稽核機制
對於sql的稽核，之前也提到過一些，稽核做得不到位，除了DBA的責任，還是需要開發同學的及時反饋，一方面開發同學可能嫌麻煩，或者他們嫌DBA麻煩，大體都是如此吧。
關於評審開發人員的sql語句 http://blog.itpub.net/23718752/viewspace-1286287/
不管怎麼樣，sql稽核是很重要的一個環節，工具只是形成了一個知識庫，但是實際來稽核的時候開發同學和DBA同學考慮的角度也不一樣，DBA可能更側重於語句的結構和效能評估。而開發更側重於業務的實現。所以兩者之間還是需要磨合，之前就有過一次沉痛的經歷，是在生產環境升級之前，開發突然提過來一個緊急變更，說這個變更很重要，但是時間緊，語句只是測試了一下，沒有讓DBA做評估，結果帶著僥倖心理來部署的時候就出了問題，一個pl/sql執行了近4個小時，在這4個小時裡，自己也是被各路領導追隨，大半夜在那做最佳化，最後發現其實可以把這個pl/sql簡化成1到兩條sql語句，執行耗費的時間其實也就不到一分鐘。有了這類沉痛的經歷之後，對於緊急變更也要嚴格來稽核。我們評估技術風險，讓領導來評估業務風險。

還有一大波案例在醞釀中，後續繼續更新。