Delen via


資料庫中的信箱在 System Center Operations Manager 環境中遭到隔離

英文原文已於 2012 年 6 月 28 日星期四發佈

07/03/2012 更新 :增加<因應措施>一節中,提供更多的詳細資料。

我們最近遇到一個 CSS 相關的問題,希望你也能知道,那就是在 CSS 中,當許多信箱同在一個信箱資料庫上,信箱會毫無緣由地遭到隔離。當你查看應用程式記錄檔時,會發現有許多 10018 事件都包含了下列資訊。

Log Name: Application
Source: MSExchangeIS
Event ID: 10018
Task Category: General
Level: Error
Description:
The mailbox for user <guid>: /o=Contoso /ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserMailbox has been quarantined. Access to this mailbox will be restricted to administrative logons for the next 6 hours.

此外在 Microsoft Exchange 疑難排解員/操作事件記錄檔中還會出現事件識別碼 5410,指出遭到資料庫空間疑難排解員隔離的每一個信箱:

Log Name: Microsoft-Exchange-Troubleshooters/Operational
Source: Database Space
Event ID: 5410
Level: Warning
Keywords: Classic
Description:
The database space troubleshooter quarantined mailbox <guid> in database <DBName>.

其實關鍵在於最後一句中的「資料庫空間疑難排解員」。在預設的情況下,部署 System Center Operations Manager 的環境都會設有一個監視器來檢查資料庫及記錄磁碟區的可用磁碟空間。此監視器預設會使用 Exchange 2010 所附的 PowerShell 指令碼 Troubleshoot-DatabaseSpace.ps1。如需查看 Troubleshoot-DatabaseSpace.ps1 指令碼,可參考下列 TechNet 文章:

使用命令介面的 Troubleshoot-DatabaseSpace.ps1 指令碼管理資料庫記錄檔成長
https://technet.microsoft.com/zh-tw/library/ff477617.aspx

System Center 小組最近剛發行了 Exchange Management Pack Service Pack 2,其中最主要的就是調整了執行指令碼的逾時值。在此 Service Pack 之前的逾時值為 300 秒,而監視器是設定為每 5 分鐘執行一次檢查。這意味著在許多大型組織中,指令碼一定會逾時,變成一個無法完成的任務。不過安裝此升級之後,新的逾時數值就會調高到 1200 秒,同時監視器也改成每小時執行一次,而不是每 5 分鐘執行。這個改變讓疑難排解員可以確實地執行程式碼,達成 SP2 之前所無法達成的目標。這讓疑難排解員得以從自己所使用的資訊儲存 PerfMon 計數器中尋找錯誤,藉此判斷資料庫的記錄位元組產生率 (PerfMon 每小時的比率可能會超過 1.0E+19 個位元組)。若估算所得每小時產生記錄的比率超過資料庫或記錄磁碟區上剩餘可用磁碟空間的容量,疑難排解員就會開始隔離信箱,以停止產生記錄,以免因為所有所有可用空間用盡而造成資料庫生卸載。不過,當 PerfMon 計數器中含有 Bogus 值 (perfmon 計數器會每分鐘更新一次,而 bogus 值又不應大於 1 分鐘) 時,疑難排解員似乎就會達到前述的隔離條件… 雖說這種情形並不會經常發生,但也無法完全排除這種可能性。

這對您而言意味著什麼?

一如 TechNet 文章所述,指令碼的主要功能在追蹤記錄的產生率,以及檢查資料庫及記錄磁碟區的可用磁碟空間。執行指令碼時,指令碼會使用儲存 PerfMon 計數器來判斷記錄產生率,同時計算目前的產生率是否會某個時數門檻 (預設為 12 小時) 之內用盡磁碟的空間。如果結果是肯定的,就會選擇性地開始隔離信箱 (一次最多隔離 150 個)。當可用磁碟空間下降到指定的值時,指令碼也會開始選擇性地隔離信箱。預設的可用磁碟空間百分比值為 25%。為能在達到上述任一項條件時隔離信箱,必須將 –Quarantine 參數傳送給指令碼。

SCOM 2007 及更新版本所使用的監視器預設會使用 Quarantine 參數,而且因為管理組件採密閉架構,所以沒有任何選項可用來變更此設定。換言之,當資料庫或記錄磁碟區的可用磁碟空間下降到 25% 以下,加上估算所得的記錄產生率可能會在未來的 12 小時內用盡剩餘的可用磁碟空間,就會開始隔離用量最高的使用者。如果資料庫上有很多信箱,就表示短時間內可能會有許多信箱會遭到隔離。

該怎麼辦?

很顯然地,讓許多信箱遭到隔離絕對不會是它的初衷,即使這種做法比起因為缺少磁碟空間而卸載整個資料庫,造成所有使用者的資料庫運行中斷,但仍會造成一些使用者的資料庫運行中斷。話說遭到隔離的信箱雖然可以藉由手動從登錄中移除信箱 GUID 的方式加以釋放,但這並非最好的做法,因為當監視器再次執行時,相同的信箱仍有可能面臨再度被隔離的命運。

你可以從下列位置找到遭到隔離的信箱:

Hkey_Local_Machine\SYSTEM\CurrentControlSet\Services\MSexchangeIS\Servername\Private-<D Bguid>\Quarantined Mailboxes\ {Mailbox GUID}

我們只想讓你知道我們已經察覺到這個問題,並且正在著手進行修正。 在找到一個能夠長治久安的解決方法之前,我們建議你先實作下列因應措施,避免信箱遭到隔離。同時為了避免更多客戶碰到這個問題,我們也從下載中心暫時移除了 Exchange 2010 SP2 管理組件。

因應措施

建立覆寫來停用檢查可用磁碟空間的監視器,如此一來就不會再執行 Troubleshoot-DatabaseSpace.ps1 檔案。

建立覆寫最好的方法是將覆寫放進特別針對 System Center Operations Manager 的自訂而建立的新管理組件中,這麼一來就可以又快又容易地管理覆寫或其他自訂設定。如果你還沒有這類型的管理組件,可參考下列步驟建立一個:

  1. 按一下操作主控台中的 [管理] 按鈕。在 [管理] 窗格上,以滑鼠右鍵按一下 [管理組件],然後按一下 [建立管理組件]。[建立管理組件精靈] 會隨即顯示。
  2. 在 [一般內容] (General Properties) 頁面的 [名稱] (Name) 中,輸入管理組件的名稱;在 [版本] (Version) 中輸入正確的版本號碼;以及在 [描述] (Description) 中輸入簡短的描述。按 [下一步] (Next),然後按一下 [建立]。

圖像

當您指定好要覆寫的管理組件之後,就可以為下列 4 個監視器建立覆寫:

圖像

在 System Center Operations Manager 中,前往 [撰寫中] 模組,然後選擇 [管理組件物件] 下的 [監視器]。你可以設定 [覆寫] (Override) 停用監視器,也可以選擇停用 [所有層級為資料庫複製 DB 邏輯磁碟空間的物件] (For all objects of class: Database Copy DB Logical Disk Space) 的監視器 (如下圖所示):

圖像

核取 [已啟用] (Enabled) 旁的方塊,然後選取 [False] 修改覆寫值。

圖像

在相同的 [覆寫內容] (Override Properties) 對話方塊上,選取根據指定自訂的管理組件。

圖像

截至目前為止,停用監視器這個選項,是唯一可以暫時解決信箱遭到隔離的方法。我們知道這麼做可能會讓管理員廡法在磁碟空間不足時收到警告,但在修正發行之前,這是避免信箱遭到隔離的最好作法。

注意:如果同時設有異動記錄磁碟機與資料庫,仍然會在資料庫磁碟空間不足時收到警告,這是因為 Perfmon 乃是依據不同的規則產生訊息。

Ben Winzenz、Kevin Carker

這是翻譯後的部落格文章。英文原文請參閱 Mailboxes on a database are Quarantined in an environment with System Center Operations Manager