TL;DR Не сжимайте базу данных. Всегда.
Но что, если вам действительно нужно его уменьшить?
Согласно статье, на которую ссылается эксперт по SQL Server Брант Озар, существуют обстоятельства, при которых сжатие вашей базы данных является законным вариантом:
- Ваша база данных составляет 1 ТБ или больше
- Вы удалили 50% данных
- У вас есть 500 ГБ+ свободного места
- Вам никогда не понадобится это пространство, потому что теперь вы регулярно удаляете и архивируете
Полный ответ:
Вы написали, что читали об этом. Надеюсь, вы сталкивались с такими сообщениями, как Брента Озара. Что плохого в сжатии баз данных с помощью DBCC SHRINKDATABASE? :
У вас высокая фрагментация, поэтому вы перестраиваете свои индексы.
Что оставляет много пустого места вокруг, поэтому вы уменьшаете свою базу данных.
Это вызывает высокую фрагментацию, поэтому вы перестраиваете свои индексы, что увеличивает базу данных и снова оставляет пустое пространство, и цикл продолжает увековечиваться.
Майк Уолш Не нажимайте эту кнопку сжатия базы данных в SQL Server! - где он объясняет то же самое:
Что происходит при сжатии базы данных?
Когда вы сжимаете базу данных, вы просите SQL Server удалить неиспользуемое пространство из файлов вашей базы данных. Процесс, который использует SQL, может быть некрасивым и приводить к фрагментации индекса. Эта фрагментация влияет на производительность в долгосрочной перспективе. Вы освободили это пространство и позволяете ОС делать с ним все, что нужно, так что вы, по крайней мере, получили то, о чем просили. Если у вас есть растущая база данных, это означает, что база данных будет расти снова. В зависимости от ваших настроек автоматического роста, этот рост, вероятно, будет больше, чем необходимо, и вы снова сократитесь. В лучшем случае это просто дополнительная работа (сжатие, увеличение/уменьшение), и результирующая фрагментация файла обрабатывается нормально. В худшем случае это приводит к фрагментации индекса, фрагментации файлов и потенциально может вызвать проблемы с производительностью во время сжатия.
и ответ Аарона Бертрана на лучшие практики и опыт SHRINKFILE на dba.StackExchange.com - где он в основном говорит, что вы можете игнорировать хорошие советы от умных, опытных людей и полагать, что ваш случай разные - но на свой страх и риск. Это его заключительный аргумент:
Гораздо дороже будет сжать файл до 4 ГБ, а затем принудительно увеличить его для размещения новых данных. Это похоже на стирку уже чистого полотенца, которое вы собираетесь использовать, чтобы вытереть беспорядок.
В заключение — вам действительно стоит обратить внимание на то, что пишут эксперты. Просто для ясности: я не считаю себя экспертом в этом вопросе.
Я хорошо разбираюсь в T-SQL со стороны разработчика, но у меня очень мало опыта со стороны администратора баз данных — я могу рассчитывать на одного сколько раз мне приходилось писать такие вещи, как планы обслуживания, миграции баз данных или заниматься любыми задачами системного администрирования, которые должен был бы выполнять администратор баз данных.
Однако все эти парни, которых я упомянул, являются ведущими администраторами баз данных: Брент Озар — MCM. (Microsoft Certified Master), Майк Уолш — 9-кратный MVP (с 2011 г.), а Аарон Бертран — 22-кратный MVP (с 1997 г.) — эти ребята действительно знают, о чем пишут.
Я бы взял бесплатный совет от любого из них в любой день недели и дважды в воскресенье.
Обновление — О файлах журналов:
Сокращение файлов журнала — это несколько иная история. Делать это на регулярной основе — плохая практика.
Размер файла журнала в основном определяется вашей стратегией резервного копирования и выбранной моделью восстановления.
Рекомендуемое чтение: - Если вы готовы, я бы посоветовал прочитать как его полный ответ, так и полный ответ Аарона Бертрана на тот же пост.
person
Zohar Peled
schedule
24.07.2019
