Уменьшение размера резервного копирования SQL? - PullRequest
9 голосов
/ 20 августа 2009

Я использую SQL Express 2005 и делаю резервные копии всех БД каждую ночь. Я заметил, что одна БД становится все больше и больше. Я посмотрел на базу данных и не понимаю, почему она становится такой большой! Мне было интересно, если это что-то делать с файлом журнала?

Ищите советы о том, как выяснить, почему он становится таким большим, когда в нем не так много данных - также как оптимизировать / уменьшить размер?

Ответы [ 6 ]

16 голосов
/ 20 августа 2009

Несколько вещей для проверки:

  • ваша база данных находится в "Простом" режиме восстановления? Если это так, то в журнале транзакций будет намного меньше записей, а резервная копия будет меньше. Рекомендуется для разработки - но не для производства

  • если он находится в режиме восстановления «FULL» - вы регулярно делаете резервные копии журнала транзакций? Это должно ограничить рост журнала транзакций и, следовательно, уменьшить общий размер резервной копии

  • Вы уже запускали на нем DBCC SHRINKDATABASE(yourdatabasename) в последнее время? Это может помочь

  • есть ли у вас какие-либо таблицы журналов / журналов в вашей базе данных, которые просто заполняются со временем? Вы можете удалить некоторые из этих записей?

Чтобы найти модель восстановления базы данных, перейдите в обозреватель объектов, щелкните правой кнопкой мыши базу данных, выберите «Свойства», а затем выберите вкладку «Параметры» в диалоговом окне:

alt text

Марк

10 голосов
/ 05 июля 2013

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

Чтобы избежать этого, вы должны изменить параметры перезаписи. В SQL Management Studio щелкните правой кнопкой мыши по вашей БД, TASKS - BACKUP, затем в окне для резервного копирования вы увидите, что по умолчанию это страница «Общие». Измените это на «Опции», и вы получите другой набор вариантов.

Опция по умолчанию вверху - «Добавить к существующему набору носителей». Это то, что делает вашу резервную копию увеличиваться в размерах на неопределенный срок. Измените это на «Перезаписать все существующие наборы резервных копий», и резервная копия всегда будет иметь размер, равный только одной полной резервной копии, самой последней.

(Если у вас есть сценарий SQL, включите «NOINIT» в «INIT»)

ВНИМАНИЕ: Это означает, что резервная копия будет содержать только самые последние изменения - если вы допустили ошибку три дня назад, но у вас есть резервная копия только прошлой ночью, вы забиты. Используйте этот метод, только если у вас есть режим резервного копирования, который ежедневно копирует ваш файл .bak в другое место, поэтому вы можете вернуться к любому из этих файлов за предыдущие дни.

3 голосов
/ 20 августа 2009

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

Чтобы исправить это, вам необходимо:

  • Возьмите резервную копию журнала транзакций. (См .: BACKUP (TRANSACT-SQL) )
  • Уменьшите файл журнала транзакций вниз до соответствующего размера для ваших нужд. (См .: Как использовать DBCC SHRINKFILE ....... )
  • Расписание регулярного журнала транзакций резервные копии в соответствии с восстановлением данных требования.

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

Модели восстановления и управление журналом транзакций

Дополнительные сведения: Как остановить неожиданное увеличение журнала транзакций базы данных SQL Server

0 голосов
/ 22 февраля 2017

7zip файл резервной копии для архивирования. Я недавно сделал резервную копию базы данных в файл .bak размером 178 МБ. После архивации в файл .7z это было только 16 МБ. http://www.7 -zip.org /

Если вам нужен инструмент для архивирования, который работает с файлами большего размера более эффективно и быстрее, чем 7zip, я рекомендую взглянуть на LZ4. Я использовал его для архивации резервных копий файлов в течение многих лет без проблем: http://lz4.github.io/lz4/

0 голосов
/ 16 декабря 2009

по мере того, как вы делаете ежедневное ПОЛНОЕ резервное копирование для своей базы данных, конечно, со временем оно станет таким большим. поэтому вы должны составить план для себя. как это 1-й день: ПОЛНЫЙ / 2-й день: ДИФФЕРЕНЦИАЛ / 3-й день: ДИФФЕРЕНЦИАЛ / 4-й день: ДИФФЕРЕНЦИАЛ / 5-й день: ДИФФЕРЕНЦИАЛ

и затем начните сначала.

и когда вы восстанавливаете свою базу данных, если вы хотите восстановить ПОЛНУ, вы можете сделать это легко, но когда вам нужно восстановить версию DIFF, вы создаете резервную копию первого ПОЛНОГО перед ней с помощью «NO-recovery», затем нужно, и тогда вы вернете свои данные в целости и сохранности.

0 голосов
/ 20 августа 2009

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

Например, у вас может быть таблица состояния, вам действительно нужно, чтобы индекс представлял собой int, когда подойдет smallint или tinyint?

Darknight

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...