数据仓库准则和非常好的做法
在 Operations Manager 2007 中，数据几乎实时写入数据仓库中。这使得数据仓库上的负荷类似于 OperationsManager 数据库计算机上的负荷。因为是个 SQL 服务器，所以磁盘子系统对总体性能最为关键，内存和 CPU 紧随其次。Operations Manager Reporting Services 也在数据仓库服务器上放置了稍微不同的负荷。影响数据仓库上负荷的因素包括：
数据插入的速率 - 为允许更有效的报表，除了有限数量的原始数据之外，数据仓库还计算并存储聚合数据。做此额外工作表示，与将操作数据集合到 OperationsManager 数据库相比，将操作数据集合到数据仓库成本可能稍高。该附加成本通常被在数据仓库上处理发现数据减少的成本抵消（与在 OperationsManager 数据库上处理数据相反）。
并发报表用户数 - 因为报表通常汇总大量数据，所以每个报表用户可以在系统上施加很大的负荷。同时运行的报表数量和运行报表的类型影响总体容量需求。通常，查询大日期范围或大量对象的报表需要更多系统资源。
以下是调整数据仓库服务器大小的一些非常好的做法：
选择合适的磁盘子系统 - 因为数据仓库现在是整体数据流过管理组必不可少的一部分，所以为数据仓库选择合适的磁盘子系统非常重要。如同 OperationsManager 数据库一样，RAID 0+1 通常是非常好的选择。一般情况下，数据仓库的磁盘子系统应类似于 OperationsManager 数据库的磁盘子系统。
数据文件和事务日志的放置 - 如同 OperationsManager 数据库一样，代理数增加时，分开 SQL 数据和事务日志通常是合适的选择。如果 OperationsManager 数据库和数据仓库位于同一物理机上，而您想要分开数据和事务日志，必须将 OperationsManager 数据库的事务日志放置于与数据仓库分开的物理卷上。只要大小合适，OperationsManager 数据库和数据仓库的数据文件可以共享同一个物理卷。
使用 64 位硬件和操作系统 - 大量的 RAM 通常对数据仓库有利，这也是一种低成本高效率地减少在此服务器上执行的磁盘活动量的方式。使用 64 位硬件使您能够轻松增加内存到 4 GB 以上。即使当前的部署不需要大于 4 GB 的 RAM，使用 64 位硬件仍为以后如果需求变化提供了增长空间。
对数据仓库使用专用的服务器硬件 - 尽管较小型部署通常可以将 OperationsManager 数据库和数据仓库合并到同一物理机上，但是代理数增加且传入操作数据量也因此增加时，最好将它们分开。如果数据仓库与报表服务器分开，报表性能也会更好。
使用电池备份写入缓存磁盘控制器 - 测试显示，磁盘控制器上的写入缓存对数据仓库上的工作负荷有利。在磁盘控制器上配置读取缓存与写入缓存比时，建议将 100% 的缓存分配给写入缓存。使用带有任何数据库系统的写入缓存磁盘控制器时，确保它们具有适当的电池备份系统十分重要，这样可以防止在中断的情况下数据丢失。
管理服务器准则和非常好的做法
管理服务器上最大部分负荷来自于收集操作数据并将该数据插入 OperationsManager 和数据仓库数据库。值得注意的是，管理服务器直接执行这些操作而不依赖 RMS。管理服务器在内存中执行大多数据队列而不是依赖于速度较慢的磁盘，因此增强了性能。管理服务器最重要的资源是 CPU，但是测试已显示它们通常不需要高端硬件。影响管理服务器上负荷的因素包括：
操作数据收集的速率 - 因为收集操作数据是管理服务器执行的主要活动，所以此速率对服务器总体使用率具有最大影响。但是，测试已显示，管理服务器通常可以用低至中等使用率维持高速率的操作数据处理。影响操作数据收集速率的主要因素是管理组中部署了哪些管理包。
以下是调整管理服务器大小的一些非常好的做法：
不要使用超大管理服务器硬件 - 大多数情况下，使用标准的实用程序服务器就足够于管理服务器执行的工作。遵守本文档中的硬件准则对大多数工作负荷来说都应足够。
代理与管理服务器之比不要超过 3,000:1 - 服务器实际性能将基于所收集的操作数据量变化，但是测试已显示，管理服务器支持 2000 个代理（每个代理有相对大量的操作数据传入）通常没有问题。每个管理服务器管理 2000 个代理是基于测试体验的准则，而不是硬限制。您可能发现，您的环境中的管理服务器能够支持更多或更少的代理。
要最大化 UNIX 或 Linux 计算机与管理服务器之比 (500:1)，请使用专用的管理服务器进行跨平台监视。
每个管理组使用最少量的管理服务器来满足冗余需求 - 部署多个管理服务器的主要原因应是提供冗余和灾难恢复而不是可伸缩性。基于测试，大多数部署将需要三到五个以上的管理服务器来满足这些需求。
