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

shrink сделать ??

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

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

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

>>Никаокго решения не нашел
плохо искал

а метода T_runcate_only нет, есть Truncate_only

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

например

USE DatabaseName
GO
DBCC SHRINKFILE(<TransactionLogName>, 1)
BACKUP LOG <DatabaseName> WITH TRUNCATE_ONLY
DBCC SHRINKFILE(<TransactionLogName>, 1)
GO

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

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

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

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

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

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

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

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

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

(16)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кстати поиск и выдача показательна тем насколько эта проблема глобальна повсеместно. И с ней сталкивается дофига народа постоянно.

Надеюсь аргументировано ответил.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Бекап лога
2. Шринк
3. фул бекап

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Маня, начинаем:
- для затравки: http://msdn.microsoft.com/ru-ru/library/ms190249(v=SQL.90).aspx (читай все, но обязательно про параметры восстановления RECOVERY MODEL);

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

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

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

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

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

(68)Маня, блеать, это не ошибка SQL и службы. Ты вообще не туда смотрел, так как знаниев нет.

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

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

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

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

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

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

А эьто в свою очередь означает что это редкая ошибка и происходит она вне зависимости от настроек, и прочей ЛАПШИ которую тут на уши вешает Кириллка.

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

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

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

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

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

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

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

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

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

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

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

(90) 60 гиг.

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

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

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

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

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

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

Реорганизация завершилась вчера через 20 минут после моего уезда и проблему не решила. базу не сжала. Шринк начал выдавать ошибку и пришлось залесть в инет и найти код для скрипта со шринком.

(98)почаще так делай
утопят тебя учредители
а перед этим яйца отрежут

(98)Ну дык причина ясна. Наймите DBA. Могу тряхнуть стариной. 50% скидка.

(98)а сегодня не уехал потому что паяльник уже греют? )))

Маня, будь мужиком, блеать. Признай, что ты чайнег :)

Специально нашел для чайнега:
#define DB_E_ERRORSINCOMMAND ((HRESULT)0x80040E14L)

Это код твоей ошибки, объявлена она в oledberr.h
Т.е. еще раз, эррогировать на HRESULT=80040E14 нет смысла, потомочто в HRESULT=80040E14 написано по-программистски (ну т.е. не для тебя, так как ты не программист) "Ошибка в команде, ахтунг, за разъяснениями вызывайте GetErrorInfo"

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

(102) если бы ты не булы тупым то уже бы давно открыл ссылку и прочитал бы

Журнал транзакций заполнен. HRESULT=80040E14
Ошибка СУБД:
Microsoft OLE DB Provider for SQL Server: Журнал транзакций для базы данных "zup" заполнен. Чтобы обнаружить причину, по которой место в журнале не может быть повторно использовано, обратитесь к столбцу log_reuse_wait_desc таблицы
sys. databases HRESULT=80040E14, SQLStvr: Error state=2, Severity=11,native=9002, line=1

или

Ошибка СУБД:
Microsoft OLE Provider for SQL Server: The transaction log for database “DataBase” is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column is sys.database
HRESULT=80040E14, SQLSTATE=4 2000, native=9002

Решение:
1. Посмотрите сколько свободного места осталось на дисках, может его нет и логу некуда записаться...
2. Это ошибка Microsoft SQL Server - переполняется лог транзакций и не очищается. Урезать его возможно различными способами, в том числе и с помощью стандартной оснастки, но не всегда данная операция получается, и размер файла лога остается прежним. Как вариант предлагаю следующее решение из двух строчек:

+102 программисты платформы вызвали GetErrorInfo и получили от провайдера "Журнал транзакций для базы данных <имябазы> заполнен...."

Внимательно читаем и смотрим -
Это ошибка Microsoft SQL Server

Я еще в сабже написал ссылку и сказал что ошибка описана по ссылке и у меня таже проблема. Но ты оказался туп и этого не заметил.

(104)Маня, ты серьезно считаешь, что еси будешь меня называть тупым, кто-то в это поверит??

Так вот "обратитесь к столбцу log_reuse_wait_desc таблицы" сообщает нам что там есть незавершенная транзакция. Это и является ПРОБЛЕМОЙ.

(108) нет. я сичтаю что ты тупость проявляешь сам своими постами корчЯ из себя знатока и умника.

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

Маня, еще раз:
- HRESULT=80040E14 это не ошибка Microsoft SQL Server;
- это код ошибки, которую выкинул oledb-провайдер на то, что скуль не смог увеличить размер лог-файла по той причине, что места на диске ему не хватило. Потому что ты криво настроил модель восстановления (бекап раз в полгода). Потому что ты взялся за то, чего не умел никогда. Потому что у тебя руки из опы. Могу долго продолжать ... :)

и я тебе Киррилка не Маня. Будешь маней называть своих родственников. Я тебя впервые вижу и слышу. Для теюя я Евгений Владимирович.

(106) Ошибка программы и ошибка в программе - чуточку разные вещи.

(112) иди накуй. вот что я тебе могу сказать.

(113)бугага, Маня, не смеши меня.

(116) Пидриллка шел бы ты уже. по добру.

мдээээээээээ

(104)Смотрим в книгу, видим фигу? Там же ясно написано кто ошибку тебе писал "Microsoft OLE DB Provider for SQL Server" и где надо подробности было смотреть "обратитесь к столбцу log_reuse_wait_desc таблицы
sys. databases HRESULT=80040E14, SQLStvr: Error state=2, Severity=11,native=9002, line=1"

Иди учись делать бекапы.

Евгений Владимирович зарубите себе на носу. Ни один сервер БД не скажет тебе свою ошибку. Он данные выдает. А ошибки он пишет в логи.
Наймите DBA, и жить станет проще.

Маня, а ты на своем сайте дашь ссылочку на эту ветку, чтоб народ видел, как ты абасцрался прилюдно?

Почему это он абасцрался? Он честно признался, что не является специалистом в данной теме. Потом, правда, начал агрессивно заблуждаться.

(121)нет
сейчас манин друг придет и даст ценный совет
маня пропиарит друга
друг пропиарит маню
и никакой рекламы

Маня, ты так и не понял-поди, что у тебя произошло? Если понял, вещай - мы скорректируем если че :)

(121) а я веточку засейваю

топикстартер правильно всё делает
новый сервак купят за лям
потом сотрудников наберут на поддержку "1с которая тормозит без поддержки"
а сам будет сидеть админом на скуле и смотреть на лог

(121) да я абацрался. но на тебя. Так что не воняй.

(126) я не выполняю обязанности админа. Но если с базой что то происходит то ковырять естественно кроме меня некому. админ который админ в этом вообще ноль.

(127)для пущей окраски ты должен был еще описать каким калом ты на меня абасцрался. Как-то уныло у тебя получилось. Попробуй еще разок :))

(129) ну ты и извращенец. За сим откланиваюсь. Ветка запахла очень сильно. Не выветрить.

(128)так вы там два брата-акробата чтоли? Печалька..

/*жует попкорн*/

(130)Маня, будь мужиком, блеать. Останься и реабилитируйся в глазах общественности - докажи, что ты чего-то стоишь.

Лень читать. Скока на исправлении  этой ошибки маня заработал? хоть часиков 10 выставил на курение манов по скл?

(134) Маня поднял 10 левелов Репутации на этом

(135) + и произвел 3 тонны огородных удобрений

да уж. и эти люди хотят от ста тыщь и покупают логан

(137) зато он знает про рекурсию )))

мажоры хуле...
базнес = связи