限制数据库损坏

Solaris Resource Manager 对限制数据库的维护是可靠的，一般不会发生崩溃。但如果真的发生崩溃，则这就是管理员的主要当务之急，因为该数据库对于 Solaris Resource Manager 的运行非常重要。应该对任何潜在的崩溃进行调查，一旦检测出来就应该加以修复。

症状

只根据一项症状是不可能可靠地确定限制数据库是否已经崩溃的，但是有若干种因素可以潜在地表明限制数据库的崩溃：

• Solaris Resource Manager 内核对组循环进行的检测可以很好地表明限制数据库已经崩溃。组循环受到 Solaris Resource Manager 的严格预防，只有当 sgroup 属性以某种方式发生崩溃时，它们才可能发生。有关详情，请参阅组循环。

• 用户在尝试登录时会看到屏幕上显示'没有限制信息可供使用'信息，用户登录被拒绝。如果限制数据库使其 flag.real 属性被清除，并有效地删除了其 lnode，则这样的情况就会发生。它不仅会影响被删除的 lnode，而且还能影响任何被孤立的 lnode（有关详情，请参阅 孤立 lnode）。请注意，只有当没有为帐户创建 lnode，或当 lnode 被故意删除后，才会显示'没有限制信息可供使用'信息，所以它并不能清楚地表明限制数据库已经崩溃。

• 利用率或限制属性中突然出现不真实的数值。这会导致某些用户突然出现限制。

• 用户突然抱怨因为特权标志的崩溃而失去了特权或未预期的特权。

如果管理员怀疑限制数据库发生了崩溃，检测崩溃的最好方法就是使用 limreport 请求其属性应具有在已知范围内的数值的 lnode 列表。如果报告了该范围之外的值，则损坏已发生。limreport 还可用来列示拥有清空的 flag.real 的 lnode。这将显示不存在 lnode 的口令映射中的帐户。

更正

当检测出崩溃后，管理员应采用限制数据库的未崩溃版本。如果崩溃仅限于限制数据库的一小部分，则管理员就能保存所有其它 lnode 的内容，并采用 limreport 和 limadm 命令把它们重新装载到刷新的限制数据库中。如果没有限制数据库的最新副本，则这样做就是最好的方法，因为新的限制数据库现在包含最新的利用率和应计属性。保存和恢复限制数据库的步骤如 第 5 章，管理 lnode所示。对于丢失了 lnode 等简单情况，只需使用 limadm 命令重新创建 lnode 就足够了。