У меня есть зеркальная база данных в режиме полной безопасности на sql server 2008 R2 Standard Edition. Я хочу создать план обслуживания для еженедельного перестройки и реорганизации индексов. В планах обслуживания заданы полные резервные копии 3 раза в день и резервные копии журналов транзакций каждые 30 минут. База данных очень активна и получает много трафика. Я попытался перестроить индексы вручную в непиковые часы, и это привело к значительному разрастанию файла журнала как в принципе, так и на зеркале.
Есть ли какие-то конкретные шаги, которые необходимо выполнить для восстановления индексов в среде зеркалирования? Я поискал в Интернете, но не нашел никакой разницы в том, как индексы перестраиваются при зеркальном отображении и без зеркального отображения.
Также могу ли я просто использовать DBCC SHRINKFILE по принципу освобождения неиспользуемого пространства в файле журнала без остановки зеркалирования?
Я бы настоятельно не рекомендовал вам регулярно сжимать журнал в зеркальной ситуации. Однажды ваш журнал будет расти на первичном сервере и не будет иметь дискового пространства для роста на зеркале, первичный не сможет отправлять журнал и будет закреплять журнал на месте до тех пор, пока он не разрастется до тошноты, и вы будете проклинать работу, которая уменьшил ваш журнал, так как вы не сможете возобновить зеркалирование без некоторых сложных хоккейных игр.
Если журнал растет, значит, ему нужно дополнительное место. В конце концов, он стабилизируется до нужного размера и перестанет расти. Этот размер, каким бы он ни был, является рабочим размером, необходимым для вашего журнала. Во всяком случае, вам следует расти ваш журнал прямо сейчас, поэтому он перестает расти автоматически.
Что касается обслуживания индекса, есть ли у вас доказательства того, что его нужно перестраивать с той периодичностью, которую вы предлагаете? Невозможно избежать уменьшения пространства журнала, необходимого во время операций перестроения индекса, если база данных является зеркальной.
Да - существует большая разница в перестроении индексов для незеркальных баз данных и зеркальных баз данных. Воздействие выше, и перед этим нужно проверить некоторые вещи.
Самое главное, что вы должны перейти от полной безопасности к высокой производительности на период обслуживания, чтобы оно не дожидалось зеркала при реорганизации индекса.
Если это действительно необходимо, файл журнала можно сжать, но он не вступит в силу, если в нем есть активные транзакции, резервные копии которых не созданы. Сжатие может быть выполнено в зеркальной базе данных теоретически, но не делайте этого с файлами данных потому что фрагментация по индексам очень вырастет.