Как уменьшить размер базы данных SQL Server?

Ответ 1

ALTER DATABASE MyDatabase SET RECOVERY SIMPLE

GO

DBCC SHRINKFILE (MyDatabase_Log, 5)

GO

ALTER DATABASE MyDatabase SET RECOVERY FULL

GO

Ответ 2

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

Шаг 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);

Ответ 3

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

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

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

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

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

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

Ответ 4

Вам также потребуется сжать отдельные файлы данных.

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

Ответ 5

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

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

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

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

NOTRUNCATE

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

TRUNCATEONLY

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

... и да no_one прав, сокращение datbase не очень хорошая практика, например, например:

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

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

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

Ответ 6

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

dbcc shrinkdatabase (MyDB)

Он сжимает файл журнала (держите проводник Windows открытым и просматривайте его).

Ответ 7

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

Если ни 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, нажать кнопку "Shrink database" на главной ленте, выбрать базу данных в появившемся окне и нажать "Готово".

Ответ 8

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

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

Ответ 9

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

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

• Резервное копирование базы данных!
• Изменить на простое восстановление
• Сжатие db (щелкните правой кнопкой мыши db, выберите все задачи > shrink db → установите на 10% свободного места)
• Убедитесь, что пространство было исправлено, если вам не нужно выполнять полную резервную копию

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

• Резервное копирование
• Убейте все подключения к db
• Отсоедините db (щелкните правой кнопкой мыши > Отсоединить или щелкните правой кнопкой мыши > Все задачи > Отсоединить)
• Удалить файл журнала (ldf)
• Перезагрузите db
• Измените режим восстановления

и др.

Ответ 10

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

Right-Click the DB -> TASKS -> SHRINK -> FILES -> select the LOG file

Ответ 11

Вам также необходимо изменить минимальный размер файлов данных и журналов. DBCC SHRINKDATABASE сократит данные внутри файлов, которые вы уже выделили. Чтобы уменьшить размер файла до его минимального размера, используйте DBCC SHRINKFILE и укажите новый размер.

Ответ 12

Удалите данные, убедитесь, что модель восстановления проста, затем скройтесь (сократите базу данных или сократите файлы). Если файл данных все еще слишком велик, и вы используете кучи для хранения данных, то есть без кластеризованного индекса на больших таблицах, - тогда у вас может возникнуть проблема с удалением данных из куч: http://support.microsoft.com/kb/913399

Ответ 13

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

Ответ 14

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

• дефрагментация физического диска
• создать новую базу данных в соответствии с моими требованиями, пространство, процентный рост и т.д.
• используйте простую задачу ssms для импорта всех таблиц из старого db в новый db
• script вывести индексы для всех таблиц старой базы данных, а затем воссоздать индексы в новой базе данных. расширяться по мере необходимости для внешних ключей и т.д.
• переименуйте базы данных по мере необходимости, подтвердите успешное, удалите старые