Azure SQL -使用Geo-replication在未指定的状态和查询存储中进行自动调优已达到其容量限制

Question

我有一个主数据库和一个二次地理复制数据库。在主服务器上，服务器自动调优是打开的。

在副本上，当我尝试做同样的事情时，我会遇到以下问题。

数据库正在从服务器继承设置，但服务器处于未指定状态。请指定服务器上的自动调优状态。

和

自动推荐管理是禁用的，因为Query已经达到其容量限制，并且没有收集新的数据。了解有关维护查询存储的保留策略的更多信息，以便收集新的数据。

但是，在服务器上，调优选项是on，所以我不理解“未指定的状态”。此外，我为什么要查看在SSMS中的两个数据库属性中设置的Query -它们与10 9MB中可用的9MB空间完全相同。

注意:这两个数据库都是在5个DTU基本定价计划上建立的。

更新

当主数据库查询存储操作模式是读写的时候，副本是只读的。看来我无法更改它(我无法从SSMS中的db属性对话框中更改)。

很公平，但同样的查询怎么能在主查询上比副本快10倍。优化不是被复制成累赘吗？

更新2

实际上，Query在SSMS上是可以查看的，我可以看到它们在两个db中都是相同的。我认为我观察到的反应时间的差异是没有关系的。

更新3

我把@vCillusion错觉的帖子标记为答案，因为他/她值得信任。然而，对于实际的问题，它太详细了。

我的副本是只读的，因此不能自动调优，因为这需要在查询存储中写入。Azure无法将任何数据收集到只读查询存储中，这会导致有关查询存储达到其容量的误导(错误)错误消息。

Answer 1

只有在查询存储处于只读模式时，我们才会收到此消息。重复检查查询存储配置。根据MSDN，您可能需要考虑以下几点：

1. 要恢复查询存储，请显式设置读-写模式并重新检查实际状态。 从QUERY_STORE中选择actual_state_desc、desired_state_desc、current_storage_size_mb、max_storage_size_mb、readonly_reason、interval_length_minutes、stale_query_threshold_days、size_based_cleanup_mode_desc、query_capture_mode_desc；
2. 如果问题仍然存在，则表示查询存储数据损坏，并继续在磁盘上运行。我们可以通过在受影响的数据库中执行sp_query_store_consistency_check存储过程来恢复查询存储。
3. 如果这没有帮助，您可以尝试在请求读写模式之前清除查询存储。 从QUERY_STORE中选择actual_state_desc、desired_state_desc、current_storage_size_mb、max_storage_size_mb、readonly_reason、interval_length_minutes、stale_query_threshold_days、size_based_cleanup_mode_desc、query_capture_mode_desc；

如果您检查了它，并且它处于读-写模式，那么我们可能在这里处理一些bug。请就此向微软提供反馈。

查询存储中的附加限制点：

此外，还引入了功能来监视性能，并且还在不断发展。它有一些已知的限制。

到目前为止，它并不适用于只读数据库(包括只读AG副本)。由于可读的辅助副本是只读的，所以这些辅助副本上的查询存储也是只读的。这意味着那些副本上执行的查询的运行时统计信息不会被记录到查询存储中。

1. 检查数据库不是只读的。
2. 查询存储不适用于系统数据库，如主数据库或tempdb。
3. 检查主文件组是否有足够的内存，因为数据仅存储在主文件组中

Answer 2

支持的场景是，只需要在主服务器上启用自动调优。自动在主目录上创建的索引将自动复制到辅助目录中。此过程通常需要主进程和辅助进程之间的同步时间。此时，不可能以与主版本不同的方式对二级只读副本进行不同的调整。查询存储错误消息是由于上面所述的只读状态造成的，应该不予理会。您的二级副本的性能问题很可能需要通过其他一些原因来探讨。