SQL 数据库维护

此信息仅作为指南提供。建议您遵守行业标准最佳实践并向经验丰富的数据库管理员寻求建议。这些信息的使用应考虑到对整体环境的广泛影响。

需要维护以下数据库：

  • InteractDB

  • InteractCacheDB

  • IadaDB

  • AuthenticationServerDB

  • HubDB

  • AuditDB

  • NotificationCenterDB

  • LicenceManagerDB

  • FileServiceDB

  • EmailServiceDB

  • BluePrismDecisionDB

  • ImsDB

  • FileServiceDB

    • CacheDB 已替换为 Hub 4.4 的 FileServiceDB。

数据库维护的常规建议

建议您：

  • 为所有数据库正确设置自动增长。数据文件的推荐值为 1024 MB，事务日志的推荐值为 2048 MB。
  • 随着数据库规模的增加，重新建立自动增长值，以便将自动增长事件的频率更小化。

    • 不要使用 % 文件增长，而是使用固定量的 MB 增长。

  • 删除任何过多的事务日志文件碎片。有关详情，请参阅 Microsoft 在线帮助。
  • 打开即时文件初始化。有关详情，请参阅 Microsoft 在线帮助。
  • 关闭自动收缩操作，设置所有数据库的页面验证进行校验，然后打开 AUTO_CREATE_STATISTICS 和 AUTO_UPDATE_STATISTICS。制定能够更新统计数据的常规流程。

    • 您可以为 Hub 和 Interact 为此安装的各数据库设置以下 T-SQL：

    ALTER DATABASE [DatabaseNameHere] SET AUTO_CLOSE OFF；

    ALTER DATABASE [DatabaseNameHere] SET AUTO_SHRINK OFF；

    ALTER DATABASE [DatabaseNameHere] SET AUTO_UPDATE_STATISTICS ON；

    ALTER DATABASE [DatabaseNameHere] SET AUTO_CREATE_STATISTICS ON；

    ALTER DATABASE [DatabaseNameHere] SET PAGE_VERIFY CHECKSUM；

  • 制定运行 DBCC CHECKDB 的常规流程—建议在低系统利用率和无系统利用率时每天至少运行一次 SQL 代理作业。应检查结果是否存在损坏。其有助于创建 SQL 代理警报，向操作人员组通知以下错误；

    • 823—硬 I/O 损坏

    • 824—软 I/O 损坏

    • 825—读取/重试损坏

    • 9100—索引损坏

    • 严重性 19-25 错误

  • 优化临时工作负载 = 开

  • 备份压缩默认 = 开

  • 备份校验默认 = 开

  • 并行成本阈值—50 是良好的起始点。

  • 并行度上限—取决于 SQL Server 的 NUMA 配置，但又不超过单个 NUMA 节点的核数。

  • 设置自动关闭 = 开

  • 服务器内存下限—SQL Server 各有不同，应进行设置。

  • 服务器内存上限—SQL Server 各有不同，应进行设置。

磁盘布局建议

建议为数据及事务日志文件、临时数据库和备份使用单独的驱动器。

创建维护计划

确保您有定期备份的维护计划。使用贵组织的首选维护计划备份 SQL 数据库。如果您的组织没有维护计划，建议您研究行业最佳实践，并选择符合贵组织所需的维护计划。

进行备份

备份应根据贵组织的恢复点 (RPO) 和恢复时间 (RTO) 目标进行设计。

  • RPO—故障后可以恢复数据的时间点。这能够决定丢失的数据量。
  • RTO—故障后恢复数据所需的时间。这能够决定平台不可用的时间长度。

在为 Blue Prism 数据库创建备份和恢复计划时，必须考虑并实施以下几点：

  • 定义 RPO 和 RTO。
  • 使用 FULL 恢复模型，允许全部、差别和事务日志备份与您的 RPO 和 RTO 保持一致。
  • 请在所有备份中使用 WITH CHECKSUM 和 VERIFYONLY 选项，验证备份是否有效，是否可在必要时恢复。
  • 使用 WITH COMPRESSION 选项可节省磁盘空间并减少备份数据库和选择恢复数据库所需的时间。
  • 记录备份和恢复流程。
  • 通过定期尝试恢复，检查您的备份是否可靠。

执行备份的频率取决于您的组织规模以及数据风险的数量和价值。

建议在绝对宕机期间执行完整备份。执行增量备份时，无需停止任何服务，否则可能会丢失某些数据。

解析索引碎片

随着时间的推移，数据库索引碎片会降低查询性能。为防止出现这种情况，请尽可能频繁地按照数据库宕机时间来重建索引。还建议在进行备份和/或删除大量数据后重建索引。此外，建议您先重新生成索引，然后进行完整数据库备份，以便在必须恢复完整备份的情况下，将索引碎片更小化。

重建/重组索引维护的建议阈值为：< 30% 重组和 > 30% 重建。

重建数据库索引可以安排在数据库服务器内作为作业运行，并且/或者可以添加到数据库维护计划中。建议您在系统活动量较低时运行它们，并计划避免其与备份和 DBCC CHECKDB 维护重叠。