Назад | Перейти на главную страницу

Как восстановить базу данных SQL Server и одновременно сжать ее файлы?

Допустим, у меня есть база данных SQL Server, файлы данных которой были созданы с начальным размером 100 ГБ, но она содержит только 10 ГБ данных. Тогда размер резервной копии базы данных составит всего 10 ГБ.

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

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

Есть ли способ восстановить базу данных и он должен занимать столько места, сколько фактические данные, которые он содержит?

Нет, извините - никак. Восстановить восстанавливает файлы в том виде, в котором они были при резервной копии. Шинки нужно делать после этого или до создания резервной копии.

Если у вас мало места на диске, вы можете поместить файл .bak в общий сетевой ресурс и восстановить его оттуда. Должно работать, если ваш запущенный sql-сервер с учетной записью домена и предоставил общему ресурсу достаточно прав для чтения файла.

Другой вариант, который ранее был в корзине «Вы ешьте орехи» (но полезен только в том случае, если у вас запущен sql server 2008 r2), является то, что SQL Server поддерживает создание файлов базы данных непосредственно в общий ресурс без использования флага трассировки, и я могу сказать из личного опыта у вас это работает! Таким образом, вы можете восстановить общую папку С ПЕРЕМЕЩЕНИЕМ.

Вообще-то нет. Несколько случайных идей, которые могут вам помочь, а могут и не помочь:

  • Если вам абсолютно не нужны данные из эта конкретная резервная копия, то вы можете создать новую (пустую) базу данных целевого размера и использовать массовые копии (или SSIS) для переноса всех таблиц из текущей (активной) базы данных в вашу копию.
  • Существуют сторонние инструменты (например, Redgate Compare), которые могут помочь автоматизировать такие вещи, если это более чем одноразовая операция.
  • Некоторые сторонние программы резервного копирования (например, Quest Litespeed) могут выполнять операцию "восстановление на уровне объекта", который может восстанавливать отдельные таблицы или другие объекты в новую (пустую) базу данных. Даже если резервная копия не была создана с помощью Litespeed, я считаю, что продукт должен работать с резервными копиями Native SQL.

Наконец, мне тоже нравится некоторая «просторность» в моих производственных базах данных, но 90 ГБ без общих 100 ГБ звучат немного чрезмерно. Следующие шаги могут дать вам то, что вам нужно, и не должны повлиять на производство:

  1. Запустить DBCC SHRINKFILE ('myfile.MDF', TRUNCATEONLY) в файле производственных данных, чтобы временно освободить любое свободное пространство в конце файла (TRUNCATEONLY не требует интенсивного ввода-вывода и не будет фрагментировать индексы)
  2. Если файл журнала тоже большой, запустите DBCC SHRINKFILE в производственном файле журнала в период низкой активности сразу после создания резервной копии журнала.
  3. Запустите резервную копию
  4. Сделайте ALTER DATABASE MODIFY FILE для повторного увеличения файла производственных данных до исходного размера.

Эти шаги не должны повлиять на производство. Единственный риск заключается в том, что некоторые данные просто оказываются в самом конце файла данных размером 100 ГБ, и в этом случае шаг (1) не освободит много места, если вообще будет.