Ошибочное применение SHRINKFILE на рабочей базе 1С. Как база осталась жива?

Добрый день.
Из-за большого размера лог файла (270 гигов) возникла необходимость его сокращения. Был сделан бекап, затем модель восстановления была изменена на простую, настало время применить SHRINKFILE к лог-файлу и вот тут по невнимательности я дал команду DBCC SHRINKFILE ([my-base], 100); вместо DBCC SHRINKFILE ([my-base_log], 100); и после работы получил размер рабочей базы вместо 17 гигов — 2,5.
База продолжила свою работу и видимо никак не испортилась, конечно я обратил внимание, что команда не исполнилась до конца и не догнала базу до 100 мегабайт, а оставила больше. Видимо, существует защита от дурака? В таком случае, что же занимало в рабочей базе 15 гигов и почему база продолжает работать?
Помогите пожалуйста, пока у меня есть время до рабочих дней, нужно ли бежать и восстанавливаться из бекапа или можно продолжить работу?

Шринк сам по себе базу не ломает, но сильно ее фрагментирует.

Гавриленко Сергей Алексеевич,

Можно ли считать, что я сделал хорошее дело и избавил базу от лишней информации? И такая операция даже нужна через какое-то время? Слишком подозрительным кажется такой размер ненужного барахла в базе.
Я почитал на msdn, но не нашёл указания делать такую операцию на рабочих базах.

Uoa

Добрый день. Из-за большого размера лог файла (270 гигов) возникла необходимость его сокращения. Был сделан бекап, затем модель восстановления была изменена на простую, настало время применить SHRINKFILE к лог-файлу и вот тут по невнимательности я дал команду DBCC SHRINKFILE ([my-base], 100); вместо DBCC SHRINKFILE ([my-base_log], 100); и после работы получил размер рабочей базы вместо 17 гигов — 2,5. База продолжила свою работу и видимо никак не испортилась, конечно я обратил внимание, что команда не исполнилась до конца и не догнала базу до 100 мегабайт, а оставила больше. Видимо, существует защита от дурака? В таком случае, что же занимало в рабочей базе 15 гигов и почему база продолжает работать? Помогите пожалуйста, пока у меня есть время до рабочих дней, нужно ли бежать и восстанавливаться из бекапа или можно продолжить работу?

)
хто жж это тебе такую "страшилку"-то "втёр" ? :)
хотя, может и правильно сделал этот "хто" ...

http://msdn.microsoft.com/ru-ru/library/ms189493.aspx

Если аргумент target_size указан, то инструкция DBCC SHRINKFILE пытается сжать файл до заданного размера. Используемые страницы в освобождаемой части файла перемещаются в свободное место сохраняемой части файла. Например, если размер файла данных составляет 10 МБ, инструкция DBCC SHRINKFILE со значением аргумента target_size, равным 8, перемещает все страницы, используемые в последних 2 МБ файла, на место любых нераспределенных страниц в первых 8 МБ файла. Инструкция DBCC SHRINKFILE не сжимает файл до меньшего размера, чем требуется для хранения данных в файле. Например, если для файла данных, размер которого составляет 10 МБ, необходимо сжатие до 7 МБ, инструкция DBCC SHRINKFILE со значением аргумента target_size, равным 6, сжимает файл до размера в 7 МБ, а не 6 МБ.

Uoa
Гавриленко Сергей Алексеевич, Можно ли считать, что я сделал хорошее дело и избавил базу от лишней информации? И такая операция даже нужна через какое-то время? Слишком подозрительным кажется такой размер ненужного барахла в базе. Я почитал на msdn, но не нашёл указания делать такую операцию на рабочих базах.

http://msdn.microsoft.com/ru-ru/library/ms189493.aspx

Рекомендации Примите во внимание следующие сведения при планировании сжатия файла. •Наибольший эффект от операции сжатия достигается при ее применении после операции, создающей много неиспользуемого пространства, например после усечения таблицы или удаления таблицы. •Большинству баз данных требуется некоторое свободное пространство для выполнения обычных ежедневных операций. Если сжатие базы данных производится регулярно, но она снова увеличивается в размерах, это означает, что место, освобожденное при сжатии, необходимо для нормальной работы. В таких случаях повторное сжатие базы данных бессмысленно. •Операция сжатия не избавляет от фрагментации индексов в базе данных и обычно приводит к еще более сильной фрагментации. Это еще одна причина, по которой не стоит выполнять регулярное сжатие базы данных.

Uoa
Гавриленко Сергей Алексеевич, Можно ли считать, что я сделал хорошее дело и избавил базу от лишней информации? И такая операция даже нужна через какое-то время? Слишком подозрительным кажется такой размер ненужного барахла в базе. Я почитал на msdn, но не нашёл указания делать такую операцию на рабочих базах.

щринк не удаляет информацию из базы.
он только убирает свободное место.
но делать этого на рабочей базе все равно не надо.

qwerty112,

Да сам себе я такое придумал, т. к. MS SQL пока для меня не очень знаком.
Лог файл-то команда отрезала за секунду, а вот с базой и правда колдовала довольно долго.
Получается, что если я на всех базах проверну такое и буду повторять это раз в пару месяцев с последующей дефрагментацией жёсткого диска в выходные дни, то ускорю работу баз данных? Как сильно неиспользуемые данные в базе, которые SHRINKFILE удаляет при таком «сжатии» мешают производительности? Спасибо!

LenaV,

Как подсказывает qwerty112 и msdn делать такую операцию можно. Почему вы не рекомендуете применять её?
Спасибо всем за разъяснения, остался один вопрос: использовать или нет команду SHRINKFILE на рабочих базах для увеличения производительности?

Uoa
qwerty112, Как сильно неиспользуемые данные в базе, которые SHRINKFILE удаляет при таком «сжатии» мешают производительности? Спасибо!

шринк не удаляет неиспользуемые данные из базы.

Uoa
LenaV, Как подсказывает qwerty112 и msdn делать такую операцию можно. Почему вы не рекомендуете применять её? Спасибо всем за разъяснения, остался один вопрос: использовать или нет команду SHRINKFILE на рабочих базах для увеличения производительности?

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