Как то были проблемы, но давно, прям пример сейчас не приведу с кодом, но у меня обрывалась эта операция, потому что загодочным образом без видимых блокировок зависала на очень долго. Но любые массовые операции лучше атомарно проводить, чтобы быть уверенным что все сработало как надо. А вот обрабатывая каждый конкретный констрэйнт все прошло довольно быстро.
Конструкции вроде - EXEC sys.sp_msforeachtable "ALTER TABLE ? NOCHECK CONSTRAINT ALL" я стараюсь не применять, выполнение всего за одну команду к сожалению не надежно , а лучше все таки в ЦИКЛЕ по одному констрэйнту за раз, с возможностью повторной попытки делать.
Статья хорошая и на самом деле в реальной работе приходилось DBA "отстреливать" сессии. Самое главное здесь даже не реализация, а знание того, что можно отсреливать и при каких условиях. К примеру если запись какого то показателя обыдена и повторяется регулярно часто, но вот она и привела к блокировкам, то ее убийство оправдано. Маркировку того что можно остреливать, а что нет можно вести через имя api - потому что это имя в СУБД можно удобно ловить.
Хочется еще добавить по поводу того, что кто то может сказать дескать делайте запросы правильно и все будет ОК - НЕТ, к примеру Важе железо или облачное просело по производительности по дискам (вышли из строя ряд дисков и пр.) и Ваши запросы из крутых 0-2 мс. быстро превращаются в тыкву по 50 мс, а их приходить много и эти 50 мс потом становятся 200 мс и локи, дедлоки и прочее счастье наваливается горой.
Ваши запросы могут быть оптимальными и да хорошо написанный запрос "проседать" будет дольше, система дольше будет живая, но реально выжить в коллапсе иногда помочь может только "отстрел", да часть данных потеряется, но система испытывая меньше пиков легче пройдет перегруз и вместо "тотальной не работы сервисов" у Вас будут тормоза, но с которыми пол-ли еще могут работать, а там ближе к вечеру или утру (активность пол-ль в минимум) искомая проблема будет решена.
Еще момент, который трудно описать, но с ним сталкивался и MS SQL и в Postgres.
1) Когда где то в середине процесс переноса большой таблицы в ней уже миллионы-миллионов-миддиарды записей неплохо остановить процесс и сделать UPDATE STATISTICS, ANALYZE (для Postgres) или даже rebuild. Я про несекционированую таблицу (к сожалению так тоже бывает). Скорость вставки может очень падать и таблице нужен "рефреш" в ходе пути.
2) Для таблиц спроективрованных только под запись (без update,delete), но очень очень больших бывает проще сделать массовый импорт-экспорт данных уже через файлы. К примеру я так выделял данные в архивную БД. Там свои нюансы в файлом форматирования, а также тем,что файлы удобно делать 2-4 Гб. Формата имя_таблицы_даты, а затем последовательно файл за файлом подгружать, не забывая сверять кол-во записей и если сбой, но delete посл-их подгруженных и по новой с посл-го загруженого. Но это конечно для любителей позабористее или когда уж сосем все плохо.
Я бы добавил еще несколько моментов для оптимизации
1) При вставке массовой данных нужен либо хинт OPTION(RECOMPILE) или WITH(INDEX(IX_<имя_таблицы>_<имя_столбца фильра>)) - второй вариант надежнее. При работе с D-SQL оптимизатор периодически ошибается и считает,что данные нужны выбирать из кластерного индекса, а не из более подходящего индекса по дате-фильтру
2) Для кластерихованных индексов хорошо бы приемнить опцию OPTIMIZE_FOR_SEQUENTIAL_KEY = ON, ее можно включить через alter index. Это опция неплохо работает для вставок мно-во строк.
Делать многосоставной кластерный индекс, в котором может быть много полей — это спорный вариант для производительности, частые операции модификации могут сделать их обслуживание дорогим, а выборки начнут простаивать в блокировках ( все же таблицы достаточно большие). Фильтрованный индекс — это хорошее решение, но делать его для достаточно сложных предикатов отбора — это опять же закладывать камень под производительность. Все таки пересечения условий могут быть очень размазаны по всему возможному диапазону значений, да и содержать сложные сочетания условий and, or, is not null.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Как то были проблемы, но давно, прям пример сейчас не приведу с кодом, но у меня обрывалась эта операция, потому что загодочным образом без видимых блокировок зависала на очень долго. Но любые массовые операции лучше атомарно проводить, чтобы быть уверенным что все сработало как надо. А вот обрабатывая каждый конкретный констрэйнт все прошло довольно быстро.
Да.
Конструкции вроде - EXEC sys.sp_msforeachtable "ALTER TABLE ? NOCHECK CONSTRAINT ALL" я стараюсь не применять, выполнение всего за одну команду к сожалению не надежно , а лучше все таки в ЦИКЛЕ по одному констрэйнту за раз, с возможностью повторной попытки делать.
Статья хорошая и на самом деле в реальной работе приходилось DBA "отстреливать" сессии. Самое главное здесь даже не реализация, а знание того, что можно отсреливать и при каких условиях. К примеру если запись какого то показателя обыдена и повторяется регулярно часто, но вот она и привела к блокировкам, то ее убийство оправдано. Маркировку того что можно остреливать, а что нет можно вести через имя api - потому что это имя в СУБД можно удобно ловить.
Хочется еще добавить по поводу того, что кто то может сказать дескать делайте запросы правильно и все будет ОК - НЕТ, к примеру Важе железо или облачное просело по производительности по дискам (вышли из строя ряд дисков и пр.) и Ваши запросы из крутых 0-2 мс. быстро превращаются в тыкву по 50 мс, а их приходить много и эти 50 мс потом становятся 200 мс и локи, дедлоки и прочее счастье наваливается горой.
Ваши запросы могут быть оптимальными и да хорошо написанный запрос "проседать" будет дольше, система дольше будет живая, но реально выжить в коллапсе иногда помочь может только "отстрел", да часть данных потеряется, но система испытывая меньше пиков легче пройдет перегруз и вместо "тотальной не работы сервисов" у Вас будут тормоза, но с которыми пол-ли еще могут работать, а там ближе к вечеру или утру (активность пол-ль в минимум) искомая проблема будет решена.
Еще момент, который трудно описать, но с ним сталкивался и MS SQL и в Postgres.
1) Когда где то в середине процесс переноса большой таблицы в ней уже миллионы-миллионов-миддиарды записей неплохо остановить процесс и сделать UPDATE STATISTICS, ANALYZE (для Postgres) или даже rebuild. Я про несекционированую таблицу (к сожалению так тоже бывает). Скорость вставки может очень падать и таблице нужен "рефреш" в ходе пути.
2) Для таблиц спроективрованных только под запись (без update,delete), но очень очень больших бывает проще сделать массовый импорт-экспорт данных уже через файлы. К примеру я так выделял данные в архивную БД. Там свои нюансы в файлом форматирования, а также тем,что файлы удобно делать 2-4 Гб. Формата имя_таблицы_даты, а затем последовательно файл за файлом подгружать, не забывая сверять кол-во записей и если сбой, но delete посл-их подгруженных и по новой с посл-го загруженого. Но это конечно для любителей позабористее или когда уж сосем все плохо.
Я бы добавил еще несколько моментов для оптимизации
1) При вставке массовой данных нужен либо хинт OPTION(RECOMPILE) или WITH(INDEX(IX_<имя_таблицы>_<имя_столбца фильра>)) - второй вариант надежнее. При работе с D-SQL оптимизатор периодически ошибается и считает,что данные нужны выбирать из кластерного индекса, а не из более подходящего индекса по дате-фильтру
2) Для кластерихованных индексов хорошо бы приемнить опцию OPTIMIZE_FOR_SEQUENTIAL_KEY = ON, ее можно включить через alter index. Это опция неплохо работает для вставок мно-во строк.
Делать многосоставной кластерный индекс, в котором может быть много полей — это спорный вариант для производительности, частые операции модификации могут сделать их обслуживание дорогим, а выборки начнут простаивать в блокировках ( все же таблицы достаточно большие). Фильтрованный индекс — это хорошее решение, но делать его для достаточно сложных предикатов отбора — это опять же закладывать камень под производительность. Все таки пересечения условий могут быть очень размазаны по всему возможному диапазону значений, да и содержать сложные сочетания условий and, or, is not null.