У меня есть 3 очень большие таблицы с кластерными индексами на составных ключах.Нет обновлений, только вставки.Новые вставки не будут в пределах существующего диапазона индекса, но новые вставки не будут совмещены с кластеризованным индексом, и эти таблицы получают много вставок (сотни - тысячи в секунду).Что вы хотели бы сделать - это DBREINDEX с коэффициентом заполнения = 100, но затем установить коэффициент заполнения 5 и применить этот коэффициент заполнения ТОЛЬКО к вставкам.В настоящее время коэффициент заполнения применяется только ко всей таблице.Есть ли способ иметь коэффициент заполнения, который применяется только к вставкам (или вставкам и обновлениям)?Я не забочусь о выбранной скорости в это время.Я загружаю данные.Когда загрузка данных будет завершена, я установлю DBREINDEX на 100. Коэффициент заполнения 10 против 30 удваивает скорость, с которой вводятся новые данные.Эта загрузка займет пару дней и не может быть запущена, пока данные не будут загружены.Кластерные индексы выровнены с доминирующим запросом, используемым приложением конечного пользователя.
Моя практика заключается в ежедневном использовании DBREINDEX, но проблема в том, что таблицы становятся большими, 10 DBREINDEX занимает много времени.Я рассмотрел возможность индексирования в «ежедневные» таблицы, а затем вставлять эти данные, ежедневно отсортированные по кластерному индексу, в рабочие таблицы.Все индексы составные, и я запускаю 6 экземпляров синтаксического анализатора на 8-ядерном сервере (много тестирований, и это, похоже, имеет лучшую пропускную способность).Данные из SINGLE-парсера располагаются в порядке PK, и я делаю вставки 990 значений за раз (пределы значений SQL).3 активные таблицы обмениваются данными только через отношение внешнего ключа с одной относительной неактивной 4-й таблицей.В настоящее время я думаю о том, чтобы иметь таблицы хранения для каждого анализатора, а затем создать другой процесс, который опрашивает эти таблицы для следующей полной вставки и перемещает данные в рабочую таблицу в порядке PK.Это будет много работы.Я надеюсь, что у кого-то есть идея получше.
Разборы начинаются в порядке PK, но редко заканчиваются в порядке PK.Некоторые отдельные разборы настолько велики, что я не смог удержать все данные в памяти до конца.Прямо сейчас вставка SQL немного быстрее, чем анализ, который создает данные.При индивидуальном разборе я запускаю асинхронную вставку и продолжаю синтаксический анализ, но не вставляю до завершения предыдущей вставки.