Медленная производительность на Sql Express после вставки больших фрагментов данных

Question

Мы заметили, что наши запросы работают медленнее в базах данных с большими объемами добавленных данных (объемная вставка) по сравнению с базами данных, в которых данные были добавлены в запись на запись , но с аналогичными объемами данных. Мы используем Sql 2005 Express, и мы попытались переиндексировать все индексы без каких-либо лучших результатов. Знаете ли вы о какой-то структурной проблеме в базе данных, которая может быть вызвана вводом данных в большие куски вместо одного за другим?

Благодаря

Answer 1

Возможно SQL Server выделено новое дисковое пространство во многих небольших кусков. При совершении больших транзакций лучше предварительно выделить много места в файлах данных и журналов.

Answer 2

Один совет, который я видел, чтобы отключить автоматическую создать статистику и статистику Автоматическое обновление перед выполнением массовой вставки:

ALTER DATABASE databasename SET AUTO_CREATE_STATISTICS OFF WITH NO_WAIT 

ALTER DATABASE databasename SET AUTO_UPDATE_STATISTICS OFF WITH NO_WAIT 

Затем вручную создать статистику по одному из 2-х способов:

--generate statistics quickly using a sample of data from the table 
exec sp_createstats 

или

--generate statistics using a full scan of the table 
exec sp_createstats @fullscan = 'fullscan' 

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

Другой вариант - проверить и дефрагментировать индексы после объемной вставки. Проверьте Pinal Dave's blog post.

Answer 3

Это интересный вопрос.

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

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

Что-то еще: а также индексы говорят, что SQL использует статистику (которая была создана в результате выполнения предыдущих запросов) для оптимизации плана выполнения. Я не знаю никаких подробностей об этом, но так же как и «переиндексации всех индексов», проверьте планы выполнения своих запросов в двух тестовых случаях, чтобы убедиться, что планы идентичны (и/или проверять связанные статистические данные).