我正在 2008R2 服务器到 2012 分发服务器到 2012 订阅服务器的事务复制中设置。所有三台服务器都处于完整恢复模式。每 15 分钟进行一次日志备份,每天对用于复制的所有三台服务器数据库进行完整备份。我们想将订阅服务器用作报告服务器。发布服务器是我们的主要 OLTP 数据库。
如何在发布者的 t-log 空间因复制问题而变满之前收到警报。无论如何我都不希望发布者宕机。发布者每 15 分钟备份一次 t-log。这是否意味着在进行日志备份时,日志读取器主动读取的所有 VLF 都可以备份?我应该使用什么警报来告诉我发布者的日志空间已满?当发布者的日志空间变得危险地大时,是否有任何脚本也可以停止复制/日志读取器代理?
当复制导致问题并在我的发布者上建立日志时,我可以删除复制并重新建立(使用新快照)。但我不想等待这种情况发生(发布者上的日志空间已满),而只想在此之前采取行动 - 例如仅在日志空间达到一定百分比时才删除复制。我该怎么做?
另外,我应该采取什么策略来停止和删除复制?我将按照Microsoft 的文档 删除复制,但不清楚是否应该在删除复制之前先停止日志读取器代理和分发代理?
您可以使用以下脚本检查日志文件的大小是否超过某个阈值、是否超过 90%,并发送电子邮件通知。
您可以在 SQL Agent 中安排上述脚本每 15 分钟运行一次,以检查日志是否已满,并通过电子邮件通知您,以便您采取措施。
参考另一个答案——手动删除复制。
如何在我的发布者的 t-log 空间因复制问题而已满之前收到警报。
这取决于您的事务日志文件增长如何设置。
如果您已预先增大事务日志文件并限制文件大小,则需要监视日志文件的使用百分比并在合适的阈值处设置警报。您可以使用DBCC SQLPERF (Transact-SQL)监视所有数据库的日志空间使用情况。另一个解决方案是使用dbatools中的Get-DbaDbSpace。还有许多其他解决方案可用于执行相同操作。
如果允许文件增长,则必须监视驱动器(日志文件所在的位置)上的可用空间。同样,您可以使用 dbatools 命令Get-DbaDiskSpace或其他解决方案来设置警报。
当发布者上的日志空间变得过大而危险时,是否有任何脚本也可以停止复制/日志读取器代理?
在这种情况下,停止日志读取器不会对您有所帮助。除非日志读取器代理处理这些记录(将它们发送到分发数据库),否则不会截断事务日志。您可以按照在 SQL Server 中手动删除复制来删除复制。
另外,我应该采取什么策略来停止和删除复制?我将按照 Microsoft 的文档删除复制,但不清楚是否应该在删除复制之前先停止日志读取器代理和分发代理?
我在上一节中回答了这个问题。如果我只能访问订阅者,如何通过脚本永久删除复制?还有其他一些选项。
顺便说一句,根据报告要求,您是否考虑过将日志传送作为解决方案?