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