Массовая вставка в индекс HEAP vs CLUSTERED, где минимальное ведение журнала недоступно (SQL Server 2008) - PullRequest
5 голосов
/ 25 августа 2011

В настоящее время используется инструмент Informatica, и у нас есть дополнительные хранимые процедуры, которые отбрасывают кластеризованные индексы, а затем добавляют их обратно в базу данных.В хранимой процедуре, где мы добавляем кластерные индексы обратно, у нас есть DDL для индексов, жестко запрограммированных в хранимой процедуре (мы не используем таблицы sys, потому что страх перед Microsoft, изменяющий таблицы sys и регенерацию оттуда, создает плохой индекс илитерпит неудачу).Это вызывает проблемы, когда люди создали кластерные индексы, но не думали обновить хранимую процедуру, и в следующий раз, когда произойдет массовая загрузка, эти индексы исчезнут.Ранее мы делали это для всех индексов, но переключили некластеризованные индексы на использование disable / rebuild.Однако это не вариант, потому что мы больше не сможем вставить в таблицу, если это будет сделано с кластеризованным индексом, потому что это, по сути, таблица.

Производительность важна, но не все.Хорошая производительность и простота обслуживания превосходят высокую производительность и сложность обслуживания.

После прочтения многих сайтов почти все согласны с тем, что при массовой вставке данных, упорядоченных не так, как ваш первичный ключ, вставка в кучу, а затемприменение pk впоследствии происходит быстрее (http://msdn.microsoft.com/en-us/library/ms177445.aspx, http://msdn.microsoft.com/en-us/library/dd425070(v=sql.100).aspx). Большинство этих сайтов делают предположения, которые я не могу использовать в своей организации и с моим набором инструментов.

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

Согласно нашим администраторам informatica, указание таблока или порядка указаний на bcp невозможно черезпользовательский интерфейс и наша организация не способствуют настройке за пределами пользовательского интерфейса из-за удобства обслуживания.

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

1 Ответ

6 голосов
/ 25 августа 2011

Мое предложение состояло бы в том, чтобы выполнить массовую загрузку в промежуточную таблицу (кучу или CI, соответствующий порядку файлов), (повторно) построить там кластерный индекс, соответствующий целевой таблице, а затем вставить прямо из промежуточной таблицы. Чтобы уменьшить блокировку, эскалацию, использование журналов и т. Д., Вы можете делать это партиями по 10000 строк за раз, фиксируя и / или делая контрольные точки так часто.

Вы также можете рассмотреть возможность использования препроцессора (возможно, C #), который берет файл журнала и создает новый с правильным порядком сортировки.

Также я думаю, что вы безопаснее используете sys.indexes и т. Д., Чем жестко кодировать структуры индекса в коде. Microsoft гораздо реже меняет имя столбца в sys.indexes, чем кто-либо в вашем магазине (без обид), изменит индекс, но забудет обновить жестко заданное определение в процедуре.

...