Как я "лечил" ERROR: could not open file »base/33264/49743»: No such file or directory

После восстановления убитого жесткого диска появилась ошибка базы 1С при попытки выгрузить базу в dt: ERROR: could not open file »base/33264/49743»: No such file or directory.

В один прекрасный вечер произошла неприятная ситуация, сервер физически перестал запускаться. Сисадмин после осмотра объявил о неисправности обоих дисков из зеркального рейда. Просто как выиграть в лотерею))). Бекап базы был не очень далекий, но все-таки хотелось восстановить базу 1С полностью, чтобы не потерять даже одного дня работы. Диск отвезли в специализированную контору, и за ночь они выудили что смогли с этих дисков.

Естественно, не обошлось без потерь. На сервере стоял сервер PostgreSQL и, следовательно, меня интересовала папка из его рабочего каталога data. На новом компьютере установил postgresql с нуля. той же версии, что и стоял на упавшем сервере, с теми же настройками. Остановил службу чистоустановленного postresql , заменяю папку data в рабочем каталоге postreSQL (обычно это находится примерно там — C:Program Files (x86)PostgreSQL9.0.3-3.1C), восстановленной специалистами с битого диска. Запускаем службу PostgreSQL. У меня она не сразу запустилась. После некоторых экспериментов выяснил, что при копировании папки слетели права на нее и служба не могла ее прочитать и не стартовала из-за этого. Настроил права на каталог data — все взлетело))) Чудо, даже 1С запустился конфигуратор)))

А вот дальше ждал неприятный сюрприз. При попытке выгрузить базу в dt вылетала ошибка СУБД ERROR: could not open file »base/33264/49743»: No such file or directory. Тестирование и исправление вылетало с той же ошибкой. Видимо специалисты не все файлы таблиц postgresql восстановили.

Я решил проблему следующим образом. Сохранил структуру конфигурации в cf файл. При тестировании и исправлении по строке состояния заметил, на каком объекте падает тестирование. У меня это оказался регистр накопления. Я его удалил, обновил базу данных. а потом заменил конфигурацию базы данных на сохраненную ранее в cf. При таких действиях таблица создастся заново, но данные из нее будут потеряны.

Мне повезло, что пострадала только одна таблица, и это оказался регистр накопления. Его легко можно заполнить заново, перепроведя документы. Если бы пострадал какой нибудь справочник или документ, было бы, конечно, хуже, данные оттуда уже нельзя было бы восстановить так просто. Могла также пострадать какая-нибудь системная таблица 1С и тогда конфигурация вообще не открылась бы. Мой путь решения не идеален, но в моем случае помог восстановить базу полностью. Может, кому поможет мой опыт))

3 Comments

  1. Dream_kz

    Зачастую структура хранения в PG такова, что этот путь представляет собой:

    base/database_oid/filenode id

    Сначала выясняем что за бд

    select datname from pg_database where oid = 33264 

    Потом выясняем что за таблица

    SELECT pg_filenode_relation(0, 49743); 

    Потом методом ПолучитьСтруктуруХраненияБазыДанных узнаем что за объект метаданных

    Немного сложнее, согласен, но надежнее.

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

    Reply
  2. nyam-nyam

    Поди после этого случая таки настроили бекап логов…

    Reply
  3. VladimirMezentsev

    Была такая же ошибка, куда то пропали несколько файлов 141253 — 141256, выгрузка в .dt перестала работать, ТИИ вылетало. Судя по всему в моем случае файлы были служебными, размер по 8Кб, все одинаковые по двоичным данным. Скопировал недостающие файлы взяв за основу 141252. Все заработало.

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *