Проблема со сжатием базы 1С на SQL Server! #491562

Захожу в SQL менеджер, выбираю нужную базу, затем задачи - сжать - файлы. Указываю сжать лог файл, указываю до 50 МБ и ОК - процес начинается и тут же прирывается!!! При этом пишет "недостаточно места на диске" (места на дистке метров 150)!! Так а как его освободить-то теперь?

убрать порнуху и прочее

а что на диске кроме этой самой базы ничего нет, что можно было бы временно переместить?

так вот нету! там 3 базы лежит и они сожрали все место на диске. теперь даже логи сжать не можем - сервак не дает

а если одну из баз через сервер "отсоединить", то ее можно буде тскопировать куда-нить в другое место (сами файлы)?

Да.

начнём с простого: базы в фулл и в симпл ?

а как потом подключить корректно?!

а более по-русски?!

админа позови

recovery mode для баз какой установлен?

восстановление происходжит из полного бекапа

я ж не про восстановление говорю :-)

дятел загляни базе в параметры что во втором сверху

модель воостановления ПОЛНАЯ

сделай бэкап на сетевой ресурс сделай Truncate сделай шринк

это долго и нужно всех пользователей выгонять! мне по быстрому нужнО!

переведи самую не нужную базу в симпл и шринкани

почему самую не нужную? Можно все перевести в симпл, судя по full там нафиг не нужен

потеряет возможность откатки на произвольную точку возможно вместе с яйцами

хм... а ты думаешь ему это под силу? откат на произвольную точку. Почитай что выше написано. Скорее всего базы созданы с настройками "по умолчанию", вот и стоит у него full, вряли это осознанный выбор. А место нужно прямо сейчас, и СРОЧНО!!!!

откатом на произвольную точку пользуемся крайне редко!!! Но иногда бывает

в это для

еще один ОЧЕНЬ ТУПОЙ ВОПРОС, но все же... если я просто отсоединю одну из баз, удалю тупо ее лог файл, а затем присоединю обратно. Вроде как лог файл создаться заново и будет начат с нуля?! ТАК ВЕДЬ?

ну да.

так а чем не вариант собственно тогда?? Это делается за несколько минут и не нужно тратить огромное количество времени на создание бекапа и разворота из них базы!

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

смешно

почему??? Лог файл разве влияет на развертывание базы?

попробуй поднять mdf без ldf смех пройдет

ща попробую!!! уже базу копирую :)

Поднимал неоднократно. Смех не проходит.

если база в сипле, то без проблем

*симпл

ясен пень у ТС фулл

Объясните идиоту - в чем разница режимов - ПОЛНАЯ и СИМПЛ ?

в наличии журнала

изменить режим уже созданной базы можно?

можно

доки для кого пишут?

см

еще не добрался - сознаюсь! Кстати по ходу дела - доки посоветуйте!

фулл режим для 1с... это излишек

Т.е. можно вообще отказаться без каких либо потерь? А что такое "Частичное протоколирование"?

спасибо!

[без каких либо потерь] + [откатом на произвольную точку пользуемся крайне редко!!! Но иногда бывает] на один стул сядь

я на нем и сижу! Я же спрашиваю - интересуюсь у местных гуру. Говорю - востанавливать произвольную точку приходится крайне редно, но иногда все же приходится. Следовательно, как написано в доках, нужна именно ПОЛНАЯ модель восстановления! так ?

угу

А что есть "произвольная точка"? На "точку" последнего бэкапа? Ответ очевиден. А вот "откатиться на пару минут назад" - ту без фулла никак.

слава яйцам - разобралтсь!!! Тогда все-таки уточнение - если лог файл весить 12 Гигов, а свободного пространства на диске осталось 2 Гига, может ли из-за этого НЕ ПРОИСХОДИТЬ сжатие лог-файла?

в моем случае скорее нужно для избежания ошибок и при все-таки их возникновении - нормального восстановления на момент критической ошибки!

легко

блин :( ну хоть с причиной точно разобрались!!!

кстати, а у меня получилось развернуть базу в режиме восстановления "Полная" без указания лога к ней!

Если "на момент" - это уже фулл. На счёт удаления журнала (и насчет смеха) - прав. У меня однажды админ прозевал свободное место и со словами "У меня копия диска есть - сейчас на ней попробую..." - удалил журнал... рабочей базы... по ошибке :( Смеялись долго... аж до слёз. И потом ещё раз - в начале следующего месяца, следующего квартала и по окончании года :((

Сорри за офф.

не, обманул :(

УБЕДИЛ !!!

а как лучше базу настроить, чтобы ЛОГ сильно не пух...а то что-то пипец прям

Нашёл ветку, почти по теме :)

настроить нельзя содержать в порядке легко см

угу на sql.ru это любимая тема

Что ж делать-то... на чужих ошибках учатся только гении. Остальные - на своих.

не льсти мне

Ха, нарисовался, как чёртик из шкатулки :) Ну скажи чего нибудь ещё. По теме.

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

+ и серваки надежные

ты не гений - однозначно

вот и я говорю.... просто иногда включаю мозг, перед тем как что то делать

сам с собой беседуешь ?

промахнулся...

для гения не простительно соглашайся на крайне одаренного

нафиг надо... я же в Железнодорожном квартиру покупать не собираюсь

просто есть специалисты, а есть халтурщики и не более того

тема раскрыта полностью - зачёт

Согласен:) тема раскрыта ,вывод - Спецы в Железнодорожном квартиры не покупают! ЗАЧЕТ :)

Лучше всего сделать, чтобы лог файл был без сильных ограничений, в свойствах базы на скуль, вкладка Files там указываем 10 процентов от базы. А шринковать лучше средствами того же sql без Maintenance, запрос, и в задачи.

а в чем разница между "чисто запросом" или визуальными средставами?

Еще один советник. Зачем тебе recovery model full коли ты не понимаешь что такое журнал транзакций и с чем его едят?

так было настроено "ДО МЕНЯ"...ну собственно продолжаю концепцию :)

Теперь рулишь ты?

уж месяц как :) просто до этого работал чисто с файловыми базами и сейчас тяжкова-то с сервером!

Вот и разбирайся ;)