Comments 10
В случай с sql agent jobs стоит пользоваться contained database , тогда у каждой базы будет свой master и прочие системные базы, соотвественно и выполнение job сможет запускаться на primary
Есть хорошие практики, как безопасно совершать большие пишушие транзакции, постоение нового большого индекса, например? Есть, конечно, очевидный способ: создать новую таблицу, проиндексировать и залить в нее данные короткими транзакциями а потом подменить одну таблицу другой.
Что невозможно если есть активная нагрузка и таблицы захвачены долгими запросами
Подмена остановится и будет ждать schema lock
Ну можно и других проблем для такого способа накидать, а также способов их обхода. Очевидно, что это не "серебрянная пуля".
Вопрос был в том, есть ли другие хорошие практики в always-on победить построение индекса на большую таблицу?
Действительно, как правило схема на PROD стабильна, за исключением релизов. Но увы, есть системы, где это не так.
Сталкивался с системой, где пользователи "обновляли" данные с помощью truncate + insert, на реплику смотрел SSRS, который рассылал миллиарды тяжёлых отчётов.
С тех пор сильно недолюбливаю truncate (особенно в связке с AlwaysOn) и триггерюсь каждый раз, когда вижу как кто-то пишет, что это очень лёгкая и приятная замена для delete.
SQL server: темная сторона AlwaysOn