Как мне сжать мою базу данных SQL Server? - PullRequest
Новая
       203

Как мне сжать мою базу данных SQL Server?

50 голосов
/ 13 января 2009

У меня есть база данных размером почти 1,9 ГБ, а MSDE2000 не позволяет использовать базы данных, размер которых превышает 2,0 ГБ

Мне нужно сжать эту БД (и многие другие, подобные этой, в разных местах клиентов).

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

Так что теперь мне нужно уменьшить БД для учета отсутствующих записей.

  • Я выполняю DBCC ShrinkDatabase('MyDB') ...... Никакого эффекта.
  • Я испробовал различные средства сжатия, предусмотренные в MSSMS .... По-прежнему безрезультатно.
  • Я создал резервную копию базы данных и восстановил ее ... По-прежнему безрезультатно.

Still 1.9Gb

Почему?

Какую бы процедуру я в итоге ни нашел, ее необходимо воспроизвести на клиентском компьютере, не имеющем доступа ни к чему, кроме OSql или аналогичного.

Ответы [ 15 ]

90 голосов
/ 18 августа 2009 
ALTER DATABASE MyDatabase SET RECOVERY SIMPLE

GO

DBCC SHRINKFILE (MyDatabase_Log, 5)

GO

ALTER DATABASE MyDatabase SET RECOVERY FULL

GO
10 голосов
/ 13 января 2009

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

Шаг 1. Усечение журнала транзакций (резервное копирование только журнала транзакций с включением опции удаления неактивных транзакций)

Шаг 2: Запустите сжатие базы данных, переместив все страницы в начало файлов

Шаг 3: снова усечь журнал транзакций, так как шаг 2 добавляет записи журнала

Шаг 4. Запустите сжатие базы данных снова.

Мой урезанный код, который использует библиотеку SQL DMO, выглядит следующим образом: 

SQLDatabase.TransactionLog.Truncate();
SQLDatabase.Shrink(5, SQLDMO.SQLDMO_SHRINK_TYPE.SQLDMOShrink_NoTruncate);
SQLDatabase.TransactionLog.Truncate();
SQLDatabase.Shrink(5, SQLDMO.SQLDMO_SHRINK_TYPE.SQLDMOShrink_Default);
7 голосов
/ 16 ноября 2013

Это старый вопрос, но я только что натолкнулся на него.

Действительно короткий и правильный ответ уже дан и имеет большинство голосов. То есть как вы уменьшаете журнал транзакций, и это, вероятно, было проблемой OPs. И когда журнал транзакций выходит из-под контроля, его часто приходится сокращать обратно, но следует позаботиться о том, чтобы в будущем ситуация с журналом не вышла из-под контроля. Этот вопрос на dba.se объясняет это. В основном - не позволяйте ему стать настолько большим, во-первых, благодаря правильной модели восстановления, ведению журнала транзакций, управлению транзакциями и т. Д.

Но при чтении этого вопроса о сжатии файла данных (или даже файла журнала) у меня возникает больший вопрос: почему? и что плохого происходит при попытке? Похоже, что операции сжатия были сделаны. Теперь в этом случае это имеет смысл в некотором смысле - потому что выпуски MSDE / Express ограничены максимальным размером БД. Но правильным ответом может быть поиск правильной версии для ваших нужд. И если вы натолкнулись на этот вопрос, пытаясь уменьшить свою производственную базу данных, и это не причина, почему, вы должны задать себе вопрос почему? .

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

Сжатие файлов данных - это специальное задание, которое следует зарезервировать для особых случаев. Учтите, что когда вы уменьшаете базу данных, вы эффективно фрагментируете свои индексы. Учтите, что когда вы уменьшаете базу данных, вы забираете свободное пространство, в которое база данных может когда-нибудь снова вырасти, - эффективно тратите свое время и наносите удар по производительности операции сжатия только для того, чтобы увидеть, как БД снова растет.

Я писал об этой концепции в нескольких постах в блоге о сокращении баз данных. Вначале приходит на ум это " Не трогайте эту кнопку сжатия ". Я говорю об этих концепциях, изложенных здесь, а также о концепции «правильного определения размера» вашей базы данных. Гораздо лучше решить, каким должен быть размер вашей базы данных, спланировать будущий рост и распределить его на эту сумму. Мгновенная инициализация файлов, доступная в SQL Server 2005 и более поздних версиях для файлов данных, снижает стоимость прироста - но я все же предпочитаю иметь правильное начальное приложение - и я гораздо меньше боюсь пробелов в базе данных, чем я сжимается вообще без мыслей в первую очередь. :)

5 голосов
/ 28 июня 2017

Поздний ответ, но может быть полезным для кого-то другого

Если ни DBCC ShrinkDatabase / ShrinkFile, ни SSMS (Tasks / Shrink / Database) не помогают, есть инструменты от Quest и ApexSQL, которые могут выполнить работу и даже запланировать периодическое сжатие, если вам это нужно.

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

https://solutioncenter.apexsql.com/sql-server-database-shrink-how-and-when-to-schedule-and-perform-shrinking-of-database-files/

Все, что вам нужно сделать, это установить ApexSQL Backup, нажать кнопку «Сжать базу данных» на главной ленте, выбрать базу данных в появившемся окне и нажать «Готово».

5 голосов
/ 13 января 2009

DBCC SHRINKDATABASE работает для меня, но это полный синтаксис: 

DBCC SHRINKDATABASE ( database_name, [target_percent], [truncate] )

где target_percent - требуемый процент свободного места, оставшегося в файле базы данных после сокращения базы данных.

И truncate Параметр может быть: 

NOTRUNCATE

Заставляет освободить файловое пространство в файлах базы данных. Если не указано, освобожденное файловое пространство освобождается операционной системой. 

TRUNCATEONLY

Заставляет любое неиспользуемое пространство в файлах данных отправляться в операционную систему и сжимает файл до последнего выделенного размера, уменьшая размер файла без перемещения каких-либо данных. Не делается попытка переместить строки на нераспределенные страницы. target_percent игнорируется при использовании TRUNCATEONLY.

... и да, нет, все правильно, сокращение базы данных не очень хорошая практика, например:

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

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

В Интернете много блогов и статей об этом.

4 голосов
/ 08 января 2010

Вы должны использовать: 

dbcc shrinkdatabase (MyDB)

Это сократит файл журнала (оставьте проводник Windows открытым и увидите, что это происходит).

4 голосов
/ 13 января 2009

Вам также необходимо уменьшить отдельные файлы данных.

Однако не стоит сокращать базы данных. Например, см. здесь

2 голосов
/ 08 января 2010

«Поэтому разумно предположить, что теперь должно быть доступно много места».

Извиняюсь, если я неправильно понял вопрос, но вы уверены, что это пространство базы данных, а не файлов журналов? Проверьте, в какой модели восстановления находится база данных. Скорее всего, она в полном объеме, что означает, что файл журнала никогда не усекается. Если вам не нужна полная запись каждой транзакции, вы сможете изменить ее на Simple, что приведет к обрезанию журналов. Вы можете уменьшить базу данных во время процесса. Если предположить, что все идет хорошо, процесс выглядит следующим образом:

  1. Резервное копирование базы данных!
  2. Изменить на Простое восстановление
  3. Сжать дб (щелкните правой кнопкой мыши по дб, выберите все задачи> сожмите дб -> установите 10% свободного места)
  4. Убедитесь, что место было освобождено, в противном случае вам может потребоваться сделать полную резервную копию

Если это не сработает (или вы получите сообщение «файл журнала заполнен» при попытке переключения режимов восстановления), попробуйте следующее:

  1. Резервное копирование
  2. убить все подключения к БД
  3. Отсоединение БД (щелчок правой кнопкой мыши> Отсоединение или щелчок правой кнопкой мыши> Все задачи> Отсоединить)
  4. Удалить файл журнала (ldf)
  5. Повторно подключите БД
  6. Смена режима восстановления

и т.д.

2 голосов
/ 13 января 2009

Вот еще одно решение: используйте Мастер публикации баз данных , чтобы экспортировать вашу схему, безопасность и данные в сценарии sql. Затем вы можете перевести свою текущую БД в автономный режим и заново создать ее с помощью сценариев.

Звучит немного глупо, но есть пара преимуществ. Во-первых, нет никакой возможности потерять данные. Ваша исходная база данных (если вы не удаляете свою БД при ее удалении!) Безопасна, новая БД будет примерно такой маленькой, как может быть, и у вас будет два разных снимка вашей текущей базы данных - один готов накатить, один минимизированный - вы можете выбрать для резервного копирования.

1 голос
/ 23 июля 2014

Я наткнулся на этот пост, хотя мне нужно было использовать SHRINKFILE в версии MSSQL 2012, что немного сложнее, чем в версиях 2000 или 2005. После ознакомления со всеми рисками и проблемами, связанными с этой проблемой, я закончил тестирование. Короче говоря, лучшие результаты я получил от использования MS SQL Server Management Studio . 

Right-Click the DB -> TASKS -> SHRINK -> FILES -> select the LOG file
Страница:
...