INSERT занимает более 5 часов, при вставке более определенного количества строк

8

При вставке в таблицу менее 1350 000 строк это занимает около 2 минут, однако, если количество вставленных строк больше, время, необходимое для вставки данных, увеличивается до 5 часов.

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

Проблема появилась впервые около 2 недель назад, и она появляется неоднократно в те дни, когда количество вставленных строк превышает + -1 350 000. Например, в один день количество вставленных строк составляет 1 200 000, а процесс занимает 2 минуты, в другой день количество строк составляет 1 450 000, а вставка данных занимает 5-6 часов.

Я пытался перестроить индексы, но это не помогло.

sql-server Петр
источник
3
Каков источник для вставки?
Мартин Смит
4
Можете ли вы опубликовать, какое ожидание связано, когда вставка занимает так много времени?
Кин Шах
4
Мы можем только догадываться, если вы не дадите больше информации. Я предполагаю, что происходит эскалация блокировки. Можете ли вы отследить ожидания и заблокировать эскалацию
Shanky
1
Вы впервые пытаетесь вставить 1,3 миллиона записей? Вы делаете транзакции? Массовый импорт? Какой тип регистрации вы делаете? Если вы делаете вставки в обычном стиле, я согласен, попробуйте делать вставки партиями.
SQLburn
2
Как вы импортируете данные (bcp, массовая вставка, SSIS, командный файл)? Откуда (локальное хранилище, тот же / другой диск, сетевое хранилище, ...)? Какая схема таблицы? Что такое команда импорта? Каков план выполнения (если это обычный T-SQL)?
Marian

Ответы:

14

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

  1. Скорость роста вашего файла данных является разумной и имеет фиксированный размер (не%!), Достаточно большой, чтобы вместить эту транзакцию и все остальное, что может происходить одновременно.
  2. То же самое для файла журнала.
  3. Мгновенная инициализация файла включена . Это поможет ускорить увеличение размера файла данных, но не слишком трудоемкое увеличение размера файла журнала.
  4. Вы не вставляете 1,35 миллиона отдельных строк в цикл или иным образом все как одну большую транзакцию. Есть что сказать, чтобы разбить ваши транзакции на куски .
Аарон Бертран
источник
1
Аарон замечателен, его предложения звучат как рост файлов данных или файлов журналов. Также убедитесь, что у вас мало виртуальных файлов журнала.
Namphibian
4

Может ли это быть проблема с памятью?

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

Лорен Печтель
источник
3

Вы пытаетесь / можно ли разделить их на более мелкие партии? Когда я столкнулся с подобной проблемой, группировка их по 5.000 (с GO) действительно сократила время, необходимое для выполнения такой задачи.

Алекс Сабо
источник