настройка

В хранилище данных я объединяю таблицу фактов с 20 измерениями. Таблица фактов содержит 32 миллиона строк и 30 столбцов. Это временная промежуточная таблица, поэтому мне не приходится иметь дело с другими пользователями, читающими или пишущими эту таблицу. Я выбираю 10 столбцов из базовой таблицы и 20 столбцов из соответствующих измерений. Таблицы измерений маленькие (от 3 до 15.000 строк). Поля, к которым присоединяются, являются целыми числами и nvarchars. Я использую оператор SELECT ... INTO. На таблицах нет индексов.

Скорость выполнения этого запроса слишком мала, чтобы быть полезной.

Пробные решения

Поскольку обработка запроса занимает слишком много времени, я опробовал следующие решения:

1. Разделите 20 объединений на 4 объединения на 5 столах. Однако производительность запросов остается низкой.
2. Поместите индексы в столбцы внешнего ключа. Нет значительного уменьшения времени.
3. Убедитесь, что поля условия соединения являются целыми числами. Я заметил увеличение производительности на 25%. Не совсем то, что я ищу.
4. Используйте вставку в утверждение вместо выбора в. Хуже производительность из-за роста файла журнала, хотя база данных находится в простом режиме восстановления.

Эти выводы привели меня к тому, что я включил фактический план выполнения, который показывает, что 89% стоимости находится во вставке таблицы . Другие затраты: 8% сканирования таблицы на таблице фактов и 2% на совпадение хэшей для внутренних объединений.

Вопросов

1. Каковы возможные причины медленной вставки таблицы?
2. Как определить это узкое место без плана выполнения?
3. Какие действия можно предпринять, чтобы снизить стоимость вставки таблицы?

Каковы возможные причины медленной вставки таблицы? Как определить это узкое место без плана выполнения?

Прочтите, как анализировать производительность SQL Server , особенно часть об анализе времени ожидания выполнения отдельного запроса .

Какие действия можно предпринять, чтобы снизить стоимость вставки таблицы?

Это будет во многом зависеть от результатов анализа производительности. Прежде всего, убедитесь, что часть SELECT работает максимально быстро. Предполагая, что проблема заключается в однопоточном полностью зарегистрированном вкладыше, некоторые решения:

• Используйте переключатель разделов для перемещения «в» данных. Это, безусловно, лучшее решение. Подготовьте промежуточные данные в отдельной промежуточной таблице, затем переключите эту промежуточную таблицу в таблицу DW. Чтение эффективной передачи данных с помощью переключения разделов .

• Убедитесь, что INSERT минимально зарегистрирован. Операции чтения, которые могут быть минимально зарегистрированы, и предварительные условия для минимальной регистрации . Даже если вы используете операции переключения разделов, все равно стоит убедиться, что сборка промежуточной таблицы минимально регистрируется.

• Убедитесь, что ваша подсистема ввода-вывода способна к быстрой загрузке. Прочитайте Введение SSD .

Ниже мой опыт и может помочь кому-то еще там.

Мы пытались перенести некоторые данные из одной базы данных в другую, также делая некоторые преобразования в пути. Тестируя трансформацию, мы делали много вставок, исправляли и удаляли, чтобы снова протестировать вставку. Однако после некоторых вставок и усечений наши запросы начали выполняться медленно, и одна простая вставка начала занимать до 9 минут, в то время как ранее она выполнялась в течение примерно 3 минут.

1. Ну, мы начали смотреть на оптимизацию SELECT в первую очередь. Вместо подзапросов мы использовали #tempTables. Хотя это немного ускорило ход событий, это все же не было удовлетворительным.
2. Отличие было в перестроении индекса и обновлении статистики в целевой базе данных, что привело к вставке примерно через 2 минуты.

Так что попробуйте эти две стратегии и посмотрите, как это работает для вас.