中文（简体）白皮书

面向 OLTP 应用程序的重要 SQL Server 2005 性能问题

Lindsey.allen — Sat, 18 Oct 2008 03:19:13 GMT

OLTP 工作负荷的特征是存在大量相似的小型事务。

在检查数据库设计、资源利用和系统性能的重要性时，请务必牢记这些特征。下面简述面向 OLTP
应用程序的重要性能瓶颈或缺陷。

数据库设计问题

常用查询存在过多的表联接。在 OLTP 应用程序中过多使用联接将导致查询运行缓慢，
浪费系统资源。通常，应该重新设计数据库，避免需要 5 个或 5 个以上表联接的频繁操作。
频繁更新（包括插入、更新和删除）的表中存在过多的索引导致额外的索引维护开销。通常，OLTP 数据库的设计中应该将索引数保持为正常运转前提下的最小值，这同样是由于大量相似事务与索引维护成本共同作用的结果。
由于缺失索引，导致大量 IO，如表和范围的扫描。根据定义，OLTP 事务不应要求大量 IO，并且应该接受检查。
未使用的索引在插入、更新和删除中导致索引维护成本，而对任何用户都没有用。
应该清除未使用的索引。任何使用过的索引（通过选择、更新或删除操作）都出现在 sys.dm_db_index_usage_stats 中。因此，任何已定义但不包括在此 DMV 中的
索引自上次重新启动 SQL Server 以来尚未使用过。

CPU 瓶颈

信号等待时间超过总等待时间的 25%。请参阅 sys.dm_os_wait_stats 中的信号等待时间和总等待时间。信号等待时间用于度量可运行队列等待 CPU 时所花费的时间。信号等待时间值很高说明出现 CPU 瓶颈。
计划重用小于 90%。查询计划用于执行某个查询。OLTP 工作负荷建议使用计划重用，因为重新创建相同的计划（用于相似或相同的事务）是对 CPU 资源的浪费。比较 SQL Server SQL Statistics：batch requests/sec 与 SQL compilations/sec。按照如下公式计算计划重用：计划重用 =（批处理请求数 — SQL 编译数）/批处理请求数。计划重用规则的特例：SQL 2005 SP2 中不缓存（而不是重用）零成本计划。使用零成本计划的应用程序具有较低的计划重用，但这不是性能问题。
并行等待类型 cxpacket 超过总等待时间的 10%。并行牺牲 CPU 资源换取执行速度。如果有大量 OLTP，并行查询通常会降低 OLTP 吞吐量，所以应尽量避免。有关等待统计信息，
请参阅 sys.dm_os_wait_stats。

内存瓶颈

Average Page Life Expectancy 持续较低。请参阅 Perfmon 对象 SQL Server Buffer Manager 中的 Average Page Life Expectancy 计数器（表示一页在缓存中停留的平均
秒数）。对于 OLTP，Average Page Life Expectancy 为 300 表示 5 分钟。只要时间
缩短就表示可能出现内存压力、缺失索引或缓存刷新的情况。
Page Life Expectancy 突然大幅下降。OLTP 应用程序（如小型事务）应该有稳定（或缓慢增长）的 Page Life Expectancy。请参阅 Perfmon 对象 SQL Server Buffer Manager。
挂起的内存授予。请参阅 Perfmon 对象 SQL Server Memory Manager 中的 Memory Grants Pending 计数器。小型 OLTP 事务应该不需要大的内存授予。
SQL Cache hit ratio 突然下降或持续较低。OLTP 应用程序（如小型事务）应具有较高的 Cache hit ratio。由于 OLTP 事务较小，不应出现以下情况：(1) SQL 缓存命中率大幅下降或 (2) 缓存命中率持续低于 90%。缓存命中率下降或较低可能表示出现内存压力或缺失索引的情况。

IO 瓶颈

较高的每次读取磁盘平均秒数。IO 子系统在队列中排队时，每次读取磁盘的时间会增加。
请参阅 Perfmon Logical disk 或 Physical disk（disk seconds/read 计数器)。通常，
在没有 IO 压力的情况下，完成一次读取需要 4 — 8 毫秒。当 IO 子系统由于高 IO 请求而
面临压力时，完成一次读取的平均时间会增加，这是在磁盘队列中排队的结果。对于许多应用程序，disk seconds/read 出现周期性的较高值是可接受的。对于高性能的 OLTP 应用程序，复杂的 SAN 子系统在处理 IO 活动峰值方面可以提供更强的 IO 伸缩性和复原性。持续的高 disk seconds/read（大于 15 毫秒）值明确指示出现磁盘瓶颈。
较高的每次写入磁盘平均秒数。请参阅 Perfmon Logical disk 或 Physical disk。高容量的 OLTP 应用程序的吞度量取决于快速顺序的事务日志写入。高性能 SAN 环境中的事务日志写入可能只需要 1 毫秒（或更短）。对于许多应用程序，考虑到复杂 SAN 子系统的不菲成本，每次写入磁盘平均秒数出现周期性的峰值是可接受的。但是，持续的高 Average disk seconds/write 值是磁盘瓶颈的可靠指示器。
由于缺失索引，导致大量 IO，如表和范围的扫描。

sys.dm_os_wait_stats 中居前等待统计信息与 IO 相关，如 ASYNCH_IO_COMPLETION、IO_COMPLETION、LOGMGR、WRITELOG 或 PAGEIOLATCH_x

阻塞瓶颈

索引争用。在 sys.dm_db_index_operational_stats 中查找锁等待和闩锁等待。
比较锁请求和闩锁请求。
较长的平均行锁等待时间或闩锁等待时间。平均行锁等待时间或闩锁等待时间的计算方法是：
锁等待时间和闩锁等待时间（毫秒）除以锁等待数和闩锁等待数。从 sys.dm_db_index_ operational_stats 计算出的平均锁等待毫秒数表示每次阻塞的平均时间。
阻塞进程报表列出长时间的阻塞。请参阅 Errors and Warnings 事件下的 sp_configure“blocked process threshold”和事件探查器“Blocked process Report”。
居前等待统计是 LCK_x。请参阅 sys.dm_os_wait_stats。
大量死锁。请参阅 Locks 事件下的事件探查器“Graphical Deadlock”，以找出死锁涉及的语句。

网络瓶颈

导致多次往返数据库的应用程序会使网络滞后时间加倍。
网络带宽全部占用。请参阅性能监视器的网络接口对象中的 packets/sec 计数器和当前带宽计数器。TCP/IP 帧的实际带宽计算方法为：packets/sec * 1500 * 8 /1000000 Mbps。

针对 SAP 数据库维护 SQL Server 的十大最佳实践

Lindsey.allen — Sat, 18 Oct 2008 03:06:37 GMT

作者：Takayuki Hoshino
撰稿人：Juergen Thomas
技术审阅人：Sanjay Mishra

SQL Server 为 SAP 应用程序提供了卓越的数据库平台。下列建议概述了针对 SAP 实现维护 SQL Server 数据库的最佳做法。

每天执行完整数据库备份

从技术角度来说，联机备份 SAP 数据库不成问题。这意味着，最终用户或夜间批处理作业可以继续使用 SAP 应用程序而不会出问题。SQL Server 备份占用的 CPU 资源很少。但是，SQL Server 备份要求较高的 I/O 带宽，因为 SQL Server 会尝试将每个使用过的区读入备份设备。SAP 所需的一切（业务数据、元数据和 ABAP 应用程序等）均包含在一个名为“<SID>”的数据库中。有时，进行完整备份所需的时间（通常为几个小时）可能会成为问题，特别是在 SQL Server 2000 中，因为在其中执行联机数据库备份时，无法进行事务日志备份。SQL Server 2005 不存在此问题。
为了使用 SAN 技术创建更快的联机备份，SQL Server 提供了可供 SAN 供应商执行快照备份或克隆 SQL Server 数据库的接口。但是，每晚备份数千吉的数据对备份基础结构来说可能负荷过重。另外一种可行的做法是每天对 SAP 数据库执行差异备份，只在周末进行完整数据库备份。

每 10 到 30 分钟执行一次事务日志备份

在生产服务器发生灾难时，要想还原到最近的状态，除了使用联机数据库备份或差异数据库备份之外，还需要使用与灾难发生时间尽可能接近的一系列事务日志备份，这一点十分重要。因此，定期执行事务日志备份至关重要。如果每两小时才创建一次事务日志备份，则在发生灾难的情况下，可能会有长达两小时内提交的事务无法还原。因此，请尽可能经常备份事务日志，这样，在发生灾难时，可以降低丢失大量已提交事务的风险。在许多客户的生产应用场景中已经证明，10-30 分钟的时间间隔是可以接受的频率。但是，在使用 SQL Server 日志传送的情况下，甚至可以每隔 2 分钟或 5 分钟就创建一次 SQL Server 事务日志备份。最短时，可达到每分钟执行一次由 SQL 代理安排的 SQL Server 事务日志备份。在减小丢失事务风险的同时，事务日志备份还可以截断 SQL Server 事务日志中的日志数据，避免事务日志写满。

配置更改时备份系统分区

每次配置更改时，应备份系统分区。使用 Windows Server 2003 自动系统恢复 (ASR) 或其他工具，如 Symantec Ghost 或 SAN Boot 还原系统分区。

配置更改时备份系统数据库

每次配置更改时，应备份系统数据库（master、msdb、model）。在 SQL Server 2005 中，无需备份资源数据库，因为它随 SQL Server 2005 安装，而且不会发生任何更改。

定期运行 DBCC CHECKDB（理想情况下，在完整数据库备份之前运行）

理想情况下，执行联机数据库备份之前，应使用 DBCC CHECKDB 进行一致性检查。但请注意，DBCC CHECKDB 是一种非常耗费时间和资源的活动，它会给 SAP 生产系统带来大量的工作负荷，特别是对 1 TB 以上的数据库。在具有优良 I/O 子系统的商用硬件上，I/O 吞吐量可以达到 100-150 GB/小时。在这样的 I/O 吞吐量下，再加上很多 SAP 数据库已达到 10 TB 或更大的事实，显然，在生产系统上执行 DBCC CHECKDB 有时候是不现实的。因此，许多人选择不运行 DBCC CHECKDB。尽管在过去十年中，硬件和软件的所有组件都变得更加可靠，但仍然可能发生物理损坏。发生物理损坏的原因之一是发生了灾难性的停电事故而硬件组件又没有备用电池。另外一个原因可能是连接件或硬件组件发生了物理损坏。在多数情况下，唯一的办法是使用备份并还原 SAP 数据库，然后应用最新的所有事务日志。但是，为了在早期检测出物理不一致的情况，或了解备份方法是否可靠，或是尽量减小物理损坏的影响，应该考虑以下三种主要措施：
- 考虑定期运行 DBCC CHECKDB。这一工作可以在运行生产环境还原映像的沙盘系统上进行。在这种系统上不必考虑 DBCC CHECKDB 耗费的时间和资源，也不会对生产用户造成影响。
- 实际测试从联机备份或差异备份以及事务日志备份还原 SAP 数据库。磁带上存有备份并不一定表示磁带上的备份是一致的，也不表示可以从磁带中读取备份。磁带硬件或盒式磁带可能由于时间久远而损坏，您也不会希望自己的磁带无法读取。保存备份并不表示在发生灾难时能够还原。还必须证明备份可读取。
- 对于数千吉的数据库，请使用日志传送或数据库镜像，保留数据库的第二份最新副本。这两种高可用性方法将硬件组件分离开来，因此可以在另一地点提供生产数据库的一致的物理映像。

每月评估安全修补程序（必要时安装）

对于大多数 SAP 客户来说，可用性是首要要求。特别是在他们需要提供全局单一 SAP 实例时，他们可不想为了应用安全修补程序而停止并重新启动 SAP 服务器。此外，在这些环境下，安装安全修补程序之前必须要进行某些测试。因此，对 SAP 客户来说，一种现实的办法是，仔细评估修补程序，降低修补程序的安装频率，最好是将其降至零。筛选不必要的数据包，禁用不必要的服务等都是不错的安全措施。
如果使用实时防病毒监控，建议不要将 SQL Server 数据库文件（包括数据文件、事务日志文件、tempdb 和其他系统数据库文件）纳入实时监控范围。如果执行磁盘备份，请排除数据库备份文件和事务日志备份文件。

评估硬件驱动程序和固件的更新模块，并在必要时安装

因商用服务器中的硬件驱动程序和固件存在 bug 而导致严重问题的情况时有发生。有时在 Microsoft 内部，此类问题较难发现，而且硬件公司有时对商用服务器客户提供的支持服务不足。因此，客户需要定期管理驱动程序和固件的更新。在更新生产环境商用服务器上的驱动程序之前，必须在测试和沙盘系统上执行全面的测试。与绝大多数其他软件组件不同，主机总线适配器 (HBA) 驱动程序或 SCSI 卡驱动程序中的微小缺陷都可能导致数据库的物理不一致。

每周或每月更新那些最大的表的统计信息

SQL Server 提供了两个选项来使统计信息保持最新：“自动创建统计信息”和“自动更新统计信息”。默认情况下，这两个选项都处于启用状态。SAP 建议保持它们的启用状态。在某些情况下，自动更新统计信息可能无法提供令人满意的性能。SAP BW 中就曾出现过这种情况。该问题已由 SAP BW 中的功能解决，记录在 SAP OSS note #849062 中。请注意，自动更新统计信息只能对 500 行以上的表运行。在某些极为特定的情况下，数据朝一个方向增长，此时建议对表的特定列按计划显式运行更新统计信息。但是，不应执行常规手动更新统计信息。如果经分析后发现性能问题的根本原因在于索引，或某些列统计信息太旧，则通常只需加大特定列或索引统计信息的更新频率。

重新生成最重要的索引或整理其碎片

重新组织表和索引对性能的影响与所执行的查询类型和系统中可用的 I/O 带宽密切相关。仅以 (1) 页的平均密度 < 80% 或 (2) 逻辑扫描碎片 > 40% 等作为阈值来衡量是否启动重组的做法只会浪费时间和资源。理由如下：
- 一些 SAP 队列表始终显示为有很多碎片。
- 当大多数 SAP 查询只读取一行或少量行时，重新组织表并不可取。
- 如果数据库服务器上的 SQL Server 有足够的 I/O 带宽和内存，表碎片的影响可能有限。

许多人从不重新组织表来加快查询性能。但是，也有人在存档 SAP 数据后重新组织表来压缩表。不是所有表都是根据存档条件来组织或排序的。因此可能出现这样的情况：尽管删除了 25% 的表数据，但表大小只减小了 10%。若要在存档后最大程度地减少占有的空间，可以对受影响的表运行 DBCC INDEXDEFRAG。DBCC INDEXDEFRAG 会压缩表页上的数据内容。DBCC INDEXDEFRAG 将朝向一页的多行的每个移动都视为单个事务。因此，运行 DBCC INDEXDEFRAG 会产生许多小型事务，而创建索引会将整个索引创建任务视为一个大型事务。DBCC INDEXDEFRAG 虽不占用很多 CPU 资源，但会产生大量 I/O 通信。因此，不要并行运行太多 DBCC INDEXDEFRAG 命令。对于大型表，不应通过重新创建聚集索引来完全重新组织表，因为这会生成大量的事务日志。

使用运行状况检查监视工具检查性能和可用性等

计划外的停机时间取决于系统故障通知传达到管理员的速度以及管理员多久可以开始恢复过程。对于可用性，SAP 管理员应明白，Microsoft 群集服务 (MSCS) 或数据库镜像 (DBM) 的自动故障转移机制可以保证系统连续可用。但是，故障转移本身会导致未完成的事务在数据库端回滚，而这又会进一步导致 SAP 端的业务事务回滚。这些批处理中断和数据不可用的后果可能很严重（例如，在工资计算中）。因此，监视系统和故障转移后发出通知对于尽快重新启动中断的 SAP 业务处理至关重要。

构建大型关系数据仓库的十大最佳实践

Lindsey.allen — Sat, 18 Oct 2008 03:01:40 GMT

撰稿人：Stuart Ozer、Prem Mehra 和 Kevin Cox

技术审阅人：Lubor Kollar、Thomas Kejser、Denny Lee、Jimmy May、Michael Redman 和 Sanjay Mishra

构建大型关系数据仓库是一项复杂的任务。本文介绍一些使用 SQL Server 构建高效的大型关系数据仓库时的设计技巧。由于大多数大型数据仓库都使用表分区和索引分区，所以，本文中的许多建议都涉及区。这些技巧大都是使用 SQL Server 2005 构建大型数据仓库的经验之谈。

考虑将大型事实数据表分区

考虑将 50-100 GB 或更大的事实数据表分区。
分区可提高易管理性，且通常可改善性能。
- 索引维护更快、粒度更小。
- 备份/还原选项更灵活。
- 数据加载和删除速度更快
当限制在单个分区内时，查询速度会更快。
一般应用日期当作事实表的分区键。
- 应用可调窗口。
应用查询分区消除。

基于事实数据表的日期键生成聚集索引

这样可使填充多维数据集或检索历史数据切片的查询更高效。
如果在批处理窗口中加载数据，则对事实数据表上的聚集索引使用 ALLOW_ROW_LOCKS = OFF 和 ALLOW_PAGE_LOCKS = OFF 选项。这有助于在查询期间加快表扫描操作，还有助于避免在大量更新过程中出现过多锁定活动。
为每个外键生成非聚集索引。这有助于“精确定位查询”，即根据选定的维度谓词提取行。对于备份/还原和部分数据库可用性等管理要求，请使用文件组。

仔细选择分区粒度

大多数客户使用月、季度或年。
对于高效的删除，必须一次删除一个完整的分区。
一次加载一个完整的分区更快。
- 对每日加载而言，按天分区可能是个不错的选择。
- 但请记住，一个表最多只能有 1000 个分区。
分区粒度会影响查询并行度。
- 搜索单个分区的查询的并行上限为 MAXDOP（最大并行度）。
- 搜索多个分区的查询对一个分区使用一个线程，并行上限为 MAXDOP。
如果需要 MAXDOP 并行度（假设 MAXDOP = 4 或更大），应避免常用查询只搜索两三个分区的分区设计。

恰当地设计维度表

对所有维度，日期维度除外，使用整数代理键；并将可能的最小整数用于维度代理键。这样可以尽量缩小事实数据表。
使用从 DATETIME 数据类型派生的 Integer 型有意义的日期键（如 20060215）。
- 不要对日期维度使用代理键
- 易于编写对此列执行 WHERE 子句的查询，以便能够消除事实数据表的分区。
对每个维度表的业务键（非代理键）生成聚集索引。
- 加载事实数据表时支持快速查找。
- 支持快速查找现有维度行，以管理类型 2 更改维度。
对每个维度表的维度键（代理键）生成非聚集主键索引。
对其他经常搜索的维度列生成非聚集索引。
避免将维度表分区。
避免事实数据表和维度表之间存在主键-外键关系。允许快速加载。通过 Transform Lookups 确保完整性，或在数据源处执行完整性检查。

编写有效的查询，以便消除分区

尽量将查询谓词（WHERE 条件）直接放在事实数据表的分区键（日期维度键）上。

使用可调窗口方法维护数据

维护一个滚动的时间窗口，以便联机访问事实数据表。加载最新的数据，卸载最旧的数据。
始终在分区范围的两端保留空分区，以确保分区拆分（加载新数据之前）和分区合并（卸载旧数据之后）操作不会导致任何数据移动。
避免拆分或合并已填充的分区。拆分或合并已填充的分区效率极低，因为这可能会导致额外产生 4 倍的日志，还会导致严重的锁定。
在要加载的分区所在的文件组中创建加载临时表。
在要删除的分区所在的文件组中创建卸载临时表。
一次加载整个最新分区时速度最快，但仅在分区大小等于数据加载频率时才有可能（例如，您每天有一个分区，每天加载一次数据）。
如果分区大小与数据加载频率不符，应增量加载最新的分区。
将大容量数据加载到分区表的不同做法在白皮书 http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/loading_bulk_data_partitioned_table.mspx 中进行了讨论。
每次始终只卸载一个分区。

有效加载初始数据

在初始数据加载期间使用 SIMPLE 或 BULK LOGGED 恢复模式。
创建带有聚集索引的分区事实数据表。
为每个分区创建非索引临时表，并使用各自不同的源数据文件填充每个分区。
并行填充临时表。
- 使用多个 BULK INSERT、BCP 或 SSIS 任务。
  - 如果没有 IO 瓶颈，请创建与 CPU 数量一样多的加载脚本，将它们并行运行。如果 IO 带宽有限，则使用较少的并行脚本。
  - 在加载中使用 0 批大小。
  - 在加载中使用 0 提交大小。
  - 使用 TABLOCK。
  - 如果源文件为同一个服务器上的平面文件，则使用 BULK INSERT。如果要从远程计算机推送数据，则使用 BCP 或 SSIS。
对每个临时表生成聚集索引，然后创建适当的 CHECK 约束。不要使用 SORT_IN_TEMPDB 选项。
使用 SWITCH 将所有分区切换到分区表中。
对分区表生成非聚集索引。
在吞吐量可达到 14 GB/秒的 SAN 中，在 64 个 CPU 的服务器上，一小时之内可以加载 1 TB（非索引表）。有关详细信息，请参阅 SQLCAT 博客文章 http://blogs.msdn.com/sqlcat/archive/2006/05/19/602142.aspx。

有效删除旧数据

尽量使用分区切换。
从非分区的索引表中删除大量行时，
- 避免使用 DELETE FROM ...WHERE ...，否则
  - 会产生大量锁定和日志记录
  - 如果取消删除，回滚时间会很长
- 通常，以下方法更快
  - 使用 INSERT 将记录插入到非索引表
  - 对表创建索引
  - 重命名新表来替换原始表名
或者，在循环中重复使用以下语句，“分批”删除
DELETE TOP (1000) ... ;
COMMIT

另一种方法是更新行，将其标记为已删除，然后在不忙的时候删除。

手动管理统计信息

将分区表的统计信息作为整体来维护。
加载新数据后，请手动更新大型事实数据表的统计信息。
对分区重新生成索引后，请手动更新统计信息。
如果在定期加载后会定期更新统计信息，则可以关闭该表的 autostats。
这对于优化可能只需要读取最新数据的查询很重要。
在增量加载后更新小型维度表的统计信息也可能有助于提高性能。对维度表更新统计信息时使用 FULLSCAN 选项可获得更准确的查询计划。

考虑有效的备份策略

对于非常大的数据库来说，备份整个数据库可能需要很长时间。
- 例如，将一个 2 TB 的数据库备份到 SAN 上拥有 10 个心轴的 RAID-5 磁盘中可能需要 2 个小时（速率为 275 MB/秒）。
使用 SAN 技术的快照备份是个非常不错的选择。
定期减少要备份的数据量。
- 历史分区的文件组可标记为 READ ONLY。
- 文件组标记为只读后，只需对其备份一次。
- 只对读/写文件组执行定期备份。
请注意，不能对只读文件组并行执行 RESTORE。

十大最佳存储实践

Lindsey.allen — Fri, 17 Oct 2008 21:45:33 GMT

要想让 SQL Server 系统的性能和运行达到最佳，关键在于适当配置 IO 子系统。以下是 SQL Server 小组推荐的一些最常用、最好的 SQL Server 存储配置方法。

了解 SQL Server 的 IO 特征以及您的应用的具体 IO 要求/特征。

为了成功地为您的 SQL Server 应用设计和部署存储，您需要了解您的应用的 IO 特征，并对 SQL Server 的 IO 模式有个基本了解。性能监视器是捕获现有应用的这些信息的最佳位置。在此，您需要问自己以下几个问题：

应用程序的读写比率是多少？
典型的 IO 速率（每秒 IO、MB/s 和 IO 的大小）都是多少？监视以下性能监视器计数器：

Average read bytes/sec、average write bytes/sec
Reads/sec、writes/sec
Disk read bytes/sec、disk write bytes/sec
Average disk sec/read、average disk sec/write
Average disk queue length

有多少 IO 本质上是有序的？又有多少 IO 本质上是随机的？此应用从根本上来说是 OLTP 应用还是关系数据仓库应用？

若要了解 SQL Server IO 的核心特征，请参阅 SQL Server 2000 I/O 基本知识。

更多/更快的心轴有助于改善性能

确保拥有足够多的心轴来支持 IO 要求，且滞后时间可以接受。
使用文件组来满足备份/还原和部分数据库可用性等管理要求。
使用数据文件跨特定 IO 配置（物理磁盘和 LUN 等）将数据库“条带化”。

不要“过度”优化存储设计；通常，设计越简单，性能越好，灵活性也更高。

除非您对自己的应用非常了解，否则不要通过将对象有选择性地放在不同的心轴上来过度优化 IO。
务必预先考虑增长策略。随着数据的增多，您将如何管理数据文件/LUN/RAID 组的增长？最好预先设计这一策略，不要等以后到了生产部署中再重新调整数据文件或 LUN。

在部署之前验证配置

在部署 SQL Server 之前，务必对 IO 子系统进行基本的吞吐量测试。确保这些测试可以达到您的 IO 要求，且其滞后时间也在可以接受的范围内。SQLIO 就是一个可用来实现该目的的工具。该工具附带了一个文档，其中介绍了测试 IO 子系统的基本知识。请下载 SQLIO 磁盘子系统基准工具。
您要明白，运行 SQLIO 测试的目的不是模拟 SQL Server 的准确 IO 特征，而是测试 IO 子系统对于常用 SQL Server IO 类型可达到的最大吞吐量。
也可以使用 IOMETER 取代 SQLIO。

始终将日志文件放在 RAID 1+0（或 RAID 1）磁盘上。这么做可以：

更好地保护文件免受硬件故障的破坏，以及
获得更好的写性能。
注意：通常，RAID 1+0 可为写密集型应用提供更大的吞吐量。所获得的性能将因硬件供应商的 RAID 实现方式而异。RAID 1+0 最常见的替代方式是 RAID 5。通常， RAID 1+0 比任何其他提供数据保护的 RAID 级别（包括 RAID 5）所提供的写性能都要好。

在物理磁盘级将日志与数据隔离

无法实现这一点时（如在整合的 SQL 环境中），请考虑 I/O 的特征，并将相似的 I/O 特征（即所有日志）分到同一个心轴上。
将异类工作负荷（IO 和滞后时间特征迥异的工作负荷）组合在一起可能会对整体性能产生不利影响（例如，将 Exchange 和 SQL 数据放在同一个物理心轴上）。

考虑 TEMPDB 数据库的配置

在安装 SQL Server 之后，务必先确定 TEMPDB 的大小，并将其移到足够大的存储区。
如果将 TEMPDB 放在 RAID 1+0，性能可能会有所提升（取决于 TEMPDB 的使用）。
对于 TEMPDB 数据库，为每个 CPU 创建 1 个数据文件，如下文第 8 项中所述。

按照 CPU 的个数创建相应数量的数据文件有利于提高分配密集型工作负荷的可伸缩性。

建议为主机服务器上的每个 CPU 创建 .25 到 1 个数据文件（每个文件组）。
TEMPDB 更应如此，此时，建议为每个 CPU 创建 1 个数据文件。
双核按 2 个 CPU 算；逻辑处理器（超线程）不算。

请勿忽视 SQL Server 的一些基本知识

数据文件的大小应该一致 – SQL Server 使用按比例的填充算法，该算法倾向于将数据分配到在空闲空间多的文件中。
预先确定数据和日志文件的大小。
不要依赖 AUTOGROW，请手动管理这些文件的增长。为安全起见，可以保留 AUTOGROW 为 ON，但应主动管理数据文件的增长。

不要忽视存储配置的基础

使用存储供应商推荐的最新 HBA 驱动程序
使用从 HBA 生产商网站下载的存储供应商特定的驱动程序
根据您的 IO 量优化 HBA 驱动程序的设置。通常，驱动程序特定设置应由存储供应商提供。但我们发现默认的队列深度值一般不够深，无法支持 SQL Server IO 量。
确保存储阵列固件满足最新建议要求。
使用多路径软件在 HBA 和 LUN 之间达到平衡，并确保运行正常
简化配置并提供可用性优势
Microsoft Multipath I/O (MPIO)：供应商借助 Microsoft 提供的驱动程序开发工具包生成设备特定模块 (DSM)。

Analysis Services 查询性能十大最佳实践

Lindsey.allen — Fri, 17 Oct 2008 21:41:46 GMT

作者：Carl Rabeler

在针对 SQL Server 2005 Analysis Services 实例进行 MDX 查询时，要想获得最佳性能，关键要做到以下几点：合理的多维数据集设计、有效的多维表达式 (MDX) 以及充足的硬件资源。本文列出了 Microsoft SQL Server 开发小组推荐的十个最常用、最有效的 Analysis Services 查询性能优化方法。有关其他与查询性能相关的 Analysis Services 最佳实践介绍，请参阅 Analysis Services 性能指南和 Analysis Services 2005 OLAP 设计最佳实践。

优化多维数据集和度量值组设计

在每个维度内为数据定义合适的级联属性关系（例如，天 > 月 > 季度 > 年），并定义相关属性的用户层次结构（称为“自然层次结构”）。自然层次结构中的属性会显现在层次结构存储区中的磁盘上，并被自动视为候选聚合。除非通过级联属性关系将构成各级别的属性关联起来，否则用户层次结构不会被视为自然层次结构。在 SQL Server 2005 Service Pack 2 (SP2) 中，对未定义为自然层次结构的每个用户层次结构，Business Intelligence Development Studio 中都会出现一条警告。
删除属性之间的冗余关系，以协助查询执行引擎生成合适的查询计划。属性与键属性之间必须存在直接或间接关系，但二者之中只能居其一。
仅包含必需的度量值组，尽量将多维数据集空间保持最小。
将要同时查询的度量值放入同一个度量值组。要知道，当查询需从多个度量值组检索度量值时，存储引擎必须执行多项操作。为了优化缓存的使用率，可以考虑将大量不是一起查询的度量值分别放入不同的度量值组，但不要过度增加度量值组的数量。
尽量少用大型父子层次结构。在父子层次结构中，只为键属性和顶级属性（如 All 属性）创建聚合，除非禁止这么做。因此，查询时要计算返回中间级单元格的查询，这对于大型父子维度来说，速度会比较慢。如果在设计中遇到有大型父子层次结构（超过 250,000 个成员）的情况，那可能需要考虑改变源架构，将部分或全部层次结构重组为级别数固定的用户层次结构。
优化多对多维度的性能（若使用）。通过多对多维度查询数据度量值组时，要在数据度量值组与中间度量值组之间执行运行时“联接”，联接媒介是这两个度量值组共有的每个维度的粒度属性。请尽可能减小中间度量值组所基的中间事实数据表的大小。为了优化运行时联接，请检查中间度量值组的聚合设计，确保聚合包含多对多维度的属性。

若要了解如何优化维度来提高查询性能，请参阅 SQL Server 2005 Analysis Services 性能指南和 Analysis Services 2005 OLAP 设计最佳实践这两篇文章。有关分析设计方案与最佳实践是否相符的帮助信息，请参阅 2007 年 2 月发布的 Community Technology Preview (CTP) 版本的 SQL Server 2005 最佳实践分析器（最终版本即将发布）。

定义有效的聚合

定义聚合，以减少存储引擎为满足查询需要而从磁盘扫描的记录数。如果 SQL Server Profiler 跟踪记录显示大多数不能从缓存解析的用户查询是通过分区读取而不是聚合读取来解析的，则可以考虑使用聚合管理器示例应用程序来设计自定义聚合。此示例可从 CodePlex 获取，网址为 http://www.codeplex.com/MSFTASProdSamples，其社区更新版可从 http://www.codeplex.com/bidshelper 获取。
避免设计过多聚合。过多聚合会降低处理性能，也可能会降低查询性能。虽然最佳聚合数因情况而异，但根据 SQL Server 最佳实践小组的经验，在几乎所有情况下，最佳聚合数都在一百以内，而非成百上千。
启用 Analysis Services 查询日志来捕获用户查询模式，并在设计聚合时使用此查询日志。有关详细信息，请参阅配置 Analysis Services 查询日志。

若要了解如何设计聚合来提高查询性能，请参阅 SQL Server 2005 Analysis Services 性能指南和 Analysis Services 2005 OLAP 设计最佳实践这两篇文章。

使用分区

定义分区，这样，当查询无法从数据缓存或聚合得到解析时，Analysis Services 只需查询较少的数据即可解析它。定义分区还可以增大解析查询的并行度。
为了获得最佳性能，将数据分区时所用的方式应符合常用查询的需要。极常见的分区方法是选择一个时间元素，如日、月、季度、年，或选择几个时间元素。选用分区方式时，要避免出现分区后大多数查询都需要从许多分区来解析的情况。
在大多数情况下，分区包含的记录应少于 2 千万条，每个度量值组包含的总分区数应少于 2,000 个。此外，应避免定义所含记录不足 2 百万条的分区。分区太多会导致元数据操作速度缓慢，分区太少又会导致错过并行。
为实时数据定义单独的 ROLAP 分区，并将实时 ROLAP 分区放入其自己的度量值组。

若要了解如何设计分区来提高查询性能，请参阅 SQL Server 2005 Analysis Services 性能指南、Microsoft SQL Server 客户咨询小组博客和 Analysis Services 2005 OLAP 设计最佳实践。

编写有效的 MDX

删除结果集中的空元组，以缩短查询执行引擎对结果集进行序列化的时间。
避免在 MDX 计算中进行运行时检查，这会导致执行路径缓慢。如果使用 Case 函数和 IF 函数执行条件检查，执行路径会很慢，因为这类检查在查询解析过程中必须解析多次。请使用 SCOPE 函数重新编写这类查询，以迅速减少 MDX 计算涉及的计算空间。有关详细信息，请参阅预算差异 - MDX 优化研究：计算模式与 NON_EMPTY_BEHAVIOR、在 MDX 中比较级别以及单元计算中的 CONDITION 与 SCOPE 对比和多选友好 MDX 计算。
尽可能使用 Non_Empty_Behavior，以便查询执行引擎能够使用大容量计算模式。然而，如果使用 Non_Empty_Behavior 的方法不当，将返回错误的结果。有关详细信息，请参阅预算差异 - MDX 优化研究：计算模式与 NON_EMPTY_BEHAVIOR 和平均值、比率、除以零与 NON_EMPTY_BEHAVIOR。
对成员属性使用 EXISTS 而非筛选，以避免执行路径缓慢。使用 NonEmpty 函数和 Exists 函数时，查询执行引擎能够使用大容量计算模式。
使用服务器端 ADOMD.NET，而非字符串操作函数（如 StrToMember 和 StrToSet），在 Analysis Services 存储过程中执行字符串操作。
尽量使用同一个多维数据集中的多个度量值组，而不使用 LookupCube 函数。
重新编写包含任意形状的 MDX 查询，以尽量减少子查询过多的情况。任意形状的集是指一组无法解析为只有单个层次结构的集的交叉连接的成员。例如，集 {(Gender.Male, Customer.USA), (Gender.Female, Customer.Canada)} 即为任意集。您可以经常使用 Descendants 函数解析任意形状，与使用其他函数编写的返回相同结果的查询相比，该函数使用的子查询较少。
尽可能重新编写会导致过多预提取的 MDX 查询。“预提取”是指查询执行引擎为了提高效率从存储引擎请求了超过实际需要的信息来解析当前查询。通常，预提取是最高效的数据检索方法。但偶尔也有例外。在某些情况下，您可以重新编写查询，在 FROM 子句中使用嵌套 select 语句，而不是在 WHERE 子句中使用集，从而消除过多的预提取。无法消除过多预提取时，可能需要禁用预提取，并使用 Create Cache 语句来准备加温。有关详细信息，请参阅如何使用 Create Cache 语句来准备 Analysis Services 数据缓存。
在使用集之前在交叉连接中先筛选该集，以便在执行交叉连接前减少多维数据集空间。

有效地使用查询引擎缓存

确保 Analysis Services 计算机有足够的内存来存储查询结果，以便在解析后续查询时可以再利用。若要监视，请使用 MSAS 2005: Memory/Cleaner Memory Shrinkable DB 和 MSAS 2005: Cache/Evictions/sec Performance Monitor 计数器。
定义 MDX 脚本中的计算。MDX 脚本中的计算有一个全局范围，因此，与这些查询相关的缓存可以由同一组安全权限下的多个会话共享。但是，在用户查询中使用 Create Member 和 With Member 定义的计算成员没有全局范围，与这些查询相关的缓存无法实现跨会话共享。
通过使用自选工具执行一组预定义的查询来准备缓存。使用 Create Cache 语句也可以达到同一目的。有关使用 Create Cache 语句的详细信息，请参阅如何使用 Create Cache 语句来准备 Analysis Services 数据缓存。有关如何使用 SQL Server 2005 Integration Services 准备缓存的信息，请参阅在 Integration Services 中生成自己的 Analysis Services 缓存准备器。
重新编写包含任意形状的 MDX 查询，以充分利用缓存。例如，在某些情况下，可以重新编写要求无缓存磁盘访问的查询，在 FROM 子句中使用嵌套 select 语句，而不使用 WHERE 子句，以使这些查询可以完全从缓存解析。在其他情况下，使用 WHERE 子句可能要好一些。

确保有柔性聚合来回应查询

请注意，对维度使用 ProcessUpdate 来增量更新维度会删除受更新和删除影响的所有柔性聚合，且在默认情况下，在下一个完整处理之前不会重新创建柔性聚合。
请务必处理受影响的对象、配置迟缓处理、对受影响的分区执行 ProcessIndexes 或对受影响的分区执行完整处理，从而重新创建聚合。

若要了解如何确保柔性聚合不被删除，请参阅 SQL Server 2005 Analysis Services 性能指南。

优化内存使用率

增加 Analysis Services 服务器上分页文件的大小或增加内存，以防当分配的虚拟内存量超过 Analysis Services 服务器上的物理内存量时出现内存不足错误。
使用 SQL Server 2005（32 位）时，请在 SQL Server 2005 Enterprise Edition（或 SQL Server 2005 Developer Edition）中使用 Microsoft Windows Advanced Server® 或 Datacenter Server，以便 Analysis Services 能够寻址高达 3 GB 的内存。若要使 Analysis Services 能够在这两个版本中寻址超过 2 GB 的物理内存，请在 boot.ini 文件中使用 /3GB 开关。如果在 boot.ini 文件中设置 /3GB 开关，则服务器至少应拥有 4 GB 内存，以确保 Windows 操作系统也有足够的内存用于系统服务。
运行多个 Analysis Services 实例或同一台计算机上还运行其他应用程序时，请将 Memory/LowMemoryLimit 属性值减至 75% 以下。
运行多个 Analysis Services 实例或同一台计算机上还运行其他应用程序时，请将 Memory/TotalMemoryLimit 属性值减至 80% 以下。
Memory/LowMemoryLimit 属性值和 Memory/TotalMemoryLimit 属性值之间需要有一定差距，通常为 20%。
在多用户环境中检测到查询失败时，请与 Microsoft 支持部门联系，请求他们协助修改 MemoryHeapType。
当运行在非一致性内存访问 (NUMA) 体系结构上时，如果 VirtualAlloc 返回需要的时间非常长，或似乎停止响应，请升级到 SQL Server 2005 SP2，并联系 Microsoft 支持部门，请求协助对预分配 NUMA 内存进行合适的设置。

若要了解何时应考虑更改默认内存使用量，请参阅 SQL Server 2005 Analysis Services 性能指南和 Microsoft SQL Server 客户咨询小组博客。

优化处理器使用率

为了增大拥有多个处理器的服务器在查询过程中的并行度，请考虑根据服务器的处理器数目修改 Threadpool\Query\MaxThreads 和 Threadpool\Process\MaxThreads 选项的值。
通常，建议将 Threadpool\Query\MaxThreads 设置为一个小于或等于服务器上处理器数两倍的值。例如，如果服务器有八个处理器，则通常将它设置为不超过 16 的值。实际上，增大 Threadpool\Query\MaxThreads 选项的值不会显著提高给定查询的性能。然而，增大此属性值可以增加同时处理的查询数。
通常，建议将 Threadpool\Process\MaxThreads 选项设置为一个小于或等于 10 倍于服务器上处理器数的值。此属性控制存储引擎在查询操作及处理操作期间所使用的线程数。例如，如果服务器有八个处理器，则通常将它设置为不超过 80 的值。请注意，如果给定服务器上的处理器数不足八个，那么，即使默认值为 64，也无需减小该默认值来扼制并行操作。
虽然修改 Threadpool\Process\MaxThreads 和 Threadpool\Query\MaxThreads 属性值可以增大查询过程中的并行度，但也必须注意 CoordinatorExecutionMode 选项的影响。例如，如果服务器有四个处理器，并接受 CoordinatorExecutionMode 的默认设置 -4，则在所有服务器操作中一次总共可执行 16 个作业。因此，如果并行执行 10 个查询，且总共需要 20 个作业，则在给定时间只能启动 16 个作业（假设当时未执行任何处理操作）。达到作业阈值时，后续作业将排队等候，直到能够创建新作业为止。因此，如果作业数量是操作瓶颈的话，增大线程数并不一定会改善总体性能。

尽量向上扩展

所有大型系统都使用 64 位体系结构。
增加内存和处理器资源，升级磁盘 I/O 子系统，以缓解单个系统上的查询性能瓶颈。
尽量避免跨服务器链接维度或度量值组，尽量避免远程分区，这些不是最佳解决之道。

无法再向上扩展时则向外扩展

如果性能瓶颈是由多用户查询工作负荷导致的单个系统上的处理器利用率问题，可以使用一组 Analysis Services 服务器为查询请求提供服务，籍此提高查询性能。请求负载可均衡地分布在两台或更多 Analysis Services 服务器上，以支持大量并发用户（这称作服务器场）。负载平衡群集通常线性扩展。
使用 Analysis Services 服务器群集来提高查询性能时，先在单台处理服务器上执行处理，再使用 XMLA Synchronize 语句将处理与查询服务器同步，然后使用 Robocopy、其他文件复制实用工具或 SAN 存储解决方案的高速复制功能来复制数据库目录。

使用Analysis Services 进行Scale-Out 查询

denny.lee — Mon, 28 Jan 2008 16:45:00 GMT

SQL Server 最佳实践

发布日期: 2007年6月13日
作者: Denny Lee, Nicholas Dritsas
投稿人: Lubor Kollar, Lindsey Allen

此白皮书描述了如何为Microsoft SQL Server 2005 Analysis Services 建立一个可伸缩且负载平衡的查询环境，以便处理在Analysis Services 服务器上并发的大量查询请求。负载平衡查询可以确保针对OLAP 多维数据集的读取在任何时刻都能查询到最新的聚合，并且将查询负载分散到所有可用的服务器上。这种scale-out 查询架构可以优化多维数据集的处理时间，增加多维数据集更新的频率，并让处理过程更加健壮，因为你可以提供更加频繁的处理能力以及透明化的错误恢复。

更多信息，请参考白皮书 Scale-Out Querying with Analysis Services

将排序规则以及数据类型从非Unicode改为Unicode所带来的影响

denny.lee — Mon, 28 Jan 2008 16:44:00 GMT

SQL Server 最佳实践

发布日期: 2007年11月
作者: Akio Jose
技术评论家: Don Vilen, Fernando Caro, Goldie Chaudhuri, Michael Wang, Sanjay Mishra, Stuart Ozer

当商务增长呈现国际化时，其数据库系统必须能够通过使用Unicode 数据类型，实现在数据表中存储多国语言字符。该白皮书研究的内容是将数据表的列从非Unicode数据类型转为Unicode数据类型以及更改数据库排序规则所花费的时间。并使用这些信息来计算更改大数据表所需的时间。

更多信息，请参考白皮书 The Impact of Changing Collations and of Changing Data Types from Non-Unicode to Unicode

在SQL Server 2005 Analysis Services 中识别并解决MDX 查询性能瓶颈

denny.lee — Mon, 28 Jan 2008 16:43:00 GMT

SQL Server 最佳实践

发布日期: 2007年8月
作者: Carl Rabeler, Eric Jacobsen
技术评论家: Craig Utley

提升单独MDX 的查询性能需要做很多事情。首先，你必须在性能不佳的MDX 查询中找到造成性能瓶颈的源。为了能够找到这个源，你需要理解如何使用现有的Microsoft Windows 以及SQL Server 2005 Analysis Services 的排错工具来辅助你找到瓶颈，并且你还要能够看懂这些工具所显示出的信息。这篇文章提供了现有工具的相关信息并演示了如何使用这些工具通过单独的MDX 查询来识别并解决MDX 查询性能瓶颈。

在SQL Server 2005中为XML 数据类型优化性能

denny.lee — Mon, 28 Jan 2008 16:42:00 GMT

Microsoft SQL Server 9.0 技术文档

发布日期: 2005年12月
作者: Shankar Pal, Babu Krishnaswamy, Vasili Zolotov, and Leo Giakoumakis

此文档将研究如何提升Microsoft SQL Server 2005中XML 数据类型的查询以及数据修改的性能。为了能够从此文章中学到更多，你需要熟悉SQL Server 2005中的XML 功能。相关背景知识，请参考Microsoft SQL Server 2005中的XML Support 以及MSDN 中的XML Best Practices for Microsoft SQL Server 2005.

更多信息，请参考白皮书Performance Optimizations for the XML Data Type in SQL Server 2005

XML在Microsoft SQL Server 2005中的最佳实践

denny.lee — Mon, 28 Jan 2008 16:42:00 GMT

Microsoft SQL Server 9.0 技术文档

发布日期: 2004年4月, 修改日期：2007年4月
作者: Shankar Pal, Vishesh Parikh, Vasili Zolotov, Leo Giakoumakis, Michael Rys

该文章将介绍XML 数据模型及其在Microsoft SQL Server 2005中的使用，并会举出相应的例子。为了能够从此文章中学到更多，你需要了解SQL Server 中一些基本的XML 功能，有关这些内容，请参阅Microsoft Developer Network 中的XML Support in Microsoft SQL Server 2005

更多信息，请参考白皮书XML Best Practices for Microsoft SQL Server 2005

SQL Server 2005安全性的最佳实践- 操作任务及管理任务

denny.lee — Mon, 28 Jan 2008 16:41:00 GMT

SQL Server 最佳实践

发布日期: 2007年3月13日
作者: Bob Beauchemin, SQLskills
技术评论家: Laurentiu Cristofor, Al Comeau, Sameer Tejani, Devendra Tiwari, Rob Walters, Niraj Nagrani

此白皮书包含了和SQL Server 2005安全性相关的操作任务以及管理任务，并列举了最佳实践以及可以让SQL Server 系统更加安全的操作任务和管理任务。每个主题都描述了一个功能及其最佳实践。有关特定功能以及文章中所提到的数据定义语言(data definition language, DDL)，请参阅SQL Server 2005 Books Online. 文章中会区别SQL Server 2005中的新功能以及被修改过的默认功能。针对操作任务的代码示例使用了Transact-SQL 语言，因此需要读者对Transact-SQL 语言有所了解以便从此文章中学到更多内容。

更多信息，请参阅白皮书SQL Server 2005 Security Best Practices - Operational and Administrative Tasks

通过聚集索引以及堆来对比数据表组织结构 (Clustered Indexes vs. Heaps)

denny.lee — Mon, 28 Jan 2008 16:40:00 GMT

SQL Server 最优实践

发布日期: 2007年5月25日
作者: Burzin Patel, Sanjay Mishra
投稿人: Kohei Ueda, Michael Thomassy
技术评论家: Stuart Ozer, Prem Mehra, Sunil Agarwal, Artem Oaks, Tengiz Kharatishvili, Mike Ruthruff, Hermann Daeubler, Tom Davidson, Eric Jacobsen, Lindsey Allen

在SQL Server 2005中，任何一个数据表不是采用聚集索引就是通过堆(没有聚集索引的情况下)来进行组织。此白皮书总结了他们之间的优点和缺点，在性能上的区别以及排序为列表(聚集索引)或者采用堆的数据表的其它操作。在六种截然不同的场景中(DML 操作在数据表中执行)测量性能并呈现出详细的报告。此白皮书提供了针对这两种数据表组织形式的优点而建议的最佳实践，同时还提供了一些示例。

更多信息，请参阅白皮书Comparing Tables Organized with Clustered Indexes versus Heaps

在SQL Server 2005 Analysis Services 的连通性场景中解决常见的连通性问题

denny.lee — Mon, 28 Jan 2008 16:39:00 GMT

SQL Server 最佳实践

发布日期: 2007年4月30日
作者: Carl Rabeler
技术评论家: Craig Utley

此文章列举了10个最常见的连通性场景，这里面包含了用户最容易遇到的连通性问题，并深入研究了常见客户端应用程序所产生的错误消息。此文章将向你展示如何快速隔离每一个错误，并且提供了如何解决造成错误消息的底层问题。

通过数据库镜像实现应用程序故障转移 (Application Failover)

denny.lee — Mon, 28 Jan 2008 16:38:00 GMT

SQL Server 最佳实践

发布日期: 2007年4月19日
作者: Michael Thomassy, Sanjay Mishra
技术评论家: Prem Mehra, Mike Ruthruff, Don Vilen, Kevin Cox, Chris Lee, Siva Raghupathy, Jaaved Mohammed, Burzin Patel, Cihan Biyikoglu, Madhu Desarapu

数据库镜像可以在数据库服务器出现故障的时候切换到另一台服务器上。为了实现无缝的用户体验，很重要的一点是让应用程序能够自动重新连接到当前的主服务器上。该文章描述了如何确保你的应用程序在数据库镜像发生故障转移的时候自动实现故障跳转。文章中提到的客户端重定向工具包括Microsoft SQL Native Client, ADO.NET, 以及Microsoft JDBC Driver.

更多信息，请参阅白皮书 Implementing Application Failover with Database Mirroring

针对Analysis Services 2005的OLAP 设计的最佳实践

denny.lee — Mon, 28 Jan 2008 16:36:00 GMT

SQL Server 最佳实践

发布日期: 2007年3月21
作者: Matt Carroll
投稿人: Robert Zare, Edward Melomed, Akshai Mirchandani, Marius Dumitru, Siva Harinath
技术评论家: Craig Utley, Nicholas Dritsas
项目编辑: Jeannine Nelson-Takaki

该文章描述了在Microsoft SQL Server 2005 Analysis Services 中设计OLAP 数据库并更好的迎合用户功能性需求和性能需求所推荐的最佳实践。为联机分析处理(Online Analytical Processing, OLAP)设计数据库，和为联机事务处理(Online Transaction Processing, OLTP)设计数据库有所不同，因此需要用不同的方法实现结果的优化。

更多信息，请参阅白皮书 OLAP Design Best Practices for Analysis Services 2005