每個 AIX LPAR 的 DB2 實例數量平衡指標
我有一個問題一直困擾著我，但我只是不知道如何驗證它。我們在我們的商店中在 AIX 上執行 DB2 LUW。我們的 AIX 目前是 7.1。對於大多數安裝，我們的 DB2 為 9.7 FP 4，而對於我們最新的數據庫，我們的 DB2 為 10.5 FP 2。我們甚至在同一個“盒子”上混合安裝（即 9.7 和 10.5）。
我們的盒子當然是 LPAR，由 AIX 管理員提供給我們。AIX 管理員也是我們的儲存管理員，因此所有磁碟都是 SAN。我們的數據庫伺服器沒有太多物理特性。
困擾我的是每個 LPAR 的 DB2 實例的正確平衡是什麼？我開始看到一些關於 DB2 自動配置本身的奇怪行為。在一個 DEV LPAR 上，我們有以下配置：
請注意，對於所有實例，以下情況都是正確的：
HEALTH_MON設置為OFF，並且對於每個數據庫AUTO_MAINT都設置為 。OFF我們確實允許在預設情況下啟用自調整記憶體管理器 (STMM)，並為此設置所有必要的參數（即，正確參數中的零或 AUTOMATIC，DB2 提供的預設值…）。如果我們建構一個 OLTP 數據庫，那麼我們將 instance parm 設置MAX_QUERYDEGREE為1並 leaveINTRA_PARALLELtoNO並將 db parmDFT_DEGREE設置為1。如果我們建構一個 OLAP 數據庫（單獨的實例），我們將 instance parm 設置MAX_QUERYDEGREE為ANYandINTRA_PARALLELtoYES並將 db parmDFT_DEGREE設置為ANY. 我們也不會嘗試在同一個實例中混合 OLAP 和 OLTP 數據庫，儘管部分問題是是否在同一個 LPAR 上混合實例……以下是我們在一個 DEV LPAR 上的內容：
- 一審是9.7。包含一些 OLAP 數據庫，儘管它們非常小，因為它們用於測試 DDL 更改。
- 二審是9.7。包含一個供開發人員使用的 OLAP 數據庫“遊樂場”。（這個應該是我們一有機會就退休了。）
- 三審是10.5。包含來自實例 2 的該遊樂場數據庫的官方 DEV 版本。
- 第四個實例是 10.5。帶有本地元數據字典的 OLTP 數據庫。
- 第五個實例是 10.5。用於查找數據的 OLTP 數據庫。
- 第六個實例是 10.5。ODS 數據庫（不確定這是 OLTP 還是 OLAP….）供開發人員綁定來自兩個事務系統的數據。
現在磁碟不是最大的問題，因為它由 SAN 處理。甚至記憶體和 CPU 在本質上都是虛擬化的，因為它是 LPAR。但是我在記憶中看到了一些奇怪的東西。
一個 OLAP 數據庫（操場和官方 DEV）相當大。開發人員正在大量數據中測試 ETL，並為他們對 QAT 和 PROD 建構的官方請求估計大小。自從其中一個開始增長以來，我注意到新的實例建構和新的數據庫建構現在預設關閉 STMM。我可以手動重新打開它，但關鍵是我覺得這很令人不安。預設情況下是否啟用 STMM 由 DB2 在創建時根據系統資源決定。所以，對我來說，這就是說 DB2 覺得它沒有足夠的資源來進行自動管理，所以它試圖限制記憶體，希望它至少能獲得那麼多。（我對此的猜測。）
當我與 AIX 管理員討論這個問題時，他們似乎並不認為記憶體和 CPU 是個問題。他們說我們並沒有真正充分利用我們所能做的，所以在他們看來（我說得非常鬆散）我們可以將所有開發實例放在同一個 LPAR 上。或類似的其他環境。同樣，這是鬆散的，因為他們了解 HA 和 DR 場景的分離點。
無論如何，這讓我想知道，在知道何時可以將實例添加到 LPAR 或何時應該拆分到其他 LPAR 之間是否有任何指示或指導？我確定答案是“視情況而定”，但我正在尋找任何近似值或指導方針？特別是如果這些在 OLTP 和 OLAP 方面有所不同。
你不會得到這個問題的任何具體答案，因為正如你所觀察到的，這取決於.
答案取決於貴公司對一個 DB2 實例對另一個實例的性能產生不利影響的容忍度。如果您的 AIX 管理員願意在作業系統級別（而不是 DB2 WLM）學習和設置 WLM 策略，您可能能夠控製或限制這種影響。
這確實是容量管理的問題。了解環境中的工作負載是關鍵，能夠辨識（或預測）何時會遇到限制將影響您決定在單個伺服器上放置多少個實例。