Дорогая причина избегать группы доступности в Azure
Деньги правят
Большинство людей, когда они начинают оплачивать услуги Azure и лицензирование SQL Server Enterprise, остаются с отверстием в своем кошельке, которое может быть заполнено только чем-то со знаком бесконечности.
Недавно выяснилось, что это еще хуже.
DBCC CHECKDB и вы
Когда вы лицензируете SQL Server с SA, вы получаете бесплатный сервер “теплого” резервирования. Это справедливо для FCI, Log Shipping, Mirroring или AG. Не вместе, конечно. Подразумевается «один сервер “теплого” резервирования», а не «каждый сервер “теплого” резервирования».
Во-вторых, вы выгружаете что-либо на один из этих серверов, вам нужно лицензировать его, как на другом сервере. Это нормально. Это полностью стоит денег, чтобы разгрузить некоторые запросы. Это не очень понятно для задач обслуживания, но все же это принимает все виды.
Опытные администраторы баз данных знают, что вы не можете ДЕЙСТВИТЕЛЬНО разгрузить DBCC CHECKDB на другой сервер, если только он не является получателем полного резервного копирования или снимка SAN специально для этой задачи. Выполнение DBCC CHECKDB в базе данных Log Shipped, Mirrored или Availability Grouped не обязательно говорит вам, является ли Primary в любом из этих сценариев поврежденным. То же самое, что проверка Primary не говорит вам, является ли Secondary поврежденным.
Те же самые опытные администраторы баз данных могут захотеть запустить DBCC CHECKDB в Secondary перед сбоем.
В конце концов, вы восстановили полную резервную копию много месяцев назад, и впервые с тех пор вы добавили транзакции. SQL не отправляет плохие базовые блоки из ваших файлов данных через провод.
Кто знает, что там происходит?
Ниже и ниже
Когда было обнаружено, что у клиента, у которого есть много опытных администраторов баз данных, не работает DBCC CHECKDB на своих вторичных АГ в Лазуре, возник вопрос почему.
Они упомянули о расходах на лицензирование, и я сказал: «Но это просто для разгрузки, а не для дополнительных проверок, верно?»
Неверно.
И вот, у них были электронные письма, в которых представители по лицензированию сказали им, что если они выполнят DBCC CHECKDB на реплике, сервер считается активным, и он должен полностью лицензировать его.
Выбор
Это оставляет вам один ужасный вариант, предполагая, что вы не хотите удваивать свои расходы на лицензирование.
Вы должны подождать, пока не закончите работу, а затем запустите DBCC CHECKDB и надейтесь, что он ничего не найдет.
Если вы хотите автоматизировать его в случае незапланированных отказов, вы делаете запуск DBCC CHECKDB после незапланированного отказа при сбое в куске кода, который может потребоваться для понимания, если он не находится в окне обслуживания.
И это не дает утешения.