Добрый день.


Разрушился файл какой-то таблички в БД.

Подключиьтся к БД не дает.

Пишет не могу прочитать блок 0 base/156715/77771



Файлы
77771
77771_vm
77771_fsm


я заменил сначала на пустые.

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


Все равно не дает подключиться к БД, пишет при попытке подключения:





Помогите оживить БД.

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

чтобы он индексы не использовал - лишь бы подключился к БД

не работает


cache lookup failed for index 2662

что делать?

vyegorovКонстантин Сергеевич Дерерк,

Вот была у вас табличка. Что-то пошло не так и база не смогла прочитать блок.
Диски проверяли?
Скопировав что-то другое в эту табличку — вы что хотели получить, оригинальные данные что были до потери блока?..

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


> Скопировав что-то другое в эту табличку — вы что хотели получить, оригинальные данные что были до потери блока?

Пустую таблицу.

Главное чтобы подключение к БД появилось.




Бэкапов нет.

Павел ЛузановКонстантин Сергеевич Дерерк



не работает


cache lookup failed for index 2662

А так:




Не, не хочет (


Я и так уже пробовал:

set PGOPTIONS="-P"

тоже не подключается.

Константин Сергеевич ДереркБэкапов нет.

Какой сорт вазелина советуете?

А, если серьезно, что можно сделать в таком случае чтобы БД заработала?

Я ведь даже не могу посмотреть что это за табличка без одключения к БД

не могу прочитать блок 0 base/156715/77771

qwwqКонстантин Сергеевич Дереркпропущено...


Какой сорт вазелина советуете?руки укоротить, по самые ягодицы



чо, и копии файлов не сделали, перед тем как руками махать ?


Сделали.

Каталог base/156715 скопировали.

Ы2Константин Сергеевич Дерерк, гугль говорит, что можно почитать это .
И как вы все время умудряетесь убивать файлы в базе? Она у вас на вибростенде стоит, или специально обученный мужик с перфоратором по диску бегает?

Читаю, спасибо.

Сомневаюсь что сработает, однако попробоватьь надо.

Maxim BogukКонстантин Сергеевич Дерерк,

У вас скорее всего какая то из системных таблиц побилась это в 99% случаев за разумные деньги и время не лечится.
А так - описание файловой структуры базы в зубы, pg_filedump в руки и может через полгода когда вы со всем этим разберетесь какие то данные вы оттуда вытащите.
При массовых инсталляциях на дешевом железе - работает только один подход - при любом сбое поднимать из backup.

PS: я надеюсь вы читали про https://www.postgresql.org/docs/9.1/static/wal-reliability.html в части windows?

Пока не понял что это такое, но попробую прочесть.