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

作者 ： 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 业务处理至关重要。