none
База не уменьшилась RRS feed

  • Вопрос

  • Добрый день. Имеем SQL  2012. На нем база выросла из-за сбоя esx и вместо 10 Гб стала 180.

    Левые строки, более 100 милл удали из базы в ручную, сделали переиндексацию и затем ребилд.

    Так вот на тестовом стенде после переиндексациии  ребилда файл базы со 180 гб уменьшился до свои 10, а вот на бою, этого не произошло.Отличие от стэнда , там SQL 2014, на бою 2012. Ну и то, что база на 2012 держит vCenter, а на тесте нет подключений кроме консоли MSSMS.

    13 июня 2017 г. 8:06

Ответы

  • Добрый день. Имеем SQL  2012. На нем база выросла из-за сбоя esx и вместо 10 Гб стала 180.

    Левые строки, более 100 милл удали из базы в ручную, сделали переиндексацию и затем ребилд.

    Так вот на тестовом стенде после переиндексациии  ребилда файл базы со 180 гб уменьшился до свои 10, а вот на бою, этого не произошло.Отличие от стэнда , там SQL 2014, на бою 2012. Ну и то, что база на 2012 держит vCenter, а на тесте нет подключений кроме консоли MSSMS.


    В SQL Server у базы данных есть свойство AUTO_SHRINK, указывающее, будет ли сервер автоматически сжимать базу, когда сочтёт нужным. Вероятно, у вас на тестовом стенде это свойство было установлено, а в рабочей среде - нет (собственно, как оно и рекомендуется делать).

    Слава России!

    • Помечено в качестве ответа Cloomger_Tasher 15 июня 2017 г. 6:52
    13 июня 2017 г. 12:16
  • почему не рекомендуется?

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

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

    • Помечено в качестве ответа Cloomger_Tasher 15 июня 2017 г. 6:53
    13 июня 2017 г. 9:12
  • Иного выхода нет. Ну, точнее есть - создание новой базы и переливка данных туда потаблично, но что-то мне подсказывает, что это вам ещё меньше понравится. 
    Сделайте шринк файлов с данными. Оставьте процентов 20-30 запаса сразу. Если всё получится, потом отдельно шринкнете логи до потребных вам размеров.

    Если у вас тяжёлый продакшен без технологических окон, можно придумать более сложный сценарий с выводом данных в соседнюю базу, проксированием доступа через view и шринк в таком состоянии
    • Изменено Roman Sergeev 14 июня 2017 г. 11:54
    • Помечено в качестве ответа Cloomger_Tasher 15 июня 2017 г. 6:52
    14 июня 2017 г. 11:49

Все ответы

  • а шринкнуть вручную не забыли?

    Правой кнопкой на базе -> Задачи -> Сжать -> База данных

    В открывшейся консольке сразу увидите % освобождаемого места.

    13 июня 2017 г. 8:37
  • а шринкнуть вручную не забыли?

    Правой кнопкой на базе -> Задачи -> Сжать -> База данных

    В открывшейся консольке сразу увидите % освобождаемого места.

    В том-то и дело, что на тесте не делали шринк и база уменьшилась.

    Да и шринк, как я почитал вообще не рекомендуется делать...

    13 июня 2017 г. 8:56
  • почему не рекомендуется?

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

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

    • Помечено в качестве ответа Cloomger_Tasher 15 июня 2017 г. 6:53
    13 июня 2017 г. 9:12
  • почему не рекомендуется?

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

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

    Ну честно говоря я не совсем понял, как это сработает. Я сделал реинидексацию, затем ребилд, затем бэкап. После восстоновления, как было 180 Гб так и осталось((((


    13 июня 2017 г. 9:22
  • Restore не уменьшает базу, Егор. Оно так не работает. 
    13 июня 2017 г. 9:49
  • Вам сперва необходимо понять, чем занято место. Данными или логами? Нередки ситуации, когда после массовых удалений и ребилдов индексов раздувается именно лог, который и надо шринкать.
    13 июня 2017 г. 9:51
  • Restore не уменьшает базу, Егор. Оно так не работает. 

    У тс было выполнено ручное удаление данных из базы, в итоге внутри БД освободилось место, но файл базы не уменьшился.

    По поводу логов: тс упоминает именно базу, то есть файл с форматом .mdf

    Кстати, а какая модель восстановления используется?

    13 июня 2017 г. 9:59
  • Restore не уменьшает базу, Егор. Оно так не работает. 

    У тс было выполнено ручное удаление данных из базы, в итоге внутри БД освободилось место, но файл базы не уменьшился.

    По поводу логов: тс упоминает именно базу, то есть файл с форматом .mdf

    Кстати, а какая модель восстановления используется?

    Модель Simple.

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


    13 июня 2017 г. 11:10
  • Вам сперва необходимо понять, чем занято место. Данными или логами? Нередки ситуации, когда после массовых удалений и ребилдов индексов раздувается именно лог, который и надо шринкать.
    Я говорю именно о базе)
    13 июня 2017 г. 11:10

  • Модель Simple.

    Ну значит логи не должны были сильно разрастаться. Сколько у вас .ldf-файл весит?

    13 июня 2017 г. 11:12

  • Модель Simple.

    Ну значит логи не должны были сильно разрастаться. Сколько у вас .ldf-файл весит?

    Логи подросли после реиндекса и ребилда. Был пару Гб, я его шринкнул. Сейчас 1 Мб.


    13 июня 2017 г. 11:18
  • ну пару ГБ это пустяки. Для активно используемых баз логи бывают разрастаются до сотен гигов для базы в 5-8ГБ. Это если полную модель восстановления использовать.
    13 июня 2017 г. 11:50
  • Добрый день. Имеем SQL  2012. На нем база выросла из-за сбоя esx и вместо 10 Гб стала 180.

    Левые строки, более 100 милл удали из базы в ручную, сделали переиндексацию и затем ребилд.

    Так вот на тестовом стенде после переиндексациии  ребилда файл базы со 180 гб уменьшился до свои 10, а вот на бою, этого не произошло.Отличие от стэнда , там SQL 2014, на бою 2012. Ну и то, что база на 2012 держит vCenter, а на тесте нет подключений кроме консоли MSSMS.


    В SQL Server у базы данных есть свойство AUTO_SHRINK, указывающее, будет ли сервер автоматически сжимать базу, когда сочтёт нужным. Вероятно, у вас на тестовом стенде это свойство было установлено, а в рабочей среде - нет (собственно, как оно и рекомендуется делать).

    Слава России!

    • Помечено в качестве ответа Cloomger_Tasher 15 июня 2017 г. 6:52
    13 июня 2017 г. 12:16
  • Добрый день. Имеем SQL  2012. На нем база выросла из-за сбоя esx и вместо 10 Гб стала 180.

    Левые строки, более 100 милл удали из базы в ручную, сделали переиндексацию и затем ребилд.

    Так вот на тестовом стенде после переиндексациии  ребилда файл базы со 180 гб уменьшился до свои 10, а вот на бою, этого не произошло.Отличие от стэнда , там SQL 2014, на бою 2012. Ну и то, что база на 2012 держит vCenter, а на тесте нет подключений кроме консоли MSSMS.


    В SQL Server у базы данных есть свойство AUTO_SHRINK, указывающее, будет ли сервер автоматически сжимать базу, когда сочтёт нужным. Вероятно, у вас на тестовом стенде это свойство было установлено, а в рабочей среде - нет (собственно, как оно и рекомендуется делать).

    Слава России!

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

    Просто наткнувшись на статью Алексея Бородина "https://habrahabr.ru/post/330492/", в которой он ЯВНО пишет" НИКОГДА, НИКОГДА не должны включать автосжатие", меня это опять же настараживает...


    14 июня 2017 г. 2:51
  • Не надо включать автосжатие на рабочих базах. Оно должно выполняться только при серьёзных изменениях в структуре модели хранения (вы вынесли блобы в отдельный storage, к примеру) или больших по объёму операциях обслуживания (сребилдили дико фрагментированный кластерный индекс и обеспечили отсутствие его фрагментации в будущем, например). И выполнять его надо не на уровне базы, а точечно на конкретных файлах
    14 июня 2017 г. 4:07
  • И всё же коллеги, что мне делать в данной ситуации? Иного выхода нет как сжать базу, что бы высвободить 170 Гб места?

    И автосжатие включено по умолчанию-его отключить?

    И за одно скажите пож-то шринковать базу или файл базы?
    14 июня 2017 г. 4:31
  • Иного выхода нет. Ну, точнее есть - создание новой базы и переливка данных туда потаблично, но что-то мне подсказывает, что это вам ещё меньше понравится. 
    Сделайте шринк файлов с данными. Оставьте процентов 20-30 запаса сразу. Если всё получится, потом отдельно шринкнете логи до потребных вам размеров.

    Если у вас тяжёлый продакшен без технологических окон, можно придумать более сложный сценарий с выводом данных в соседнюю базу, проксированием доступа через view и шринк в таком состоянии
    • Изменено Roman Sergeev 14 июня 2017 г. 11:54
    • Помечено в качестве ответа Cloomger_Tasher 15 июня 2017 г. 6:52
    14 июня 2017 г. 11:49
  • Спасибо всем за помощь.

    В пятницу буду делать.

    15 июня 2017 г. 6:52