Еще момент, который трудно описать, но с ним сталкивался и 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.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Еще момент, который трудно описать, но с ним сталкивался и 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.