IBM i上的MCH2804消息的原因和解决办法

IBM i 上的某核心应用突然挂起，不能为前端应用提供数据服务了，经检查发现日志多次报 MCH2804 消息。

MCH2804 的字面含义是“试图超过目标对象 &1 的存储限制。”这里的“目标对象 &1 ”代表某个 user profile

，也就是说，试图超过某个 user profile 的存储限制。

这个 user profile 定义中的 MAXSTG 参数已经是 *nomax 了，怎么会超过这个 user profile 的存储限制呢？

原来 MCH2804 消息与 user profile 的极限值有关系，虽然 user profile 中的 MAXSTG 被设置为 *NOMAX ，但日志中还会报 MCH2804 ， MAXSTG 定义了这个 user profile 所拥有的 object 能占用的存储空间的大小，而操作系统中的 user profile 最大支持的 entry 数目是有限制的，不能超过系统规定的极限值，这是系统报 MCH2804 的真正原因。下表列出了不同 IBM i 版本中 user profile 所能支持 entry 数量的极限值。

客户一定会关心哪些 Object 会被记录到 user profile 的 entry 条目。

1. User profile 所拥有的每个 MI 对象需要一个逻辑条目。
2. User profile 所拥有私有权限的每个 MI 对象也需要一个逻辑条目。
3. 对于 MI Object 拥有私有权限的每个 user profile 在这个 Object 所有者的 user profile 中都会占用一个逻辑条目。对于拥有完整 user profile 的客户来讲，这是导致 entry 数量迅速增长主要原因。
4. 被删除的逻辑条目仍然会消耗一些空间来跟踪它，这个空间被称为 Free Entry （自由条目）， user profile 中的自由条目不能被填充。

数据库文件由多个 MI object 组成，这些 MI object 被保存到 user profile 的条目中，例如，一个 FILE object 至少有三个对象被保存到 user profile 的条目；一个用于文件目标，两个用于文件的每个 Member （成员）。如果在文件上建立一个索引，那么文件中的每个成员还都会有增加一个额外的条目。一个有 100 个成员的文件将至少有 201 个目标占用条目，如果在文件上建立了索引，还会有 100 个条目。还有一些额外的内部目标也可能与该文件相关联，如果这个文件有私有权限，那么每个 MI 对象都有一个私有权限（不仅仅是外部 FILE 对象）。给数据库文件授予私有权限可能会导致拥有者 User Profile 中的条目迅速增长，这也是导致 User Profile 爆表的主要原因。

可以通过 WOKOBJPVT 命令查看某个 User Profile 对 object 的私有权限。

每个 User Profile 都有两个存放上述信息的库 (repository) 。一个库是 machine index ，用于快速访问定位条目，另一个是用于永久存放条目的表（ table ），该表主要用于重建索引，这是因为 machine index 在系统崩溃后可能会被损坏。 Machine index 和 space 目标会随着 authority 、 primary group authority 和所有权权限被添加到 user profile 中而分配存储空间，这些空间对象的存储会根据需要进行扩展。

一个 user profile 的物理大小限制约为 48MB ，表为 16MB ，索引可以根据需要增长，以容纳 1 , 048,574 个条目。当表被占满时，索引通常在 32MB 左右。

如果 user profile 的空间被占满了之后，我们可以通过以下两种方法来解决：

1. 将 user profile 拥有的对象的所有权转移给其他 user profile 。这将为每个 MI 对象删除一个条目，并且对 MI 对象有私有权限的 user profile 也将删除一个条目，这个方法的效果显著。

例如可以用 DSPUSRPRF USRPRF(XIAOQING) TYPE(*OBJOWN) 命令显示某用户所拥有的 object 的名称和数量。

用 CHGOBJOWN 命令将 object 的所有权限转移到另一个用户 , 例如 :

2. 撤销 user profile 对目标对象的一些私有授权。虽然私有授权的存在是出于安全和功能上的考虑，但它们也是有代价的，它们占用了空间，对性能有损害，而且会导致更长的保存时间，建议应根据实际安全需求，谨慎处理用户的私有权限，可以考虑用授权列表和 group profile 来减少 entry 数量。
   
   上述两种方法都能减少 user profile 中的 active entry 的数量。但是，由于以下原因， user profile 的物理尺寸可能不会改变，这是正常的。
3. 在 user profile 的表中，被删除的条目作为 free entry 存在。
4. 在索引中，已经被创建的其他 entry 来定位表内的 free entry 。
5. 在索引中，那些已被删除的条目，然而除非 machine index 的同一逻辑页中的所有条目都被删除，否则整个页面仍显示为已使用（依旧存在）。它的 free space 只能被重新用于类似的条目上，也就是说，数据内容与被删除的条目内容足够相似的那些 entry ，使通往该条目的路径会把它带到相同的逻辑页面，这种情况下， free space 才能被重用。

当权限和所有权从 user profile 中被删除时，这些 entry 同时被删除，并生成自由空间， free entry 可被立即重用，该空间被适合的相同逻辑空间中的相似条目所使用。

索引和表中被释放的 entry 将随着时间的推移被删除；另外当达到大小极限时，表和索引被压缩；在系统 IPL 和 reclaim storage 时，也会被压缩。

User profile 的索引空间和表空间不会被自动重建，只在损坏或不同步时才会被重建，正常的 IPL 或异常的 IPL 不会自动重建 user profile 。

最后，有人可能会问， IBM i 对 User profile 的这个极限值有没有预警信息可以参考？回答时肯定的，目前系统提供两种方法。

方法 1 ：通过 PRTPRFINT 命令列出每个 user profile 的 entry 使用情况，单位时百分比。

方法 2 ：通过 AUINTERNALS 宏来分析每个 user profile 在 SYSASP 和其他 iASP 中的的 entry 使用情况，这种方法提供的信息更为详细。

使用这个方法之前，需要安装补丁。

v7r2m0: MF68098 (pre-reqs MF68059)

v7r3m0: MF68099 (pre-reqs MF68060)

v7r4m0: MF68101

在 vlog 中会提供报警信息 0B00 3009 。

当 user profile 的空间使用了 90% 的时候，系统就会自动报 VLOG 0B00 3009 ，提示 user profile 的名称、 iASP 和当前 entry 的使用数量。

这里的“ 02F00000 ”是十六进制数，代表 entry 的数量（ 49283072 ），“ E3C5E2E3D7D9C6F1 ”是 TESTPRF1 user profile ， ASP NUMBER 是“ 23 ”， 35 ASP 。

同时，可以进入 SST 查看更详细的信息，如 entry 的准确数目、使用的百分比、拥有的目标对象数量、授权对象数量

、授权用户数量等信息。

具体方法如下：

• 1. Start a service tool
• 4. Display/Alter/Dump
• 1. Display/Alter storage
• 2. Licensed Internal Code (LIC) data
• 14. Advanced analysis
• Select AUINTERNALSby putting 1 beside it and hit enter
• In the options field, fill in: ENTRYCOUNTS ALL FILTER 90

这里的 90 代表 90% ，即列出 entry 数超过 90% 的 user profile 等信息。


总之，每个系统都会有自己的极限值， IBM i 也不例外，没有必要大惊小怪，事实证明采用上述两种解决方法和对 user profile 的 entry 值的两种预警检测方法，可以有效地预防和避免这个问题的发生。

参考文档：

“ User Profile Size Limit/Limit of Pointers to Objects Owned by a User Profile ”

来自 < https://www.ibm.com/support/pages/user-profile-size-limitlimit-pointers-objects-owned-user-profile#:~:text=The%20maximum%20size%20for%20a,10%20million%20to%2050%20million. >

谢谢阅读，仅供参考。