v7: 1С 7.7 + SQL 2005: можно ли чистить transaction log? #624585

Заказчик прислал выгрузку БД, сделанной средствами самого SQL. Сама база (mdf) - 14Gb, log - 6Gb. С некторого момента размер базы стал упираться в размер диска (сейчас все базы перевёл на SSD), и я решил почистить лог - мне он вроде как ни к чему. В результате использовал DBCC SHRINKFILE и ужал лог до единички. Однако после этого стал замечать странности при работе в 1С Предприятии. Например, при интерактивной работе (открытие, поиск, тра-тат-та - всё через штатный интерфейс) с таким большим справочником, как ОС (~30000 наименований) 1С начинает как-то жутко тормозить и системник в это время показывает индикатором постоянную загрузку диска. Может, это просто по времени совпало с очисткой лога, но хочу уточнить: можно ли чистить лог баз SQL Server для 1С? Есть ли здесь какие-то известные грабли?

Можно. Но осторожно. Все зависит от настроек. Телепатически нелечится.

Нет с этим проблем. Забей.

А какие настройки могут повлиять? И чтоб не лечить телепатически, какую инфу предоставить?

ТИп базы FULL или Simple. Ставь Simple и забудь.

Т.е. тип recovery model влияет на производительность в 1С? Или мы говорим о базах SQL вообще?

full - режим полного протоколирования, в виду специфики работ 1С 7.7 с базами в формате SQL данный режим в большинстве случаев неактуален ставьте simple - и будет вам счастье

для более полного понимания вот:

Подобная задача всплывала в работе, только вопрос оставался в том, что журнал транзакций был нужен на всякий случай.... Мало ли что упасть может. Сделал двумя заданиями в SQL 1. Выполняется каждые 30 минут в течении рабочего дня (с 7:00 до 20:00) BACKUP LOG [Имя_Базы] TO  DISK = N'ПутьИмя.bak' WITH  RETAINDAYS = 1, NOFORMAT, NOINIT,  NAME = N'Имя', SKIP, NOREWIND, NOUNLOAD,  STATS = 10 GO 2. В 6 утра каждый будний день DBCC SHRINKFILE(Имя_Log (без расширения),1) В итоге получаю минимальный размер файла журнала транзакций актуальный. Плюс каждый день в 00:00 идет архивирование бекапов в zip. Место всегда на диске есть. Нагрузки никакой.

Всем выступившим огромное спасибо за советы! Но мы слегка уклонились от первоначального вопроса. Ещё раз поставлю правильно акцент: если мы чистим лог Сиквела, то может ли это повлиять на производительность 1С? Или это как следствие, а первоначально сама БД начинает тормозить и выполнять какие-то дополнительные действия в случае такой потери лога? Судя по ответам и рассуждая чисто теоретически - получается, что не должно быть влияния, т.к. лог - это просто протокол работы с БД.

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

Если Вы чистите лог Сиквела, то Сиквелу придется тратить время на расширение лога. И каждый раз, когда лог будет расширяться, система будет простаивать, ожидая, когда расширение закончится. Поэтому урезание лога - вредная и бессмысленная процедура. С раширением лога борются двумя способами: 1. Переводом базы в режим Simple. 2. Если это нежелательно, то регулярными бекапами логов - например, каждые 15 минут.

Если у вас есть нормальный админ и железка под сервер правильная, то говорить неочем. Поставьте simple модель и непарьтесь. А размер лога обычно где-то в районе 30%. Этого как правило бывает достаточно что б незаморачиваться. Если с размером лога неугадали, постепенно увеличивайте до оптимального. Тут уж протелепартировать никак. С каких пор 14 Гиг для сервера проблема?.. Это я к тому что что-то с железом не то. А вы все пытаетесь скуль нагнуть.

"он идиотский... показывает степень непонимания предмета" Сам ты идиотский - см. разумные объяснения эффекту, например, в

Я разрешаю :)

"С каких пор 14 Гиг для сервера проблема?" Почему большинство невнимательно читает вопрос? До сих пор не пойму... Я же написал, что Заказчик прислал базу мне на мой рабочий ПК. Этоне сервер - это ПК разработчика. А я для работы с БД 1С специально SSD прикупил - а там, как известно, гигабайты пока уж очень недешёвые по сравнению с обычными HDD. Вот и приходится поджимать место где только можно.

Нет, чудес не бывает. Это собственно тоже самое, что когда пользователи думают, что Виндов тормозит из-за переполнения реестра мусором, который пользователь понахватал при еще дневной установке игр. Но на работе сеё редко ставится. Так же бытует мнение, пользователей, что скорость прямо пропорциональна свободному месту на жёстком диске :)

+ В общем автор работает не по должности :)

Что ты хочешь, рыбак? (спросила золотая рыбка) Просветление для нуба: 1. DBF БД работает быстрее SQL БД 2. SQL БД дает в типовой постановке от 1С, т.е. при простой конвертации:   а. снижение производительности БД (SSD - тут не помощник)   б. снимает ограничение на размер хранимой информации, т.е. если в DBF формате система ограничена 2Гб любого DBF файла, то в SQL вы ограничены только размером жесткого диска. 3. При любом раскладе SSD - прирост даст только в терминальном режиме, это когда все на одном компе (сервере) работают через RDP :) 4. 1С 7.7 очень чувствительна к ряду факторов:   а. Железо, желательно что бы оно не тормозило, ну не любит 1С долгие отклики от железяки, на которой оно крутится.   б. Сеть должно функционировать нормально, т.е. 1С нелюбит когда пропадают пакетики. 1С это не любит только по одной причине, она не умеет восстанавливать соединения с БД. Т.е. если связь прерывается, то 1С попросту валится :) (...есть и другие замечательные свойства 1С, но они в другой раз...)

Обычно стараюсь не реагировать на отзывы тех, кто выступает с нападками на автора вопроса. Но один Ваш пункт прокомментирую: "2. SQL БД дает в типовой постановке от 1С, т.е. при простой конвертации:  а. снижение производительности БД" Ну если Вы Спец с большой буквы "С" по 1С, особенно по 7-ке, то Вам должно быть известно, что под SQL 7-ка в некоторых случаях ведёт себя не так, как в локально/сетевом варианте с DBF. В основном это связано с особенностью исполнения запросов, которые в случае MS SQL Server транслируются на T-SQL. Мы уже на этом собаку съели, и поэтому при внутренних разработках на наших ПК полностью моделируем программную инфраструктуру Заказчика. Вплоть до точного повторения его версии SQL Server.

Пфффф... какие запросы, мальчик? 1С после конвертации БД, при каждом запросе от 1С, тянет всю таблицу тебе на ПК через сеть. При этом размер тянутой информации зависит от сложности запроса. При этом она пишет все подтянутые данные во временный файл в формате, угдай ;) Да, в формате DBF... Так что сынок, не думай, что при переходе на SQL ты получишь мего скорость :) Да же SSD тебя не спасет :) ... Но ты я смотрю не любишь нравоучений, так что, ты на вопрос "можно ли чистить transaction log?", получил ответ "Можно". Да про скорость тебе объяснили. ... Так что "Будь Мужиком, думай головой!" :)

"Папаша", объясни тогда общепризнанный факт (который, наверное, признают все остальные - ну кроме тебя, конечно): почему под SQL 1С может работатьне так, как в DBF базе?

потому что запросы криво написаны

не зачем держать у себя всю базу. обрежь

Пусть новоиспечённый родитель объяснит - не надое му подсказывать :)

Ха=ха, интересная мысль. И после этого бух. баланс сойдётся? Вы себе представляете, что такое почистить бух. базу предприятия скажем за 10 лет работы с таким количеством ОС ?

А почему бы балансу не сходиться? Ни фига не понимаю Вашу мысль :(

Странно... И как люди работают, ежегодно обрезая базу? У них, наверное, никогда баланс не сходится...

Может не совсем точно выразился. Уточню: базу резать можно, но это очень кропотливый ручной труд. Это не одна из стандартных конфигураций - там уже уйма своего написана/переписана, и настроить какую-то автоматическую процедуру очистки такой базы - это тот ещё труд.

А Вы как хотели? И с елки осматривать окрестности, и за зеленкой в аптеку не ходить?

Начинаем уходить в сторону от вопроса, с которого начался флейм...

жать базу можно. Ставить лог 1 нельзя. Наверное прирост для лога 10% стоит? По умолчанию? Вот ты свой серер и нагрузил. Установи размер лога где-то в треть базы.

Вот нам всем пример - человек тихо и спокойно всё подытожил :)

Как резюме осталось добавить только 1 пункт: ставь 'recovery model' в 'simple' для лучшей производительности и меньшей скорости роста лога.

Вы так и ни хрена не поняли, хотя Вам столько времени все объясняли :(

Я, например, для себя все вопросы прояснил. Ладно, пускай собаки лают - а моему каравану дальше двигаться надо.

Малыш, ты сейчас послал всех гуру по 1С :) ... Плыви, титаник :)

Дятел, птица, тоже птица :)

"1С после конвертации БД, при каждом запросе от 1С, тянет всю таблицу тебе на ПК через сеть. При этом размер тянутой информации зависит от сложности запроса. " Весьма спорно, и касается исключительно некоторых черных запросов. Ибо не каждый запрос можно транслировать в sql, скажем если в запросе применяются функции. Вообще, черные запросы в семерке - ЗЛО, ибо идеологически кривее этого только регистры накопления. А вот прямые запросы - рулез.

Не очень понятно, зачем задействуется лог при Select`ах? Изменения данных не происходит... Замедление, скорей, может вызывается перестройкой индексов, либо какими-то глюками при построении плана запроса

не при просто селектах, а при селектах одновременно с записью из других потоков

Ну это же не Select:) Там идет блокировка вставки, перестроение(возможно), Select...

Что же ты, папаша-гуру-1С, так и не нашёлся что ответить, когда тебя упрекнули в том, что ТЫ, такой великий, не смог ответить на один простой вопрос: почему под SQL 1С 7.7 работает не так, как под DBF? А то что ты оскорбляешь других людей, просто показывает твой уровень как человека. не как специалиста, а как Человека. Ну да ладно. Как у нас туту в округе говорят, "дай Бог тебе здоровьячка".

Ну вот примерно таких подробных объяснений я и хотел услышать. Вроде как база 1С в моём примере из вопроса должна только на выборку работать (=SELECT SQL), но лог-то растёт... Т.е. какие-то попутные операции на обновление таблиц идут. Например, действительно перестройка индексов.

Какая перестройка индексов может быть при чтении?

Профайлер спасет. И обслуживание индексов, возможно.

Мне тоже это и непонятно, но кто его знает как там 1С внутри устроена (кроме разрабов :)

Да все уже знают. Кому не лень. Не занимается она в фоне всякой хренью.