Вопрос: Как исключить индексы из резервных копий в SQL Server 2008


Наши ночные полные (и периодические дифференциальные) резервные копии становятся довольно большими, главным образом из-за количества индексов на наших таблицах; примерно половина размера резервной копии состоит из индексов.

Мы используем просто модель восстановления для наших резервных копий.

Есть ли способ, используя FileGroups или какой-либо другой способ разбиения файлов на исключать индексы из резервных копий?

Было бы неплохо, если бы это можно было распространять и на полнотекстовые каталоги.


18
2018-04-30 06:49


Источник




Ответы:


Если вы перейдете в режим полного восстановления, вы можете сделать это с файловыми группами, но это действительно очень неуклюжий. Вы оставляете данные в основной файловой группе и помещаете индексы в отдельную (не по умолчанию, это ключевую) файловую группу.

Затем вы размещаете резервные копии так, чтобы каждую неделю выполняли резервное копирование основной группы файлов и резервное копирование журнала транзакций каждые X минут.

Когда происходит стихийное бедствие, вы восстанавливаете основную файловую группу самостоятельно. Данные внезапно появляются в сети, но индексы - нет. Однако, чтобы вернуться к нормальной жизни, вам нужно будет экспортировать эти данные в новую чистую базу данных и добавить туда индексы. Вы не можете полностью загрузить базу данных без восстановления всех файловых групп, и вы не можете сказать «Мне больше не нужна эта другая файловая группа».

Подробнее о том, как это работает, проверьте мои видео-учебник по файловой группе восстанавливается.


14
2018-04-30 12:06



Хе-хе, я переместил некластеризованные индексы в свою собственную файловую группу; модель простого восстановления полностью сокрушила меня. Индексы были на самом деле больше, чем данные - как он насмехался надо мной! Ну, может, какая-то третья сторона выпустит волшебную пулю Подсказка Подсказка :) - Jarrod Dixon♦
И, может быть, просто, возможно, вы получите бесплатное лицензирование. ;-) - Brent Ozar


Честно говоря, вы действительно не хотите этого делать, даже если вы преодолеете другие проблемы, которые другие поднимают здесь.

Когда вы восстанавливаете резервную копию в чрезвычайной ситуации, вы не хотите ждать восстановления индексов, и вы будете испытывать отвратительную производительность до тех пор, пока не сделаете это.

Я не могу думать о ситуации, когда вы хотите восстановить резервную копию без индексов, поэтому во всех случаях вы действительно захотите создать резервную копию в одно и то же время.

Вам, вероятно, придется искать другие решения этой проблемы ...

-Адам


5
2018-04-30 17:16



«вы не хотите ждать, пока индексы перестроят», очень презумптивный, ИМО - Jeff Atwood
Да, но имейте в виду, что я обобщаю здесь. Я не был уверен, что есть больше ситуаций, когда лучше откачать индексы и перестраивать, чем ситуации, когда лучше создавать резервные копии индексов и избегать пересоединения. Другими словами, один случай в общем лучше, и если конкретная ситуация не требует этого, нужно ошибаться на стороне их поддержки. При этом каждая ситуация отличается. Мне любопытно узнать, сколько времени потребуется для восстановления индексов SO, и насколько производительность сайта страдает до тех пор, пока они не будут выполнены (при условии, что это произойдет при восстановлении). - Adam Davis
Долгосрочное архивное резервное копирование - это конкретный случай использования, который я сейчас рассматриваю, что привело меня к этому вопросу. У меня есть проект, который завершен и больше не нужен база данных в Интернете, но также не нужно загромождать наш сетевой диск большим файлом резервной копии, чем это необходимо. Я не хочу потерять определения индексов, но не буду возражать против их восстановления, если мне когда-нибудь понадобится восстановить это снова. - richardtallent


Звучит так, будто это не поддерживается. Из этого Информация об ошибке:

В этом был большой интерес, поэтому я расскажу немного подробнее о том, что происходит за кулисами, и что это значит реализовать эту функциональность.   Некоторые типы индексных страниц разделяются на отдельные единицы распределения, а другие - на страницы данных.   Если в настоящее время мы смотрим только на растровое изображение распределения, чтобы узнать, выделена ли выделенная область, теперь нам нужно будет войти и интерпретировать то, что хранится в каждой единице распределения. Кроме того, теперь мы не сможем просто выполнять линейное сканирование файлов данных, копируя данные, и мы будем пропускать их в файле.   Вся эта интерпретация структур данных резко замедлит резервное копирование. Восстановление становится еще более интересным, потому что есть много структур, которые нужно было бы исправить, чтобы учесть дыры в резервной копии. В противном случае у вас будут карты распределения, указывающие на страницы, которые не были скопированы, и поэтому у них есть мусор и т. Д. И т. Д.   Таким образом, реализация этого будет означать, что мы сохраним меньше данных, займем больше времени и продолжим восстановление.   Другим аспектом, который следует учитывать, является то, что для этого все потребуется много усилий, чтобы все было в порядке. Хотя это не ваша проблема на поверхности, считайте, что это означает, что другие функции, которые вы, возможно, захотите увидеть, не будут созданы.


3
2018-04-30 08:44



Это не будет проблемой для полнотекстовых индексов, не так ли? Они, как правило, довольно большие. - Michael Teper


может быть сумасшедшей идеей, но здесь идет.

  1. отбросьте некластеризованные индексы, занимающие много места
  2. сделать резервную копию
  3. заново создайте индексы, которые вы уронили

Конечно, вы можете это сделать только в том случае, если в базе данных вы можете провести некоторое время в день.

Кроме того, не удаляйте кластеризованные индексы, так как SQL Server будет тратить много времени, превращая их в кучу.

Покупает ли это дополнительное дисковое пространство еще проще?

Вы считали, что делаете сжатые резервные копии? это новая функция 2008 года, это может быть для вас вариант.


1
2018-05-04 03:49



Да, мы включили сжатие для резервных копий, но встроенное сжатие не так уж и велико. У нас на самом деле есть резервная копия в конце недели, а не 7-битная резервная копия, а затем 7zip для разработчиков. это около 1/3 размера, но это займет некоторое время, чтобы бежать! - Jarrod Dixon♦
Что касается простоя DB, можем ли мы действительно жить без обоих serverfault.com а также stackoverflow.com насколько это возможно? Я вздрагиваю от этой мысли :) - Jarrod Dixon♦
Я сам его не тестировал, но я подозревал, что так много. Он не очень настраиваемый. Если вы все еще рассматриваете сжатие как вариант, взгляните на SQL Lightspeed (дорого, но удивительно, но цена очень оборотный) и резервное копирование RedGate. Очень настраиваемые и отличные результаты - Nick Kavadias