Azure SQL - 使用地理复制进行自动调整 - 处于未指定状态的服务器和查询存储已达到其容量限制
Azure SQL - Automatic Tuning with Geo-replication - Server in unspecified state and query store has reached its capacity limit
我有一个主数据库和一个辅助异地复制数据库。
在主服务器上，服务器自动调整已打开。
当我尝试执行相同操作时在副本上遇到以下问题。
The database is inheriting settings from the server, but the server is
in the unspecified state. Please specify the automatic tuning state on
the server.
和
Automated recommendation management is disabled because Query Store
has reached its capacity limit and is not collecting new data. Learn
more about the retention policies to maintain Query Store so new data
can be collected.
但是，在服务器上，调整选项是 on，所以我不明白 "unspecified state"。此外，为什么我查看在 SSMS 的两个数据库属性中设置的查询存储，它们完全相同，10MB 中有 9MB space 可用。
注意：两个数据库都是在 5 个 DTU 基本定价计划上设置的。
更新
虽然主数据库查询存储操作模式为读写，但副本为只读。看来我无法更改它（我无法从 SSMS 中数据库的属性对话框中更改）。
很公平，但同一个查询怎么可能在主服务器上比在副本服务器上快 10 倍。优化不是交叉复制的吗？
更新 2
实际上查询存储在 SSMS 上是可见的，我可以看到它们在两个数据库中是相同的。我认为我观察到的响应时间差异无关。
更新 3
我将 @vCillusion 的 post 标记为答案，因为 he/she 值得学分。但是，关于实际问题，它太详细了。
我的副本是只读的，因此无法自动调整，因为这需要写入查询存储。 Azure 无法将任何数据收集到只读查询存储中，导致有关查询存储达到其容量的误导性（错误）错误消息。
只有当查询存储处于只读模式时，我们才会收到此消息。仔细检查您的查询存储配置。
根据 MSDN，您可能需要考虑以下问题：
要恢复查询存储，请尝试明确设置读写模式并重新检查实际状态。
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;
如果问题仍然存在，则表示查询存储数据损坏并在磁盘上继续。我们可以通过在受影响的数据库中执行 sp_query_store_consistency_check 存储过程来恢复查询存储。
如果这没有帮助，您可以尝试在请求读写模式之前清除查询存储。
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;
If you checked it and it's in read-write mode, then we might be dealing with some bug here. Please provide feedback to Microsoft on this.
查询存储中的附加限制点：
另外，请注意查询存储功能的引入是为了监控性能，并且仍在不断发展。它有一些已知的限制。
As of now, it does not work on Read-Only databases (Including read-only AG replicas). Since readable secondary Replicas are read-only,
the query store on those secondary replicas is also read-only. This
means runtime statistics for queries executed on those replicas are
not recorded into the query store.
- 检查数据库不是只读的。
- 查询存储不适用于 master 或 tempdb 等系统数据库
- 检查主文件组是否有足够的内存，因为数据仅存储在主文件组中
支持的场景是只需要在主服务器上启用自动调整。在主数据库上自动创建的索引将自动复制到辅助数据库。此过程需要主要和次要之间通常的同步时间。目前不可能对次要只读副本进行与主要副本不同的性能调整。如上所述，查询存储错误消息是由于其只读状态所致，应予以忽略。您的辅助副本的性能问题很可能需要通过其他一些原因进行探讨。
我有一个主数据库和一个辅助异地复制数据库。 在主服务器上，服务器自动调整已打开。
当我尝试执行相同操作时在副本上遇到以下问题。
The database is inheriting settings from the server, but the server is in the unspecified state. Please specify the automatic tuning state on the server.
和
Automated recommendation management is disabled because Query Store has reached its capacity limit and is not collecting new data. Learn more about the retention policies to maintain Query Store so new data can be collected.
但是，在服务器上，调整选项是 on，所以我不明白 "unspecified state"。此外，为什么我查看在 SSMS 的两个数据库属性中设置的查询存储，它们完全相同，10MB 中有 9MB space 可用。
注意：两个数据库都是在 5 个 DTU 基本定价计划上设置的。
更新
虽然主数据库查询存储操作模式为读写，但副本为只读。看来我无法更改它（我无法从 SSMS 中数据库的属性对话框中更改）。
很公平，但同一个查询怎么可能在主服务器上比在副本服务器上快 10 倍。优化不是交叉复制的吗？
更新 2
实际上查询存储在 SSMS 上是可见的，我可以看到它们在两个数据库中是相同的。我认为我观察到的响应时间差异无关。
更新 3
我将 @vCillusion 的 post 标记为答案，因为 he/she 值得学分。但是，关于实际问题，它太详细了。
我的副本是只读的，因此无法自动调整，因为这需要写入查询存储。 Azure 无法将任何数据收集到只读查询存储中，导致有关查询存储达到其容量的误导性（错误）错误消息。
只有当查询存储处于只读模式时，我们才会收到此消息。仔细检查您的查询存储配置。 根据 MSDN，您可能需要考虑以下问题：
要恢复查询存储，请尝试明确设置读写模式并重新检查实际状态。
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;如果问题仍然存在，则表示查询存储数据损坏并在磁盘上继续。我们可以通过在受影响的数据库中执行
sp_query_store_consistency_check存储过程来恢复查询存储。如果这没有帮助，您可以尝试在请求读写模式之前清除查询存储。
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;
If you checked it and it's in read-write mode, then we might be dealing with some bug here. Please provide feedback to Microsoft on this.
查询存储中的附加限制点：
另外，请注意查询存储功能的引入是为了监控性能，并且仍在不断发展。它有一些已知的限制。
As of now, it does not work on Read-Only databases (Including read-only AG replicas). Since readable secondary Replicas are read-only, the query store on those secondary replicas is also read-only. This means runtime statistics for queries executed on those replicas are not recorded into the query store.
- 检查数据库不是只读的。
- 查询存储不适用于 master 或 tempdb 等系统数据库
- 检查主文件组是否有足够的内存，因为数据仅存储在主文件组中
支持的场景是只需要在主服务器上启用自动调整。在主数据库上自动创建的索引将自动复制到辅助数据库。此过程需要主要和次要之间通常的同步时间。目前不可能对次要只读副本进行与主要副本不同的性能调整。如上所述，查询存储错误消息是由于其只读状态所致，应予以忽略。您的辅助副本的性能问题很可能需要通过其他一些原因进行探讨。