Вырезка из статьи: SQLskills SQL101:Readable secondary performance problems
Группа доступности AlwaysOn (AG) отличный инструмент, который позволяет без дополнительных ухищрений иметь возможность чтения данных со вторичной реплики. До появление AG, мы могли воспользоваться Зеркалированием, но тогда доступ на чтение мы могли получить только через создание снимка БД, который даёт только статическую информацию на момент его создания. Реплика, доступная на чтение в AG, постоянно обновляется, что позволяет получать максимально свежие данные.
Но, тема же называется «AlwaysOn. Проблемы производительности реплики на чтение» и я хотел бы рассмотреть какую цену мы платим за такое удобство.
Как мы все знаем, мы ничего не получаем бесплатно. Реплика на чтение действительно очень удобна, но у этого удобства есть своя цена. Все запросы, которые выполняются на реплике для чтения, автоматические используют уровень изоляции read-committed snapshot. Это означает, что запрос на чтение не накладывает разделяемую блокировку и не блокирует любые изменения в БД.
Иными словами мы используем версионный механизм, версии строк которого хранятся в tempdb и соответствуют времени запуска запроса. Ко всем строкам, которые были изменены, добавляется 14 байтовый тэг в конец строки, который позволяет связать строку со своей версией в tempdb. Этот механизм был представлен в SQL Server 2005.
Обратите внимание, что все AG реплики точные копии основного сервера. Так как же версионный механизм может работать на вторичной реплике, добавляя 14 байт в конец строки? Это ведь уже не точная копия, верно?
После добавления вторичной реплики на чтение к AG, ко всем изменённым строкам на основном сервере начинают добавляется пустые 14 байт. Эти 14 байт занимают дополнительное место в файле лога и передаются на вторичную реплику, что позволяет использовать версионный механизм на вторичной реплике.
Это не ломает правило точной копии, так как эти 14 байт не используются в восстановлении БД.
Давайте вспомним что происходит если строка становится больше, а на странице больше нет места? Правильно, происходит разбиение страницы (page split) в индексе или появляются forwarded records в куче, что вызывает появление фрагментации и увеличение размера на жёстком диске.
Чтобы избежать этого, нам необходимо использовать fill factor и настроить регулярное обслуживание индексов.
Здесь вы можете найти больше информации по производительности вторичной реплики на чтение, так же можно посмотреть и тут — AlwaysOn Solution Guide: Offloading Read-Only Workloads to Secondary Replicas.
