Журнал транзакций заполнен. HRESULT=80040E14. Лог в 350 гиг #570612

Забился диск. Интернет прошуршал. Никаокго решения не нашел. Одно есть у Евгения Но не помогает, ругается что нет такого метода T_runcate_only SQL 2005. Перезагрузки сервера, скуля, остановки сервера 1С не помогают. Лог чистится не хочет.

Забился диск. Интернет прошуршал. Никаокго решения не нашел. Одно есть у Евгения Но не помогает, ругается что нет такого метода T_runcate_only SQL 2005. Перезагрузки сервера, скуля, остановки сервера 1С не помогают. Лог чистится не хочет.

shrink сделать ??

Вчера вечером запускал реораганизацию Не помогло.

шринк не делается. как раз и вылазит ошибка эта

По ссылке прочитай. Все в точности так же.

>>Никаокго решения не нашел плохо искал а метода T_runcate_only нет, есть Truncate_only

в гугле набери "sql 2005 shrink log file" 100500 примеров рабочего кода

например USE DatabaseName DBCC SHRINKFILE(<TransactionLogName>, 1) BACKUP LOG <DatabaseName> WITH TRUNCATE_ONLY DBCC SHRINKFILE(<TransactionLogName>, 1) GO

Теперь я стану почетным членом Профсоюза 1сников?

Спасибо Друг!!! Убрал чертночку сразу 250 гиг снесло как и не бывало!

Правда юзеры расстроились... теперь работать придется.

Это насколько надо быть ленивым что не контролировать свободное место на сервере? Ну или хотя бы за размером базы следить. Этож надо лог до 350 гиг дотянуть, а если бы был терабайтный винт?

Самый эффективный и быстрый способ экстренного избавления от лога - детач, физическое убитие лога и аттач с созданием нового. А вообще, нафиг тебе модель восстановления full, ежели ты бэкапы транзакций не делаешь? Поставь simple и лог расти не будет. Правда, ежели база помрет, но выживет старый бэкап и не чиканный с того времени лог, то есть шаманские способы восстановления. Но лучше всего просто штатно лог бэкапить.

Первый раз с sql столкнулся? Ставь simple, один фиг в этой базе архивация не настроена по-человечески.

он зарабатывать хочет, через N времени опять позовут и отбашляют за починку)

Может ему проще работать будет? А то с зарабатываем у него не очень получается.

Хватит бердни соченять спасибо. Прочитал что это баг скл сервера, какой то службы которая отвечает за лог файл. В результате чего лог не режется и соотвественно за считанные дни может забить всё.

Интересно, где это названо багом SQL Server'а. Хотя нет, такой бред читать не интересно

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

и в чем баг ? ты сам выбрал фул-режим

баг в том, что все работало намано, потом запустил обработку 1С на ночь, транзакция была большая. обработка отработала, а транзакция повисла. и лог начал резко расти и за ночь место на диске кончилось, гигов 200 съело просто так. почистил все, запустил обработку без транзакции, все прошло успешно. так и не понял в чем дело, списал на плохую погоду на марсе

[обработка отработала, а транзакция повисла] сказочник

Ты первый начал.

Маня, это тебе не всякую муйню рисовать - тут читать BOL надо много.

Я нашел в гугле что это баг службы скл. какая то бибилиотека.

ну все заклюют теперь маню багом в скл :)

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

какой баг то злой, что аж его с хз какой версии починить не могут )))))

Тема просто дичайший баян

Баян. Не баян. Но поисковики никуда больше не привели. В сабже единственная нормальная ссылка с описанием и решением (но опять же там тоже автор не значет причины и не указывает её). Ошибка в коде.

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

Если внимательно изучить яндекс/гугл по поиску 1С HRESULT=80040E14 то там весь мосх вылезет. Ссылок полно - толку полный ноль. Такие же делетанты вопрошают и отвечают. С учетом того что код ошибки касается многих проблем различных (выдается при разных обстоятельствах) Кстати поиск и выдача показательна тем насколько эта проблема глобальна повсеместно. И с ней сталкивается дофига народа постоянно. Надеюсь аргументировано ответил.

нуежели тебе интересна такая работа? я бы в жизни не устраивался чтобы такое делать. Для меня 1С это хобби и удовольствие в решениях задач. Предагать услуги по вывозу мусора это слишком низко как то.

Маня, соглашайся на платные удаленные консультации - вон народ предлагает. Тебя же попрут с работы нафиг с такими знаниями. Это не баг скуля, чайнег. Это его штатное поведение. Я даже не знаю с какого места начинать объяснять :)

напиши это Мане по почте. Я его что то в этой ветке не вижу.

вот именно. ))  каждый должен заниматься любимым делом ;)

кстати. какое еще "штатное поведение". Обоснуй. Иначе как то несеръезные аргументы. Тыж знаток?

так ты начни уж с какого нить места. Нормального. Так чтобы одним постом, а не на сто догадки лепить.

Кстати тут все такие умники и полагающие что майкрософт и SQL и вообще любое ПО на земле не содержит ошибок? Если их 1С сотнями шлепает, й майкровоста они как правило тысячами регулярно выходят апгрейды.

Маня, ну ты клоун :)) Начнем с простого: - ты знаешь что есть BOL?

Кстати по спискам ошибок типовых которые лежат на официальном сайте там есть ошибки, которые датированы 2006-07 годами и так и висят, причем за десятки обновлений так их никто и не исправляет и видимо и не собирается.

Тут дело в том, что SQL Server не совсем тот механизм который "обязан" работать из коробки, его надо чуть чуть настраивать хотя бы по минимуму. Например, сделать планы обслуживания нормальные.

Дык у тебя же и научились.

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

Маня, наводящий вопрос: а ты када делал бекап этой базы?

А что техподержку Микрософта спросить не судьба?

и как это относится к ошибке? планы и прочее. Не наблюдается никакой нитки связывающей. Ты отвечаешь! что настройка и планирование на 100 процентов! и эта ошибка не появится?

Погоди. Если у тебя за ночь лог на 350 гиг разбух без причины (не было тяжелых обработок) - это одно. Возможно, в самом деле баг. А если лог рос изо дня в день и в итоге дорос - то это твой баг, а не майкрософта.

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

Дык и дураку понятно. Этож надо так на сервером издеваться что он общие ошибки выдавать стал. А что бекап вообще не делался?

После выполнения твоего скрипта у тебя вычистилось 250 гб, планом обслуживания делается следующее(например):

Ничего не росло. Он был в регулярном состоянии от 5 до 10 гиг. И шринком я его чистил. Да и тестирования провожу регулярно и прочие процедуры.

Ты скуль чтоль первый раз увидел?

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

Ну? Так за какой период был резкий скачок и были ли в этот период "тяжелые" обработки и перепроведения? Модель восстановления full как раз и предполагает, что лог сам резаться не будет. А рости он может скачкообразно - в зависимости от активности в базе.

что дураку понятно? бьаза работает себе три года. Ничего не пухнет, все нормально работает, бекапы делаются выгрузкой и раз в несколько дней СКЛ бекапом. И тут на те. За день (видимо именно за ночь). В описании к ошибке сказано что проблема в незавершенной транзакции, которая произошла и вынудила какую то службу раздувать лог.

Причем тут БЕКАП И ШРИНК? Пилять вы тут все такие тупики. причем тут ЭТО? и Обслуживание и прочее? Если произошел сбой, ошибка и скуль начал раздувать лог.

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

Маня, ты дураг и палишся :)

Я вот ржу над одной из ошибок, когда прога не пускает в пофигуратор не позволяет сделать обновление и прочее. И юзеров выкидывает) нашел в инете)) долго ржал. оказывается чтобы ошибка исчезла нужно в списке запуска 1С удалить строку с базой и прописать заного))) Это мега просто. причем никто ничерта не шарит в чем проблема, но решение нашли.

Вот так сам и взял? Не верю.

Мисье, я Вас покину.

Маня мне тут по аську стукнулся и сказал что он шлет тебя лесом.

Смейся дальше. Это просто простейший способ похерить проблемные пользовательские настройки, если нет времени и желания разбираться в чем именно там проблема возникла.

Стесняюсь спросить, у Вас случаем не раздвоение личности? А то в профилях сайт один и тот же да и фото очень похожи.

Короче все с вами понятно. Пришли высунуть что-то (ведь всегда можно кинуть - ну маня - это считается универсальной отмазкой), но высунуть нечего и себя спецами называют. Я неуч в этом вопросе и признаю это, но вы то куда лезете? Я как опытный задал простой вопрос - конкретная ссылка на описание проблемы (предоставленная 1С либо майкрософтом). Обычно спецы оперируют этим. Но никто не привел.

Ты про себя говоришь? ты разбирался? сталкивался? знаешь? - никуа не знаешь только трындишь что надо делать. Обычно все ошибки документированы майкрософтом либо 1С (насчет 1С не уверен).

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

Я написал что я нашел в интернете(!) а не сам придумал. Что это ошибка SQL и службы. Т.е. баг проги который вызвал такое поведение. Причем получается достаточно редкий. Вы тут начали пистеть всякое разное и прочее. Сразу видно никто вообще не имеет даже представления об админской работе.

Маня, начинаем: - для затравки: (читай все, но обязательно про параметры восстановления RECOVERY MODEL);

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

Понять не могу. Это ты троллишь так, что ли? Твое сообщение об ошибке, которым ты тыкаешь - следствие того, что место на диске закончилось (ну или задан предельный размер лога в настройках, но у тебя другая ситуация). СЛЕДСТВИЕ, а не ПРИЧИНА. Причину тебе уже миллион раз попытались объяснить. Про себя и других. Разбирался, сталкивался, знаю. Хамить начал? Тогда ПНХ. До свиданья.

"Про себя и других. Разбирался, сталкивался, знаю." НУ И ГДЕ ЖЕ ОТВЕТ? Почему вышла ошибка? Конкретно что сбойнуло?! Вы или меня не понимаете или решили мое время потратить на вас.

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

А что логи посмотреть не судьба было? Там как все и было написано. А сообщение тебе вообще-то не сервер выдал, а провайдер. Сервер сообщения в логи пишет.

Маня, блеать, это не ошибка SQL и службы. Ты вообще не туда смотрел, так как знаниев нет. HRESULT=80040E14 - HRESULT это коды ошибок, используются в COM (в частности OLEDB). 0x80040E14 - это сама ошибка, но это ни о чем. Это говорит только то, что последний вызов oledb-метода (скорее всего ICommandText::Execute) прошел с ошибкой. Текст ошибки тебе вывалили.

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

Ну дык причина проста. Наймите DBA.

Или будешь все своими руками делать? Если да. Ну чтож поделать, раз ты такой нищий

+ Даже не обязательно перепроведение. Из-за реструктуризации такое может быть, если структура БД менялась.

(760 там тоже предположения. Ибо если бы это было утверждение то ошибка бы была систематической, т.е. постоянной при каждом большом перепроведении. И у всех! Но это произошло у меня раз за 3 года, судя по интернету тоже самое просходило еще у десятков других людей работающих не первый день. Все это 9если идти по логике) является следствием какой то очень сложной хрени которая смогла произойти. А эьто в свою очередь означает что это редкая ошибка и происходит она вне зависимости от настроек, и прочей ЛАПШИ которую тут на уши вешает Кириллка.

иди для начапла сайт себе сделай, нищий.

У тебя сейчас выставлена модель восстановления FULL, что подразумевает, что за лог-файл ты сам отвечаешь. Он будет расти до бесконечности, при такой модели, пока ты не выполнишь бекап, после чего он обрезается. И дальше по новой. Расти он будет от каждой транзакции. Сделал запись/проведение/удаление чего-либо - получай увеличение лог-файла. Он потому и называется так, что хранит все транзакции, по которым в случае чего можно откатиться до нужного состояния.

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

Ну ты же прог, как ты можешь нам тут такую лапшу вешать "оно само сломалась". Как тебе не стыдно.

мне этот вариант подходит. Но лог я регулярно проверял и шринкал. и делал бекапы. Он максимум рос при базе в 60 гиг был у меня 15 гиг. Но не 250 за одну ночь. Так что модель тут нипричем.

Служба эта называется Database Engine. Когда она аварийно останавливается, то ой.

Маня, ты дураг, опять палишься :))

Так сделал уже. Уже и продал немного. Дело пошло. С понедельника на магенту перехожу. А то что-то много народу набежало.

чтобы она остановилась тоже должна быть причина.

С логикой у тебя всё в порядке. Но ты сам признал, что в вопросе не рубишь. Значит не можешь отсеять адекватные отзывы в интернете от дилетантских. Поверь, дело с 99,9% вероятностью не в ошибке MSSQL. Причина в том, что по какой-то причине была очень высокая активность в базе в дни между бекапами, что лог добросовестно и отразил. Размер базы у тебя какой?

остановка службы следствие.

60 гиг.

Ой палишся. Это чтоб лог у тебя так вырос ты должен был базу за ночь раз 400 перепровести.

Причина криво настроенные бекапы. Или они вообще не выполнялись.

Вчера окола 5 часов я с диска убрал 30 гиг файлов. До 18 часов эти 30 гиг испарились и осталось 10 метров.

Ну ты же прог, как ты можешь нам тут такую лапшу вешать "оно само сломалась". Как тебе не стыдно.

Вполне достаточно. На 7.7 при реструктуризации базы с полным пересчетом бухитогов у меня лог где-то впятеро и раздувало. Когда недельку не чистил, то после реструктуризаций и перепроведений и вдесятеро разносило.

В 18 запустил на базе сжатие с реорганизацией. Час просидел не дождался .уехал домой. Утром юзеры заходя в базу и при любом двмижении - отчете, либо записи дока вываливались из БД. Реорганизация завершилась вчера через 20 минут после моего уезда и проблему не решила. базу не сжала. Шринк начал выдавать ошибку и пришлось залесть в инет и найти код для скрипта со шринком.