Сеть из трех серверов, везде SQL, зоопарк конфигураций, платформа везде одна 8.3.13.1644.
Uptime около двух лет.
Внезапно ложится электроснабжение. UPS не удержали, полтора часа без электричества.
После включения появились вопросы к одному серверу.
на нем крутятся 3 базы Альфа-авто 5.х, УАТ (тоже Рарус) и одна старая ЗУП.
ЗУП и УАТ работают нормально, все 3 Альфы выкидывают Ошибку формата потока в произвольных местах, при открытии или проведении журналов или документов.
Что делали:
-кэш чистили
-сервер останавливали
-базу с сервера удаляли и добавляли обратно
-1С на сервере переустановили
-ТиИ
-базу выгружали в dt и загружали обратно
-базу выгружали в файловую, тестировали chdbfl и ТиИ и загружали обратно
-меняли пользователей на новых
-IPv6 отключен, по крайней мере в свойствах сетевых подключений
- ЖР сократили
База прекрасно проходит ТиИ, chdbfl и выгрузку в файлы.
Кэш сервера можно почистить удаляя базу через консоль "Администрирование серверов 1С" . У меня обычно когда очистка кэша на терминальном сервере у пользователя не помогает я делаю чистку самого сервера 1С и именно таким образом .
(8) Ошибка формата потока это вряд ли проблема с сервером.
Она возникает когда платформа при сохранении данных во внутреннем формате допустила ошибку.
Сама по себе эта ошибка "Формата потока" самая не информативная. Понять где проблема с данными нельзя.
Для примера, это конечно не касается данного случая, но по теме "Ошибки формата потока" - если в каталоге файловой базы создать пустой файл 1Cv8.cdn (пустым по стандарту он быть не должен), то это тоже будет "Ошибка формата потока"
(1) про лицензии ничего не написали, очевидно там кряк висел, а после ребута отвалился. 2 года не перегружали сервак?) А потом узнали что с 8.3.11 формат полетел))
(20) На новой платформе базы Альфы проработали месяца три до этой перезагрузки. Плюс откатить платформу нельзя, на ней всякие базы на УФ работают, на других серверах. Технически можно, но надо потом всем прописывать версии платформы для баз, убиться.
(9) Все базы на MS SQL. Они физически не могут запускаться на разных платформах. Сразу происходит сверка версий клиента и сервера и сообщение об ошибке.
(25) нашел Tool_1cd 0.3.0 2015 года.
С форматом 8.3.8 он работать не умеет.
Выкинул базу в файловую, конвертировал в старый формат.
Она перестала открываться, причем говорит что чем-то занята.
(32) Перестала открываться где?в конфигураторе или tool_1cd? В любом случае она может открыться или там или там. Возможно где-то процесс открыт и висит
tool_1cd с возможностью редактирования?
По поводу старого формата - да, надо конвертировать. Есть версия 0.4, которая умеет с 8.3.8 работать, но она без возможности редактирования
https://yadi.sk/d/UQPr9PsV3ljMpQ - 0.3 с возможностью редактирования - 100%.
Она перестала открываться, причем говорит что чем-то занята.
Unlocker'ом можно попытаться выяснить - кто занял?
А вообще, вот что пришло на ум - а антивирус на сервере есть? Какой? А то у меня в практике был случай, когда наличие Касперского приводило к ошибкам в работе файловой базы, причем chdbfl.exe "помогала" весьма своеобразно: с каждым ее прогоном количество найденных ошибок в базе лавинообразно увеличивалось!
(34) (33) и в Конфигураторе и в Tool_1CD. Было поздно, unlocker на production сервер ставить было страшновато, и я отложил этот вопрос до сегодня. Антивируса нет.
(1) Попробуй покопать в сторону того как Альфы защищены ? - Что там ключ, лицензия, доп файл ? - может быть ошибка связанная с защитой конфигураций. Типовухи то нормально пашут, да еще и три одинаковых конфы.
(1) А в файловом режиме попробуйте поработать с АльфаАвто? Если к структуре базы нет вопросов - значит при работе в файловом режиме их не будет. А движок баз какой? Postgres или MS SQL? Попробуйте, убедимся в стабильности файлового режима, затем в зависимости от движка будем смотреть, что происходит при ошибке.
1. Обязательная остановка сервера 1С (если не остановить - чистка кеша не помогает).
2. Чистка кеша у ВСЕХ пользователей (беда, когда их много :-) в C:\Users\-UserName-\AppData\Roaming\1C\1cv8\
1. проверить винты на ошибки после таких отрубаний не помешало бы.
2. при действиях с базой - ее из списка баз 1с удаляли или нет? было такое когда-то - помогло удалить из списка запускаемых баз добавить ее же из другого места под другим именем в списке.
3. проблемную базу перенести на другой комп локально. если работает норм - искать проблему в сервере.
(10)1. Попробуем, спасибо. Но в логах Win и SQL серверов должны же быть сообщения об отказе оборудования в таком случае?
2. кэш чистили, базы из списка удаляли.
3. Попробуем, но админы артачатся. Чето у них там не срастается с возможностью переноса пока. Но такая идея у меня в списке есть.
(12)
сисадмин грит в системных логах такого не фиксится. надо чтото стороннее юзать. sql точно не скажет будут только ошибки базы фиксится. еще вариант попинать сеть. может пакеты улетают в никуда если какойнить роутер пошел погулять. но это все после исключения ошибки базы (сиречь 3 вопрос)
(13) Тоже думаю в эту сторону. Там еще система управления оборудованием есть.
Но УАТ от того же Раруса на тех же библиотеках стоит рядом и работает норм.
Если ТиИ и выгрузка-загрузка dt проходит, то повреждены не данные, а конфигурация.
Если повреждения в конфигурации поставщика, то поможет снять с поддержки и обратно поставить.
Если повреждения в текущей конфигурации, то накатить конфигурацию из целой базы. Просто накатить, без сравнить-объединить.
1. если имеется ранняя копия БД разворачиваешь рядом с основной
2. Делаешь копию своей БД на всякий случай
3. удаляем данные из таблицы config нашей продуктивной БД
delete from ТвояБД.[dbo].[config]
копируешь из созданной БД в шаге 1 таблицу config в свою продуктивную БД.
INS ERT IN TO ТвояБД.[dbo].[config]
SEL ECT * FR OM КопияБД.[dbo].[config]
GO
Пробуешь запустить, данный метод работает если конфа копии и продуктива совпадает
Оказывается какой я везучий...
На этом же сервере лежали несколько копий этих же самых Альф для разработки.
Вот что получил при запуске одной из копий. Восстанавливать наверное не буду.
А варианты пробую, завтрашний рабочий день покажет что получилось.
(31)Если сервера просто упали, а не выключились, то наибольшая вероятность это частично рухнувший дисковый массив, проверьте дисковый массив на ошибки, а затем файловую систему с исправлением ошибок и перезагрузкой сервера.
(71)Еще 1 вариант посмотреть журнал скл сервера на момент запуска сервера после падения, возможно он сделал либо * открытых транзакций либо усечение лога обнаружив битые записи, если такое было, то база частично разрушена.
(31) У моих клиентов данное сообщение появилось после применение крека при обновлении платформы. У Вас она точно лицензионная? Не закидываю, просто стараюсь помочь :-), а то люди мучались, базу восстанавливали, а оказалось все просто.
Когда ты снимаешь с поддержки конфигурацию для того что бы сделать ее не типичной программисты 1с сделали так сказать подвох, в данном моменте она разделяется на 2 базы: 1- это основная типичная конфигурация, которая становится подскрытой, а вторая уже твоя с которой ты работаешь! Так вот когда происходит сбой очень часто слетает конкретно эта подскрытая база и выдает Ошибку формата потока и так просто определить в каком месте это происходит трудно.
Отдельно установи родную версию конфигурации методом объединения добавляй свою конфигурацию после чего выгружай уже отреставрированую конфигурацию и заливаю ее в свою БД.
У меня была типичная ситуация перерыл все что только не пробывал ничего не помогло пока так не провел данную процедуру.
(36) Надо же!!!!!! какой ты внимательный!!!!!!
Я сообщил о том что наоборот СРАВНИ!!!! и ОБЪЕДЕНИ!!!!
иначе вы по верх запишете те же самые ошибки конфы что у вас и не найдешь в чем причина!!!
(35) довольно часто причиной ошибкой потока является конфигурация поставщика.
Проверяется попыткой сохранения базы поставщика в cf. Лечил загрузкой чистой конфигурации в основную с накатом затем изменений
(39) Информативно. Но у меня ОФП вылазит хаотично - вот сейчас с утра сам поймал:
1 - при открытии Чек ККМ
2 - при открытии Номенклатуры
Пипл ловит при редактировании Выписки, при добавлении товаров и работ в Заказ-наряд.
Обычно в файловом режими помогает такие ошибки устранить chdbfl или удаление из списка этих баз и добавление их обратно. Может платформу обновить? Или как вариант создать чистую аналогичную базу и перекинуть туда данные из ломоной базы.
Попробуйте найти последний работоспособный архив, поднять его на копии, сохранить конфигурацию в .cf, в рабочей базе разрешить изменения, применить, снять с поддержки, применить, загрузить конфигурацию (не "сравнить-объединить"!) из .cf бэкапа, применить.
Также ошибки формата потока бывают из-за побившихся внешних печатных форм и обработок в базе.
Ещё есть мысль проверить chkdsk файловую систему диска с базами SQL попробовать DBCC CHECKDB на SQL-базе https://infostart.ru/public/61123/
Антивирусы отключи, фаервол на время на сервере с базами и сервере лицензирования (где стоит та часть которая позволяет запустить Альфы легально), могли настроить по принципу "до перезагрузки".
По моему личному опыту ( правда только на файловых базах ) Если ошибка проявляется в разных местах и при разных действиях , то скорее всего ошибка в системных таблицах базы ( не обязательно config или configssve) я бы смотрел в сторону таких таблиц как Systemsetting , Dymlistsetting и т.д ( всего их не больше 15 таблиц) , опять же ТЖ должен показать к какой таблице обращается , после которой происходит крах системы .
Явно Рарусовская защита глючит. Почему - надо разбираться. Может быть, не та версия DLL цепляется, как разъясняется тут:
Для каждой конфы прописывается каталог системы защиты, так что для одной указываете каталог, например, LocalProtect08, в котором размещаются файлы системы защиты этой конфы, для другой - LocalProtect18. При начале работы системы идет синхронизация с системой защиты в указанном каталоге на сервере, потом с локальной системой защиты на компе.
(56) Надо прокачать эту тему тоже. у меня 2 базы 5.1.10.09, одна 5.0.13. но глючат все вместе и одинаково, а копии, незапущенные в момент сбоя, пашут как часики.
Переактивируйте лицензию сервера 1с, лицензия сервера проверяется только при 10 активных пользователей и часто без лицензий сервер ведет себя очень странно!!!!
61.
Aleksandr_prof
19206.04.19 13:42 Сейчас в теме
Предлагаю вариант лечения базы по шагам:
1. Находим любую рабочую резервную копию этой же версии. Если работает - выгружаем конфигурацию поставщика и переходим к пункту 2. Если не работает, проблема не в базе и не в конфигурации. Тогда удаляем полностью платформу, СЛК и ставим заново.
2. В повреждённой базе выгружаем все данные с помощью обработки в XML файл.
3. Создаём чистую базу из конфигурации поставщика.
4. Загружаем данные из файла XML обратно в базу. Делаем ТИИ, проверяем список пользователей и их права (а желательно вообще завести новых пользователей!!! это важно). Пытаемся воспроизвести ошибку. Если ошибки нет - значит задача решена.
(61) вот что получается:
я взял базу разработчика, которая с осени лежала на винте в файловом варианте.
Версия конфигурации та же, что и у аналогичной рабочей.
Через dt закинул ее на сервер и попробовал повалить с ОФП.
Нифига, работает как проклятая со вчерашнего вечера и не падает.
То есть получается - проблема в закрытом модуле в основной конфигурации?
69.
Aleksandr_prof
19209.04.19 14:20 Сейчас в теме
Какие исходные данные на текущий момент? Правильно понял, есть на данный момент есть повреждённая база и чистая? Обе одной и той же версии? И обе серверного режима. И что делать дальше - вы не знаете. Так?
(69) Да. "Поврежденная" база проходит все мыслимые тесты и выгрузки на ура, в файловом режиме работает как часы.
Конфигурации поставщика, взятые из "Поврежденной" и "живой" баз, идентичны.
Сегодня в 21:00 мск сравню основные конфигурации. интуиция подсказывает что они тоже будут идентичны ).
в данном случае "живая" база - это моя копия этой же базы для разработки. Обе базы подкл. к одному хранилищу.
(70)Судя по ошибкам, у вас не структура повредилась, а данные конфигурации и возможно данные самой базы. По пробуйте выгрузить конфигурацию ошибочной базы в новую базу и воспроизведите ошибку. Простым сравнение может и не дать результата если есть скомпилированные модули.
77.
Aleksandr_prof
19210.04.19 03:42 Сейчас в теме
Предлагаю сделать так рабочую базу: создать чистую базу, абсолютно чистую. С помощью специальной обработки выгрузить все данные из повреждённой базы в файл. Потом с помощью этой же обработки загрузить данные из файл в чистую базу.
(77) Думаю можно попробовать выгрузку и загрузку сторонними программами (Через MS SQL), и пробовать загрузку данных сторонними средствами в чистую конфигурацию. Сейчас полно таких здесь. Вообще РАРУС достал своими "защитами" от копирования и использования, поэтому сбои лицензий тоже нельзя упускать из вида.
Сегодня переустановили систему защиты. Я уж было хотел $m начать раздавать, но тут вылетел с ОФП уже из базы, которая не вылетала до этого вообще. Поиск продолжается.
(80) Проблема была в одновременной эксплуатации баз Альфа 5.0 и 5.1 на одном сервере. Сначала две базы 5.1 убрали на другой сервер. Они там прекрасно заработали.
5.0 на старом сервере продолжала вылетать до обновления на 5.1.16