目前，Optim Performance Manager 为整个数据共享组或具体成员提供了 DB2 pureScale 监视。集群缓存工具的专门监视还不可用。因此，在收集的数据量和 Optim Performance Manager 处理和">存储数据所需的工作量方面，DB2 pureScale 监视可被视为类似于监视一个分区数据库环境。但是，有一些主要的区别。
通常，DB2 pureScale 系统运行大量 OLTP 工作负载。最佳实践建议首先选择“OLTP production with Low overhead”系统模板，然后再增加全局抽样率。当启用 Extended Insight 数据的收集时，需要特别注意 DB2 pureScale 系统处理的事务和 SQL 语句量。如果事务和语句量非常大，Optim Performance Manager 可能无法应对生成的监视数据量，进而关闭对这些组件的监视以预防因监视数据而引起系统无法响应。在这些情况下，适用“配置 Extended Insight 监视的最佳实践”一节中记录的相同最佳实践。
对于分区数据库环境，需要特别注意受监视对象的数量。具体来讲，这适用于启用了 I/O and Disk Space 配置文件和 Dynamic SQL 配置文件时。如果受监视数据库具有大量成员并包含大量这种对象，可以为这些配置文件配置更高的抽样间隔，并减少在 I/O and Disk Space 配置文件中收集的数据。
以下限制目前适用于监视 DB2 pureScale 系统时：
• DB2 pureScale 系统的分区集不适用（会收集所有成员的数据）。
• DB2 PureScale Feature 目前不支持 DB2 Workload Manager。因此，不要在 Optim Performance Manager 内使用“Workload Manager Configuration”，并始终确保禁用了 Workload Manager 监视配置文件。
运行 Optim Performance Manager
本章介绍一些管理 Optim Performance Manager 和确保它以最优的性能运行的技巧和提示。
请参阅红皮书中的“附录 A. 管理存储库服务器和存储库数据库”。该附录中的重要章节包括：
• A.2 存储库服务器的工作原理
• A.4 从存储库数据库删除数据
• A.5 存储库数据库中的自动 runstats 和重组
• A.7 更改存储库数据库的数据库配置
• A.8 为存储库数据库启用行压缩
7.1 验证 Optim Performance Manager 设置
完成初始配置并让 Optim Performance Manager 监视数据库一段时间后，我们建议检查 db2pesrv.log，以查看 Optim Performance Manager 是否在以最优的性能运行。 除了列出为每个受监视数据库启动了哪些监视线程，db2pesrv.log 文件还指出了内存不足错误等错误条件，或指出是否存在使数据收集所花时间长于预期的收集间隔瓶颈。 要了解有关收集间隔瓶颈和如何处理它们的更多信息，请参阅红皮书的“A.12 确定收集间隔瓶颈”。
要了解有关内存瓶颈的更多信息，请参阅红皮书的“A.11 更改存储库服务器的 Java 堆大小参数”。
如果系统内存或运行了 Optim Performance Manager 的 DB2 实例的 DB2 受保护用户或实例所有者的 ulimit 参数太小，也可能发生内存瓶颈。如果发生此情况，您将在 db2pesrv.log 中看到以下类似消息：
• 15:38:34.284][1] the snapshot category [locking] is disabled due to memory problems. Optim Performance Manager will try to enable the category again in a few minutes. [15:38:34.284][1]If the problem persists, increase the physical memory for Optim Performance Manager or disable the snapshot category [locking] permanently.
• [13:04:51.204][1]Terminating: Error while taking history snapshot. PMGETLIST failed, rc=-101: Allocation of 134104960 bytes in file: tablemem.c at line: 286 failed.
要解决此问题，执行以下任务：
• 增加 Optim Performance Manager 的物理内存。
• 在 Linux 和 UNIX 上，执行以下操作：
1. 将运行 Optim Performance Manager 的 DB2 实例的受保护用户的 ulimit 参数设置为更高的值或无限制。如果未指定受保护的用户，可以检查运行 Optim Performance Manager 的 DB2 实例的 ulimit 参数，增大 ulimit 参数的值或将它设置为无限制。
2. 重新启动运行 Optim Performance Manager 的 DB2 实例，使更改生效。
• 如果这些步骤失败，以及如果问题是由快照类别锁定导致的，可以永久禁用 Locking 监视配置文件中的锁等待信息收集。
监视是一种平衡操作！
监视是一种平衡操作。您需要平衡监视信息的需要与收集和处理此信息对受监视系统带来的影响。在一天结束后，可通过监视来满足组织内的特定用途，所以一定要充分理解组织的监视需求并相应地规划 Optim Performance Manager 的实现。
监视最佳实践建议，您应该首先收集满足业务即时监视需求的信息水平。如果出现需要更多信息的额外业务需求，那么可在此时启用对所需信息的收集。
重要事项：不要从一开始就收集所有监视信息，除非业务确实需要这么做。收集所有监视信息将需要更多资源来收集和处理数据，而且您的业务很可能仅需要该数据的一个子集。而且您很可能不会再次查看配置，禁止收集那些您环境中没有用的指标。
每一种情况都是独一无二的，因为业务部署的应用程序、数据库服务器和环境者是独一无二的。甚至两个业务部门部署的同一个应用程序也可能在其用途上有巨大的区别，因此监视需求也同样具有巨大的区别。
Optim Performance Manager 通过对收集的监视信息类型和时间进行严密控制来支持这些最佳实践，进而允许每个业务部门收集适当级别的监视信息。