Наши ночные полные (и периодические дифференциальные) резервные копии становятся довольно большими, в основном из-за количества индексов в наших таблицах; примерно половина размера резервной копии состоит из индексов.
Мы используем просто модель восстановления для наших резервных копий.
Есть ли способ, используя FileGroups или какой-либо другой метод разделения файлов, чтобы исключить индексы из резервных копий?
Было бы неплохо, если бы это можно было распространить и на полнотекстовые каталоги.
Если вы переключитесь в режим полного восстановления, вы можете сделать это с файловыми группами, но это действительно очень неудобно. Вы оставляете данные в основной файловой группе, а индексы помещаете в отдельную (не по умолчанию, это ключевую) файловую группу.
Затем вы распределяете резервные копии так, чтобы резервное копирование файловой группы основного выполнялось каждую ночь, а резервное копирование журнала транзакций - каждые X минут.
В случае аварии вы самостоятельно восстанавливаете основную файловую группу. Данные внезапно оказываются в сети, а индексы - нет. Однако, чтобы вернуться к нормальной работе, вам нужно будет экспортировать эти данные в новую чистую базу данных и добавить оттуда индексы. Вы не можете полностью вывести базу данных в оперативный режим без восстановления всех файловых групп, и вы не можете сказать: «Мне все равно больше не нужна эта другая файловая группа».
Подробнее о том, как это работает, читайте в моем видеоурок по восстановлению файловых групп.
Честно говоря, вы действительно не хотите этого делать, даже если вы преодолеете другие проблемы, которые здесь поднимают.
Когда вы восстанавливаете резервную копию в чрезвычайной ситуации, вы не хотите ждать, пока индексы перестроятся, и пока вы этого не сделаете, у вас будет ужасная производительность.
Я не могу представить себе ситуацию, когда вы захотите восстановить резервную копию без индексов, поэтому во всех случаях вы действительно захотите создать их резервную копию одновременно.
Вероятно, вам придется искать другие решения этой проблемы ...
-Адам
Похоже, это не поддерживается. Из этого информация об отчете об ошибке:
Это вызвало большой интерес, поэтому я расскажу немного подробнее о том, что происходит за кулисами, и о том, что будет означать реализация этой функции. Некоторые типы индексных страниц разделены на отдельные единицы размещения, а другие смешаны со страницами данных. Если в настоящее время мы смотрим только на битовую карту распределения, чтобы увидеть, выделен ли экстент, теперь нам нужно будет войти и интерпретировать то, что хранится в каждой единице распределения. Кроме того, теперь мы не могли бы просто выполнять линейное сканирование файлов данных, копируя данные, мы бы пропустили файл. Вся эта интерпретация структур данных резко замедлит резервное копирование. Восстановление становится еще более интересным, потому что существует множество структур, которые необходимо исправить, чтобы учесть дыры в резервной копии. В противном случае у вас были бы карты распределения, указывающие на страницы, для которых не было выполнено резервное копирование, и поэтому на них есть мусор и т.д. дольше восстанавливать его. Другой аспект, который следует учитывать, - это то, что для этого потребуются большие инженерные усилия. Хотя на первый взгляд это не ваша проблема, учтите, что это означает, что другие функции, которые вы, возможно, захотите увидеть, не будут построены.
может быть безумной идеей, но начнем.
Конечно, вы действительно можете сделать это, только если ваша база данных допускает некоторый простой в течение дня.
Кроме того, не удаляйте кластеризованные индексы, поскольку SQL Server будет тратить много времени на их преобразование в кучу.
Кажется ли покупка дополнительного дискового пространства более простым решением?
Вы думали сделать сжатые резервные копии? это новая функция 2008 года, возможно, это вариант для вас.