Лучший способ развернуть новый индекс на очень большой таблице в SQL Server 2008
У меня есть база данных в производстве с одной таблицей, которая стала чрезвычайно большой (много накопленных данных).
Для улучшения производительности запросов, я использовал оптимизатор SQL-сервера, который предложил новый индекс.
Таким образом, я сделал копию производственной базы данных для тестирования против, и она действительно улучшает производительность, однако моя проблема состоит в том, что потребовалось приблизительно 24 часа для создания индекса и в то время как индекс создается, приложение неприменимо.
Для этого конкретного приложения, снижающегося в течение нескольких часов, не проблема, а 24-часовое время простоя было бы, и я ищу способ создать этот индекс, не имея необходимость делать это.
У меня только есть несколько идей в данный момент.
Одна идея состоит в том, чтобы скопировать резервное копирование на другой сервер. Примените новый индекс и любые другие изменения. Скопируйте резервное копирование назад на рабочий сервер. Удалите приложение и слияние по любым новым данным с тех пор, когда я взял резервное копирование.
Конечно, это имеет его собственный набор проблем как необходимость объединить данные назад вместе, таким образом, мне не нравится эта идея по этой причине.
Это - Стандарт SQL Server 2008 года Ed.
Я обычно развертываю изменения базы данных сценарием.
ОБНОВЛЕНИЕ: Другая идея состояла бы в том, чтобы переместить данные архива из основной таблицы за несколько дней в блоках. Тогда создайте индекс, когда таблица стала достаточно маленькой. Тогда медленно перемещайте данные назад.
3 ответа
Учитывая недостаток вычислительной мощности, доступной на виртуальной машине, в сочетании с, несомненно, довольно низкой пропускной способностью ввода-вывода, я бы действительно рассмотрел возможность расчета времени для резервного копирования, восстановления на полуприличном сервере, индексации, а затем резервного копирования / восстановления обратно на виртуальную машину.
Чтобы начальное резервное копирование не занимало много времени, можно сделать резервную копию в один день и перемещать ее в течение дня, а затем, когда начнется окно обслуживания, сделать резервную копию журнала транзакций и переместить его - на основании того, что это будет меньшее перемещение. (Это предполагает режим массового / полного журнала)
Если вы использовали Enterprise, вы могли бы использовать опцию ONLINE в CREATE INDEX , которая строит индекс без сохранения долгосрочных блокировок таблицы. Есть предостережения относительно его использования; см. подробную информацию в связанной статье, и вы можете обнаружить, что влияние на производительность будет слишком большим. Но это академично, поскольку вы сказали, что используете стандарт (извините за то, что сначала пропустил).
Тот факт, что это виртуальная машина, сразу наводит на мысль о временном «накачивании» виртуальной машины или даже о временном перемещении на максимально загруженную не-виртуальную машину. Я бы подумал, что при перестроении индекса для очень большой таблицы важнейшими факторами будут оперативная память и скорость ввода-вывода; виртуальная машина использует диск напрямую или виртуализированный диск? Можете ли вы временно переместить данные на физический диск? Что-то в этом роде.
FWIW, ваша идея «взять его в автономный режим и сделать это» - это именно то, что я бы сделал с базой данных MySQL (никогда не приходилось делать с базой данных SQL Server): отключите основную БД, сделайте снимок, очистить журналы / включить ведение журналов и запустить его обратно. Сделайте индекс на отдельной машине. Когда все будет готово, отключите БД, сделайте резервную копию обновленной БД (на всякий случай), верните снимок, примените бинлоги и верните БД обратно. Это действительно так просто; Я полагаю, что вы можете сделать это и с SQL Server. Конечно, предполагается, что вы можете применить 24 часа бинарных журналов к (недавно оптимизированной) таблице в приемлемом временном окне!
Завершающий блок всегда выполняется, за исключением следующего примера:
String test() {
try {
System.exit(0);
} finally {
return "2";
}
}
В этом случае JVM останавливается без выполнения завершающего блока .
В данном примере возвращаемое значение будет 2 .
Нельзя использовать именованные параметры в самом JDBC. Можно попробовать использовать рамку Spring, поскольку она имеет некоторые расширения, позволяющие использовать именованные параметры в запросах.
-121--914045-Другим подходом может быть не реализация индексов для всех таблиц, предложенных оптимизатором SQL Server, а первая реализация для одной таблицы или группы таблиц. Как вы упомянули, несколько часов простоя в порядке, поэтому с помощью этих нескольких часов запланируйте различные таблицы, для которых необходимо выполнить индексацию. Теперь ежедневно выбирайте таблицы, индексы которых могут быть построены при данном времени простоя. Умная работа может легко решить эту проблему.
К нам подошел тот же сценарий, когда мы могли получить только 1 часов простоя ежедневно, и мы сделали тот же подход и в течение 9 дней были сделаны новые индексы, и время простоя также было эффективно использовано.
Надеюсь, это поможет...