Shrink database sql server: Shrink a database — SQL Server

Содержание

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

какой смысл задавать начальный размер после создания базы данных?

Предположим, вы имели в виду:

какая польза от установки начального размера при создании базы данных ?

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

Одной из ваших долгосрочных целей при создании базы данных должно быть сведение к минимуму или полное устранение всех без исключения событий изменения размера файла. Не всегда возможно быть на 100 % точным с точки зрения планирования емкости, но вы должны иметь в виду, например, сколько данных вы ожидаете собрать в течение следующего месяца, года и т. д. Это может быть немного сложнее для журналы, но как только вы узнаете, сколько данных вы ожидаете, вы можете сделать грубый расчет размера журнала с помощью такой формулы (эта идея пришла от Джеффа Хитена и на самом деле только вчера пересекла мой стол):

 (наибольший индекс * 1,25)
+
(наибольший объем журнала, созданный во время выполнения переиндексации * 2. 1)

Таким образом, если размер вашего самого большого индекса составляет 4 ГБ, а при последнем переиндексировании было создано 2 ГБ журнала, то 4 * 1,25 + 2 * 2,1 = 9,2 ГБ файла журнала. Это даст вам файл журнала, который может справиться с вашей типичной перестройкой, включая откат, если это произойдет, без необходимости увеличивать физический файл.

Оптимальные настройки автоматического роста немного сложнее предсказать, потому что это баланс. Вы хотите свести к минимуму количество раз, когда файлы будут увеличиваться, но также свести к минимуму время, необходимое для каждого увеличения. Это означает, что вам никогда не нужен размер прироста в 1 МБ. Предположим, у вас есть транзакция, которая вставит 15 МБ данных. Гораздо лучше увеличиться на 50 МБ один раз, чтобы приспособиться к этому росту (и следующим двум транзакциям точно так же), чем увеличиваться за 15 независимых событий роста. И вам, вероятно, тоже не нужен размер прироста в 20 ГБ, так как это может занять слишком много времени само по себе. В частности, для файлов журналов, поскольку они не могут извлечь выгоду из мгновенной инициализации файла, лучше ошибиться в сторону меньшего размера, но я не знаю, существует ли какое-либо оптимальное магическое число, не зная среднего размера вашей типичной транзакции, а также характеристики производительности хранилища, в котором находится лог-файл.

Опять же, весь смысл в том, чтобы избежать событий роста и сокращения, как чумы.

Хотя иногда это необходимо, события увеличения и уменьшения отрицательно сказываются на производительности вашей базы данных. Рост — даже при включенной мгновенной инициализации файлов, которая возможна только для файлов данных, поскольку файлы журналов в любом случае должны быть обнулены — требует, чтобы все транзакции приостанавливались, пока файл(ы) расширяются. Сжатие обычно вызывает фрагментацию, которая, особенно при медленном вводе-выводе, может ощущаться при чтении больших таблиц. С SSD это становится все менее актуально, да и не так важно, когда все ваши данные помещаются в память. Но за исключением того и другого…

Чего я не понимаю в людях, которые постоянно сжимают свои файлы, так это зачем? Если ваши данные или файл журнала однажды выросли до этого размера, они снова вырастут до этого размера. Освобождение места тем временем кажется мне бесполезным. Для чего вы собираетесь использовать пространство в то же время? Вы не можете ничего поместить туда, потому что вам нужно оставить место свободным, чтобы SQL Server мог снова увеличить файл, затем вы можете снова уменьшить его, а затем он снова может увеличиться. И так далее.

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

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

http://www.sqlskills.com/blogs/paul/why-you-should-not-shrink-your-data-files/
https://sqlblog.org/2009/07/27/oh-the-horror-please-stop-telling-people-they-should-shrink-their-log-files
http://www.straightpathsql.com/archives/2009/01/dont-touch-that-shrink-button/
http://www.brentozar.com/archive/2009/08/прекратите-сжимать-ваши-базы-файлов-серьезно-сейчас/

Почему регулярное сжатие НЕ является правильным способом высвобождения пространства базы данных в SharePoint или в любой базе данных SQL Server — Узнайте о высокой доступности и аварийном восстановлении SQL Server

Блог

PostWhy регулярное сжатие НЕ является правильным способом высвобождения пространства базы данных в SharePoint, а также в любой базе данных SQL Server

в Без рубрики

Оставить комментарий

Недавно я получил вопрос о том, как освободить место в базе данных в SharePoint. Конкретная упомянутая база данных была WSS_Logging , хотя это могла быть любая из баз данных SharePoint или любая другая база данных SQL Server, если на то пошло. База данных росла очень быстро, поэтому ферма была настроена на хранение данных только за неделю. Но поскольку база данных не стала меньше, они решили уменьшить ее, чтобы освободить место. На что я ответил: « У вас заканчивается свободное место на диске? ”

Почему я против регулярного сокращения базы данных

Я все еще регулярно вижу это – план обслуживания базы данных, который ежедневно создает резервные копии и уменьшает базу данных после задачи обслуживания индекса. Причина этого в том, что администратор просто хочет каждый день освобождать место на диске. Очень хорошие намерения без понимания последствий действия. Вот почему я не тороплюсь, чтобы объяснить, почему регулярно сжимать базы данных — плохая идея.

В предыдущей записи блога я говорил о том, что базы данных подобны коробкам, которые каждый день наполняются содержимым. По мере заполнения поля количество свободного места уменьшается. Но если вы знаете, что вам нужно будет заполнить его большим количеством контента, разве вы не купите коробку побольше? К сожалению, это не то, что мы делаем, когда сокращаем базы данных. По сути, мы выбрасываем коробку со свободным пространством, чтобы заменить ее коробкой меньшего размера, в которой достаточно места для хранения всего существующего контента. Представьте, что бы вы сделали, чтобы выполнить эту задачу — выгрузить коробку из ее содержимого, выбросить коробку, заменить ее коробкой меньшего размера и положить содержимое обратно. один только для того, чтобы увидеть, как кто-то другой завтра заменит его на больший (этот кто-то другой использует SQL Server, запускающий авторост для размещения новых данных, хранящихся в базе данных). Но это похоже на то, что происходит с вашими базами данных каждый раз, когда вы их сжимаете — Вы в основном тратите ресурсы каждый раз, когда делаете это.

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

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

Идем дальше. Представьте себе план обслуживания базы данных, в котором сразу за задачей обслуживания индекса следует задача сокращения базы данных. Фу! Вы только что фрагментировали индексы, которые были дефрагментированы в вашей базе данных.

Поясню кое-что. Я не против сокращения баз данных, особенно в экстренной ситуации, когда есть риск простоя из-за нехватки места на диске. Кроме того, есть и другие способы решения проблемы с дисковым пространством, такие как добавление нового файла и перемещение в него данных. Я просто не люблю регулярно сжимать базы данных. Итак, сделайте себе одолжение и проверьте, есть ли в ваших планах обслуживания базы данных Задача сокращения базы данных включена везде. Если вы не можете, попросите администратора базы данных убедиться, что у вас его нет. Удалите его, если найдете. Игнорируйте все, что любой эксперт по SharePoint говорит вам об обратном, даже если ответ приходит с форума TechNet/MSDN и помечен как «Отвечено». Ваши пользователи SharePoint будут вам за это благодарны.

Правильное решение проблем с пространством в базе данных

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

Теперь вы можете спросить: « мой сервер базы данных работает уже почти год, и мы не собирали статистику использования для определения емкости диска. Что мы делаем? »

На что я бы ответил, спрашивая: « У вас есть резервные копии базы данных? «Ну, я очень надеюсь, что да.