限制資料庫損毀

Solaris Resource Manager 非常努力維護限制資料庫，損毀不太可能發生。然而如果的確有損毀發生的話，會對管理員帶來嚴重的問題，因為這個資料庫是 Solaris Resource Manager 操作的基礎。因此應該仔細調查任何潛在的損毀，並且在偵測到之後立即加以處理。

徵兆

沒有任何一種徵兆可以確切地判定限制資料庫已經遭受損毀，不過可以藉由確認幾種跡象來決定損毀的限制資料庫﹕

• 若是 Solaris Resource Manager kernel 偵測到一個群組迴圈，很可能表示限制資料庫已經被損毀。Solaris Resource Manager 會非常小心地防範群組迴圈的發生，唯一可能會發生的原因是一個 sgroup 屬性由於某種原因被損毀。請參閱群組迴圈中更詳細的說明資訊。

• 當使用者嘗試登入時，如果看到一個 'No limits information available'的訊息，其登入的操作被回絕。這是因為限制資料庫損毀，因而導致其 flag.real 屬性被清除，連帶地刪除其 lnode。它不只會影響被刪除的 lnode，也會影響所有被孤立的 lnode（請參閱孤立的 lnode一節中的詳細說明）。請注意，如果沒有為帳號建立任何 lnode，或是它已經不小心被刪除的話，'No limits information available' 訊息也會出現，因此不能單憑這個訊息就斷定限制資料庫已經損毀。

• 使用量或限制屬性突然出現不合理的數值。某些使用者可能會因此而忽然達到使用量的限制。

• 使用者突然抱怨喪失使用權限或是獲得未預期的權限，因為權限旗標損毀。

如果管理員懷疑限制資料庫中出現任何損毀，最佳的偵測方法就是使用 limreport 來要求一份 lnode 清單，其屬性值應該在某個範圍之內。如果數值在報告的範圍以外，就會發生損毀。limreport 也可用來列出具有明確 flag.real的 lnodes。這就表示其密碼對映中的帳號沒有 lnode。

修正

如果偵測到損毀情況，管理員應該回復限制資料庫尚未損毀的版本及相符的設置。如果限制資料庫損毀的範圍並不大，管理員也許能夠保存其他所有 lnode 的內容，然後使用 limreport 和 limadm 指令，重新將它們載入一個新的限制資料庫中。如果找不到最近的限制資料庫副本的話，這可能是一個較理想的方法，新的限制資料庫現在會包含最近的使用量及累計屬性。 第 5章, 管理 lnode一節中包含儲存與回復限制資料庫程序的相關資訊。如果只是遺失 lnode 這種簡單的問題的話，只要使用 limadm 指令來重新建立它們便可。