Solaris Resource Manager のリミットデータベースの保守は信頼性があるため、損傷することはほとんど考えられません。ただし、このデータベースは Solaris Resource Manager の操作にとって基本的なものであるため、損傷が実際に起きた場合には、大きな問題です。損傷の可能性がある場合は調査し、損傷が見つかったら修正する必要があります。
リミットデータベースが壊れていることを的確に判定できる唯一の症状はないので、いくつかの症状から判断する必要があります。
Solaris Resource Manager のカーネルによるグループループの検出は、リミットデータベースが壊れていることを示す有力な症状です。Solaris Resource Manager にはグループループが起こらないような予防措置がとられているので、ループが起こるのは sgroup 属性が何らかの理由で壊れている場合に限られます。詳細は、「グループループ」を参照してください。
ユーザーがログインしようとすると、「No limit information available」というメッセージが表示され、ログインできない。リミットデータベースが壊れているために flag.real 属性が消去され、その l ノードが事実上削除されている場合に、この問題が生じることがあります。これは、削除された l ノードに影響するだけでなく、親のない状態になった l ノードにも影響します (詳細は、「親のない l ノード」を参照)。「No limit information available」というメッセージは、そのアカウントの l ノードが作成されていなかったり、意図的に削除されていた場合に表示されます。したがって、これはリミットデータベースの損傷をはっきり示すものではありません。
usage 属性や limits 属性の値が実際には起こりえない数値となる。ユーザーによっては、急激に属性値が制限値にまで達することがあります。
ユーザーが急に特権を喪失したり、今まで持っていなかった特権を持つようになったりする。この原因は特権フラグの損傷によるものです。
リミットデータベースの損傷を検出する最もよい方法は、limreport を使って l ノードを一覧表示することです。ある範囲内にあるはずの属性の値がその範囲外にあることがあります。範囲外の値があると、損傷があったことが分かります。flag.real が消去されている l ノードも表示できます。この l ノードが表示される場合には、l ノードが存在しないアカウントがパスワードマップにあることを示します。
損傷を検出したら、管理者は、リミットデータベースを損傷していない状態に戻す必要があります。リミットデータベースの一部分だけが壊れている場合には、他のすべての l ノードの内容を保存し、limreport と limadm を使って新しいリミットデータベースに再読み込みできることがあります。このリミットデータベースには、最新の usage 属性と accrue 属性が含まれているので、リミットデータベースの最新のコピーがない場合は、この方法が必要です。リミットデータベースの保存と復元のための手順は、第 5 章「l ノードの管理」を参照してください。l ノードがなくなっているだけのような場合は、limadm コマンドを使うだけで作成し直すことができます。