3

我有一个主数据库和一个辅助地理复制数据库。在主服务器上，服务器自动调整已打开。

在复制品上，当我尝试做同样的事情时，我遇到了以下问题。

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

和

自动推荐管理被禁用，因为查询存储已达到其容量限制并且没有收集新数据。详细了解用于维护查询存储以便收集新数据的保留策略。

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

注意：两个数据库都是在 5 个 DTU 基本定价计划中设置的。

更新

主数据库查询存储操作模式为读写，副本为只读。看来我无法更改它（我无法从 SSMS 中数据库的属性对话框中更改）。

很公平，但是相同的查询如何在主数据库上比在副本上快 10 倍。优化不是复制过来的吗？

更新 2

实际上查询存储在 SSMS 上是可见的，我可以看到它们在两个数据库中是相同的。我认为我观察到的响应时间差异不相关。

更新 3

我将@vCillusion的帖子标记为答案，因为他/她值得称赞。但是，就实际问题而言，它太详细了。

我的副本是只读的，因此无法自动调整，因为这需要写入查询存储。Azure 无法将任何数据收集到只读查询存储中，从而导致有关查询存储达到其容量的误导性（和错误）错误消息。

4

2 回答 2

1

只有当查询存储处于只读模式时，我们才会收到此消息。仔细检查您的查询存储配置。根据MSDN，您可能需要考虑以下内容：

  1. 要恢复查询存储，请尝试显式设置读写模式并重新检查实际状态。

    ALTER DATABASE [QueryStoreDB]   
SET QUERY_STORE (OPERATION_MODE = READ_WRITE);    
GO  

SELECT 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  
FROM sys.database_query_store_options;

  2. 如果问题仍然存在，则表明查询存储数据已损坏，并在磁盘上继续存在。我们可以通过在受影响的数据库中执行sp_query_store_consistency_check存储过程来恢复查询存储。

  3. 如果这没有帮助，您可以在请求读写模式之前尝试清除查询存储。

    ALTER DATABASE [QueryStoreDB]   
SET QUERY_STORE CLEAR;  
GO  

ALTER DATABASE [QueryStoreDB]   
SET QUERY_STORE (OPERATION_MODE = READ_WRITE);    
GO  

SELECT 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  
FROM sys.database_query_store_options;

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

查询存储中的其他限制点：

此外，请注意 Query Store 功能被引入以监控性能，并且仍在不断发展。它有一些已知的限制。

截至目前，它不适用于只读数据库（包括只读 AG 副本）。由于可读的辅助副本是只读的，因此这些辅助副本上的查询存储也是只读的。这意味着在这些副本上执行的查询的运行时统计信息不会记录到查询存储中。

  1. 检查数据库不是只读的。
  2. 查询存储不适用于 master 或 tempdb 等系统数据库
  3. 检查主文件组是否有足够的内存，因为数据仅存储在主文件组中
于 2018-06-07T15:34:49.277 回答
0

支持的场景是只需要在主服务器上启用自动调整。在主节点上自动创建的索引将自动复制到辅助节点。此过程占用主要和次要之间通常的同步时间。目前，不可能对辅助只读副本进行与主副本不同的性能调整。查询存储错误消息是由于其如上所述的只读状态，应忽略。次要副本的性能问题很可能需要通过其他一些原因进行探索。

于 2019-01-17T10:57:45.047 回答