內容提要
對於最小化甚至消除計劃的數據庫停機本文描述了幾種最佳實踐。停機就是數據庫不能響應用戶請求的所有情況，無論是數據庫完全下線，還是在不可接受的性能情況下部分下線。有計劃停機包括在你的數據庫系統中常規數據庫維護或升級活動。
停機對你數據庫環境的可用性有直接的影響。可用性是一個對系統服務用戶應用請求的能力的衡量標准。一些數據庫環境在可用性上能承受偶爾的中斷，而其他環境必須隨時可用。你選擇的可用性策略和為了達到這個可用性目的而花費的資源，這應該由你的商業來驅動。
DB2 數據服務器包含可以幫助你 消除某些類型的計劃停機並減少其他影響。這篇文章將討論這些功能，以及什麼時候如何使用它們來達到一個高級別的可用性。
最佳實踐
維護表和索引:
Reorg 操作是很耗資源，並會限制可用性——在有可能的情況下避免執行它。
使用 DB@ 集群技術，比如 MDC 表或集群索引來防止或減少重組表的需求。
設置 DB2MAXFSCRSEARCH 注冊變量或盡可能短的保持你的事務，以降低表重組的空間需求。
使用 PCTFREE 參數或減少行擴大的 UPDATEs 以降低刪除溢出記錄的需求 。
使用自動壓縮替代表重組，來壓縮表。
把所有 type-1 索引轉換成 type-2 索引。
如果你需要運行一個重組的話，就使用一個在線重組。
使用 CLEANUP 選項來減少你的索引重組的范圍。
數據移動和數據攝取:
使用 SQL INSERTs 替代一個裝載操作，來保證大型表的讀寫的可用性。
在使用 range-partitioned 表時，添加一個數據分區或把一個表作為一個數據分區添加。
如果應用程序只需要對目標表的讀取進行訪問時，那麼可以使用一個在線裝載。
升級操作:
如果你有 HADR，則使用滾動升級功能。
安裝新的 DB2 軟件並行化你的現有數據庫。
備份操作:
使用在線備份，以保證你的數據庫可用性。
通過使用表空間級別或增量備份，來縮短你的備份操作的時間。
把所有數據、索引和大表空間創建為 DMS 或自動存儲表空間，並設置 DB2_OBJECT_TABLE_ENTRIES 注冊變量為最大值，來減少和其他並行操作的沖突。
在一個在線備份過程中，你正在執行一個非常重要的替換操作，那就把 DB2_TRUNCATE_REUSESTORAGE 設置為導入。
調優和配置:
在配置更改中使用 DB2 的動態配置能力，來保持數據庫在線。
使用 DB2 的自動調整能力來提高性能，同時保持數據庫可用。
為 AUTOMATIC 設置確定參數，從而防止缺少資源的錯誤信息。
存儲管理:
對 DMS 表空間使用自動存儲，或啟用 auto-resize 能力來讓數據庫管理器自動防止文件系統滿，同時仍保持完全的讀寫訪問。
對每個只有一個表的表空間，使用自動存儲或在 ALTER TABLESPACE 語句中使用 REDUCE 子句來簡化空間釋放。
介紹
這篇文章側重於管理有計劃的數據庫停機策略，尤其是在執行維護操作時。目的是達到一個數據庫可用性級別，能滿足你的商業需求。
本文具體側重的范圍包括：
表和索引維護
數據裝載或數據吸收
升級
備份
本文也將提供一個概要戰略來提高可用性，通過：
調優功能和配置
存儲管理
可用性
在你的商業流程以及你的底層數據庫解決方案的背景下，可用性是對數據庫及時的為用戶應用程序處理事務的能力的衡量。
一個數據庫解決方案的可用性需求是由你的業務需求決定的。例如，如果一個數據庫解決方案服務於一個從上午 9:00 到下午 5:00 的單個的店面業務，那麼數據庫可在下午 5:01 到次日上午 8:59 期間下線而仍被認為是高可用的。另一方面，如果相同的數據庫解決方案提供了一個跨多個時區的存儲鏈，可能的停機時間窗口就變得更小了。如果數據庫解決方案服務一個需要每天 24 小時對服務客戶的在線業務，那麼數據庫不能在影響客戶的情況下下線。
停機
停機破壞了數據庫方案服務用戶應用程序的能力。停機可以很徹底，就像在一個數據庫處於下線或部分下線狀態，或由於在系統資源上的高需求導致不可接受的低性能。
停機可以分成兩類：一類是意外停機，這將是“對意外停機和恢復做好准備”最佳實踐關注的；另外一類是計劃停機，這將是本文關注的。
意外停機
意外停機的例子包括：
系統的一個或多個關鍵組件失敗，包括硬件或軟件的失敗。
疏於管理或用戶應用程序行為，比如意外刪除了一個核心業務事務需要表。
由於不理想的數據庫配置導致的低性能，或者不合適的硬件或軟件。
計劃停機
計劃停機的例子包括：
維護操作需要你把數據庫下線，或者維護活動可以在不停止數據庫的情況下執行，不過這樣做會對性能產生負面影響。這些是最常見的計劃停機類型。
你的軟件或硬件升級，比如安裝 DB2 Fix Pack，這可能需要數據庫部分或全部停機。
可用性策略
你選擇的可用性策略應該基於計劃停機可能會對你的業務產生的影響。在某些情況下，在一個策略上投入大量資源以保證你的數據庫的高可用性可能是正確的；而在其他情況下可能不需要一個高可用性系統。
判斷你的可用性策略的一個關鍵因素是你的業務，或在業務中的一個特定系統，對發生停機的容忍程度。例如，一個上面有飯店的菜單信息的網站可能可以容忍發生計劃停機。在其他情況下，任何停機（計劃或意外）對於處理交易相關事務的股票交易服務器可能都是災難。投入大量的資源來確保飯店的服務器 99.99% 可用，可能是沒有成本效益的，然而在股票交易這種情況下，這是非常必要的。量化停機的影響、在這期間損失的收入、損失的生產力，甚至喪失的客戶信心和信譽，將有助於你對可用性策略投資的程度做出決定。
當然，只要有可能你都應該通過執行例程維護任務盡量避免計劃停機，比如在數據庫處於在線狀態進行數據庫備份。在進行升級的時候，你也可以顯著的降低計劃停機的時間。
一些數據庫維護任務可能總是需要完全或部分計劃停機，不過你可以采取步驟來減少這些停機的影響。對這些維護任務完成的時間來說，可以通過最小化這些數據庫任務消耗的系統資源來減少影響。例如，對一個表或索引進行過多的重組，會毫無必要的消耗系統資源，在這個時間點你的終端用戶會感受到對他們的請求不可接受的響應時間減慢。理論上數據庫可能仍然是在線的，但是處於“brown out”症狀，可能導致應用程序在事務提交之前就發生超時。說到升級，你可以通過使用 DB2 的功能（比如高可用性災難恢復“HADR”或利用在相同系統上的分開的 DB2 安裝）明顯的減少停機持續時間（因此產生的影響）。
下面的章節將討論最小化或消除計劃停機的影響的最佳實踐。
提高在表和索引維護過程中的可用性
在表或索引上的重組操作（reorgs）是資源集中的行動，會限制表的能力以及減少並發。然而，如果你遵循這些普通的指南，就應該可以減少 reorg 相關的停機影響：
只在必要的時候執行重組
只使用 2 類索引
減少執行重組的需求
將重組操作的影響最小化
只在必要的時候執行索引和表的重組。
重組不應該僅作為歷程周期性執行。事實上很多 DB2 索引和表，永遠不需要被重組。這個主題的其他信息請參見 DB2 信息中心“Determining when to reorganize tables and indexes”部分。
如果你使用 REORGCHK 命令來判讀是否需要執行重組，並確保閥值公式和你的工作負載相關。使用下面的經驗法則來解釋公式，你應該可以顯著地限制重組的頻率和影響：
F1:為 PCTFREE設置一個中性值
這個公式和溢出記錄的百分比相關。考慮調整每頁空閒空間的百分比（PTCFREE）來降低以後重組的需求。設置一個中性值，比如 5% 就被證明很好。溢出記錄會增加處理時間，這是因為溢出域需要作為所有對表操作的一部分被訪問。如果在你的工作負載中溢出記錄不被頻繁訪問，那麼你可以忽略這個公式。你可以通過使用 overflow_Accesses 監控元素來判斷溢出有多頻繁。
F2,F3:如果你不需要空間，可以忽略它們
這些公式與重組表獲得的空閒空間相關。如果你不需要使用別處的空間而且也不需要為其它表釋放空間，或者如果更多數據將被添加進這個表中你可以忽略這兩個公式。如果表趨於再次增長，明智的選擇是不釋放空間。
F4：使用一個 MDC表或者一個集群索引
這個公式是和一個索引的集群率相關的。如果你為了好的性能而需要集群，就可以考慮使用一個多維集群（MDC）表或者一個集群索引。如果你的工作負載包含不重要或不太重要的語句而它們可以從集群獲得好處，就可以忽略這個公式。
F5,F6：如果你不需要空間，或是使用 CLEANUP選項，則可以忽略它們
這些公式是關於你是否需要重建索引的。如果你不需要釋放空間在別處使用，可以忽略這兩個公式。如果你的確想執行一個重組來重建索引，那你應該首先嘗試使用有 CLEANUP ONLY ALL 的重組，來精煉索引。有 CLEANUP ONLY ALL 的重組速度更快、資源消耗更少，以及產生的影響更小，因為沒有涉及對象切換階段，所以這個階段需要加表級別的鎖。
F7：如果 pseudo-deleted鍵沒有影響
這個公式關於在 non-pseudo-empty pages 上的 pseudo-deleted 的 RIDs。它描述了對最低影響的需求，CLEANUP ONLY ALL 的索引是最佳匹配。雖然這個公式可能建議你執行一個重組，但你仍然可以忽略它。例如，如果 pseudo-deleted 鍵的出現不會對在線工作負載產生負面影響而且你也不需要 pseudo-deleted 鍵占用額外空間的話，你就不需要進行重組。
F8:如果 pseudo-empty葉子頁面沒有影響則忽略
這個公式是和 pseudo-empty 葉子頁面相關的。它描述了最低影響的需求，使用 CLEANUP PAGES 的索引重組是最佳匹配。就像 F7，就算這個公式建議你執行一個重組，你仍然可以忽略它。
把所有 type-1 索引轉換成 type-2 索引。
在 DB2 Universal Database™ Version 8.1 之前，所有的索引都是 type-1 索引。即使所有新的索引是 type-2 索引 type-1 索引仍然可以出現在你的數據庫中。 因為 type-2 索引有很多好處，比如增加並發特征和允許附加函數，比如在線表重組，所以你應該轉換所有剩余的 type-1 索引。對 REORG 命令指定 CONVERT 選項來執行這個轉換。
減少執行重組的需求。
問問你自己重組真的必要嗎，是否有其他方法可以達到重組的效果？
你不應該在沒有理解能從它那裡得到什麼的情況下執行一個重組。例如數據庫系統的一般智能可以顯示索引重組需要做很多事情，包括（並不完全）：
在索引中減少大小和級別數目
在索引中減少 pseudo-deleted 鍵的數目
提高索引頁面的序列性，並因此提高索引按距掃描的 I/O 性能
當這些理由是一個重組的有效理由時，記住在大多數情況下 DB2 索引管理算法會爭取消除顯式進行重組的需求。例如，pseudo-deleted 鍵在數據操作語言 (DML) 處理時被自動刪除。
同樣的，你也有執行表重組的理由，包括：
估計索引鍵的數據行重組，並會因此在某些查詢計劃中提高 I/O 性能。
釋放內嵌的空閒空間。
消除溢出行
壓縮一個表
在不需要重組的情況下，你可以使用很多策略來達到這個結果。
使用集群技術。多維集群（MDC）表和集群索引能幫助你避免重新集群的重組需求。MDC 表在任何時候都保持表的集群以及遵守所有指定維度。如果你決定使用 MDC 表，為了最小化它們在存儲上的開銷，你必需小心的為你的表選擇維度。使用設計顧問來檢測你的數據和工作負載，並提供一個推薦的具有最優性能和空間需求的維度集合。
集群索引將基於指定的索引保持表的集群，在一個最大努力的基礎上，這減少了重組的需求並保證了高集群率。雖然這會明顯的減少對個表重組的需求，但是集群縮影會嚴重影響插入和更新速度。
利用 DB2MAXFSCRSEARCH注冊變量。在某些情況下，這會減少釋放空間的重組需求。這個注冊變量可以控制插入過程中的插入速度和空間釋放的速度。在表中添加新頁面之前限制為了容納被插入行對頁面數目的需求，因為較低的值有利於更快的插入。通過搜索更多的表，使得較高的值有更好的空間利用率。它的默認值 5 是一般情況下很好的折中。然而，如果你有非常大的表，並且經常進行刪除操作，就應該考慮對 DB2MAXFSCRSEARCH 設置更高的值。如果有足夠的連續可用空間，那麼值 -1 將確保這些空間在表中添加一個新頁面之前使用。
注意，設置較大的值以及 -1 並不意味著每次插入都要對整個表進行搜索。作為替代，表中空閒空間是被緩存了的，而且會在搜索空間時提供。例如，當表中的所有頁面都滿了時（這些信息都是被緩存了的），一個後續的插入將不進行搜索，一個頁面將立刻被添加進表中，即使在注冊變量被設置為 -1 的情況下。
讓你的交易越短越好。短期運行的事務減少了重組釋放空間的需求，因此盡可能多的執行提交操作。長期事務的出現延緩了表中被刪除空間的重用。
減少或消除頻繁的 UPDATEs這會增大行數。這可以減少執行重組表帶來的刪除溢出的行的需求。例如，如果可能的額外空間消耗允許的話，就可以在一個經常更新的列上使用 CHAR(8) 來替代 VARCHAR(8)。更新 VARCHAR(8) 列，可能改變行的長度，而更新 CHAR(8) 則不會。
利用 PCTFREE參數。這可以減少經常執行重組，來刪除溢出的記錄。這個空閒空間可以在不需要產生溢出記錄的情況下，用來調節行增長。通常情況下，如果你知道行數在後面會擴大（例如通過一個後續的更新操作），那麼你就應該使用 PCTFREE。如果你知道行數在後面不會增長，例如果是固定長度的行，那麼你就不要使用 PCTFREE 參數。
使用自動壓縮。壓縮的目的是為了可以減少或消除重組需求。使用自動壓縮，當表增長到一定大小時，表壓縮就開始自動行壓縮了。
另外，如果你對一個常做大量插入和刪除的表使用 ALTER TABLE APPEND ON，那麼你應該尤其小心。當你使用附加模式，刪除操作會在表中間產生中斷，而且插入將不使用這些空間，因為數據值添加在表最後。因此對表使用 APPEND 模式會導致更多的表片段，並需要更頻繁的重組。
最小化重組的影響。
如果你不得不對你的表或索引執行一次重組，那麼盡量不要執行離線重組。使用在線（也叫 implace）重組或一個清除重組來達到相同的結果，並保持最大可用性。
使用一個在線表重組。一個在線重組常常是在重組操作時保持數據可用性的理想方法。所有的讀取和寫入都不會中斷，除了在裁剪階段，在此階段所有寫入操作都暫停了，不過讀取操作仍然保留。在這裡做出的妥協就是在線重組的性能更差，而且會增加日志空間的消耗。然而，你可以通過更改重組操作來緩解它。例如，如果你只是為了釋放空間而進行重組，並且如果集群在工作負載中並不重要的話，就可以執行一個不指定索引的在線重組（並確保在表中沒有定義集群索引）來最大化重組期間的可用性。
執行 cleanup來替代完全索引重組。一個實際的例子，如果一大批刪除操作剛剛在一個表中刪除了大量的行，這會留下偽刪除的索引鍵。索引管理器通常將在稍後自動清除這些偽刪除鍵值。然而，如果你希望確保下次通過索引的訪問不會因為偽刪除鍵的出現而受到不利影響的話，就使用有 ALLOW WRITE Access … CLEANUP ONLY 選項的 REORG INDEXES 命令來有效的刪除偽刪除鍵，並保持表和索引的讀寫訪問。如果你不需要這些空間而且你的工作負載沒有命中這些鍵值，那最好不要管它們，讓索引管理器來處理對它們的刪除就好了。
提高在數據裝載或數據吸收過程中的可用性
在你向表中導數時，可以使用很多策略來最大的保證目標表中未受影響數據的可用性。這些方法按它們提供的可用級別、從高到低是：
使用 SQL INSERTs
使用 ATTACH 選項來轉入數據
使用在線裝載
使用 INSERTs 向一個表中插入數據。
雖然高速裝載實用工具可以以很快的速度裝載數據，但是 SQL INSERT 轉換率非常高而且常常能滿足大多數需求。然而，使用 INSERT 進程的好處是保持你的表完全可讀寫。在 SQL INSERt 不能滿足你的性能需求情況下，可以考慮使用其他插入方法，比如緩沖插入和批量插入，或編寫你的應用程序，從多個連接並行插入。
使用 ATTACH 或 ADD/LOAD 來轉入數據到分區表。
表分區讓你能有效的把一個新表或不用的表，關聯或附加到一個分區表中。或者，你把一個表作為一個新的數據分區添加並裝載數據。
你可以使用 ATTACH 子句來合理化數據吸收，通過裝載新分區的數據到一個新的或不使用的表，然後通過 SQL 執行任何數據淨化的操作，而數據仍然在這個表中。這些活動對在線工作負載訪問分區表沒有影響，因為新的或未使用的表還沒有和分區表關聯。一旦數據准備活動完成，就可以使用 ALTER 語句的 ATTACH 子句，把這個表作為分區表的一個新的分區被附加。這是一個高效操作，因為它簡單的把現有表作為分區表中的分區關聯，而不需要移動任何數據。
在這個事務被提交後，新的分區在你發出有 ALLOW WRITE AccessZ 子句的 SET INTEGRITY 之前，對於在線訪問是不可見的。這將在表中定義的所有索引和 MQTs 中反映新分區的數據，同時允許對這個表進行讀寫操作。然而，如果你關心 attach 操作需要的 SET INTEGRITY 的日志需求，那這個可能不是最好的辦法。
另外一個選擇是，把一個表作為新的數據分區添加到其他的分區表中然後裝載數據。如果這個表沒有約束或 MQTs 定義的話，這就避免了 SET INTEGRITY 語句。如果在這個操作過程中你只需要這個表的讀取訪問的話，就可以使用這個選項。
使用在線裝載。
在一個標准的裝載操作過程中，裝載實用工具用一個超級排它鎖將目標鎖定，然而在線裝載允許讀取訪問。在你需要最快數據裝載以及某種程度的可用性的情況下，使用在線裝載。對你的 LOAD 命令指定一個在線裝載選項，包括 ALLOW READ Access 選項。
提高在升級過程中的可用性
使用高可用性災難恢復（HADR）滾動升級功能。
你使用 HADR 來升級到一個更高的 DB2 補丁版本只會造成監控中斷。
步驟如下：
停止備用數據庫
升級備用數據庫
激活備用數據庫
一旦那備用數據庫處於對等狀態，在備用數據庫上執行 TAKEOVER HADR 命令。
把客戶端定向到新的主數據庫
像上面步驟 1-3 一樣升級原來的主數據庫。
在相同系統的不同的位置安裝新的 DB2 軟件。
從 DB2 Version 9 開始你可以在同一個系統中安裝多個 DB2 服務器和客戶端副本。你可以使用這個能力，在不同的路徑上安裝一個新的 Fix Pack，並把你的生產實例轉存到新的實例路徑。如果你沒有使用 HADR，那麼這將是一個有效的方法來加速升級過程。
用一個現有 DB2 數據庫生產安裝介質，在不同的路徑上，新安裝一個 DB2 產品。
停止你的生產數據庫實例。
從新的安裝路徑調用 db2iupdt 命令來升級這個實例。
啟動新的數據庫實例。
執行所有需要後升級的操作，像調用 db2updv8 或 db2updv9、或像 DB2 信息中心安裝修訂包主題中的直接重新綁定包。
可選，卸載你不再需要的 DB2 產品的早期版本。
在備份過程中提高可用性
備份操作可以在數據庫在線或離線狀態下執行。一個在線備份允許應用程序在數據庫備份過程中有完全的讀寫操作訪問權限。雖然一個在線備份可能比離線備份長很多，但是有些步驟可以讓你縮短它。
有兩個方法允許你減少在線備份的時間：表空間級別備份和增量備份。一個表空間基本的備份，僅備份了指定集合的表空間，而不是整個數據庫。一個增量備份只讀取在最後一次備份後更改了的頁面。
就像在線備份和其他實用工具的兼容性中描述的一樣，在線備份不能和一些其他操作一起並行運行。然而，有兩個你可以用來防止這些不兼容的注冊變量：DB2_OBJECT_TABLE_ENTRIES和 DB2_TRUNCATE_REUSESTORAGE。
如果你的表空間包含大量對象（表、索引、大對象列），在你創建 DMS 自動存儲之前把，DB2_OBJECT_TABLE_ENTRIES 設置為 65532 會幫助你避免備份過程中和在線創建索引以及在線重組索引的不兼容。如果你計劃在在線備份過程中使用有 RELPACE 選項的導入實用工具，那就設置這個注冊變量為 IMPORT。Import replace 操作通常用來截去表內容，而且使用這個注冊變量你可以提高在線備份過程中的可用性。
在“Preparing for unplanned outages and recovery”最佳實踐文檔中，有對數據庫恢復更詳細的討論，恢復操作一般在主數據庫系統發生計劃外停機情況下執行。
提高在性能調優過程中的可用性
另外一個可以潛在影響可用性的維護任務是更改數據庫配置參數。幸運的是，DB2 有自動調整能力、動態（在線）配置能力和注冊便利設置，能夠讓你在調整性能時不會導致停機。
利用 DB2 的自動調整能力。
若干 DB2 配置參數可以被自動調整，這讓你可以在不停機的情況下優化性能。雖然自動調整算法可以存為永久性的，但是一個常用的最佳實踐是臨時啟用自動調整，允許自動調整算法判斷工作負載的最佳設置。然後，一旦這些最佳設置被確定下來後，你可以取消自動調整以確保不再有自動的更改發生。這個策略試用於相對穩定的工作負載。
設置若干參數為 AUTOMATIC 的另外一個好處是，防止了停機錯誤的情況。例如，AUTOMacTIC 設置消除了指定一個最大值的需求。就算系統中有足夠的內存，設定最大值可能會因為一個堆被耗盡而產生錯誤信息。雖然系統仍然保持運行，但是這些類型的錯誤可能以一個應用程序錯誤顯示給用戶。從用戶的角度，這些錯誤可能意味著系統不可用，即使可能不是這樣。
下面的參數可以被設置為 AUTOMATIC：
Applheapsz：應用程序可以持續增長直到達到了 appl_memory 或 instance_memory 的限制。
database_memory：從 DB2 Version 9.5 開始，自動調整內存管理器（STMM）可以在 instance_memory 限制下，根據需要調整分配到數據庫的內存。
Dbheap：數據庫堆現在可以在 database_memory 和 instance_memory 的限制內根據需要增長。如果你有很多的表在數據庫中活躍（像在 SAP 數據庫）的話，這就非常重要。TCB（表控制塊）需要一些 dbheap 空間。
Instance_memory: 從 DB2 Version 9.5 開始，這個參數限制所有數據庫和數據庫相關應用程序的內存消耗。如果其他應用程序有內存需求，那麼要設置這個值為自動調要謹慎。如果其他應用程序消耗越來越多的內存，那麼數據庫可能釋放過多內存，這也可能減少數據庫處理大量交易或復雜查詢的能力。
mon_heap_sz：這個參數可以避免的由於事件監控器缺少內存錯誤信息。
stat_heap_sz：RUNSTATS 和實時的統計信息在搜集時的內存需求。他與評估一個最大值不同，因此它最好被設置為自動，這樣可以避免 runstats 操作失敗。
stmtheap：復雜語句需要大量的語句堆來編譯。設置這個值為自動將有助於避免語句編譯時沒必要的錯誤。
設置 DB2_OPT_MAX_TEMP_SIZE 為 1024。
如果其他訪問模式（例如，索引排序）可用的話，就設置 DB2_OPT_MAX_TEMP_SIZE 變量來啟用 DB2 優化器，以避免大量臨時表空間用來排序。這減少了臨時表空間的文件系統滿的可能性，並因此減少了 SQL 錯誤的可能性，增加了系統總的可用性。
使用 DB2 的動態配置能力。
在數據庫可用時，很多 DB2 配置參數可以在線更改。數據庫（或數據庫管理器）配置參數在線更改，必須在數據庫連接（或數據庫管理器 attachment）中進行。
設置 DB2 注冊變量 DB2_OPTPROFILE 為 YES。
如果這個變量在你啟動實例之前設置了，那麼你可以在不需要重啟數據庫實例的情況下，繞過 DB2 優化器問題。許多優化器問題可以通過更改像 DB2_REDUCED_OPTIMIZATION 這樣的注冊變量或通過應用一個新的 DB2 補丁來解決，然而，這兩種方法都需要一個短暫的停機。
提高存儲管理中的可用性
使用自動存儲或對 DMS 表空間啟用自動 auto-resize 能力。
這兩種技術通過自動擴展現有容器或自動添加新容器，根據需要自動添加存儲到表空間。允許數據庫管理器自動處理整個文件系統情況。在這兩種情況中，完全讀寫能力受到保護，並且最小化了 I/O 帶寬開銷。
使用自動存儲並且每個表空間一個表。
當一個 DMS 表空間中有多個表存在時，回收一個單獨被刪除表的空間可能不方便。如果每個表空間只有表的情況就可以通過刪除表空間來回收空間。在自動存儲出現之前，這個建議可能會帶來過多的管理開銷，因為每個表空間需要關心它自己的存儲管理。對於自動存儲，這個情況就不存在了，因為自動存儲表空間是一個可以在上面創建表的邏輯上的條目。所有自動存儲表空間的存儲管理都在一個地方，在數據庫層面。
要牢記表空間大小必須是 4、8、16、32 K。這些值決定了一個表在給定表空間中，允許的行的最大長度。
在 ALTER TABLESPACE 語句中使用 REDUCE 子句。
REDUCE 子句可以被用來在表空間的高水位標記（這是，表空間中曾經使用過的最高的地址）之上釋放未使用的空間。在確定情況下，這個更改語句也可以在不需要數據庫下線的情況下，減少高水位標記。
結論
為了實現它們，你選擇的數據庫可用策略和你需要投入的資源，反映了你的事務可以容忍的相關數據庫停機。
DB2提供了若干功能和能力，讓你能減少甚至消除某些類型的停機帶來的影響，這些類型和例程維護活動相關，比如重組、裝載、備份、升級、數據庫配置和調優測試，還有就是存儲管理。減少停機持續時間或頻率，將增加你的數據庫解決方案支持你的事務需要的時間。
最後請注意在開發策略中為了避免計劃停機：無論多麼精心進行設計或處理，它們的成功執行取決於對這篇文章中提到的技術的正確理解，並依賴於嚴格的測試。你可以通過利用下面列出的資源來學習更多關於 DB2 高可用性能力。
-
