Pull to refresh

Comments 10

В случай с sql agent jobs стоит пользоваться contained database , тогда у каждой базы будет свой master и прочие системные базы, соотвественно и выполнение job сможет запускаться на primary

А если баз в группе доступности много, и там джобы с кучей шагов, один на одну базу, другой на другую итд? Это лишь один из более сложных сценариев

Есть хорошие практики, как безопасно совершать большие пишушие транзакции, постоение нового большого индекса, например? Есть, конечно, очевидный способ: создать новую таблицу, проиндексировать и залить в нее данные короткими транзакциями а потом подменить одну таблицу другой.

Что невозможно если есть активная нагрузка и таблицы захвачены долгими запросами

Подмена остановится и будет ждать schema lock

Ну можно и других проблем для такого способа накидать, а также способов их обхода. Очевидно, что это не "серебрянная пуля".

Вопрос был в том, есть ли другие хорошие практики в always-on победить построение индекса на большую таблицу?

надо попробовать в какой момент schema lock будет в режиме online - в начале или конце. интересный вопрос

Действительно, как правило схема на PROD стабильна, за исключением релизов. Но увы, есть системы, где это не так.

Сталкивался с системой, где пользователи "обновляли" данные с помощью truncate + insert, на реплику смотрел SSRS, который рассылал миллиарды тяжёлых отчётов.

С тех пор сильно недолюбливаю truncate (особенно в связке с AlwaysOn) и триггерюсь каждый раз, когда вижу как кто-то пишет, что это очень лёгкая и приятная замена для delete.

о да, truncate тоже считается schema modification

Релизы тоже надо пережить, желательно не прерывая работы. Ну и патерны с "плавающим окном" для секционированных таблиц не стоит сбрасывать со счетов.

О да, еще одно место которое может вызывать то же самое

Sign up to leave a comment.

Articles