Некоторые начальные предостережения:
- Общеизвестно, что худшая практика - когда-либо сокращать производственную базу данных или файл данных (файлы журнала - другая проблема, о которой говорит этот вопрос ). Я советую людям не сжимать свои базы данных в таких сообщениях в блоге, где я говорю о «правильном определении размера» и хорошем планировании. Я там не один ( Пол Рэндал , Брент Озар , просто чтобы предоставить еще пару ссылок). Сжатие файлов данных или индексов фрагментов базы данных является медленным и трудоемким для ваших ресурсов, может привести к утечке в вашей системе и, как правило, является плохой вещью
- В этом случае мы все знаем, что риск существует, мы готовы с ним справиться, но мы освободили много места, которое, как мы знаем, больше никогда не понадобится. Так что в этом конкретном случае - сокращение имеет смысл как один из наших вариантов.
Если вы читали о проблемах и рисках, и вам все еще нужно сделать это сокращение, поскольку вы освободили значительное количество места, надеюсь, остальная часть этого ответа поможет вам. Но учитывайте риски.
Есть два основных подхода, которые здесь рассматриваются два:
1.) Сжатие Да, сделать фактическое сжатие - рассмотрите возможность использования DBCC SHRINKFILE
вместо DBCC SHRINKDATABASE
, у вас есть больше контроля над тем, что сокращается и как. Это наверняка вызовет некоторое снижение производительности - это большая операция, выполняющая много операций ввода-вывода. Вы можете потенциально уйти с повторными стягивается заданного размера , который получает все меньше.
Это пример "A.)" в приведенной выше DBCC SHRINKFILE
ссылке. В этом примере файл данных сокращается до целевого размера 7 МБ. Этот формат является хорошим способом многократного сжатия, как позволяет ваше окно простоя. Я бы сделал это при тестировании разработки, чтобы увидеть, как выглядит производительность и насколько низко / высоко вы можете пойти с приращением, и определить ожидаемые сроки производства. Это онлайн- операция - вы можете запустить ее с пользователями в системе, которые обращаются к сокращенной базе данных, но при этом почти гарантировано снижение производительности. Поэтому следите и наблюдайте за тем, что вы делаете с сервером, выбирайте окно простоя или период более легкой активности, в идеале.
USE YourDatabase;
GO
DBCC SHRINKFILE (DataFile1, 7);
GO
Всегда помните: - каждый раз, когда вы сжимаете, вы фрагментируете свои индексы и должны выполнять перестройку индекса, если вы собираетесь сокращать порции в течение длительного периода времени. Теперь вы несете эти расходы каждый раз, если не можете сделать все это в одном окне.
2.) Новая база данных - вы можете создать новую базу данных и перенести в нее данные. Вам нужно было бы написать сценарий для пустой базы данных и всех ее ключей, индексов, объектов, процедур, функций и т. Д., А затем перенести в нее данные. Вы можете написать сценарии для этого или использовать такой инструмент, как SQL Data Compare от Red Gate или других поставщиков с аналогичными инструментами. Это больше работы по настройке с вашей стороны, больше разработки и тестирования, и в зависимости от вашей среды может также выбить ваше окно простоя, но вариант, который нужно учитывать.
Когда я буду вынужден сжать базу данных
Если бы это было мое окружение, я хотел бы посмотреть , чтобы оставить изрядное / здоровенное количество белого пространства в файл данных , потому что мне нравится быть на диск боров и как подготовиться к будущему / непредвиденному росту. Поэтому я был бы согласен вернуть пространство обратно, если бы мы просто удалили большую часть пространства, но я бы никогда не поверил тем, кто говорит «но оно никогда не вырастет снова», и все равно оставил бы некоторое пространство. Маршрут, по которому я бы, вероятно, пошел ( вздох) - это сжатый подход, если у меня были меньшие окна простоя и я не хотел брать на себя сложность создания пустой БД и переноса данных в нее. Поэтому я постепенно уменьшал его (в зависимости от того, сколько раз я думал, что мне нужно было основываться на моем тестировании в dev и желаемого размера. Постепенно выбирая меньший размер файла), а затем перестраивал индексы ... И тогда я ' никогда не говори никому, что я сжал свою базу данных ;-)