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

Администрирование - Системное

ERROR: could not open file ''base/33264/49743'': No such file or

4
После восстановления убитого жесткого диска появилась ошибка базы 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)\PostgreSQL\9.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С и тогда конфигурация вообще не открылась бы. Мой путь решения не идеален, но в моем случае помог восстановить базу полностью. Может, кому поможет мой опыт))

4

См. также

Комментарии
Избранное Подписка Сортировка: Древо
1. Dream_kz 77 04.07.18 13:07 Сейчас в теме
Зачастую структура хранения в PG такова, что этот путь представляет собой:
base/database_oid/filenode id
Сначала выясняем что за бд
select datname from pg_database where oid = 33264 

Потом выясняем что за таблица
SELECT pg_filenode_relation(0, 49743); 

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

Немного сложнее, согласен, но надежнее.
И бд все же лучше создать новую из бэкапа, а данные внесенные между бэкапом и моментом аварии попытаться перенести с помощью ВыгрузкиЗагрузкиXML (хотя бы основные документы, и связанные с ними справочники), не всегда рушится только одна таблица, и не всегда можно вообще запустить тестирование.
nyam-nyam; +1 Ответить
2. nyam-nyam 05.07.18 10:27 Сейчас в теме
Поди после этого случая таки настроили бекап логов...
Оставьте свое сообщение