В настоящее время используется инструмент Informatica, и у нас есть хранимые процедуры, которые удаляют кластеризованные индексы, а затем добавляют их обратно в базу данных. В хранимой процедуре, где мы добавляем кластеризованные индексы обратно, у нас есть DDL для индексов, жестко запрограммированный в хранимой процедуре (мы не используем системные таблицы, потому что опасение, что Microsoft изменит системные таблицы и регенерирует оттуда, создает плохой индекс или терпит неудачу). Это вызывает проблемы, когда люди создали кластеризованные индексы, но не подумали об обновлении хранимой процедуры, и в следующий раз, когда происходит массовая обработка, эти индексы исчезнут. Ранее мы сделали это для всех индексов, но переключили некластеризованные индексы на использование отключения/перестроения. Это не вариант, потому что мы больше не сможем вставлять в таблицу, если это делается для кластеризованного индекса, потому что это, по сути, таблица.
Производительность важна, но не все. Хорошая производительность и простота обслуживания превосходят высокую производительность и сложную ремонтопригодность.
После прочтения многих сайтов почти все согласны с тем, что при выполнении массовой вставки данных, упорядоченных не так, как ваш первичный ключ, вставка в кучу с последующим применением pk выполняется быстрее ( http://msdn.microsoft.com/en-us/library/ms177445.aspx , http://msdn.microsoft.com/en-us/library/dd425070(v=sql.100).aspx). Большинство этих сайтов делают предположения, которые я не могу использовать в своей организации и с моим набором инструментов.
В настоящее время из-за наших текущих политик стандартов мы должны использовать ПОЛНУЮ модель восстановления, поэтому минимальное ведение журнала не будет происходить независимо от того, какой выбор я делаю в отношении кучи или кластеризованного индекса.
По словам наших администраторов информатики, указание подсказок tablock или порядка в bcp невозможно через пользовательский интерфейс, и наша организация не приемлет настройку за пределами пользовательского интерфейса из-за удобства обслуживания.
Таким образом, вопрос после всего этого заключается в том, что со всеми вышеперечисленными факторами вы бы порекомендовали нам продолжить наши несколько ненадежные хранимые процедуры, вставить в кластеризованный индекс или иметь какое-то третье решение, намного превосходящее его. Я также понимаю, что есть другие вопросы о стеке, похожие на этот пункт, но они не касаются конкретно массы и/или не делают подобных предположений в своих ответах.
