标签: log-shipping

问题定义

我们的数据库服务器需要转移到另一个数据中心。它运行在 Microsoft SQL Server 2012 Enterprise（64 位）上，包含两个大约 2TB 和 1TB 的数据库。

几乎没有停机时间将是理想的。

工作量

这些数据库用于 .NET 网站，并且会不断更新。

不过，周末不可用也是可以接受的。当前使用的数据库将一直是唯一使用的数据库，直到切换到新数据库。

理想情况下，只需将 DNS 条目更改为指向新的数据库服务器，同时确保数据库未更新，即可实现该切换。

此外，只要从一台服务器切换到另一台服务器（停机时间）保持在较低水平，此操作所花费的时间并不重要。

考虑的方法

• 备份还原

  过去曾这样做过，但即使是通过内部网络完成的，停机时间也很长，因此比通过 Internet更有效

• 日志传送

  据我所知，这种方法可以通过配置主/从并将主数据库的精确副本传输到其只读从属来最大限度地减少停机时间。如上所述，不需要访问从属数据库，我们只需要一种方法来拥有主数据库的副本而不会损坏数据。

  它在资源利用方面似乎也非常有效，并且不会对主性能产生太大影响。

  我可能对这种方法有误，因此请随时纠正我。

• 数据库镜像

  我不太了解这种方法，但它似乎是一个有效的选择。不需要实时同步，主节点的性能非常重要，因此如果选择这种方法，异步将是可行的方法。

• 其他选择？

  该服务器直接在裸机硬件上运行，因此不幸的是，不能选择较低级别的解决方案。也许有更好的方法来完成这项工作？

约束

如上所述，这些数据库非常大，以至于难以维护，但这是另一个问题。

SQL Server 的版本将相同（Microsoft SQL Server 2012 Enterprise 64 位）。

它必须在两个数据中心之间通过网络传输，因此很可能通过 Internet 传输。不幸的是，将磁盘从一个站点发送到另一个站点进行初始同步并不是一种选择。为转移提供某种安全性是理想的，但我们会在这种情况下做到最好。

这应该很好地概述了我们对这项任务的需求，希望你们中的一些人以前不得不面对这种情况。

我正在使用 SQL Server 2008 R2 运行日志传送。

我遇到了辅助数据库驱动器空间不足且未应用日志传送事务日志的情况。

我想解决这个问题的方法是删除辅助数据库并从头开始配置日志传送。

我现在遇到的问题是我的辅助数据库处于恢复状态，我无法删除它们。我该如何继续？

例如，如果我尝试让它们离线，我会收到错误消息，

ALTER DATABASE is not permitted while the database is in the Restoring state.

我们正在使用日志传送并RESTORE WITH STANDBY在 SQL Server 2012 上以只读模式恢复数据库以用于报告目的。但是，在完成一两个日志备份的还原后，日志传送设置不断中断。日志传送仅在运行时中断RESTORE WITH STANDBY；RESTORE WITH NORECOVERY不会造成任何问题。

我对此的唯一直觉是主数据库不是那么动态。因此，当没有交易时，这可能会导致RESTORE流程出现问题？

任何想法，已知的修复？

通过运行在两个表上进行大量更新的常规作业，我让它工作了几天。当作业停止运行时，日志传送设置很快失败，无法处理 .trn 文件。我重置了日志传送，并试图通过只做一个小的更新来查看它是否会继续运行，更改表中一个记录的一列的值，无论它仍然失败。

感谢您的所有回复。

PS：摘自我们的日志

02/25/2013 13:00:00,LSRestore_DBDB01-A_BulldogDB,进行中,1,DBREPORTS,LSRestore_DBDB01-A_BulldogDB,日志传送恢复日志作业步骤.,2013-02-25 13:00:12:31无法将日志备份文件“\\dbsan01\DBBackups\LSBackup_BulldogDB\BulldogDB_20130225180000.trn”应用到辅助数据库“BulldogDB”。（Microsoft.SqlServer.Management.LogShipping）***
2013-02-25 13:00:12.31 *** 错误：处理数据库“BulldogDB”的日志时出错。如果可能，从备份中恢复。如果备份不可用，则可能需要重建日志。
恢复期间发生错误，导致数据库“BulldogDB”(8:0) 无法重新启动。诊断恢复错误并修复它们或从已知良好的备份恢复。如果未纠正或预期错误，请联系技术支持。
RESTORE LOG 异常终止。
为文件 1 上的数据库“BulldogDB”文件“BulldogDB”处理了 0 页。
为文件 1.(.Net SqlClient 数据提供程序) 上的数据库 'BulldogDB' 文件 'BulldogDB_log' 处理了 1 页 ***
2013-02-25 13:00:12.32 *** 错误：无法记录历史记录/错误消息。（Microsoft.SqlServer.Management.LogShipping）***
2013-02-25 13:00:12.32 *** 错误：ExecuteNonQuery 需要打开且可用的连接。连接的当前状态是关闭的。(System.Data) ***
2013-02-25 13:00:12.32 跳过辅助数据库“BulldogDB”的日志备份文件“\\dbsan01\DBBackups\LSBackup_BulldogDB\BulldogDB_20130225180000.trn”，因为无法验证该文件。
2013-02-25 13:00:12.32 *** 错误：无法记录历史记录/错误消息。（Microsoft.SqlServer.Management.LogShipping）***
2013-02-25 13:00:12.32 *** 错误：ExecuteNonQuery 需要打开且可用的连接。连接的当前状态是关闭的。(System.Data) ***
2013-02-25 13:00:12.33 …

我正在为两个数据库 db1 和 db2 创建日志传送。

它将从 SQL Server 2008 R2 升级到更新的版本 SQL Server 2012。

在 SQL Server 2008R2 上，它们都是dbi_version= 661：

DBCC TRACEON (3604);  
GO 
DBCC PAGE (db1, 1, 9, 3); 
GO 
DBCC TRACEOFF (3604); 

我在待机模式下恢复它们：

RESTORE DATABASE db1 FROM DISK = 'Q:\db1.bak' WITH STANDBY = N'R:\SQLLog\db1.undo'

其中一个恢复正常，升级，另一个给我错误：

由于需要升级数据库，因此无法使用 WITH STANDBY 恢复此备份。在没有 WITH STANDBY 的情况下重新发出 RESTORE。

我是一家没有 DBA 的小商店的开发人员，我正在尝试使用 sql server 2012 进行日志传送。我正在尝试将报告从事务系统卸载到新的数据仓库，并将使用此数据库作为暂存区。

我运行了日志传送向导，每次都可以运行主备份和文件复制作业。辅助还原作业似乎随机失败。

主服务器只有一个事务日志作业。差异备份被禁用（不确定这是否重要）但有完整备份。

辅助服务器是全新安装，没有维护计划、备份或活动用户。

有没有办法强制备份恢复同步，或者始终确保它保持同步？

它只是看起来很脆弱。请指教。

编辑日志如下：

*Starting transaction log copy. 
Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7'
Retrieving copy settings. 
Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7'
Retrieved copy settings. 
Primary Server: '', 
Primary Database: 'db', Backup Source Directory: '\\server\folder', 
Backup Destination Directory: '\\server\folder', 
Last Copied File: '\\server\folder\db_20160105070002.trn'
Starting transaction log restore. 
Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7'
Retrieving restore settings. 
Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7'
Copying log backup files. 
Primary Server: 'server', Primary Database: 'db', 
Backup Source Directory: '\\server\folder', 
Backup Destination Directory: '\\server\folder'
Retrieved common …

这是关于内部部署的常规 SQL Server 2014 标准版。

这与 SQL Azure 无关。本次对话中唯一的 Azure 部分是 Azure 博客存储，作为某些位（SQL 备份和日志）的传输

设想：

主 SQL Server 位于数据中心 1。

备份位于数据中心 2。

在 SQL 2014 中，是否可以使用“备份到 url/azure blob 存储”作为日志传送管道？

我们喜欢将 db 和日志备份到 azure blob 存储的想法。出色、简单、自动的异地备份存储。

使用相同的管道将日志传送到备份数据库服务器会很棒。

可行吗？

（注意：两台服务器都不是域的成员。这是两台独立的服务器，彼此之间没有 AD 或其他关系。）

我目前正在设置大型数据库（约 1.5TB）的日志传送，并且想知道我可以对日志文件做些什么。

就目前而言，我想做以下步骤：

1. 将数据库更改为完全恢复
2. 在主服务器上进行完整备份（5-6 小时）
3. 将完整备份还原到次要备份（留在 NORECOVERY 中）
4. 在主服务器上进行 DIFF 备份
5. 将 DIFF 备份还原到辅助（仍在 NORECOVERY 中）
6. 使用“数据库已初始化”初始化日志传送

问题是，当我进行完整备份时，日志文件填满的速度会比备份完成的速度快。

我有哪些选项可以防止日志文件填满？我是否可以在完整备份期间照常进行日志备份，因为 DIFF 还原将涵盖在该时间范围内发生的任何事务？有没有人用这种大小的数据库做过这件事，有什么提示/技巧可以让它更容易？

我的 SQL Server 2005 主服务器出现故障，所以我在辅助服务器上启动了日志传送数据库。数据库在辅助服务器上，我只需要删除它的日志传送设置，而主服务器不再可访问。

似乎sp_delete_log_shipping_secondary_database应该在辅助服务器上执行存储过程来执行此操作，它“删除辅助数据库并删除本地历史记录和远程历史记录”，正如msdn 上所述。

这也会删除数据库本身吗？还是只有它的日志传送设置？当主服务器不可访问时它会做什么？

我不能丢失辅助服务器上的数据库，因为它已经在使用中。

我们有一个相当简单的设置来从我们的本地主 PostgreSQL 数据库复制到我们在 AWS 中的表示层。我们正在使用 WAL 运输archive_command设置。基本上设置如下所示：

    +-------------+
    |   Master    |
    +-------------+
     WAL  |     
segments  |              
         \|/                     +--------------+
    +-------------+   WAL      +-+------------+ |      
    |             |----------->| Hot Standby  | |
    |      S3     |  segments  |   Slaves     | |
    |             |            |              |-+
    +-------------+            +--------------+

这种设置似乎通常相当健壮，但我还没有想出一种检测故障的好方法，无论是主站未能向上推档案，还是从站或从站未能检索日志文件。什么是确定从站相对于主站是否是最新的好方法？确定 master 是否未能发送 WAL 文件的好方法是什么？

澄清一下，我们严格将奴隶用作只读副本，我们永远不会故障转移到它们。

我们已设置将日志传送到备用/只读的辅助 SQL 服务器，以卸载所有 SSRS 报告生成。
这在以下方面施加的限制内工作正常：

1. 在事务日志恢复期间踢出用户（我们通过设置多个实例并使用循环调度恢复最近的事务日志来解决这个问题）
2. 数据已过时，最多在预定事务日志备份/还原作业指示的时间范围内。

不幸的是，第一次运行任何/所有存储过程，在事务日志恢复后，它需要比正常情况更长的时间来完成。同一存储过程的所有后续执行都在预期时间内完成。如果我们然后执行另一个存储过程，第一次它很慢并且所有后续的执行都在预期的时间内完成。

作为参考，与第一次运行时的 ~01:00 相比，执行差异通常为 ~00:02。

我认为这与服务器执行统计或存储过程参数嗅探/存储执行计划有关。
有没有办法解决这个问题？或者这是事务日志还原所固有的？

如果这只是任何存储过程的第一次执行，我们可以通过在恢复时执行任何存储过程来轻松解决这个问题，但它似乎会影响所有存储过程的第一次执行。

我尝试count( * )在 11 个表上运行我用于测试接触的存储过程。第一次运行时间为 00:32，随后的 count(*) 时间为 00:00。不幸的是，这对存储过程的第一次运行没有任何影响。

is_temporary在执行存储过程之前或之后，我在主服务器或辅助服务器上都看不到任何统计结果。

我目前在SQL Server 2012中


查询Exection计划：
乍一看查询执行计划出现显著不同，但是，在保存的执行计划和打开.sqlplan文件生成它们是完全一样的。差异似乎来自我使用的不同版本的 SSMS，主服务器上的 2014 年和辅助服务器上的 2018 年。查看辅助节点上的执行计划时，它会在每个节点的百分比和 ### (##%) 的时间成本 ### 下方显示 - 这些数字和实际执行计划都不会在进一步执行时发生变化。
我还包括客户端统计数据，它们显示的几乎完全相同，唯一的区别是主服务器执行服务器回复的等待时间为 1.4 秒，而辅助服务器需要 81.3 秒。

正如您预测的那样，我确实从第一次执行中看到了大量 PAGEIOLATCH_SH 锁：

diff after first exec vs diff after second exec
waiting_tasks_count    10903    918  
wait_time_ms          411129  12768  

这种情况的一个奇怪之处是，除了设置的循环多实例部分之外，我们已经让我们的生产 SSRS 服务器从备用/只读数据库读取，该数据库由定期事务日志提供，并且没有经历这些在第一次执行存储过程时会减慢速度。但是，每次恢复事务日志时，我们的用户都会被启动，这是上述设置应该解决的问题。