Проблема:
При настройке групп доступности SQL Server Always On с локального экземпляра SQL Server на экземпляр SQL Server, работающий на виртуальной машине Azure, вы можете столкнуться с сообщениями об ошибках в журнале ошибок SQL Server на вторичном сервере, указывающими на неправильно выровненные Log IO. Эти ошибки могут повлиять на производительность и надежность вашей группы доступности.
Решение:
Чтобы исправить эту проблему, вам необходимо убедиться, что физические настройки секторов дисков, на которых размещаются SQL-базы данных, согласованы между локальным экземпляром SQL Server и Azure SQL Server. Microsoft рекомендует иметь одинаковый размер сектора для всех дисков на всех репликах, особенно для тех, на которых размещаются файлы журналов.
Вот шаги для исправления несоответствия физических настроек секторов:
- Включите флаг трассировки 1800 с помощью команды DBCC TRACEON. Этот флаг гарантирует, что формат создания журнала использует размер сектора 4 КБ.
- Убедитесь, что флаг трассировки включен, запустив DBCC Tracestatus.
- Добавьте флаг трассировки в качестве параметра запуска, чтобы он оставался на месте после перезапуска сервера.
Вот пример того, как включить флаг трассировки 1800:
dbcc traceon (1800, -1)
После включения флага трассировки вы должны увидеть информационное сообщение в журнале ошибок, подтверждающее его активацию. Вы также можете использовать DBCC Tracestatus, чтобы проверить статус флага трассировки.
Чтобы добавить флаг трассировки в качестве параметра запуска, измените параметры запуска SQL Server и включите “-T1800” в качестве параметра. Это гарантирует, что флаг трассировки будет автоматически включен после перезапуска сервера.
Обратите внимание, что вам нужно включить флаг трассировки только на репликах с размером сектора 512 байт. Вторичная реплика, у которой размер сектора 4 КБ, не требует флага трассировки.
Итог:
Включение флага трассировки 1800 на всех репликах с размером сектора 512 байт решает проблему неправильно выровненных Log IO в группах доступности SQL Server Always On. Может потребоваться некоторое время, чтобы сообщения об ошибках исчезли из журналов ошибок SQL Server, поскольку агент AG догоняет репликацию журнала. Если проблема сохраняется, вы можете попробовать перезапустить вторичную реплику или повторно инициализировать ее, если базы данных не слишком большие.
Следуя этим шагам, вы можете обеспечить оптимальную производительность и надежность групп доступности SQL Server Always On в гибридной среде локальной сети и Azure.