Ошибка базы. HELP.Could not read block 26637 of relation base/50468/3305609: inv #601766

Добрый день. Случилась беда с базой Конф: v8 УТ 10.3.6.8 база на PostgreSQL 8.4.3-3.1C При тестировании и исправлении вылетает ошибка Ошибка СУБД Error: Could not read block 26637 of relation base/50468/3305609: invalid argument В конфигураторе останавливается на надписи: Проверка логической целостности. Регистры накопления. Продажи. - 15% Дамп базы не делается ни средствами 1с ни PostgreSQL. База работает. Сбоев нет. Кто сталкивался? Что делать?

прогони копию базы, её же штатной проверкой, в папке 1cv82/../bin/chdbfl.exe как вариант попробуй

Не уследил в какой момент перестали создаваться копии. И уже все затерлись ((..Есть совсем старые но там нет ошибок.

а новую копию создать нельзя??

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

Ну пробуй через XML в чистую базу выгрузить, возможно частями

Хотелось бы конечно выгрузить базу штатными средствами и потом уже сменить PostgreSQL или дело не в нем ведь?

я просто не знаю, в SQL вообще не скопировать базу как в файловых??? там ведь есть путь к базе?

Поди БД файловая :)

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

Я ведь написал БД на PostgreSQL, Резервная копия не делается ни средствами 1с ни средствами Postgre

Написано же, "база на PostgreSQL 8.4.3-3.1C "

Отчеты строятся по любым периодам, ошибок не бывает..или это не связано?

А по теме, "Продажи" - регистр оборотный, перепроведением восстановится. Так что грохнуть таблицу регистра, загрузить конфигурацию, реструктуризацию запустить, потом перепровести.

Опасно конечно заниматься этим без резервной копии..может есть ещё варианты?

а копию сделать кто мешает? останавливаешь службу и копируешь файлы :)

Образ винчестера сделай. :)

А постгри потом стартанет если заменить базу на старую?

:)

Без танцев с бубном точно нет, но зато файлы останутся... "Продажи" - первый поломатый регистр, на котором спотыкается ТиИ. Их может быть 100500...

Плохо дело чувствую

Кстати, идея. Недавно делал РБД с этого узла и она создалась без сбоев. Там конечно обрезанный узел но нужно попробовать на полном плане. А с файловой уже проще.

сделай так: 1. создай новую пустую базу с этой конфигурацией 2. экспортом гони таблицы из поломатой в новую 3. составляешь список таблиц которые не удалось копирнуть 4. принимаешь решение чего дальше способ безопасный, геморный, но понятный

+1 за такой подход

Спасибо попробую. Один вопрос Экспорт - это ты имеешь ввиду средство 1с или Postgre? Ни разу не сталкивался.

средстави СУБД, я с пости не работал, я только со скулем, зато так например востанавливал базу 7.7 примерно 60 гигов после краха винта и скульного рековера, там черти что было :)

Понял Спасибо. Буду пробовать. Отпишусь.

Беда случилась уже давно когда Выбирали СУБД на учёбу забыли денег выделить ..)

))

Нашел таблицу которая дает ошибку. accumreg7721 ERROR:  could not read block 26637 of relation base/50468/3305609: Invalid argument Кто знает что за таблица?

регист... теперь тупо в новой базе сделай ТиИс и потом полное перепроведение, и все будет рабочее.

ERROR:  could not read block 26637 of relation base/50468/3305609: Invalid argument судя по последним словам, может это по больничным листам?)))))))

хотя лучше не перепроведение, а что-то более правильное, на сколько я понял у тебя один регист "продажы" крякнул, подумай как его заполнить без перепроведения :)

Объясни что такое ТиИс? И как в новой? - я не могу её залить в новую базу. Да конечно лучше как то заполнить )

Тестирование и Исправление.

Тоесть перенести все таблицы в новую базу кроме этой и уже например средствами 1с её заполнить..? дошло

А можно как то посмотреть что это за блок такой 26637?

никак, это к 1с не имеет отношение, это номер страницы в файле субд

а вообще если такая ошибка появилась - это ОЧЕНЬ серьезный звонок админу, вариантов масса, от начала рассыпания дисков, до серьезных проблемм с софтом. нет никакой гарантии что на этом сервере сабж не повторится но уже в КРУПНЫХ МАСШТАБАХ

Спасибо за помощь vde69

В Postgre подобные ошибки случаются с завидным постоянством, и, что самое плохое, - нет штатных утилит по лечению тип DBCC в MSSQL, поэтому главное правило - регулярные архивы. Схема лечения такой ошибки следующая. В pgadmin нужно запустить переиндексацию с перебором всех таблиц, например, подобным скриптом: CREATE OR REPLACE FUNCTION _Reindex_Base(  schema_name in  name,  result out bigint ) LANGUAGE plpgsql as $BODY$ DECLARE  table_name  name; BEGIN  FOR table_name IN (    SELECT t.table_name    FROM information_schema.tables t    WHERE t.table_schema = schema_name      AND t.table_type = 'BASE TABLE' --      AND t.table_name > '_reference84'    ORDER BY t.table_name Нормальные таблицы будут переиндексироваться, на битых будет спотыкаться. Битые таблицы потом нужно идентифицировать, каким объектам базы они соответствуют - благо обработок по представлению структуре базы везде валяется немеряно. Далее битые таблицы придется удалить и пересоздать - проще всего автогенерируемым CREATE скриптом в том же pgadmin. После этого восстанавливать данные, исходя из важности потерянных таблиц и имеющихся архивов. Служебные данные, типа итогов регистров - переформировать; движения регистров - можно восстанавливать, можно заново получить перепроведением. Справочники, документы, перечисления, независимые регистры сведений - только восстанавливать из бэкапов - либо тянуть в виде таблиц Postgre, либо разворачиать архивные базы полностью и выгружать-загружать средствами 1С.

вот по этому я и сижу на скуле :) а пости извени это пРости какое-то

Спасибо большое, сейчас пробую.

не гонялся бы ты поп за дешевизной...

Да уже тоже сижу думаю об этом..)

Бесплатность линуксов нивелируется стоимостью поддержки.

Это всего лишь стоимость несделанного вовремя бэкапа(ОС, СУБД и все остальное, практически, не имеет значения). Ключевая фраза в - "Не уследил..."

Извините, в