为什么 sys.fn_hadr_backup_is_preferred_replica 需要这么长时间？有没有更好的办法？

Question

我用来sys.fn_hadr_backup_is_preferred_replica查询每个可用性组副本上的数据库，以确定是否应该在该副本上备份数据库 - 然后，如果该函数返回 true，则检查msdb.dbo.backupset数据库最近是否已备份。

我遇到的问题是该函数需要很长时间才能运行（每个数据库大约 3 秒） - 谁能推荐一个更快的替代方案？

为了回应下面的评论，我目前使用的是 SQL 2012 SP1 (11.0.3000.0) - 但是，我正在创建的查询需要针对多个客户站点上 SQL Server 2012 的多个不同安装，因此，即使这个系统功能在后续的更新中得到了改进，遗憾的是我可能无法强迫人们更新。

Answer 1

我遇到的问题是该函数需要很长时间才能运行（每个数据库大约 3 秒）

这可能是越来越多的不支持谓词下推的动态管理对象之一，因此，随着任何给定副本上 AG 和/或 AG 数据库数量的增加，您可能会注意到更高的延迟。

正如 @Kin 在 Connect #783011 (RIP) 中指出的那样，这可能正是已修复的问题；遗憾的是，连接项并未指明您可以在哪里找到修复程序。

根据一些快速搜索（以及评论日期），我认为您至少需要2012 SP1 CU8，它（通过KB #2918791）修复了 2012 SP1 CU7 中引入的回归（通过KB #2887115）。

我在后来的版本中没有看到任何证据表明该函数在 2012 SP1 CU8 之后已被修改，并且修改可能与引入的回归有关。

但我非常支持使用最新的服务包分支：

• SP2是当前唯一支持的分支；RTM 和 SP1 已经退役，所以如果您仍在使用它们，那么是时候迁移了；
• 最新的 CU（当前为SP2 CU #8）；
• 如果您的应用程序使用连接池，您可能也会对这个按需修补程序感兴趣。

谁能推荐一个更快的替代方案？

如果您查看 的源代码sys.fn_hadr_backup_is_preferred_replica，您会发现存在一些复杂的逻辑和瀑布变量填充，如果您不使用镜像或日志传送，则可以通过编写自己的清理版本来短路它们。但随后您会调用禁止的系统函数RetrieveDbReplicaState()，例如您无法自己调用的系统函数，并且您意识到没有办法重写此函数并复制其完整功能

因此，最好的选择是应用 Microsoft 提供的任何修复程序来优化该功能。如果您在迁移到最新版本后仍然遇到缓慢的情况，您可以提交另一个 Connect 项目，或者您可以直接使用 CSS 提出案例（请注意，如果您的 AG 中有 10,000 个数据库，他们可能会告诉您停止这样做那）。