了解极大型数据库迁移最佳做法

  • 11 分钟

包含以下指导原则基于实际客户项目以及从这些项目中获得的经验。 指导原则提到了过去不成功的方案。 例如，建议不要使用 UNIX 服务器或虚拟化服务器作为 R3load 导出服务器：

  • 通常，导出性能是总体停机时间的一个门控因素。 当前硬件往往已使用 4-5 年以上，升级成本高得令人望而却步。
  • 因此，获得切实可行的最大导出性能非常重要。
  • 在放弃和使用 Intel R3load 服务器之前，以前的项目花费了数人周甚至数人月的时间来尝试在 UNIX 或虚拟化平台上优化 R3load 导出性能。
  • 双插槽市售 Intel 服务器价格低廉，能显著提升性能，在某些情况下，效果比在 UNIX 或虚拟化服务器上进行微调改进要高出几个数量级。
  • 客户通常具有现有的虚拟机场，但大多数情况下这些场不支持新式卸载或 SR-IOV 技术。 VMware 版本通常较旧、未修补或未针对高网络吞吐量和低延迟进行配置。 R3load 导出服务器需要快速的线程性能和极高的网络吞吐量。 R3load 导出服务器可能以接近 100% 的 CPU 和网络利用率运行 10-15 小时。 这不是大多数 VMware 场的典型用例，而且大多数 VMware 部署从来不是设计用于处理 R3load 之类的工作负载。

提示

请不要投入时间来优化 UNIX 或虚拟化平台上的 R3load 导出性能。 这不仅会浪费时间，而且比在项目开始时购买低成本 Intel 服务器的费用要高得多。 因此，VLDB 迁移客户需要确保项目团队在项目开始时拥有快速的新式 R3load 导出服务器。 这可以降低项目的总成本和风险。

最佳实践

  • 调查和盘点当前的 SAP 环境。 确定 SAP 支持包级别，并确定是否需要进行修补以支持目标 DBMS。 一般情况下，操作系统兼容性由 SAP 内核决定，DBMS 兼容性由 SAP_BASIS 补丁级别决定。
  • 生成需要在源系统中应用的 SAP OSS 说明列表，例如 SMIGR_CREATE_DDL 的更新。 考虑升级源系统中的 SAP 内核，以避免在迁移到 Azure 期间发生很大的变化（例如，如果系统运行旧的 7.41 内核，请在源系统上更新到最新的 7.45 以避免在迁移期间发生很大的变化）。
  • 开发并阐述高可用性和灾难恢复解决方案。 该文档应将解决方案分解为 DB 层、ASCS 层和 SAP 应用程序服务器层。 独立解决方案（例如 TREX 或 liveCache）可能需要单独的解决方案。
  • 制定大小调整和配置文档，用于详细说明 Azure 虚拟机类型和存储配置。 多少个高级磁盘，多少个数据文件，如何在磁盘之间分配数据文件，存储空间使用率，NTFS 格式大小= 64kb。 此外，阐述备份/还原以及 DBMS 配置，例如内存设置、最大并行度和跟踪标志。
  • 制定网络设计文档，包括虚拟网络、子网、NSG 和 UDR 配置。
  • 阐述并实施安全和强化的概念。 删除 Internet Explorer，为 SAP 服务帐户和服务器创建 Active Directory 容器，并应用防火墙策略来阻止除有限数量的必需端口之外的其他所有端口。
  • 创建 OS/DB 迁移设计文档，用于详细说明包和表拆分的概念、R3load 数量、SQL Server 跟踪标志、已排序/未排序、Oracle RowID 设置、SMIGR_CREATE_DDL 设置、Perfmon 计数器（例如 BCP 行数/秒和 BCP 吞吐量 kb/秒、CPU、内存）、RSS 设置、加速网络设置、日志文件配置、BPE 设置、TDE 配置。
  • 创建一个“运行计划”图，用于显示每个测试周期的 R3load 导出/导入进度。 这样，迁移团队便可以验证优化和更改是否提高了 R3load 导出或导入性能。 X 轴是完成的包数，Y 轴是已用的时间。 此运行计划在生产迁移期间也很重要，可以将规划的进度与实际进度进行比较，并提前识别任何问题。
  • 创建性能测试计划。 识别最前面的大约 20 份联机报告、批处理作业和接口。 阐述原始源系统上的输入参数（例如日期范围、销售办事处、工厂、公司代码等）和运行时。 与 Azure 上的运行时进行比较。 如果存在性能差异，请运行 SAT、ST05 和其他 SAP 工具来识别低效的语句。
  • 审核部署和配置，确保群集超时、内核、网络设置、NTFS 格式大小都与设计文档一致。 在重要的服务器上设置 perfmon 计数器，以便每隔 90 秒记录基本的运行状况参数。 验证 SAP 服务器是否位于单独的 AD 容器中，并且该容器是否具有应用了防火墙配置的组策略。
  • 检查首席 OS/DB 迁移顾问是否已获得许可！ 请求顾问姓名、s-user 和认证日期。 向 BC-INS-MIG 发送 OSS 消息，并请求 SAP 确认顾问是当前顾问并已获得许可。
  • 在可能的情况下，在一个物理位置建立与 VLDB 迁移项目关联的整个项目团队，而不要使他们分散在多个洲和时区。
  • 确保有一个适当的回退计划，并且该计划是整体日程安排的一部分。
  • 为 R3load 导出服务器选择快速线程计数 Intel CPU 型号。 不要使用“节能型”CPU 型号，因为它们的性能较低；不要使用 4 插槽服务器。 Intel Xeon E5 Platinum 8158 就是一个很好的例子。

避免问题的最佳做法

  • 不要将导出和导入工作分包给两家不同的顾问组织。 有时，源系统外包给一家顾问组织或合作伙伴并由其管理，但客户希望迁移到 Azure 并改用另一家合作伙伴。 由于导出和导入优化与配置之间的紧密耦合，将这些任务分配给不同的组织不太可能会产生良好的结果。
  • 在迁移和上线期间不要吝啬 Azure 硬件资源的费用。 Azure 虚拟机按分钟收费，其大小可以轻松缩小。 在 VLDB 迁移期间，使用最强大的可用虚拟机。 客户已在大小超出 200-250% 的系统上成功上线，然后在运行超大系统时稳定下来。 监视系统利用率 4-6 周后，容量过大的虚拟机会减小大小或关闭，以降低成本。