Каталог решений - Опыт лечения базы 1С в клиент-серверном режиме (PostgreSQL)

Итак, начнем. Это был ничем не приметный день, кроме того что это был понедельник. По плану было дотянуть до конца рабочего дня и поставить обновление на УПП, в котором должны появиться новый бизнесс процес, константа, и 3 дополнительных регистра сведений. Установку решил проводить «из дома» по удаленномму соединению, т.к. продажники работают до-поздна.

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

После обновления базы данных решив заполнить вновь созданные регистры зашел в режим отладки. При открытии формы списка регистра вывалилась ошибка типа  «Ошибка СУБД: ERROR:  relation «_infor22964_bydims_rrr» does not exist». и предложения: завершить работу и перезапустить.

Если быть честным — то мне немного «поплохело» от таого сообщения. «Бэкапа нет, и тут ошибка СУБД, которую я первый раз увидел».

Первым делом я конечно решил вернуть конфигурацию к первоначальному состоянию. НО в момент обновления конфигурации базы данных вываливалась та же ошибка «типа не найдена таблица и отвали».

Вторым этапом было связаться с администратором сервака и попросить его сделать откат на часик — другой. Одмина пришлось ждать и нервничать ок 2 часов — ибо он ужинал. После окончания ужина узнал, что у него средствами Postgresql делается один архив в сутки, и менно тогда жеж когда у меня делается архив средствами 1С.

Я был практически в отчаинии…. Догадывался что работатьна базе можно, но будут проблемы с дальнейшим написанием и обновлением…  и с этим надо что-то делать…

Итак в качестве третьего этапа рассматривались следующие варианты: восстановление утреннего архива и перенос документов с помощью типовой обработки «ВыгрузкаЗагрузкаXML», что идет в составе «Конвертации данных» и тестирование и исправление. К тому жеж я задумался над созданием позднего архива. Сразу скажу, что архив не создался, вывалив ту же ошибку.

Вариант с переносом данных решил отложить, ибо «это может быть потраченное впустую время», и ХЗ какой период документов сегодня правила наша «родная» бухгалтерия. И я решил обратиться к просторам инета. Самой полезной инфой было: http://www.forum.mista.ru/topic.php?id=393749&page=1 где мне пришлась по душе идея «исправления таблиц базы данных средствами SQL».

Третий этап, он жеж конечный: «исправления таблиц базы данных средствами SQL».

Теперь расскажу, что мне потребовалось: мне потребовалось сделать восстановление аврхива в базу данных SQL, и установить на компе утилиту «PGAdmin III».

Архивную базу данных я обновил до последнего состояния рабочей базы. Оказалость, что количество таблиц при «нормальном обновлении» на восстановленном архиве на 5 шт. превышало количество таблиц на рабочей базе. из чего я сделал вывод что при обновлении рабочей базы не создалось 5 таблиц. Оставалось найти их и создать вручную. Не смотря на то что на указаном выше форуме прочитал, что при восстановлении базы данных могут создаться таблицы с другими именами, моя практика показала полное совпадение имен рабочей базы и восстановленной. Проблема была в том, что необходимо было найти эти таблицы из 3500 шт. не зная языка SQL.

Для определения нужных таблиц я решил востанавливать конфигурацию до первоначального состояния и при обновлении читать какие таблицы нехватает 1С. Сказано — сделано. Вываливается ошибка — в «правильной базе» (она же восстановленно-обновленная) ищу таблицу с таким именем (в нижнем окне беру команду необходимую для создания таблицы) и создаю в рабочей подобие ее вручную, с полниым перечнем колонок. Главное — в последней вкладке при создании таблицы добавить команды по созданию индексов, что немаловажно. Главной ошибкой моей было то, что когда я не находил требуемую 1С таблицу — я создавал такую — это не правильно, (как я понял позднее — 1С пыталась очистить индексы и не находя жаловалась) в итоге я пришел к тому, что нашел таблицы, которые я не еще не создал, и при создании который создавался индекс, который я ошибочно считал таблицей и создавал. Например в указанном тексте ошибки — сообщение именно об индексе. Реальная теблица же называлась «_inforeg22964», и для нее создавалось еще 2 индекса.

В итоге, я нашел и создал 5 таблиц недостающих. У меня конфигурация «вернулась в исходное состояние». После этого я сделал архив БД средствами 1С, и повторно выполнил обновление, которое прошло успешно. 

Вот так я вышел из сложившегося положения, больше НИКОГДА не буду забывать/забивать делать архив перед обновлением.