1с sql Просмотреть лог файл #120896

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

а чей лог смореть то? 1с или же Sql?

При проведении базы вылетела ошибка sql, видимо его логи и нужны...

Блин, хоть бы послал кто... в нужном направлении... Меняю правильный ответ на вкладышъ от "Дональда"!

Текст ошибки в студию.

в логахъ я его и мечтаю найти, говорят что то типа "потеря связи с базой" если с аглицкого переводить... фигня в том что сам я этого увидеть не успел :(

Мне б только знать как прочитать то что нарисовано в baselog.ldf, быть может счастье совсем близко...

счастье даже на горизонте не маячит, потому как не там логи те, что ты ищещ. То, что тебе хочеться лежать в "Program FilesMicrosoft SQL ServerMSSQL$SERVER_TESTLOG" - но они тебе ничем не помогут..

вот ведь, замкнутый круг получается... как жеж мне победить то что возникает глубокой ночью, повторяется не по законам а по собственному разумению да к тому же еще и не оставляет следов... мистика прям... Спасиб и на этом, вот только вразумите тогда что там в этом baselog.ldf на стольго гигов напихано (под 30 гиг)?  или эт так предательски назвали саму базу, что я её с логом спутал... Если есть немного полезных сцыл по теме (где что искать в этом sql-е), был бы признателен, и выслал бы вкладышь на указанный вами адрес :)

у тебя 30 гиг файл ldf ? интересненько... лдф - файл транзакций, он не должен быть такого размера. Мой совет: базу через конфигуратор выгрузить в зип, потом создать новую, с неограниченным ростом лдф'а, загрузить, бэкапнуть, шринкануть, списать размер лдф"а, ограничить рост бэкапа этим размером, прописать еженощный бекап и хотя бы еженедельный шринк. Возможные грабли: если база долбанутая, при выгрузке может упасть. Т.е. лучше сделать бекап, из него поднять копию, ей сделать тестирование и исправление, потом ее выгружать и дальше по плану; но может не хватить места на сервере.

+10 >ограничить рост бэкапа то есть ограничить рост файла транзакций=лдф.

Спасиб за инфу, нечто подобное делал не так давно, по подсказке бывшего смотрящего, видимо толку не много случилось. Вообщет база страшна, нечто полностью самописное, огромное, с хранением вместо ссылок на объекты их текстовых идентификаторов, и прочими радостями доставляющими не мало гемора, избыток инфы в ней коллосальный, я даж опасаюсь её сильно чем нить напрягать, масса уж фантастических замутов в ней бродит... Есть что-нить из литературы, что бы не на ощупь делать, ненавижу пытаться исправить то чего не понимаю...

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

почему превосходит?, нет ограничений я пока не делал, вот только понять бы как это влияет на "потерю связи с базой" во время проведения, я кажется "0" в sql администрировании и походу без литер-ры мало чего пойму... не хочетца вас напрягать боле... мнебы книгу умную или сцылу... Спасиб... не думал что все так запутано... Я попобую еще раз все это проделать но только обдуманно а не нажимая то что на листочке написали... :)))

у лога ограничения нету, соответсвенно, он начинает прирост, допустим, на 10% от размера ночью. Значит, пока лог будет расти, 1С будет ждать ответа от SQL а потом вывалится по таймауту, что у тебя и наблюдается. Отсюда вывод - сократить этот самый лог, например, так backuplog baselog with truncate_only и быть счастливым.. счастье будет продолжительным, если это делать не оставлять на самотек..

Спасиб, постараюсь разрулить...