none
Разделить базу MS SQL на несколько файлов RRS feed

  • Вопрос

  • Есть база 2 Тб на MS SQL Ent 2012. На данный момент файл базы один. Подскажите какие есть способы, чтобы разбить базу на несколько файлов? например по 500 Гб.
    28 декабря 2018 г. 5:48

Ответы

  • Например так:

    https://social.msdn.microsoft.com/Forums/sqlserver/en-US/61c08bb2-e443-4ccd-89d8-34611b050522/split-one-mdf-file-into-several-files?forum=sqldatabaseengine

    28 декабря 2018 г. 6:13
  • 1) Создать N новых файлов в файловой группе PRIMARY. Сразу нужного размера (а лучше с запасом процентов в 20-30)
    2) Сделать SHRINKFILE EMPTYFILE первому (основному) файлу
    3) Изменить размер первого файла до стандартного (500Мб + 20/30)
    4) Сделать SHRINKFILE EMPTYFILE последнему файлу
    5) Удалить последний файл
    6) Перестроить все сильно фрагментированные индексы

    Перед всеми манипуляциями сделать бекап, сменить модель восстановления на simpe, убедиться, что на диске с логами транзакций достаточно места. После успешного завершения манипуляций шринквернуть модель восстановления в прежнее значение.

    Будьте готовы к долгому ожиданию. Мониторить происходящее можно через performance monitor, activity monitor и стандартные отчёты SSMS

    Если допустим простой и есть место, то я бы пошёл по пути миграции в новую базу.

    28 декабря 2018 г. 11:13

Все ответы

  • Например так:

    https://social.msdn.microsoft.com/Forums/sqlserver/en-US/61c08bb2-e443-4ccd-89d8-34611b050522/split-one-mdf-file-into-several-files?forum=sqldatabaseengine

    28 декабря 2018 г. 6:13
  • 1) Создать N новых файлов в файловой группе PRIMARY. Сразу нужного размера (а лучше с запасом процентов в 20-30)
    2) Сделать SHRINKFILE EMPTYFILE первому (основному) файлу
    3) Изменить размер первого файла до стандартного (500Мб + 20/30)
    4) Сделать SHRINKFILE EMPTYFILE последнему файлу
    5) Удалить последний файл
    6) Перестроить все сильно фрагментированные индексы

    Перед всеми манипуляциями сделать бекап, сменить модель восстановления на simpe, убедиться, что на диске с логами транзакций достаточно места. После успешного завершения манипуляций шринквернуть модель восстановления в прежнее значение.

    Будьте готовы к долгому ожиданию. Мониторить происходящее можно через performance monitor, activity monitor и стандартные отчёты SSMS

    Если допустим простой и есть место, то я бы пошёл по пути миграции в новую базу.

    28 декабря 2018 г. 11:13
  • Спасибо за советы!

    Только сейчас смог заняться и проверить. Шринк основного файла размером 2ТБ занял 6 дней.

    Такие вопросы появились:

    1)  Можно ли SHRINKFILE EMPTYFILE остановить, а потом запустить заново? Например, запускать только по ночам, а утром отменять и так пока не выполнится.

    2)  Можно ли не переводить базу в simple? SHRINKFILE EMPTYFILE одной транзакцией делается? т.к критична потеря данных.


    11 апреля 2019 г. 9:16
  • Можно не переводить в simple, но размер transaction log-а будет большим и нужно, чтобы для него хватило места. 
    emptyfile можно отменить в любой момент, но после этого сервер может снова начать писать в этот файл. Нужно сразу же после сделать TRUNCATEONLY и зафиксировать максимальный размер на текущем состоянии через alter database.
    Если вы понимаете, что прямо вот точно будет много дней всё это дело идти, то можно попробовать пойти по пути с итеративными shrinkfile с указанным targetsize и последующей коррекцией максимального размера.

    Можно пойти со стороны данных, а не файлов. Выберите таблицы, которые дают основной вклад в потребление дискового пространства. Для каждой из них можно предпринять следующие действия:
    1) Создать новую таблицу аналогичной структуры в новой файлгруппе
    2) Переименовать старую
    3) Сделать view с исходным именем таблицы с union all этих двух таблиц и instead of триггером на DML, который обеспечит вставку данных в новую таблицу
    4) Последовательно переносить данные порциями по ~50к записей из старой таблицы в новую

    Такой подход можно применять прямо на проде (собственно только там так сложно и нужно), но он требует очень высокой степени аккуратности в реализации и понимания структуры запросов и нагрузки.
    Констрейнты на таблицу придётся отключить. И будет просадка на чтении, но её размер зависит от паттерна нагрузки.

    15 апреля 2019 г. 11:09
  • Всем спасибо, все получилось. База разделена через SHRINKFILE EMPTYFILE. На разделение ушло около 7 дней.