Получить MS SQL Server, чтобы освободить место на диске

Таблица плохо управляемой базы данных стала огромной. 48 + концертов бесхозных записей. Я пытаюсь очистить его и вернуть опасно полный жесткий диск в нормальное состояние. Я буду удалять около 400 миллионов записей из этой таблицы. Это работает, как я печатаю. Я заметил, что я не вижу никакого падения в моем жестком диске, но я вижу падение памяти на запросы системных таблиц, я бегу, чтобы получить размер таблицы. База данных использует "Простую модель восстановления".

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

1. Поскольку база данных не должна быть такого размера. Это все еще плохо для меня, чтобы уменьшить это?
2. Это производственная база данных. Если я уменьшу его, это вызовет простои или заблокирует базу данных?
3. В SQL Server Management Studio у вас есть два варианта сжатия, базы данных или файлов. Учитывая мою ситуацию, что будет лучшим вариантом?
4. существует ли правило о проценте свободного места, которое должна иметь БД?

Даже чтение описания тега shrink заставляет меня не хотеть этого делать. Есть ли другой способ?

Я буду удалять около 400 миллионов записей из этой таблицы.

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

обратите внимание, что я не вижу никакого падения в моем жестком диске

Вы не захотите, так как вам нужно явно уменьшить файл базы данных, чтобы освободить место. Просто удаляя записи, SQL-сервер не освободит место обратно в ОС .

1. Поскольку база данных не должна быть такого размера. Это все еще плохо для меня, чтобы уменьшить это?

Как правило, это плохая практика, поскольку базы данных должны быть правильно расположены. Если вы на 100% уверены, что ваша база данных НЕ будет снова такого размера, то вы можете сузить базу данных (в вашем сценарии) .

2. Это производственная база данных. Если я уменьшу его, это вызовет простои или заблокирует базу данных?

Сжатие базы данных является очень интенсивным вводом-выводом. Рекомендуется использовать его DBCC SHRINKFILEво время технического обслуживания или при минимальной активности.

3. В студии управления у вас есть два варианта, База данных или Файлы. Учитывая мою ситуацию, что будет лучшим вариантом?

Вы должны использовать TSQL, чтобы сделать сжатие. (так как вы спросили, сжатие FILE - это путь вместо базы данных). Вы можете использовать сжатую базу данных в чанках - скрипт tsql, чтобы выполнить сжатие чанков.

Помните, что когда вы сокращаетесь, вы фрагментируете свои индексы.

4. существует ли правило о проценте свободного места, которое должна иметь БД?

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

Ссылки: Почему журнал транзакций продолжает расти или не хватает места?

у вас есть веские основания для беспокойства, поскольку сжатие БД в SQL Server часто «отстой». Пол Рэндал, глава Storage Engine в SQL 2005, заявил, что ShrinkDB написан очень плохо. Он найдет пустое пространство, взяв данные в самом конце, поместив их в самом начале и продолжая делать это, пока у них не будет свободного места в конце файлов БД. На этом этапе он может освободить пространство из SQL Server и вернуть его ОС. Вы эффективно обращаете свои файлы базы данных, таким образом, вы обычно увидите массивную фрагментацию. Вы можете прочитать о его взглядах в этом посте в блоге или на этом внутреннем видео MCM.

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

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

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

Кроме того, рост файла журнала намного важнее. Дополнительные файлы журнала могут вызвать фрагментацию VLF. Это делает ваше восстановление намного медленнее и может повлиять на контрольную точку / усечение. Вот некоторые риски производительности, которые вы берете на себя с фрагментированным журналом. Сделайте DBCC LOGINFO();на каждой базе данных. Постарайтесь сохранить число около 50 для каждого Ким Триппа, но если вы видите сотни, у вас есть проблемы фрагментации, что означает, что ваши файлы журналов должны были расти для поддержки операций. Хороший способ узнать, каким должен быть ваш лог-файл для Пола Рэндала, - просто позволить ему расти в течение недели и переиндексировать. Это может быть хорошим моментом, возможно, вы можете добавить немного свободного места на всякий случай. Убедитесь, что ваши журналы не фрагментированы с помощью DBCC LOGINFO (); еще раз, и если они есть, значит, они сильно выросли. Сожмите и повторно разверните файл журнала, используяэтот метод .

Вы можете уменьшить его достаточно, чтобы убедиться, что ваш сервер не выйдет из строя в течение периода времени, необходимого для оценки потребностей в хранилище и надлежащего планирования услуг аппаратного / хостинга (см. Вопрос 4). Нет, это не заблокирует это. Смотрите ограничения . Сократите базу данных, потому что она упрощает работу.

Я предлагаю заключить договор на проведение экспертизы и составить план.