План выполнения хранимой процедуры - манипулирование данными

Question

У меня есть сохраненный процесс, который обрабатывает большой объем данных (в этом примере около 5 миллионов строк). Производительность сильно варьируется. Я запустил процесс всего за 15 минут и видел, как он длится 4 часа.

Для обслуживания и проверки правильности логики и обработки у нас есть SP, разбитый на разделы:

1. TRUNCATE и заполните рабочую таблицу (проиндексированную), которую мы можем проверить позже с помощью инструментов автоматического тестирования.

2. Соедините несколько таблиц вместе (включая некоторые из этих рабочих таблиц), чтобы создать другой рабочий стол

Повторяйте 1 и / или 2, пока не будет получен окончательный результат.

Меня беспокоит то, что это один SP, и поэтому он получает план выполнения при первом запуске (даже WITH RECOMPILE). Но в то время рабочие таблицы (постоянные таблицы в рабочей схеме) пусты.

Я обеспокоен тем, что независимо от схемы индексации план выполнения будет плохим.

Я рассматриваю возможность разрыва SP и вызова отдельных SP изнутри, чтобы они могли воспользоваться переоцененным планом выполнения после построения данных в рабочих таблицах. Я также видел ссылку на использование EXEC для запуска динамического SQL, который, очевидно, может также получить RECOMPILE.

Я все еще пытаюсь получить разрешения SHOWPLAN, поэтому я летаю совершенно слепо.

Answer 1

Можете ли вы определить, есть ли проблемы с блокировкой? Вы запускаете SP в достаточно небольших транзакциях?

Разбиение его на подпроцедуры не должно иметь никакой выгоды.

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

Answer 2

В нескольких случаях я видел, что этот уровень разнообразия времени выполнения / планов запросов сводится к статистике. Я бы порекомендовал некоторые тесты, запускающие статистику обновления для таблиц, которые вы используете непосредственно перед запуском процесса. Это приведет к переоценке плана выполнения SQL и, как я подозреваю, даст вам более согласованные результаты. Кроме того, вы можете преуспеть в том, чтобы увидеть, соотносятся ли различия во времени выполнения с заданиями по повторной индексации вашим dbas. Возможно, вы могли бы также собирать некоторую статистику работоспособности индекса перед каждым запуском.

Если нет, как предлагали другие авторы, вы, скорее всего, страдаете проблемами блокировки и / или конфликта.

Удачи с этим.

Answer 3

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

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

Кроме того, какова цель вашего процесса. Похоже, вы перемещаете довольно много данных, и в этом случае вы можете рассмотреть возможность использования разбиения. Вы можете переключать данные в основную таблицу с относительной легкостью.

Надеюсь, то, что я подробно изложил, понятно, но, пожалуйста, не стесняйтесь задавать дополнительные вопросы.

Ура, Джон

Answer 4

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

• "другая" нагрузка на машину БД
• при использовании разных данных могут быть "простые" и "жесткие" данные
• проблемы с необходимостью выделить больше памяти / хранилища файлов
• ...

Вы пытались запустить SP с одними и теми же данными несколько раз?

Кроме того, чтобы выяснить, что является причиной времени выполнения / изменчивости, я бы попытался провести некоторые подробные измерения, чтобы определить проблему до определенного раздела кода. (Самый простой способ - вставить несколько вызовов журнала в разные точки sp). Затем попытайтесь объяснить, почему этот раздел медленный (кроме "5M строк ;-)), и найдите способ сделать это быстрее.

Пока, я думаю, есть несколько вопросов, на которые нужно ответить, прежде чем идти по пути "расщепления sp".

Answer 5

Возьмите бесплатную копию "Dissecting Execution Plan" по ссылке ниже, и, возможно, вы сможете получить один или два из них, которые дадут вам представление о том, что действительно происходит под капотом вашего SP.

http://dbalink.wordpress.com/2008/08/08/dissecting-sql-server-execution-plans-free-ebook/

Answer 6

Это какой-то ввод или вывод, или вы создаете отчет? Если это фид, я бы посоветовал вам изменить процесс на использование служб SSIS, которые должны очень быстро перемещать 5 миллионов записей.

Answer 7

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

Вы можете принудительно использовать индексы в своем запросе ...

Мне кажется, что вы идете по неверному пути.