軟件測試中Oracle決策支持系統下的性能調整和優化原則

軟件測試中Oracle決策支持系統下的性能調整和優化原則

DSS 系統的特征是從大量的數據中產生有意義的報告。DSS 應用可能會經常與 OLTP 一起使用，但因為它們的設計要求差異很大，把 OLTP 系統用于決策支持不是好的主意。OLTP 的用戶一般很多，而 DSS 系統的用戶一般較少。決策支持系統的例子有與定單錄入系統（OLTP系統）一起工作的現金流預測工具，該工具可以幫助決定需要多大的現金儲備。另一個決策支持的例子是客戶需求分析工具，該工具可以找出某個地域客戶對哪個產品購買量最大。

　　決策支持系統的主要特征是：

• 讀取大容量的數據，經常使用全表掃描作為存取數據的方法。
• 極少量地更新數據。一般而言，從OLTP 系統的數據（也可能是其它的數據源）會以批的方式流向 DDS 系統，用戶自己極少會更新 DSS 的數據。

　　下圖反映了DSS系統的特征：

　　DSS系統在運行時，有如下的一些要求：

• 合理的響應時間。
• 結果是準確的。
• 可以在白天使用。

　　為了滿足上面的要求，應當從以下幾個方面考慮調節數據庫DSS應用系統。

1. 在使用應用邏輯和聲明約束來維護完整性方面，切記聲明完整性約束的代價要小。在DSS系統中，相關完整性約束和表的check 約束是主要使用的約束形式。

2. 盡量要使代碼被存儲過程對象共享。

3. 即使一條SQL語句在不同的運行環境下捆綁變量（bind variable）取了不同的值，Oracle認為他們是同樣的SQL語句。因此，要使分析SQL語句的工作減少到最抵，應當使用捆綁變量，而不是將這些不同的值直接放到SQL語句中（使用 literal）（如果這樣做了，Oracle 認為它們之間是不同的SQL，需要重新分析）。但是，這樣做會有如下的損失：優化器無法知道列的可選擇性。而完全寫出來的SQL 語句（使用 literal），可使基于成本的Oracle優化器使用直方圖統計（histogram）。

4. 無論如何，對DSS系統來說，分析 SQL 用的時間要比執行SQL語句用的時間要少的多。工作重點應當是優化SQL語句執行計劃的存取路徑上。這里的微小調節可能會帶來幾分鐘，甚至是幾小時性能的提高。開發人員必須考慮：

• 使用并行查詢（parallelized query）。這可以使多個處理器工作在一起，同時處理一條SQL語句。使用鏡像多處理（Symmetric Multiprocessors，SMP）、集群、大規模并行處理（massively parallel processing，MPP）會極大地提高DSS系統的性能，因為這樣做可以將工作分在多個 CPU 上完成。
• 應當用提示來控制SQL 語句的存取路徑，并利用 explain plan 來調節SQL 語句。

5. 因為DSS系統的數據更新以定時的批處理為特征，所以，DBA 在進行性能調節時有很多選擇。DSS系統可以使用索引和簇（特別是哈稀簇），因為數據更新并不經常發生。在批量的數據更新完成后，可以重新創建索引和簇，以避免修改索引和簇的負面影響。如果不能在批量處理完成后重新創建簇，則為存取性能考慮，不應為在裝入時不斷增長的表創建簇。

6. 應當將索引存放到一起。

7. 因為大多數查詢是全表掃描，應當僅在有選擇性查詢的表上加索引。

8. 應當經常用 analyze 進行統計。對那些數據分布不均勻的表，應當經常產生統計直方圖（Histogram）。

9. 對那些不同值很少的列，使用 bitmap 索引。

10. 對于塊插入和修改，必須設置如下的初始化參數：SORT_AREA_SIZE、BITMAP_MERGE_AREA_SIZE、CREATE_BITMAP_AREA_SIZE。

11. 對那些需要用鍵列做條件做準確匹配的查詢或范圍查詢，如果要將行的信息全部查出，應考慮使用組織索引表。

12. 在一些情況下，一些表根本不變化，此時可以將這些表放到一個特殊的表空間中，并使該表空間只讀。

13. 因為DSS應用經常進行全表掃描，所以應當將 DB_BLOCK_SIZE 的值設得高一些，即使這需要重新創建數據庫也應這樣做。因為大量讀是DSS系統的基本特征，這樣做會使DSS系統的性能發生根本改變。還應當注意參數 DB_FILE_MUTIBLOCK_READ_COUNT 的設置，該參數決定了全表掃描和快速全索引掃描每次操作系統讀調用操作的數據庫塊數。盤區的尺寸應當是DB_BLOCK_SIZE* DB_FILE_MUTIBLOCK_READ_COUNT的倍數

原文轉自：http://www.anti-gravitydesign.com