Справка по производительности запросов

Question

У меня долгая работа. Обрабатываемые записи находятся в таблице из 100 тыс. Записей.

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

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

РЕДАКТИРОВАТЬ: Основная таблица в основном используется только для этой нагрузки. Я получаю плоский файл, который загружаю как есть перед обработкой. После проверки этой таблицы я выбираю одну запись за раз и перемещаю данные в соответствующие системные таблицы.

Answer 1

У меня была похожая проблема с производительностью, когда в таблице обычно несколько миллионов строк, но мне нужно только обработать то, что изменилось с начала моего последнего выполнения. В моей целевой таблице есть столбец IDENTITY, поэтому, когда начинается мой пакетный процесс, я получаю самое высокое значение IDENTITY из набора, который я выбираю, где идентификаторы больше, чем мое предыдущее пакетное выполнение. Затем, после успешного завершения пакетного задания, я добавляю запись в отдельную таблицу, указывающую это самое высокое значение IDENTITY, которое было успешно обработано, и использую его в качестве начального ввода для следующего вызова пакета. (Я также добавлю, что моя таблица закладок общего назначения, поэтому я использую несколько разных заданий, каждое из которых имеет уникальные имена.)

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

Answer 2

Несколько указателей (два моих цента):

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

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

Не назначать ненужные (ключи) индексы для этой таблицы перед загрузкой.

Рассмотрите возможность переключения «модели восстановления» БД в режим массовой загрузки, чтобы не регистрировать массовые транзакции.

Можно ли использовать задачу SSIS (ETL) для загрузки, очистки и проверки?

UPDATE:
Вот типичный сценарий ETL - хорошо, зависит от того, с кем вы говорите.

1 . Извлечение в flat_file_1 (у вас это есть)
2 * * тысячи двадцать-два. Очистить flat_file_1 --> SSIS --> flat_file_2 (вы можете подтвердить здесь)
3 . Соответствует flat_file_2 --> SSIS --> flat_file_3 (применяются все стандарты компании)
4 . Доставка flat_file_3 --> SSIS (bulk) --> db.ETL.StagingTables (несколько, по одному на пункт назначения)
4B . insert into destination_table select * from db.ETL.StagingTable (массовая загрузка вашего конечного пункта назначения)

Таким образом, если время процесса (1-4) истекло, вы всегда можете начать с промежуточного файла. Вы также можете проверять каждый этап и создавать файлы отчетов из SSIS для каждого этапа, чтобы контролировать качество данных. Операции 1-3 в основном медленные; здесь они происходят вне базы данных и могут быть выполнены на отдельном сервере. Если вы архивируете flat_file(1-3), у вас также есть контрольный журнал того, что происходит - хорошо для отладки. :)