Доброго всем дня.
Есть база 1С Документооборот клиент-серверная, на MS SQL. Изначально все файлы хранились в базе данных. Потом включили настройку "хранить в томах на диске", стандартной обработкой Документооборота перенесли файлы на диск, там они появились. Но размер базы не уменьшился! Как был 300 гигов, так и остался. Shrink средствами SQL я делал, не помогло. В 1С запускал "тестирование и исправление" - "Реструктуризация таблиц". Не помогло. Что ещё можно сделать, чтобы эти уже удаленные из базы файлы не занимали там место? Обработка ДО показывает что в базе осталось файлов только 12 Мб.
(21) Как оказалось, это не сами файлы, это Справочник.СообщенияИнтегрированныхСистем. Фиг знает, какое это отношение имеет к файлам, но там куча помеченных на удаление (60 000 с лишним), вычищу, посмотрим что будет с размером. Спасибо за наводку.
(11)И на чем основаны ваши сомнения? На полном незнании принципов устройства MS sQL и его файлов?
Средства 1с типа ТиИ не имеют ни малейшего отношения к уменьшению размеров файлов, управляемых СУБД.
Что ещё можно сделать, чтобы эти уже удаленные из базы файлы не занимали там место?
А кто сказал, что они там что-то занимают? В общем-то, ваши файлы теперь там ничего не занимают, их место пусто и будет постепенно заниматься прочими объектами базы данных. Просто на какое-то время, зависящее от скорости генерации новых данных, файл данных перестанет расти.
Уменьшение размера файла данных ничего кроме увеличения свободного места на диске не даст. Это в лучшем случае. В худшем добьетесь замедление работы. Оно вам надо?
(13) То-то я вижу вы дофига понимаете в устройстве MS SQL, если ляпнули что "ваши файлы теперь там ничего не занимают". Именно для этого я и делал Shrink и если бы место было не занято, shrink бы его освободил.
"Уменьшение размера файла данных ничего кроме увеличения свободного места на диске не даст." - спасибо, кэп, без вас бы я не догадался! Вы хоть читали пост-то? База 320 гигов, из них 300 - файлы, если это место освободить, база будет гигов 20, копии проще разворачивать, 320 гигов для копии найти на сервере где уже куча всего - весьма увлекательная задача.
Отменили же начисление стартмани просто за любые посты, зачем писать коммент если даже не читал пост?
У меня SQL Server Management Studio на русском.
Попробуйте с начала на копии:
- в параметрах базы устанавливаем реквизит "Модель восстановления:" - Простая
- выполняем процедуру "Задачи - Сжать - Базы данных", все параметры по умолчанию
- после, в параметрах базы возвращаем реквизит "Модель восстановления:" - Полная
(7) "Сжать" это и есть Shrink, который я делал. Модель восстановления на простую я конечно не менял, попробую, но у меня сомнения. Это же на логи влияет, размер логов у меня минимальный, у меня сам файл данных в SQL огромный.
(21) Как оказалось, это не сами файлы, это Справочник.СообщенияИнтегрированныхСистем. Фиг знает, какое это отношение имеет к файлам, но там куча помеченных на удаление (60 000 с лишним), вычищу, посмотрим что будет с размером. Спасибо за наводку.
То-то я вижу вы дофига понимаете в устройстве MS SQL, если ляпнули что "ваши файлы теперь там ничего не занимают". Именно для этого я и делал Shrink и если бы место было не занято, shrink бы его освободил.
Плюньте в глаза тому, кто вам это сказал. Ибо это полная чушь. Для срабатывания Shrink надо соблюсти некоторые условия. О чем, похоже, даже не задумывались. Может таки сначала доку по сей команде почитаете и не будете ламерствовать, обсуждая вопросы, в которых вы ни хрена не понимаете?