資料庫調校的確是一項十分具有挑戰性的工作，坊間的技術文獻或參考書藉從基礎到深入比比皆是，我僅能就我過去的實務經驗做一些分享，
以下分六大部分跟大家釋疑～
[應用程式調校]
1. PL-SQL & T-SQL Statement
PL-SQL (Procedural Language) 是一種程序語言，可以做結構化程式設計的語言，像VB / JAVA / C 都是，而 Oracle 就是利用 PL/SQL 來搭配 SQL 語言撰寫資料存取程式，並以 PL/SQL 的程序敘述 (Procedural Statement) 來控制流程，其好處就是將原本應該在應用程式裡的語法寫在資料庫引擎上，這會讓大量的資料交易及邏輯運作落在 Server 上處理，減輕應用程式的負擔，同時也不必為了每次相同的語法再 Parsing 一次，加快了資料存取，但依據 Ben 所提供的資料看來，還未看到廠商使用到此一特性（Oracle 得天獨厚的），只是利用一般的 T-SQL (Transaction-SQL) 去處理資料，如果真是這樣，其實有點擔心...
2. Transaction 的使用
一般的語法為 Delete from Employee Where Status='Leave' ，此交易一點保障都沒有，若能在前後加上 Transaction 及 Commit，就會形成一種保證．
--------------------------------------------------------------
Transaction
Delete from Employee Where Status='Leave'
Commit
--------------------------------------------------------------
系統在搜尋這筆資料時可能須要一點時間，這時若發生停電，網路不通.....等現象，就會 Rollback 回去，否則，若應用程式在處理完這筆資料後還有其它動作要執行，就會造成資料大亂!
3. SQL Statement
-> 配合程式設計裡的語法，應注意 Where 後面如語法，若是兩個欄位的交集請將英數字欄位寫在後面，因為 Oracle Engine 會先比對最後面的條件再往前比對，以此類推，如 Where JobTitle='經理' and Age < 25
-> 若欲搜尋的欄位資料是較少的，須放在後面，如 Where Dept='系統協調室' and JobTitle='經理'，如此一來 Oracle 會先把整個公司的經理找到後（可能只有1位，再往前找屬於系統協調室的那一筆資料；反相，它就會先找到80幾個系統協調室的人才找到那個經理，那一個快呢? 故程式設計扮演了重要的角色，資料庫的調整不應只著重在Database本身！
[資料庫設計的調校]
1. Table Design:
-> 除了主 Table 以外，都不應該超過 20 Fields．
-> 必要且過多的 Table，就應建立不同的 Instance 來處理．
2. Type Define
-> Flag性質的欄位，讓其愈精簡愈好，且將其改為char type，可以加快搜尋速度．
-> 欲儲存大量字串資料請定義成 Long / Text 型態，讓資料存得更有效率．
-> 日期與時間欄位避免使用字串型態(char / varchar2)來設計，否則做日期資料比對時一定很痛苦!
-> 看了許多系統，大部分的數字欄位，都被定義成 Number(22)，事實上並非每一個欄位都會用到這麼長的資料，甚至於 ID 欄位也被定義成 Number(22)，不僅浪費磁碟空間，也拖慢了資料搜尋速度．
3. Relational DataBase
關聯式資料的圖表，可一目了然所有的 Table，如下圖所示......
4. Key / Index
-> Key: 為資料庫裡唯一不重複的索引鍵是眾所皆知的，但一個 Table 如果使用過多的欄位為其複合式主索引鍵，就應該將其拆成兩個資料表並建立其關聯，才能使資料有效的應用．
-> Index: 是為龐大的資料庫建立起一套快速找到資料的索引，就像書本的目錄一樣，這也是大家都知道的道理．但是，你每建立一筆 Index 系統會利用此 Table 的資料複製一份約百分之幾的資料 (此參數是可以設定的) 在你的磁碟機上，故不適當或過多的 Index 會造成系統負擔．
-> 故 Index 的建立，最簡單的原則就是每個 SQL Statement 的 Where 後面的欄位皆要建立，是複合 Index，還是獨立 Index ，須視應用程式的原始目的而定．
5. Restriction
欄位的約束一定要被建立好，可以避免因為應用程式的邏輯錯誤，而將不合理的資料存在資料庫中，如 性別欄位只有男女兩種，結果卻會存在[大學]這種不合理的字串，若資料分析設計的階段就能清楚的定義每個欄位的合理性，程式設計師在開發時，就會提早將此不合理的現象剔除．
[特別調校]
1. 7 x 24 不間斷監控
資料庫的調校並非立竿見影一次OK，它必須一次又一次的 Tuning，除非系統設計的階段就能預見十年(甚至更久)以後的資料成長量．
2. 交易隔離與鎖定
此部分十分重要，與效能有很大的關係，但太多了，下回有時間在分析給各位！
[環境調校]
1. 作業系統:
Oracle 曾經發表過在 Windows 平台上的 Oracle DB 為實驗性質的，故將其運用在 Production 的系統是不恰當的，除非資料量不太大！再者 OS 本身的穩定性也考驗著 DB Engine 的可用性，故千萬不要於資料庫所在的作業系統上再增加其它的應用程式或用途．
2. 網路:
資料庫本身是大量資料進出的地方，故其網路線材可以使用 Fiber 會比起 CAT5 來得好，其頻寬可以1G 以上，並利用多片網路卡設定成虛擬叢集網路卡，確保交易資料不中斷．
3. 磁碟陣列:
只是是商用資料庫都支援此一功能，一筆資料寫到不同的磁碟組，一定比寫到同一個磁碟中來的快得多．但並非做完 RAID 就沒事，而是須要區分須要較長期保存的Data應寫到RAID 1；須要較快查詢速度的Data應寫入RAID 5，最重要的是 Disaster Recovery 的演練．
[未來的實務建議]
調校Database，可以從下列Solution著手，它不見得最好，只是一些原則而已...
1. 整理所有應具備的文件 (包括 Table Schema / Index / Triger / Store Procedure / View )，每個資料表及欄位都應說明清楚其用途．
2. 先將所有的程式中對資料庫存取的 SQL Statement 調出來審查，包含存取時間，Index 的使用效能．
3. 刪除資料庫中不必要的資料表. (如: Temp Table )
4. 移除主資料表中一輩子都不會用到的欄位 (即所謂 Garbage Fields)
5. 針對每個欄位分析其資料屬性, 依據上述提及的資料庫設計的型態進行調整
6. 標準化資料庫的命名原則
-> app 開頭的與表單有關
-> atr 開頭的是屬性資料表
-> cfg 開頭的與系統參數設定有關
-> JCIC 開頭的與聯徵資料有關
如此一來是不是比較容易了解，再加上文件的說明，一個對系統陌生的人很快就可以上手了!
[總論]
1. 以上所提及的範例來自於銀行的各種系統．
2. 上述所提及的項目環環相扣，缺一不可，系統效能就是這麼一回事．
3. 資料庫的設計就像申論題一樣，沒有所謂的標準答案，但有一定的原則，故以上建議並非只適用於 Oracle，而是資料庫設計的通則．
4. 資料庫是可以被管理設計的更好的，一味的加購硬體是無法解決系統效能不彰的資料庫引擎．
5. 還有很多的分享沒有辦法在這裡一一描述，否則就要出書了！希望各位在IT領域上名列前茅於所有的競爭行庫之間，共勉之～
Add new comment