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

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

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

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

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

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

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