При запуске oncheck -cI dbname
выдает, что есть ошибка в индексах системной таблицы sysprocbody

========================
Validating indexes for dbname:informix.sysprocbody...
Index procbody
Could not check rowids and perform data<->index check
ISAM error: Primary and Mirror chunks are bad

Собственно вопрос: как это лечится?
========================

пробовала удалить/создать индекс типа:

========================
drop index procbody;
CREATE UNIQUE INDEX procbody ON sysprocbody(procid, datakey, seqno);
========================

выдает:

========================
Database selected.


511: Cannot modify system catalog (sysprocbody).
Error in line 1
Near character position 18

511: Cannot modify system catalog (sysprocbody).
Error in line 1
Near character position 66


Database closed.
========================

Что в общем-то естественно, но как это лечится - не понятно.

Кто-нибудь сталкивался с подобным?

vybegallo---- ADMIN GUIDE --------
If you run oncheck -cI while the database
server is in on-line mode, oncheck detects the corruption but does not
prompt you for repairs. If corruption exists, you can drop and re-create the
indexes using SQL statements while you are in on-line mode (the database
server locks the table and index). If you run oncheck -cI in quiescent mode,
and corruption is detected, oncheck prompts you to confirm whether the
utility should attempt to repair the corruption.


Понятно, что если делать в онлайн-режиме он ничего не исправит, а только найдет.
Переводили сервер в quiescent mode (oninit -s), он находил эту ошибку, но исправить ее не мог.
Поэтому и пыталась убить/создать на нем индексы.
Да, делалось это под пользователем informix. Но как видите - безрезультатно.

AndronМожет у вас диски неисправны ? Стоит их проверить если исправление логической структуры в пространствах не помогает. А primary и mirror чанки у вас на разных дисках или на одном ?

Может и диски неисправны.
Чем проверить (на Linux)? fscheck -ом?

Судя по всему primary и mirror чанки на разных дисках:

из onconfig -a:
=================================
ROOTPATH /dbs_pri/dbname/root01.dbf
MIRRORPATH /dbs_mir/dbname/root01.dbf
=================================


вот что выдает df:

=================================
/dev/sdb1 8815372 656040 7711524 8% /dbs_pri/dbname
/dev/sdc1 8815372 656040 7711524 8% /dbs_mir/dbname
=================================

vybegalloНу тут или в саппорт звонить, или выгружать-загружать базу.
саппорта нету.
выгружать- загружать это dbexport/dbimport?
надо ли загружать ее на новый сервак, либо на тот же? и типа должно помочь?

vybegalloНа этот же. Если выгрузится - то должно помочь, поскольку индексы в новой базе будут построены заново. Чанки проверить можно командой dd if=<chunk name> of=/dev/null bs=2k count=<# of pages in chunk>

их проверять после выгрузки базы?
а где про эти проверки почитать?

vybegalloнет, их проверять до переноса. Почитать надо man dd
Все, что dd делаеи - читает из одного файла (чанка) и копирует в другой (/dev/null ). Таким образом проверяется всего лишь читаемость чанков. Логическая целостность проверяется oncheck-ом.
то есть в таком варианте все можно проверить на рабочих серверах,
и никаких изменений он не сделает.
а тока проверит целостность?

vybegalloЧанки проверить можно командой dd if=<chunk name> of=/dev/null bs=2k count=<# of pages in chunk>

chank name как я понимаю можно посмотреть в базе sysmaster

Select chknum, fname From syschunks

а откуда вытащить инфу о числе страниц в чанке?

Daugava ladyirina
а откуда вытащить инфу о числе страниц в чанке?

"Из того же материала" (с)
chksize из таблицы syschunks

И что, можно эту проверку запускать прямо на рабочем сервере, не останавливая его? А конфликты не возникнут?

вот что получилось в итоге по проверке чанков:

то,что выдает "Select chknum, fname, chksize From syschunks":

======================================
chknum fname chksize
1 /dbs_pri/dbname1/root01.dbf 65536
2 /dbs_pri/dbname2/work03.dbf 900000
4 /dbs_pri/dbname2/work01.dbf 768000
5 /dbs_pri/dbname2/work02.dbf 768000
7 /dbs_pri/dbname2/blob01.dbf 768000
8 /dbs_pri/dbname1/log01.dbf 65536
9 /dbs_pri/dbname1/log02.dbf 65536
10 /dbs_pri/dbname1/log03.dbf 65536
11 /dbs_pri/dbname1/log04.dbf 65536
12 /dbs_tmp/tmp01.dbf 131072
13 /dbs_tmp/tmp02.dbf 131072
14 /dbs_tmp/tmp03.dbf 131072
15 /dbs_tmp/tmp04.dbf 131072
16 /dbs_tmp/tmp05.dbf 131072
17 /dbs_tmp/tmp06.dbf 131072
18 /dbs_tmp/tmp07.dbf 131072
19 /dbs_tmp/tmp08.dbf 131072
======================================

то, что выдает dd на каждый чанк:

======================================
# dd if=/dbs_pri/dbname1/root01.dbf of=/dev/null bs=2k count=65536
65536+0 records in
65536+0 records out

# dd if=/dbs_pri/dbname2/work03.dbf of=/dev/null bs=2k count=900000
900000+0 records in
900000+0 records out

# dd if=/dbs_pri/dbname2/work01.dbf of=/dev/null bs=2k count=768000
dd: /dbs_pri/dbname2/work01.dbf: Input/output error
270534+0 records in
270534+0 records out

# dd if=/dbs_pri/dbname2/work02.dbf of=/dev/null bs=2k count=768000
768000+0 records in
768000+0 records out

# dd if=/dbs_pri/dbname1/log01.dbf of=/dev/null bs=2k count=65536
65536+0 records in
65536+0 records out

# dd if=/dbs_pri/dbname1/log02.dbf of=/dev/null bs=2k count=65536
65536+0 records in
65536+0 records out

# dd if=/dbs_pri/dbname1/log03.dbf of=/dev/null bs=2k count=65536
65536+0 records in
65536+0 records out

# dd if=/dbs_tmp/tmp01.dbf of=/dev/null bs=2k count=131072
131072+0 records in
131072+0 records out

# dd if=/dbs_tmp/tmp02.dbf of=/dev/null bs=2k count=131072
131072+0 records in
131072+0 records out

# dd if=/dbs_tmp/tmp03.dbf of=/dev/null bs=2k count=131072
131072+0 records in
131072+0 records out

# dd if=/dbs_tmp/tmp04.dbf of=/dev/null bs=2k count=131072
131072+0 records in
131072+0 records out

# dd if=/dbs_tmp/tmp05.dbf of=/dev/null bs=2k count=131072
131072+0 records in
131072+0 records out

# dd if=/dbs_tmp/tmp06.dbf of=/dev/null bs=2k count=131072
131072+0 records in
131072+0 records out

# dd if=/dbs_tmp/tmp07.dbf of=/dev/null bs=2k count=131072
131072+0 records in
131072+0 records out

# dd if=/dbs_tmp/tmp08.dbf of=/dev/null bs=2k count=131072
131072+0 records in
131072+0 records out
======================================

Ну я вижу ошибку в чанке /dbs_pri/dbname2/work01.dbf
но что можно с этим сделать?

да, df выдает об этом диске, где поломанный чанк

/dev/sdb2 8823436 6414296 1960928 77% /dbs_pri/dbname2

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

да, кстати,никто не знает, почему такое происходит:

в onconfig -е проставлено, что имеет место зеркалирование
===============================
MIRROR 1 # Mirroring flag (Yes = 1, No = 0)
MIRRORPATH /dbs_mir/dbname/root01.dbf
# Path for device containing mirrored root
MIRROROFFSET 0 # Offset into mirrored device (Kbytes)
===============================


диски подключены все
===============================
# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sda2 8064304 2378396 5276252 31% /
/dev/sda5 4032092 3007996 819272 79% /home
/dev/sda6 1011928 270564 689960 28% /opt
/dev/sda8 2498348 893200 1478240 38% /opt2
/dev/sda7 1517920 92 1440720 0% /tmp
/dev/sdb1 8815372 656040 7711524 8% /dbs_pri/dbname1
/dev/sdb2 8823436 6414296 1960928 77% /dbs_pri/dbname2
/dev/sdc1 8815372 656040 7711524 8% /dbs_mir/dbname1
/dev/sdc2 8823436 6414296 1960928 77% /dbs_mir/dbname2
/dev/sdd2 17640244 6229928 10514216 37% /export
/dev/sde1 17639220 14763828 1979372 88% /backup
===============================

однако, в инфе, которую выдает
"Select chknum, fname, chksize From syschunks"
никакого упоминания о наличие чанков на зеркальных дисках нет.
это нормально?

они есть или все таки их нет?

AndronЗачем так сложно - лезть в системные таблицы чтобы посмотреть есть ли зеркальные чанки ? Используйте проверенную временем команду onstat -d ;-)

Да по сложности одинаково. Можно и так. Вопрос-то не в этом. А что с этим делать?

vybegallo1. приведите результаты команды onstat -d
2. что делать - спасать данные, менять диск, заливать данные заново. Это если нет бэкапа. Если есть - то менять диск, восстанавливаться из бэкапа, накатывать логи.
Спасать данные - либо dbexport, либо вручную (скриптами) выгружать в файлы.
ontape , onbar не будут архивировать битый диск - и нет в этом никакого смысла.
Informix Dynamic Server 2000 Version 9.21.UC4 -- On-Line -- Up 14 days 18:53:45 -- 151096 Kbytes

Dbspaces
address number flags fchunk nchunks flags owner name
14ccd7d0 1 0x2 1 1 M informix root_dbs
1538db98 3 0x2 4 3 M informix work2_dbs
1538dce0 5 0x12 7 1 M B informix blob2_dbs
1538de28 6 0x2 8 4 M informix log_dbs
1525b018 7 0x2001 12 8 N T informix tmp_dbs
5 active, 2047 maximum

Chunks
address chk/dbs offset size free bpages flags pathname
14ccd918 1 1 0 65536 63242 PO- /dbs_pri/dbname1/root01.dbf
14ccda88 1 1 0 65536 0 MO- /dbs_mir/dbname1/root01.dbf
14d0c320 2 3 0 900000 749597 PO- /dbs_pri/dbname2/work03.dbf
1538d018 2 3 0 900000 0 MO- /dbs_mir/dbname2/work03.dbf
14d0c490 4 3 0 768000 49 PO- /dbs_pri/dbname2/work01.dbf
1538d188 4 3 0 768000 0 MD- /dbs_mir/dbname2/work01.dbf
14d0c600 5 3 0 768000 22315 PO- /dbs_pri/dbname2/work02.dbf
1538d2f8 5 3 0 768000 0 MO- /dbs_mir/dbname2/work02.dbf
14d0c770 7 5 0 768000 ~95952 96000 POB /dbs_pri/dbname2/blob01.dbf
1538d468 7 5 0 768000 0 MOB /dbs_mir/dbname2/blob01.dbf
14d0c8e0 8 6 0 65536 8139 PO- /dbs_pri/dbname1/log01.dbf
1538d5d8 8 6 0 65536 0 MO- /dbs_mir/dbname1/log01.dbf
14d0ca50 9 6 0 65536 65533 PO- /dbs_pri/dbname1/log02.dbf
1538d748 9 6 0 65536 0 MO- /dbs_mir/dbname1/log02.dbf
14d0cbc0 10 6 0 65536 65533 PO- /dbs_pri/dbname1/log03.dbf
1538d8b8 10 6 0 65536 0 MO- /dbs_mir/dbname1/log03.dbf
14d0cd30 11 6 0 65536 65533 PO- /dbs_pri/dbname1/log04.dbf
1538da28 11 6 0 65536 0 MO- /dbs_mir/dbname1/log04.dbf
14d0cea0 12 7 0 131072 130733 PO- /dbs_tmp/tmp01.dbf
14ccdbf8 13 7 0 131072 131069 PO- /dbs_tmp/tmp02.dbf
14ccdd68 14 7 0 131072 131069 PO- /dbs_tmp/tmp03.dbf
14cfd830 15 7 0 131072 131069 PO- /dbs_tmp/tmp04.dbf
14cfd9a0 16 7 0 131072 131069 PO- /dbs_tmp/tmp05.dbf
14cfdb10 17 7 0 131072 131069 PO- /dbs_tmp/tmp06.dbf
14cfdc80 18 7 0 131072 131069 PO- /dbs_tmp/tmp07.dbf
14cfddf0 19 7 0 131072 131069 PO- /dbs_tmp/tmp08.dbf
17 active, 2047 maximum

==========================
понятно, что dbexport.....
что диск менять.
а чем тут должно помочь зеркалирование? которое средствами информикса, вроде бы включено?

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

проверила чанк зеркальный на поломанный основной

# dd if=/dbs_mir/dbname2/work01.dbf of=/dev/null bs=2k count=768000
dd: /dbs_mir/dbname2/work01.dbf: Input/output error
250874+0 records in
250874+0 records out


не весело, аднака.