1. 介绍 SQL Server 原木运输
1.1什么是 SQL Server 原木运输？
SQL Server 日志传送是一种自动化灾难恢复解决方案，它维护生产数据库的热备用副本。该技术将主服务器实例上的主数据库的事务日志备份传输到一个或多个位于不同辅助服务器实例上的辅助数据库，确保辅助数据库与主数据库保持同步，从而防止数据丢失和服务器故障。
1.2 原木运输的目的和益处
日志传送在数据库管理中发挥着多种关键作用：
- 它的主要作用是灾难恢复，提供可靠的故障转移。 tar当您的主服务器因硬件故障、软件损坏或影响数据中心的灾难性事件而无法使用时，您将收到此消息。
- 它也是acost-有效的 高可用性解决方案与需要昂贵许可的企业级功能不同，日志传送可以与……配合使用 SQL Server 标准版，使预算有限的组织也能负担得起。
- 备用模式下的辅助数据库除了用于灾难恢复外，还能提供其他价值。数据库管理员可以利用它们进行只读报表生成，并将查询工作负载从生产服务器卸载。
- 延迟恢复功能可防止意外的数据修改。通过配置恢复延迟，您可以创建一个时间窗口，以便在用户错误操作造成破坏性更改影响到辅助数据库之前进行恢复。
2. SQL Server 原木运输组件和工作流程
原木运输包括以下几个部分：
- 主服务器和主数据库：主服务器代表您的生产环境 SQL Server 运行主数据库的实例。
- 备份共享：用于存储和传输事务日志备份的中间位置，备份内容从主服务器传输到辅助服务器。
- 辅助服务器和辅助数据库：辅助服务器ost 主数据库的热备用副本。
- 监控服务器（可选）：此服务器跟踪整个日志传送拓扑中所有备份、复制和恢复操作的历史记录和状态。
- 代理作业：包括备份、复制、恢复和警报作业，实现整个日志传送过程的自动化。
自动化工作流程如下：
- 备份作业在主服务器上运行，并在备份共享上创建主数据库的事务日志备份。
- 复制作业在每个辅助服务器上运行，并将日志备份文件从备份共享传输到辅助服务器。
- 恢复作业在每个辅助服务器上运行，并将复制的事务日志备份应用到辅助数据库。
- 警报作业在监控服务器上运行，检查备份和恢复操作是否在可接受的时间范围内完成。
3. 先决条件和要求
3.1 SQL Server 版本要求
自 SQL Server 2000 年及之后的所有版本均继续提供支持 SQL Server 2005 年至 2025 年。这种长期的支持表明了该技术的稳定性和持续相关性。
3.2 SQL Server 版本要求
日志传送功能适用于标准版、工作组版、企业版和开发人员版。 SQL Server这种广泛的版本支持使得没有企业版许可证的组织也能使用日志传送功能，这与某些功能不同，例如： Always On 可用性组 需要企业版或评估版。
注意：Express Edition 不支持日志传送。
3.3 数据库恢复模型要求
日志传送要求主数据库使用完整恢复模式或大容量日志恢复模式。不支持简单恢复模式，因为…… SQL Server 自动截断事务日志，破坏日志传送所需的连续日志链。
有关恢复模式的更多详细信息，请参阅我们的 综合指南 SQL Server 备份.
4. 使用 SSMS 配置日志传送
在配置日志传送之前，请准备好备份共享文件夹，用于存储和传输事务日志备份。
- 在主服务器或专用文件服务器上，创建一个文件夹（例如， C:\备份)
- 右键单击该文件夹并选择 物业
- 点击 共享 标签
- 点击 高级共享
- 确保 共享该文件夹
- 点击 权限 并授予 完全控制 允许 SQL Server 服务帐号 NT 服务\MSSQLSERVER。
- 点击 OK 申请。
- 记录网络路径（UNC）（例如， \\服务器名称\备份)
4.2 启用和配置日志传送
- 右键单击主数据库并选择 物业.
- 在 数据库属性 对话框中，选择 交易日志传送 左侧面板中的页面。
- 确保 在日志传送配置中将其启用为主数据库 启用日志传输。
- 然后您可以在此属性页面配置备份设置、辅助服务器和监控服务器。我们将在以下小节中介绍它们。
4.2.1 配置备份设置
- 点击 备份设置 按键
- 在 事务日志备份设置 对话，在 备份文件夹的网络路径 在字段中，输入 UNC 路径（例如， \\服务器名称\备份)
- 如果备份文件夹位于主服务器上，请输入本地路径（例如， C:\备份)
- 配置其他设置，例如备份保留期、警报阈值、备份作业和压缩。
- 点击 OK 确认设置并关闭对话框。
4.2.2 配置辅助服务器实例和数据库
- 点击 添加 下 辅助服务器实例和数据库
- 在 辅助数据库设置 对话框中，单击 互动 连接到辅助服务器实例。
- 在 二级数据库 从下拉菜单中选择现有数据库或输入新的数据库名称
- 在 初始化辅助数据库 标签，选择 是的，生成主数据库的完整备份，并将其还原到辅助数据库（如果辅助数据库不存在，则创建它）。
- 点击 复制文件 标签
- 在 复制文件的目标文件夹（此文件夹通常位于辅助服务器上）输入辅助服务器上目标文件夹的本地路径。
- 确保文件夹存在。 SQL Server 服务帐户具有写入权限
- 点击 OK 确认设置并关闭对话框。
4.2.3 配置监控服务器
- 确保 使用监控服务器实例
- 点击 个人设置
- 点击 互动 连接到监控服务器实例
- 米 删除历史记录后 以小时为单位指定保留期限
- 点击 OK 确认设置并关闭对话框。
4.2.4 检查和完成配置
- 检查所有设置。 交易日志传送 页
- 验证备份设置、辅助服务器配置和监控设置
- 点击 OK 应用配置
- 该向导会在主服务器、辅助服务器和监控服务器上创建所有必要的作业。
- 点击 关闭 配置完成后
5. 原木运输的优缺点
5.1的好处 SQL Server 原木运输
- Cost-有效的解决方案： 平台合作 SQL Server 标准版无需昂贵的企业版许可，使预算有限的组织也能获得可靠的灾难恢复能力。
- 配置和维护简便： 配置向导通过清晰的选项引导管理员完成设置。ost 无需专门培训，即可在 15-30 分钟内配置数据库。
- 支持多个辅助服务器： 支持多个辅助服务器，不受架构限制。可以部署一个辅助服务器用于本地灾难恢复，一个用于远程恢复，第三个用于生成报告。
- 对主服务器的影响极小： 异步运行，消除了主服务器上的同步开销。事务提交时间不受影响。
- 使用现有事务日志备份： 日志传送备份是标准的事务日志备份，可用于与日志传送无关的时间点恢复。
- 延迟恢复选项： 恢复延迟功能可防止意外的数据修改，而其他功能则不具备此功能。 实时复制解决方案.
- 无需共享存储： 每台服务器使用独立存储，无需共享存储，也无需相关的成本控制。osts.
- 跨平台支持： 在 Windows 和 Linux 系统上都能完美运行 SQL Server 部署。
- 跨领域适用： 不需要域信任关系或 Active Directory 集成。
5.2 原木运输的缺点和局限性
- 无自动故障转移： 主要限制在于需要手动进行故障转移。管理员必须执行多个步骤才能恢复服务。
- 数据同步延迟： 辅助数据库的备份和恢复频率总是落后于主数据库。
- 仅限数据库级配置： 在数据库级别而非实例级别进行配置。保护 50 个数据库需要 50 套独立的配置。
- 手动更改连接字符串： 故障转移后，应用程序必须更新连接字符串，使其指向备用服务器。
- 辅助数据库中断： 备用模式下的辅助数据库会在恢复操作期间断开用户连接。
- 独立数据库管理： 每个数据库配置都必须单独管理，没有协调管理能力。
6. 最佳实践和用例
6.1 何时使用原声运输
- 低成本灾后恢复： 擅长担任助理ost- 为无法承担企业版许可费用的组织提供有效的灾难恢复解决方案osts.
- 适中的RPO/RTO要求： 能够容忍 15-30 分钟数据丢失和 30-60 分钟停机时间的应用与它的功能完美契合。
- 只读报表服务器： 为能够容忍周期性断开连接的报表工作负载创建只读副本。
- 标准版环境： 组织标准化 SQL Server 标准版无法访问 Always On 可用性组，因此日志传送是目前最好的选择。
- 服务器迁移项目： 通过在过渡期间保持同步副本，促进服务器迁移。
- 延迟数据需求： 配置恢复延迟，以便将数据库保留在过去的固定时间点，以满足合规性或审计要求。
6.2 何时不应使用原木运输
- 近乎零停机时间要求： RTO 要求低于 15 分钟的应用不能依赖手动故障转移。
- 需要自动故障转移： 当业务需求要求无需管理员干预即可自动故障转移时，此方法不适用。
- 需要实时同步： 需要从辅助服务器获取实时或近实时数据的应用程序无法接受日志传送固有的延迟。
- 最小数据丢失容忍度： 对于以秒为单位衡量恢复点目标 (RPO) 或要求零数据丢失的组织而言，需要同步解决方案。
6.3个最佳实践
- 备份频率优化： 平衡备份频率、系统开销和恢复目标。tar以 15 分钟为间隔进行测试，并根据实际需要进行调整。
- 网络路径考虑因素： 备份位置应使用 UNC 路径而非映射驱动器。备份共享文件夹应放置在可靠的网络基础设施上。
- 监控和警报设置： 日志传送设置完成后，立即配置备份、复制和恢复作业失败的警报。
- 定期测试安排： 安排每季度或每半年一次的故障转移测试，以验证流程并保持管理员的准备状态。
- 文档维护： 维护详细的运行手册，记录配置详情、故障转移程序和故障排除步骤。
- 安全注意事项： 使用权限要求最低的专用服务帐户。适当限制网络共享权限。
- 磁盘空间管理： 持续监控备份位置的磁盘空间。配置当空间低于 20% 时发出警报。
- 保留策略配置： 设置备份保留期限，使其长于您可接受的最大同步延迟。
- 恢复延迟保护： 当防止意外修改的保护措施需要增加同步延迟时，可以配置恢复延迟。
7. 解决常见问题
7.1 备份作业失败
- 磁盘空间不足： 检查作业历史记录是否存在磁盘空间错误。通过删除旧备份或启用压缩来验证可用空间和剩余空间。
- 权限问题： 验证 SQL Server 服务帐户对本地文件夹和网络共享都具有完全控制权限。
- 数据库未完全恢复： 切换回完整恢复模式并进行完整备份。tar在事务日志链中。
7.2 复制作业失败
- 网络路径不可访问： 通过手动映射网络路径，测试从辅助服务器的连接性。
- 身份验证问题： 如果服务器位于不同的域中，请为网络共享访问配置明确的凭据。
- 文件锁定问题： 将备份文件夹从杀毒软件的实时扫描中排除，以防止文件被锁定。
7.3 恢复作业失败
- 缺少备份文件： 确认目标文件夹中是否存在文件，并检查复制作业历史记录。
- 恢复序列错误： 找出缺失的事务日志备份，并按顺序恢复它们以修复日志链。
- 数据库状态错误： 如果有人恢复了数据库，则使用 NORECOVERY 恢复完整备份来重新初始化日志传送。
- 数据库文件损坏： 如果即使操作顺序和配置正确，恢复失败的情况仍然存在，则可能是数据库文件本身已损坏。在这种情况下，您可能需要使用专门的恢复工具。 SQL恢复工具 在尝试重新初始化日志传送之前，从损坏的 .MDF 和 .NDF 文件中提取数据。
7.4 同步延迟问题
- 网络带宽限制： 启用备份压缩功能，以减小文件大小和带宽需求。
- 高交易量： 考虑提高备份频率，以创建更小、更易于管理的备份文件。
- 恢复频率不足： 提高恢复作业频率，使其接近备份频率，并最大限度地减少延迟。
7.5 监控服务器连接问题 (SQL 2025)
- OLE DB 提供程序错误： SQL Server 2025 年的默认强制加密与缺乏正确加密配置的旧版本存在冲突。
- 加密配置不匹配： 在监控服务器上验证链接服务器配置并检查加密设置。
- 解决方法： 删除并使用 TLS 1.3 参数重新创建日志传送，或将所有实例升级到 TLS 1.3。 SQL Server 2025.
7.6 SQL Server 代理服务问题
- 服务未提供tar泰德： 检查代理服务状态并将其配置为 start 自动。
- 工作安排已禁用： 检查作业计划状态并启用已禁用的计划。
- 作业步骤失败： 查看工作历史记录，找出失败的步骤和具体的错误信息。
8. 常见问题 (FAQ)
问：Express Edition 可以使用日志传送吗？
答：不， SQL Server Express Edition 不支持日志传送，因为它缺少相关功能。 SQL Server 代理。
问：日志备份应该多久安排一次？
答：默认的15分钟间隔时间较为合理。您可以根据自己的恢复目标进行调整。
问：辅助数据库可以用于生成报告吗？
答：是的，配置为备用模式的辅助数据库允许在恢复操作之间进行只读访问。
问：如果主服务器发生故障会发生什么情况？
答：执行手动故障转移，使备用数据库上线。数据丢失量等于故障发生时的同步延迟。
问：我可以拥有多个辅助服务器吗？
答：是的，日志传送支持无限数量的独立配置的辅助服务器。
问：如何计算同步延迟？
A：使用日志传送监控表，将上次恢复的事务日志时间戳与当前时间进行比较。
问：日志传输可以跨域工作吗？
答：是的，它可以在不同的领域或工作组环境中运行，而无需建立信任关系。
问：无恢复模式和待机模式有什么区别？
答：无恢复模式会使数据库无法访问。备用模式允许在两次恢复之间执行只读查询。
问：我可以暂停日志发货节奏吗？rar我爱你吗？
A：是的，禁用备份、复制和恢复作业以暂停同步，同时保留配置。
问：如何移除日志传送配置？
答：在 交易日志传送 属性页：
- 取消选中 在日志传送配置中将其启用为主数据库
- 点击 OK 移除配置并删除作业。
问：我可以将辅助数据库切换到读写模式吗？
答：是的，执行 RESTORE DATABASE WITH RECOVERY，但这会破坏日志传送链。
问：我可以配置的最大恢复延迟是多少？
答：没有硬性限制。您可以根据自身防护需求，配置从几分钟到几天不等的延迟时间。
问：日志传送如何影响备份策略？
答：它创建事务日志备份，可用于日志传送和时间点恢复。
问：我可以使用日志传送进行服务器迁移吗？
答：是的，配置日志传送到新服务器，进行同步，然后在维护期间执行旧服务器的计划内故障转移。
问：哪些监控工具可以与日志传输配合使用？
A: SQL Server Management Studio 内置了报表功能。SQL Monitor 和 SolarWinds 等第三方工具可提供更强大的监控功能。
9 结论与建议
9.1 要点总结
SQL Server 原木运输提供可靠的，ost通过自动化事务日志备份和恢复操作实现高效的灾难恢复。该技术与标准版兼容，所需基础设施极少，并支持多个辅助服务器。
日志传送适用于恢复目标适中且可以接受手动故障转移的情况。其主要局限性包括需要手动故障转移、同步延迟以及数据库级配置范围。
该技术与现有的备份策略完美融合，支持通过待机模式进行只读报告，并提供延迟恢复保护以防止意外更改。
9.2 为您的环境做出正确的选择
在实施原木运输方案之前，请根据您的具体需求进行评估。考虑恢复点目标、恢复时间目标、预算限制和操作复杂度容忍度。
组织使用 SQL Server 对于恢复要求适中的标准版，强烈建议考虑日志传送。而对于恢复时间目标 (RTO) 严格低于 15 分钟的企业，则应评估 Always On 可用性组。
考虑采用混合方法，将原木运输与其他技术相结合，以实现cost 在满足各种需求的同时进行优化。
9.3 后续步骤和其他资源
首先进行小规模试点实施以积累经验。制定全面的文档，包括配置详情、故障转移程序和故障排除指南。
定期安排故障转移测试，以验证流程并确保管理员随时准备就绪。保持与时俱进。 SQL Server 更新和改进。
案例
- 微软官方文档： 关于原木运输（SQL Server)
- 微软官方文档： 配置日志传送（SQL Server)
关于作者
袁盛 是一位高级数据库管理员 (DBA)，拥有超过 10 年的 SQL Server 环境和企业数据库管理。他成功解决了金融服务、医疗保健和制造等行业的数百个数据库恢复场景。
袁专长于 SQL Server 数据库恢复、高可用性解决方案和性能优化。他拥有丰富的实践经验，包括管理多TB数据库、实施Always On可用性组以及为关键业务系统开发自动备份和恢复策略。
通过他的技术专长和实践方法，袁致力于创建全面的指南，帮助数据库管理员和 IT 专业人员解决复杂的 SQL Server 高效应对挑战。他始终掌握最新 SQL Server 版本和微软不断发展的数据库技术，定期测试恢复场景以确保他的建议反映现实世界的最佳实践。
有关于的问题 SQL Server 恢复或需要额外的数据库故障排除指导？袁欢迎 反馈和建议 用于改进这些技术资源。