есть сервер
IBM Informix Dynamic Server Version 9.40.UC5TL

есть проблема.
18:03:14 Maximum server connections 1020
18:03:14 Level 0 Archive started on rootdbs, datadbs, saldo1, saldo2, log
18:05:18 I/O read chunk 3, pagenum 1223127, pagecnt 256 --> errno = 5
18:05:19 Assert Warning: ISAM error: An error has occurred during archive back up.

как можно сделать L0 ?

vybegalloУ вас сбойный диск, сначала надо его починить, иначе Информикс не даст сделать полный бэкап .
Чтобы его починить его кужно отключит.
Стобы онключит нужен юекап.

vybegallodbexport
Попробую объяснить пополнее. Нужно провести процедуру с минимальным , очень желательно нулевым downtime.
Придумана схема: ставим еще один сервер, HDR репликация. меняем диск. HDR репликация.
но нужен L0 backup.
Можно ли указать ontape (onbar?) чтобы он игнорировал ошибку диска ?
onunload же не стопорится.

zaietsДа не проблема с внешним backup/restore
Должно работать на любой версии (7.3 ..., за предыдущие не ручаюсь)
Лочишь сервер onmode -c block
Копируешь на второй сервер
Поднимаешь Информикс oninit -r
Настраиваешь репликацию

Но даст ли сервер скопировать?
Это еще вопрос. Скопировать можно, но придется повозиться.

А что лежит в третьем чанке? Может оно не критично и можно как-то иначе обойти?

Есть еще EDR можно, попытаться и этим путем.

как внешний backup/restore использовал банальный dd
как бы удостоверится что все Ок ?

vasilisОшибка чтения может быть из-за нарушения структуры страницы и физически на уровне ОС будет читаться и копироваться свободно (и даже onunload-ом, который не проверяет целостность страницы), но это не значит, что на новом месте эта страница будет признана Информиксом за нормальную. Так что даже на новом инстансе и новом диске ошибка может остаться и проявляться только во время чтения страницы. Причинами нарушения структуры чаще всего служат отключения питания при включенном кешировании записи на диск или подобные вещи (типа, автономный кэш контроллера при отсутствии автономного питания).

Ошибка чтения гдето на уровне железа. Непонятно, правда почему не произошел remapping. Но диск всеравно подлежит замене. Посколько физически сектор нечитаем, то при копировании он был заменен нулями. "Больное" место локализировано, таблица, лежащая в этой странице переименована в do_not_touch и пересоздана/загружена из ближайшего .unl
Но из за замены нулями эта страница не должна бы (по идее) быть принятой за нормальную. Информикс на запасной машине поднялся.
oncheck -ce , -ci, -cc ничего подозрительного не выдали. Какие проверки нужно/хорошо было бы сделать еще ?

Извиняюсь за поздний ответ

oncheck -cD p4c:stat1

BAD PAGE 3:1223278: pg_addr 0:0 != bp->bf_pagenum 3:1223278
BAD PAGE 3:1223279: pg_addr 0:0 != bp->bf_pagenum 3:1223279
BAD PAGE 3:1223280: pg_addr 0:0 != bp->bf_pagenum 3:1223280
....
(в принципе подобное и ожидалось
т.к. копировал с заменением сбойных участков нулями)
Чинить не предлагает

ontape сделал но в логах ругань

04:29:16 IBM Informix Dynamic Server Version 9.40.UC5TL
04:29:16 Who: Session(114, informix@dagobert, 5706, 0x30a4d604)
Thread(151, arcbackup1, 30a234a0, 3)
File: rsarcbu.c Line: 2698
04:29:16 stack trace for pid 4524 written to /tmp/af.47f516e
04:29:16 See Also: /tmp/af.47f516e
04:29:16 Archive detects that page 3:1223296 is corrupt.
04:29:16 Assert Warning: Archive detects that page 3:1223297 is corrupt.

восстановил ка другом сервере
та же ругань при oncheck
есть ли возможность восстановить страницы ?

больная таблица была переименована и восстановлена из бекапа.
не ее не удаляли, таким образом локализируя сбойные участки диска.
теперь диск заменили, но остались плохие страницы.
Правильно ли я понял что после drop table ontape и oncheck перестанут ругатся и эти страницы станут доступными длч повторного использования ?