性能與安全的權衡
對於數據庫調優而言，沒有絕對的性能也沒有絕對的安全。正如魚和熊掌不能兼得一樣，是不能完全兼顧的，就像是矛和盾此消彼長。下面就對比較常見的幾個因素做一個簡要的闡述：
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、並發的用戶和事務數量：
這是對於系統資源損耗情況的討論，不能單從資源消耗多就判斷系統性能有問題，因為對於資源的使用上，比如說當使用多時可以接受很多的用戶操縱，在單位的時間內可以完成很多的事務。為了做到這點，負荷必然大，性能消耗必然多。這就是一個平衡點，一般需要保證系統在一個平穩的狀態下運行後，盡可能多的去承擔用戶的訪問為佳（即事務量越多越好）。
優化的影響因素有很多，這只是對某幾點的一個簡單闡述，在博客中會逐漸的通過幾方面去擴展優化。如果感興趣的話，可以關注一下。
