Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Применимо к:База данных SQL Azure 2025 (17.x)
При сохранении статистики первичная реплика сохраняет статистические данные в виде постоянной статистики, которую можно отправлять во все вторичные реплики. Этот процесс выполняется автоматически, не требуя вмешательства вручную. Механизм сохранения статистики использует Query Store для системы вторичных реплик, доступных только для чтения.
Хранилище запросов для доступных для чтения вторичных реплик доступно в SQL Server 2025 (17.x) и Базе данных SQL Azure.
Хранилище запросов для доступных для чтения вторичных реплик по умолчанию включено в SQL Server 2025 (17.x) и базе данных Azure SQL.
Background
В доступных для чтения вторичных реплик статистика также может быть автоматически создана при включенном параметре автоматического создания статистики , но эти статистические данные временные и исчезают при перезапуске экземпляра. Если статистика по базе данных только для чтения или моментальному снимку только для чтения отсутствует или устарела, ядро СУБД создает и сохраняет временную статистику.tempdb
Когда ядро СУБД создает временную статистику, имя статистики добавляется суффиксом _readonly_database_statistic , чтобы отличить временную статистику от постоянной статистики. Суффикс _readonly_database_statistic зарезервирован для статистики, созданной SQL Server. Причина, по которой этот подход использовался, заключается в решении рабочих нагрузок, выполняемых в отношении доступных для чтения вторичных реплик, которые могут потребовать различающуюся статистику, которая не существует в первичной реплике.
Временная статистика, созданная на вторичных репликах, остается видимой только для той реплики, которая их сформировала. Первичная реплика никогда не обращается непосредственно к этим временным объектам статистики и узнает о постоянном объекте статистики только после его сохранения. При сохранении временной статистики в первичной реплике они становятся доступными для всех реплик в группе доступности с помощью механизма синхронизации.
Поддержка представлений каталога
Для обеспечения возможности сравнения создания или обновления статистики между вторичным и первичным серверами, а также для помощи в понимании того, где была сформирована статистика, в представление каталога добавлены три новых столбца sys.stats.
| Имя столбца | Тип данных | Description |
|---|---|---|
replica_role_id |
tinyint |
1 = primary, 2 = Secondary, 3 = Geo Secondary, 4 = Geo HA Secondary |
replica_role_desc |
nvarchar(60) | Основной, Вторичный, Гео-вторичный, Гео-вторичный с высокой доступностью |
replica_name |
sysname | Имя экземпляра реплики в группе доступности.
NULL для первичной реплики |
Эти столбцы отслеживают право собственности на статистику и происхождение в течение всего жизненного цикла сохранения данных. Когда вторичная реплика создает временную статистику и она сохраняется в основной реплике, столбцы replica_role_id и replica_name определяют исходную реплику. Если эти постоянные статистические данные позже обновляются на первичной реплике, владение передается на основную реплику, что отражается в этих столбцах.
Поведение сохранения статистики
Если временная статистика сохраняется из вторичной реплики в основную, происходит несколько важных действий: временная статистика вторичной реплики не удаляется автоматически после сохранения. Запросы, которые изначально активировали создание этих временных статистик, продолжают использовать их до тех пор, пока запрос не будет перекомпилирован или реплика не перезапущена. Это означает, что временные и постоянные версии одной статистики могут временно существовать.
Оптимизатор не учитывает владение репликой при определении того, следует ли использовать статистику. Она оценивает все доступные статистические данные на основе оценки охвата столбцов и селективности. Сведения о реплике поддерживаются главным образом для отслеживания и устранения неполадок.
Заметный сценарий возникает, когда постоянная статистика, созданная из временной статистики, становится устаревшей. Если значительные изменения данных происходят на первичных столбцах, влияющих на эти статистические данные, постоянная статистика может рассматриваться как устаревшая. Когда запросы на вторичные реплики ссылаются на эти столбцы, вторичные обновляют статистику на основе их представления данных, отражая изменения, примененные через процесс повторного воспроизведения.
Короче говоря, сохраняемость не удаляет способность вторичной реплики обновлять устаревшие статистические данные; она просто добавляет механизм совместного использования статистики между репликами.
Observability
Расширенные события
persisted_stats_operation(Операционный канал) активируется для enqueued, dequeued, processed и failed событий. Это может быть полезно для отслеживания, если сообщение статистики не может быть сохранено на основном сервере, или если имеется интерес к просмотру процесса обработки сообщений. Временная статистика остается в tempdb на вторичных репликах, пока фоновый процесс повторяет попытку отправки сообщения в случае проблемы связи между первичной и вторичной репликами.
Примеры связанных сообщений об ошибках, которые могут быть зарегистрированы в ERRORLOG
- 9131: функция отключена во время запуска SQL.
- 9136: таблица или индекс удалены или изменены.
- 9137: Схема изменилась с момента начала транзакции снимка; повторить.
- 9139: данные слишком большого размера, чтобы отправить на основной сервер.
Следующий запрос может обеспечить некоторую видимость статистики в таблице, включая статистику, сохраненную из вторичных реплик:
SELECT sch.[name] AS SchemaName,
obj.[name] AS TableName,
s.[name] AS StatsName,
CASE
WHEN s.stats_id >= 2 AND s.auto_created = 1 THEN 'AUTO_STATS'
WHEN s.stats_id >= 2 AND s.auto_created = 0 THEN 'USER_CREATED_STATS'
ELSE 'INDEX_STATS'
END AS type,
s.is_temporary,
CASE WHEN s.replica_name IS NULL
AND s.replica_role_desc = 'PRIMARY'
AND s.stats_id >= 2
AND s.auto_created = 1
THEN 'PRIMARY'
ELSE s.replica_name
END AS replica_name,
s.replica_role_id,
s.replica_role_desc
FROM sys.schemas AS sch
INNER JOIN sys.objects AS obj
ON sch.schema_id = obj.schema_id
INNER JOIN sys.stats AS s
ON obj.object_id = s.object_id
WHERE sch.[name] <> 'sys'
ORDER BY sch.[name], obj.[name], s.stats_id;
Соображения
Сохраняемая статистика для читаемых дополнительных реплик включена по умолчанию, если включен параметр автоматического создания статистики, а также параметры конфигурации с областью базы данных READABLE_SECONDARY_TEMPORARY_STATS_AUTO_CREATE и READABLE_SECONDARY_TEMPORARY_STATS_AUTO_UPDATE, что является конфигурацией по умолчанию. Нет конфигурации с областью действия базы данных для включения и отключения этой функции.