效能與安全的權衡

    對於資料庫調優而言，沒有絕對的效能也沒有絕對的安全。正如魚和熊掌不能兼得一樣，是不能完全兼顧的，就像是矛和盾此消彼長。下面就對比較常見的幾個因素做一個簡要的闡述：

1、多元化控制檔案：

      多個地方，意味著更安全，一個損壞了可以轉儲另外一個繼續使用。但同樣，越多也意味著IO壓力越大，一般為2到3個控制檔案多元化。比如：假設3個控制檔案都損壞的概率已經相當低了，再多的控制檔案也就沒有意義了。因為一個控制檔案損壞，資料庫立刻就會崩潰，檢查點的發生會產生預警資訊，這樣就可以根據提示人為的做出干預，儘快對其解決。

2、多元化日誌組成員：

       多遠化日誌組成員一樣，越多也就意味著IO壓力越大，但對於日誌組，要根據實際生產環境去制定適宜的日誌組個數、日誌組成員的個數、日誌組的大小。

3、經常產生檢查點：

       發生檢查點以後，如果要做資料恢復的話，說明要從檢查點以後資料進行恢復，這就意味著檢查點發生的多，恢復的量級就少。即使資料丟失，也能確定發生這個檢查點的時候，資料都寫入到了資料檔案裡。但經常發生檢查點對於效能上IO量會大。因為發生檢查點時髒塊會同步到磁碟上，設計髒塊的目的就是一個髒塊修改了很多次，在將髒塊寫入到磁碟的時候可以一次完成。有一點要提及的就是修改記憶體中的資料狀態要比修改磁碟中的資料狀態快很多，設想一下把多次修改記憶體中的狀態，變成多次直接修改磁碟中的狀態，會有怎樣的變化。做一個極端化假設，髒塊每次細微變化就觸發一次檢查點，把髒塊寫入到磁碟中，是保證了資料的安全性，但這就破壞設計緩衝區的目的。記住一點，寫入磁碟的資料效率要遠低於寫入記憶體資料的效率。

4、資料檔案備份：

       沒有備份，資料丟失是無法恢復的。要明確的知道，在做資料的備份的時候，會產生大量的讀和大量的寫，這個過程需要很大的IO，做的多對資料庫是有影響的。但客戶都會有一個最長的恢復時間（到達現場的時間、轉儲環節、recover環節，經過測試能滿足客戶要求的最長的停機時間），如恢復一週資料需多長時間，要有備份策略，在做備份之前要跟客戶協調好，如果可以的話需要簽署某些備份協議以保證雙方應承擔的義務和責任。

5、開啟歸檔：

       一般生產庫均會開啟歸檔，排除某些允許資料可以丟失的現場環境，實際工作中很少有不開歸檔的。一旦存在這種情況的話，往往資料是可以從其它途徑恢復的。如把資料從庫中匯出，這樣就可以接受非歸檔。舉個例子可以不開歸檔，比如一個用於實驗或分析的庫，其中的資料是由另外的庫匯入的，這種情況就可以接受不開歸檔。

同樣的，歸檔的路徑越多，安全性越高，效能影響就會越大，這就是一個相互制衡的因素。

6、資料塊檢查：

舉例：

SQL> show parameter check

NAME                       TYPE      VALUE

------------------------------------     -----------    ------------------------------

db_block_checking             string      FALSE

db_block_checksum            string      TRUE

log_checkpoint_interval         integer     0

log_checkpoint_timeout         integer     1800

log_checkpoints_to_alert        boolean    FALSE

       由上圖的檢視可以查詢到db_block_checking引數：

FALSE：表示當從資料快取區把資料往磁碟上寫的時候，僅要求system表空間往下寫的時候，是需要驗證的，其它表空間不做驗證；

TRUE：表示所有表空間在寫髒塊時都做驗證。

     該資料庫檢查越多，IO越多，但資料越安全。這就要看事務的重要程度了。

7、併發的使用者和事務數量：

       這是對於系統資源損耗情況的討論，不能單從資源消耗多就判斷系統性能有問題，因為對於資源的使用上，比如說當使用多時可以接受很多的使用者操縱，在單位的時間內可以完成很多的事務。為了做到這點，負荷必然大，效能消耗必然多。這就是一個平衡點，一般需要保證系統在一個平穩的狀態下執行後，儘可能多的去承擔使用者的訪問為佳（即事務量越多越好）。

       優化的影響因素有很多，這只是對某幾點的一個簡單闡述，在部落格中會逐漸的通過幾方面去擴充套件優化。如果感興趣的話，可以關注一下。