限制数据库损坏

Solaris Resource Manager 对限制数据库的维护是十分健壮的，损坏是不太可能发生的。但是如果损坏真的发生了，则管理员应当给予极大关注，因为该数据库是 Solaris Resource Manager 操作的根基。任何潜在的损坏均应予以调查，如果确实监测到，就予以更正。。

症状

如果限制数据库发生损坏，则管理员应当给予极大关注。借助单独一个症状无法可靠地确定限制数据库业已遭到损坏，但是有若干的标志可能会反映出限制数据库发生损坏，应当予以鉴别。

• Solaris Resource Manager 核心监测到一个组循环，这是对限制数据库遭到损坏的一个正面指示。 Solaris Resource Manager 严格避免组循环，而发生组循环的唯一途径是由于某种原因，sgroup 属性遭到损坏。请参考 "组循环"，了解更多细节。

• 用户在试图登录时，看到"无限制信息可用"消息显示出来，且登录遭到拒绝。发生此情形，有可能是由于限制数据库遭到损坏，而使得用户的 flag.real 属性被清空，从而有效地删除了用户的 lnode。这不但会影响到所删除的 lnode，还会影响到任何孤立的 lnode（有关细节请参考"孤立 lnode" 一节）。注意，如果没有为帐户创建 lnode，或者所创建的 lnode 遭到故意删除，则也会出现"无限制信息可用"消息，所以，这并非明确指示限制数据库业已遭到损坏。

• 利用率或者限制属性突然出现不现实的值。这有可能使得某些用户突然命中限制。

• 用户突然抱怨失去特权或者意外获得特权，这是由特权标志损坏引起的。

如果管理员怀疑限制数据库发生了损坏，则最有可能用来监测的方法就是使用 limreport(1SRM)，请求获得属性超出某个已知正常范围的 lnode的列表。该命令也可以用于列出 flag.real 被清空的 lnode。这会指示出口令映射中的并不存在 lnode 的帐户。

处理

如果监测到了损坏，则管理员应当返回到一个未遭损坏的限制数据库版本。如果损坏只是限于限制数据库一小部分，则管理员有可能将所有其它lnode 的内容保存起来，并借助 limreport(1SRM) 和 limadm(1MSRM)命令将其重新装入一个新的限制数据库。如果没有最近的限制数据库副本可用的话，则建议进行此类操作，否则新的限制数据库就会包含最近的利用率和应计属性。保存和恢复限制数据库的过程，在管理 lnode 一节中有描述。对于 lnode 丢失的简单情形，只要借助 limadm命令加以创建就足够了。