ДИСКЛЕЙМЕР
Автор не несет никакой ответственности, кроме как за достоверность предоставленной информации.
Всю нижеследующую информацию воспринимать и использовать на свой страх и риск.
ПРЕДЫСТОРИЯ
Ситуация досталась мне в следующем виде.
Разрушенная база (её имя для конкретики UTn) - это узел РИБ, который не обменивался с центром с марта 2015. Конфигурация, соответственно, тоже мартовская.
Рядом (на этом же сервере) живая база РИБ (имя 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 перед прыжком в пропасть ;)
