Comments 12
В случай с sql agent jobs стоит пользоваться contained database , тогда у каждой базы будет свой master и прочие системные базы, соотвественно и выполнение job сможет запускаться на primary
Есть хорошие практики, как безопасно совершать большие пишушие транзакции, постоение нового большого индекса, например? Есть, конечно, очевидный способ: создать новую таблицу, проиндексировать и залить в нее данные короткими транзакциями а потом подменить одну таблицу другой.
Что невозможно если есть активная нагрузка и таблицы захвачены долгими запросами
Подмена остановится и будет ждать schema lock
Действительно, как правило схема на PROD стабильна, за исключением релизов. Но увы, есть системы, где это не так.
Сталкивался с системой, где пользователи "обновляли" данные с помощью truncate + insert, на реплику смотрел SSRS, который рассылал миллиарды тяжёлых отчётов.
С тех пор сильно недолюбливаю truncate (особенно в связке с AlwaysOn) и триггерюсь каждый раз, когда вижу как кто-то пишет, что это очень лёгкая и приятная замена для delete.
Это же именно реализация анекдота про сибирских мужиков - целенаправленный abuse системы. Либо специально оставить открытой транзакцию, либо менять схему параллельно с работой. В реале ни того, ни другого никто не делает. Во втором случае вы воспользовались тем, что Snapshot Isolation не распространяется на Schema Stability Lock. Я помню, как раньше и без AlwaysOn можно было успешно положить или как минимум дестабилизировать систему, попытавшись поменять схему таблицы под нагрузкой. Причем не добавить столбец, а, например, сделать SWITCH PARTITION для классического сценария Sliding Window. До одной из самых последних версий это автоматически вызывало Schema Stability Exclusive Lock на всю таблицу (в последних версиях только на участвующие в деле партишены, так что если мы делаем purge на старые данные, то не мешаем никому работать и никто не мешает нам). И таким образов даже попытка чтения с NOLOCK не проходила: NOLOCK не пытается сделать Shared Lock на данные, но все равно делает Schema Stability Shared Lock на схему. При этом запросы с NOLOCK заходили подряд без очереди, так что ALTER TABLE ... SWITCH PARTITION мог ждать бесконечно - лично убивал такой после более, чем суток бесплодного ожидания. В общем, если работать с MSSQL нормально, а не пытаться сознательно его обвалить, то все и в самом деле будет работать.
SQL server: темная сторона AlwaysOn