在 4 月的 IIUG Informix Conference 上，我們舉行了一次最快的 Informix DBA 競賽。我在一個簡單的客戶結賬流程中添加了一些錯誤的 SQL，並在默認 ONCONFIG 文件中設置了一些錯誤的配置選項 —— 重建了日常生活中比較常見的挑戰。未修改的基准測試需要運行大約 30 分鐘時間，我給參賽者的任務是讓它能更快地運行。最快的一名 DBA 讓它能在 4 分鐘之內運行。在上一期文章中，我討論了這項挑戰並列出了獲勝者；這次，我將講解他們是如何做到的。
首先，分析問題
成功的 DBA 都花費了足夠的時間來研究問題。我們在一個文檔中描述基准測試，包括所有代碼和預期結果。我們還在一個視頻中描述了他們需要解決的問題，並展示了如何運行基准測試。
花較長時間研究材料的選手取得了更好的成績，因為他們可以更好地專注於自己的任務。舉例來說，我故意改變了模式，將緩沖流通率設定為非常高的值，而最快的 DBA 在看了數據和模式後發現了這個問題。另外，基准測試系統只有一個磁盤，因此利用 Informix 並行磁盤讀取和寫入並不沒有太大的用處。所有成功的 DBA 首先都研究了問題、分析了事實，然後才開始制訂計劃。
Informix 配置：ONCONFIG 文件更改在確定如何修改 Informix Dynamic Server (IDS) 配置文件過程中涉及的一項挑戰是 ONCONFIG 文件。這些更改專門針對基准測試環境，並且不一定能適用於所有場景，但它們確實能為您提供一些關於 ONCONFIG 文件的啟發。
BUFFERPOOL成績優秀的 DBA 都增加了服務器所使用的緩沖數量。服務器擁有 3 GB RAM。最快的 DBA 使用了幾乎一半的 RAM 用作緩沖，創建一個 16 KB 分頁大小的 dbspace（大於默認 2 KB 分頁大小），並分配了三分之一的內在作為這個 16 KB 分頁的緩沖。這解決了記錄太大而無法適應默認 2 KB 分頁大小的問題，它將記錄保存在一起，並將大多數記錄放在內存中。總的來說，我認為 BUFFERPOOL 調整對性能的影響最大。
最快的 DBA 還特別控制了 BUFFERPOOL 的大小。而 BUFFERPOOL 過大會造成 OS 開始換出磁盤並會降低整個系統的速度。在添加緩沖時，您還需要考慮 Least Recently Used (LRU) 查詢的數量，它們用於管理 BUFFERPOOL 中的所有這些額外的分頁。最快的 DBA 增加了 LRU 查詢，以便於更加有效地處理額外的內存。
SHMVIRTSIZE，這是 Informix 將分配給工作空間和虛擬內存的內存量。所有較快的 DBA 增加了這個值。而最快的 DBA 增加的最多。SQL 中還有大量 “group by” 語句，因此增加虛擬內存並對 Parallel Database Query (PDQ) 流程執行一些更改可以讓任務更多地在內存中完成。
DS_TOTAL_MEMORY，這是 SHMVIRTSIZE 內存中將用於 PDQ 操作的內存量。其默認值非常小，增加這個值有助於排序和索引構建。
DS_NONPDQ_QUERY_MEM，這是在未使用 PDQ 執行排序時分配給排序任務的內存量。由於基准測試系統上只有一個磁盤驅動器，因此 PDQ 並沒有太大用處。增加這個參數有助於排序和索引構建。
LOCKS，LOCKS 的數量和它們可用的內存量。如果此配置參數不夠大，則 Informix 會動態增加它，但動態增加的值是非常有限的。最快的 DBA 都設置了 LOCKS 的數量，這樣服務器就不需要動態增加這個值。
RESIDENT，設置這個值可以將 Informix 維持在內存中，並通知 OS 不要將數據庫服務器換出到磁盤中。所有較快的 DBA 都設置了這個值，以便將 Informix 維持在內存中。CPU VP ——基准測試機構采用四核 CPU，並且可以支持四個 Informix CPU 虛擬處理器 (VP)。所有較快的 DBA 都將 CPU VP 的數量設置為 3 到 4 之間，以便於利用機器上的所有 CPU。
DBSPACETEMP，我在基本配置中創建了一個臨時的 dbspace，但是並未在 ONCONFIG 文件中定義它，因此未使用它。而是將 rootdbs 用於排序和臨時文件。所有較快的 DBA 都修改了 ONCONFIG 文件，在其中標識並定義了這個參數。一些 DBA 甚至創建了兩個或三個額外的臨時 dbspaces，因此 Informix 可以並行讀取和寫入 tempdbs。
一些最快的競賽者還修改了其他 ONCONFIG 參數，包括 PHYSBUFF、LOGBUFF、DIRECT_IO、VP_MEMORY_CACHE_KB 和 CLEANERS。很難確定它們的作用有多大，但最快的 DBA 發現其中一些參數能極大提高速度。我還比較關注哪些參數未被更改。可能是時間不夠，但沒有人修改過 read-ahead 參數 RA_PAGES 和 RA_THRESHOLD，也沒有人修改過 index-cleaning 參數和 BTSCANNER。
Informix 模式更改
我故意在數據庫的兩個表中使用了非常大的列：客戶表中的 CHAR(2000) 列和賬單表中的 CHAR(1000) 列。但是，這些空間通常都被浪費了。在客戶表中，大約只使用了 100 個字符，而賬單表中的字符都沒有使用過。這不僅浪費空間，還造成表溢出了 2 KB 分頁，從而導致大多數緩沖 Thrashing 非常高的緩沖流通率。有許多解決方案可解決此問題，其中之一是修改表並將這些列轉換為 LVARCHAR 列。此更改減少了在基准測試期間讀取和寫入的緩沖數量，並且可能對總體性能造成了最大的影響。
一些 DBA 還對模式進行了另一項修改，即將賬單表的索引創建工作移動到插入了所有數據之後進行，而不是在插入數據之前。這樣可以更快地載入沒有索引的表，並且創建的索引會更加緊湊和優化。此外，在 IDS 11.50 中，建立索引會對表自動執行 UPDATE STATISTICS HIGH，這將為 Informix 查詢優化器提供關於表的更好的信息。一些 DBA 在客戶表上添加了額外的索引，這有助於基准測試中的最後一項查詢操作。
SQL 優化
基准測試包括兩條針對賬單的 INSERT 語句和三條 UPDATE 語句。UPDATE 語句還包含一些子查詢。在基准測試流程結束時，它執行了兩條帶 Group By 從句的 SELECT 語句，用於檢查數值。最後兩條語句生成的數值需要與預期結果相吻合；這正是我們驗證基准測試是否成功完成的方式。為增加難度，我還在 SQL 中添加了一些多余的、不必要的代碼。
經過精心規劃，我認為認為整個流程可以使用一條 INSERT 語句再加上一到兩條 UPDATE 語句便可完成，但沒人注意到這一點。但是，一些較快的 DBA 確實發現了 SQL 語句中存在一些沒有用的代碼，並從基准測試流程中刪除了這些代碼。
敬請期待 IOD 2009
開展這次競賽是非常有趣的，所有 Informix DBA 參與者都發揮了自己的智慧和創造力。我們在此恭喜獲勝者！上一期文章中（ibm.com/developerworks/data/dmmag /archive.html）已經宣布了他們的獲獎。詳細名單請訪問我們的網站：www.advancedatatools.com/Informix /index.Html。
我們在 2009 年 7 月 18 日至 9 月 30 日舉辦另一項競賽，即 Fastest Informix DBA Contest II。在 10 月份的 IBM Information On Demand 2009 global Conference 上，我們將為競賽者舉行一次網絡討論會和 Birds of a Feather 會議 —— 請訪問 Advanced Data Tools 網站（如上）了解更多信息。希望能見到您。
