Таблица Config целевой базы была заменена на содержимое таблицы Config от другой рабочей базы.
Но на самом деле конфигурации у них существенно отличались, поэтому после таких действий целевая база рухнула окончательно.
Что же делать?
ДИСКЛЕЙМЕР
Автор не несет никакой ответственности, кроме как за достоверность предоставленной информации.
Всю нижеследующую информацию воспринимать и использовать на свой страх и риск.
ПРЕДЫСТОРИЯ
Ситуация досталась мне в следующем виде.
Разрушенная база (её имя для конкретики UTn) — это узел РИБ, который не обменивался с центром с марта 2024. Конфигурация, соответственно, тоже мартовская.
Рядом (на этом же сервере) живая база РИБ (имя UT), конфигурация которой актуальна.
При возникновении проблем в базе UTn — на уровне СУБД была перенесена таблица Config из базы UT
Но так делать нельзя было, так как это внутренние релизы конфигураций с разницей почти в полгода, а значит, таблицы Config и структуры таблиц с данными на уровне SQL существенно отличались.
Мало того — копии не создавались автоматически, и коллега не потрудился создать копию вручную перед выполнением столь рискованного скрипта (по переносу конфигурации на уровне SQL).
И мы получили следующее:
- Разрушенная база
- Эта база важная, восстановить надо любой ценой
- Нет ни одной копии, даже старой
Симптомы на уровне 1С
Первое, что я увидел при запуске Предприятия
Тип не определен <некий GUID>
Завершить перезапустить… 
Конфигуратор доступен, открывается, но при попытке внести любые изменения (точней, обновить конфигурацию ИБ) — валится с записью дампа
ЛЕЧЕНИЕ, РЕМОНТ и ТАНЦЫ С БУБНОМ
Неудачные попытки
По привычке пробовал чистить ConfigSave — не помогло
Пробовал обновить ConfigSave из Config — не помогло
Чистить кеш и всякое такое
«Тестирование и исправление» — запись дампа почти сразу
Попробовал внести изменения в конфигурацию, чтоб спровоцировать реструктуризацию, удалил константу, попробовал обновить конфигурацию ИБ, ошибка изменилась, но, увы, я не помню какая она точно была.
Как я встал на верный путь
Попробовал пойти тем же путем, которым база была поломана, а именно: скопировать Config из разных живых баз от разных дат и на разных серверах
Конечно, идеально подошла бы любая база от даты, когда остановился обмен между разрушенной базой и центром РИБ, тогда бы структура таблиц на уровне SQL и содержимое таблицы Config было бы подходящим. Но такой не нашлось.
После слепого шаманства неопределенное время я в итоге получил ошибку «В схеме базы данных отсутствует таблица…»
Увидел в SQL-студии таблицу DBSchema, с одной строкой и одной колонкой, в которой какое-то сериализованное значение, которые непонятно как развернуть, некий черный ящик. Сделал поиск про эту таблицу в официальном партнерском форуме 1С для специалистов. Наткнулся на опыт, где восстановить работоспособность базы помогла замена содержимого битой базы в таблицах Config, Params и DBSchema на содержимое из аналогичных таблиц живой базы.
Ближайшая база под рукой была вышеупомянутая UT. Разница между конфигурациями живой и битой баз — несколько месяцев. Попробовал..
Иии… БИНГО!
Помогло! Ошибки в конфигураторе изменились, причём на более понятные. Режим предприятия открылся, но формы мало каких объектов открывались, возникали ошибки уровня SQL. Вполне ожидаемо, что SQL «не видел» каких-то реквизитов в таблицах, а какие-то были, наоборот, лишними, но уже было понятно, с чем работать.
Попытка оптимизировать процесс, взяв более «близкую» копию
Пришла идея повторить способ с другими базами, то есть взять копии, чтоб дельта между датами живой и битой базы была поменьше. Но так как базы большие и на этом удаленном сервере — то ли канал был загружен, то ли в принципе узкий, решил не таскать базы целиком, а создать на местах с подходящими копиями отдельную чистую базу SQL, в которую руками перенести эти 3 служебные таблицы из развернутых копий, и эти маленькие промежуточные базы (где только 3 таблицы) уже заархивировать, и их переносить на удаленный сервер с проблемной базой. К сожалению, этот способ у меня не сработал, возможно, я что-то сделал неверно при переносе таблиц Config, Params и DBSchema в промежуточную базу SQL. В самом конце, в конфигуратор либо предприятие войти не получалось, 1С сообщал что конфигурация разрушена, предлагал починить, но безуспешно.
«Долгая дорога в дюнах» или «Рутина, в студию!» [ПРЕДИСЛОВИЕ]
В итоге, я вернулся к варианту переноса этих 3 конф. таблиц из живой базы на том же сервере, пусть и разница между внутренними релизами конфигураций была несколько месяцев. Зато конфигуратор и предприятие открывались, а ошибки если и были — были понятными и разрешимыми, хотя и неясно куда всё это приведёт.
Продолжение следует…
ЭПИЛОГ К ПЕРВОЙ ЧАСТИ
Если тебе интересно продолжение с техническими подробностями, и также краткий курс по SQL для 1С-специалиста — ставим звезду! Чем больше будет людей, которым интересно — тем интересней мне будет этим заниматься, а значит, быстрей, полней и качественней подготовлю и опубликую! Критика, вопросы и пожелания — в комментарии, пожалуйста!
Успехов! И не ленитесь сделать SAVE перед прыжком в пропасть 😉
UPD Продолжение последовало
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Сам сломал, сам чиню… на инфостарт статью пишу….
Уже наверное не первая статья на тему «неудачно динамически обновились»… И всё равно продолжают динамически обновлять…. Ни чему людей жизнь не учит.
Возможно, что автор как раз и исправляет за горе-администратором — программистом!
Автор! Добавьте по-больше скриншотов для наглядности! 😉
Называйте статьи правильно: «Как я безуспешно восстанавливал разрушенную базу».
like за колоссальную работу! Когда у самого случилась такая фигня, убил не мало времени и сил. К сожалению не полностью удалось восстановить (((
(1) TODD22, я обновлял и буду обновлять, так как соблюдаю правила и готов к возможным ошибкам (знаю как лечить). Мне лично непонятно слепое отрицание динамического обновления без попытки разобраться что к чему.
(6) bforce, Обновляй кто тебе запрещает?
Разобраться в чём? Если есть вероятность того что что то будет испорчено динамическим обновлением проще от него отказаться чем разбираться.
Мне лично на работе есть чем заняться. Если есть на работе свободное время ломать базы а потом героически по 3 дня разбираться что к чему и как это починить я рад за вас.
У меня к сожалению 100+ розничных торговых точек торгующих практически круглосуточно. И простой центральной базы хотя бы 1 день несёт в себе невероятные проблемы.
Разговор не о том что кто то «слепо отрицает» а о том что динамическое обновление периодически подкидывает проблем и периодически появляются статьи как эти проблемы исправлять.
Я то же сталкивался с проблемами после динамического обновления. Для меня проще от него отказаться в принципе чем потом заниматься восстановлением и ремонтом баз. Я лучше полезный и нужный функционал в конфигурации буду развивать.
(7) TODD22,
Радуйтесь! Никогда больше 3 минут решение вопроса не занимало. Все возможные проблемы уже давно до вас все выловили и описали как лечить, а вы похоже просто не хотите этого осознать. Все остальное, что у вас написано — это вывод из первого предположения.
(7) TODD22,
по вашей логике стоит отказаться и от платформы вообще, потому что в ней есть ошибки, в которых не хочется разбираться. В то же время, обычная практика — это попытаться понять причину и предложить «способ обхода» ошибки.
(8) bforce,
Да ладно… И столько статей на ИС. Автор статьи явно не в 3 минуты с решением уложился.
Я предпочитаю не создавать себе проблем.
Я такого не писал. Так что это ваша логика. И довольно странно додумывать за других.
Обычная практика это не создавать себе проблем.
Способ обхода всех ошибок связанных с динамическим обновлением это по возможности им не пользоваться. Всё остальное это не способы обхода ошибок, а исправление последствий.
А вот тут уже тянет на философский диспут: «Какое качество специалиста является более ценным: недопущение ошибок в работе или умение грамотно/быстро устранять возникающие ошибки?» 🙂
p.s.
Тоже отказался от димано, выполняю ее только, если уже совсем деваться некуда.
ИМХО недопущение ошибок. Специалист который создаёт ошибки а потом их грамотно/быстро устраняет будет заниматься тем что будет создавать ошибки и затем с ними бороться. Вместо выполнения полезной работы.
Вот бы у нас в отделе кто нибудь из программистов ломал бы базу а потом садился бы «быстро/грамотно» её восстанавливать. Я думаю он бы много о себе нового узнал от коллег.
А вообще интересный такой момент. Сейчас для одной компании делаю интеграцию их сервиса с 1Ской. Этим сервисом с недавних пор пользуется Яндекс и получает от туда данные для своих нужд.
Там невероятно жёсткие требования к работе баз, к доступности и стабильности и всё это прописано в договорах. Там за подход «если не проканает то я наверное починю» увольняют сразу.
И там в голову никому не приходит делать такие вещи. Зато среди 1Сников нормальная практика ломать, а потом чинить.
Я им предложил добавить регламентное задание на стороне их сервера для обмена с 1Ской очень много нового узнал о требованиях к стабильности сервисов и тд. Там каждую лишнюю функцию нужно обосновывать и очень серьёзно.
Казалось бы можно всё организовать, обкатать сервис и тд. Но нет… Цена ошибки очень велика и то же прописана в договоре.
(1) TODD22, статья не о том, кто сломал и стоит ли делать бекапы. Но вообще-то сломал не я 🙂
(13)
На работу в одну организацию устроился там бэкапы делались выгрузкой dt файла. При том что база на СУБД.
При этом программист утверждал что он крутой специалист и что он всё правильно сделал и делать бэкапы выгрузкой dt файла это правильно.
(3) DoctorRoza, обязательно, как только найдётся время, постараюсь на этой неделе.
(4) vasyak319, а с чего Вы взяли, что безуспешно?
(2) DoctorRoza, «не ошибается тот, кто ничего не делает» 😉 На самом деле, я категорически благодарен коллеге за создание такой ситуации, и подаренную мне возможность исследовать платформу и SQL на данном уровне.
Коллеги, данная статья НЕ посвящена вопросам динамического обновления, еще раз история такая:
Незначительная часть данных была потеряна, базу удалось оживить, сейчас работает.
Здесь я бы хотел поделиться приёмами, которые позволили это сделать.
Несколько позже оформлю продолжение
(18) vasyak319, интересно взглянуть на фрагмент, который привёл Вас к такому выводу. Стоит отметить, неверному. Потрудитесь процитировать?
(19) Ваша статья кончается вот этим:
т.е. итог — получение глючной и стрёмной базы. Восстановление с таким результатом это и есть «безуспешно».
(20) vasyak319, экий Вы пессимист 🙂 Из неопределенной фразы делаете вывод в худшую сторону. Восстановленная база работает вполне надёжно.
Имел аналогичный опыт. разрушилась база ms sql. комплексная или ут. разрушились Config , params
c dbnames const. это естественно тк они создаются одновременно и находятся в на диске рядом .
таблицы с данными не пострадали. резервных копий нет.
тк я уже ориентировался в структуре таблиц, то подобными «тыканиями» автора не занимался.
я уже знал, что имена таблиц бд с одинаковой конфигурацией могут отличаться.
Поэтому задача стояла так.
1) подобрать по совподению типов полей и их последовательности
нииболее близкую конфу.
2) сделать так что бы имена полей в бд соответствовали и записи dbnames убитой таблицы params
+
скопировать таблицу конфигурации констант,params и ,возможно, dbchema
Было заявлено что конфа полностью типовая.
соответственно нужно было подобрать самую близкую конфигурацию. и по ней восстановить dbnames, const и config . сравнивая структуры таблиц разрушенной и созданными пустыми из конфигураций
я создал несколько пустых баз с разными релизами конфигураций, подходящими по времени создания базы.
создал таблицу описаний таблиц и типов полей
заполнил данными нашел наиболее подходящую. оказалось , что есть недостающие таблицы.
выяснилось , что конфа все таки обновлялась . создал пустые базы с более свежими конфигурациями.
подобрал конфигурацию с полным совпадением по кол-ву таблиц (без const) но не по кол-ву полей . но в анализе я исключил const, тк клиенты сказали что конфигурация не изменялась и они на 80% были разрушены .
Имена таблиц в бд и наиболее подходящей отличались. соответственно нужно было или сгенерировать
правильный dbnames или переименовать поля и таблицы разрушенной бд (в кол-ве 200 шт).
Решил пойти более сложным путем — генерацию dbnames, чтобы иметь опыт полного контроля.
Лишние поля (2 шт ) оказались доработками. Их имена выяснились во внешних обработках. Так же выяснилось, что и константы были добавлены.
удалось выяснить смысл полей константы и подправить конфу.
В итоге
были скопированны из базы образца
таблицы conct , парамс, config, сгененрирована новая запись dbnames в таблице params
в конфигураторе добавлены недостающие поля и константа. их имена исправлены ручками в бд, а не в dbnames
дописана конфигурация изменения проведения по значениям новых полей.
далее ТИИ копии для проверки.
единственное не помню: удалились ли неопознанные поля при реструктуризации.
тк dbnames сжата deflate для чтения-записи использовал спасибо авторам.
Как говорят на хабре, нет вернее способа угробить карму, чем попросить ее поднять 🙂
Опубликовано продолжение
Пессимистам — просьба не читать 🙂