Проблемы с индексами

[owl77 Профиль]

Доброго дня всем!
Сегодня по некоторым признакам выполнения одного из запросов к нашей БД возникли подозрения на некорректность одного из индексов. Определил recid подозрительной записи, запустил idxfix в небольшом диапазоне recid для данной таблицы для одного индекса. Idxfix в процессе работы выдал следующее:

[2014/05/15@12:28:42.994+0400] P-28363 T-1 I IDXFIX 8: (8828) Index 55 (PUB.acct, close-date): Deleted key <2433417> recid 53289096.
[2014/05/15@12:28:43.087+0400] P-28363 T-1 I IDXFIX 8: (8828) Index 55 (PUB.acct, close-date): Deleted key <2433417> recid 54470164

.

После этого запрос начал выполняться корректно. Решив не останавливаться на этом, прогнал idxfix для всей таблицы, для всех активных индексов. Результат более 300 изменений на таблицу размером пару сотен мегабайт. В логе БД это отобразилось вот так:

[2014/05/15@13:28:29.922+0400] P-28575 T-1 I IDXFIX 10: (8827) Index 48 (PUB.acct, acct-cont): Added key <><<FC>><> recid 60343968.
[2014/05/15@13:28:29.922+0400] P-28575 T-1 I IDXFIX 10: (8827) Index 533 (PUB.acct, acct-cont-fil): Added key <><><<FC>><> recid 60343968.

Как я предполагал раньше, ситуация с некорректным индексом - исключительная, но в нашем случае я вижу, что подобных ошибок великое множество. Данная ситуация мне кажется ненормальной. Помогите разобраться в причинах возникновения подобной проблемы и устранить её если это возможно.

Конфигурация системы:
Sol10 SPARC 64-bit
OpenEdge Release 10.2B07
Бисквит

[George Профиль]

OpenEdge Release 10.2B07
Бисквит

Issue # PSC00248436
65536: maximum number of sub-transactions
A savepoint counter overflows after 65535 assignments. As a result not everything is being restored during rollback leading to various database corruptions.
Fixed in V10.2B08

Если есть логи работы 1 и 2 (или 3-го) пунктов idxfix, то диагноз можно подтвердить.

Idxfix восстановил физическую целостность базы, но логическая целостность осталась нарушенной:
viewtopic.php?f=7&t=2490

[dmi Профиль СайтICQ]

Кроме всего, текстовый дамп и лоад может показать много сюрпризов.

[owl77 Профиль]

Да уж, ситуация более чем удручающая:(((
Вот полный лог полученный в результате выполнения idxfix для одного индекса. Именно это я сделал на боевом сервере сегодня ночью. Похоже имеет смысл копию БД сделанную до этой процедуры отложить в сторонку и сделать несколько её экземпляров!

[2014/05/15@22:27:08.275+0400] P-12784 T-1 I IDXFIX 13: (451) proutil -C idxfix session begin for root on /dev/pts/189.
[2014/05/15@22:28:36.328+0400] P-12784 T-1 I IDXFIX 13: (8828) Index 55 (PUB.acct, close-date): Deleted key <2433417> recid 53289096.
[2014/05/15@22:28:36.381+0400] P-12784 T-1 I IDXFIX 13: (8828) Index 55 (PUB.acct, close-date): Deleted key <2433417> recid 54470164.
[2014/05/15@22:30:46.856+0400] P-12784 T-1 I IDXFIX 13: (8827) Index 55 (PUB.acct, close-date): Added key <2433417> recid 40501675.
[2014/05/15@22:30:48.383+0400] P-12784 T-1 I IDXFIX 13: (8827) Index 55 (PUB.acct, close-date): Added key <2433417> recid 40970385.
[2014/05/15@22:30:51.834+0400] P-12784 T-1 I IDXFIX 13: (8827) Index 55 (PUB.acct, close-date): Added key <2433417> recid 42049667.
[2014/05/15@22:30:53.815+0400] P-12784 T-1 I IDXFIX 13: (8827) Index 55 (PUB.acct, close-date): Added key <2433417> recid 42640019.
[2014/05/15@22:30:54.423+0400] P-12784 T-1 I IDXFIX 13: (8827) Index 55 (PUB.acct, close-date): Added key <2433417> recid 42823344.
[2014/05/15@22:31:02.872+0400] P-12784 T-1 I IDXFIX 13: (8827) Index 55 (PUB.acct, close-date): Added key <2433417> recid 45555332.
[2014/05/15@22:31:03.457+0400] P-12784 T-1 I IDXFIX 13: (8827) Index 55 (PUB.acct, close-date): Added key <2433417> recid 45763987.
[2014/05/15@22:31:09.302+0400] P-12784 T-1 I IDXFIX 13: (8827) Index 55 (PUB.acct, close-date): Added key <2433417> recid 47716002.
[2014/05/15@22:31:11.208+0400] P-12784 T-1 I IDXFIX 13: (8827) Index 55 (PUB.acct, close-date): Added key <2433417> recid 48364322.
[2014/05/15@22:31:22.641+0400] P-12784 T-1 I IDXFIX 13: (8827) Index 55 (PUB.acct, close-date): Added key <2433417> recid 52071300.
[2014/05/15@22:31:25.386+0400] P-12784 T-1 I IDXFIX 13: (8827) Index 55 (PUB.acct, close-date): Added key <2433417> recid 53032863.
[2014/05/15@22:31:39.067+0400] P-12784 T-1 I IDXFIX 13: (8827) Index 55 (PUB.acct, close-date): Added key <2433417> recid 57852969.
[2014/05/15@22:31:43.728+0400] P-12784 T-1 I IDXFIX 13: (8827) Index 55 (PUB.acct, close-date): Added key <2433417> recid 59471909.
[2014/05/15@22:31:46.250+0400] P-12784 T-1 I IDXFIX 13: (8827) Index 55 (PUB.acct, close-date): Added key <2433417> recid 60343968.
[2014/05/15@22:32:36.801+0400] P-12784 T-1 W IDXFIX 13: (5408) WARNING: -l exceeded. Automatically increasing from 200 to 210.
[2014/05/15@22:32:36.801+0400] P-12784 T-1 W IDXFIX 13: (5408) WARNING: -l exceeded. Automatically increasing from 210 to 220.
[2014/05/15@22:32:36.802+0400] P-12784 T-1 W IDXFIX 13: (5408) WARNING: -l exceeded. Automatically increasing from 220 to 230.
[2014/05/15@22:32:36.803+0400] P-12784 T-1 W IDXFIX 13: (5408) WARNING: -l exceeded. Automatically increasing from 230 to 240.
[2014/05/15@22:32:36.804+0400] P-12784 T-1 W IDXFIX 13: (5408) WARNING: -l exceeded. Automatically increasing from 240 to 250.
[2014/05/15@22:32:36.804+0400] P-12784 T-1 W IDXFIX 13: (5408) WARNING: -l exceeded. Automatically increasing from 250 to 260.
[2014/05/15@22:32:36.805+0400] P-12784 T-1 W IDXFIX 13: (5408) WARNING: -l exceeded. Automatically increasing from 260 to 270.
[2014/05/15@22:32:36.805+0400] P-12784 T-1 W IDXFIX 13: (5408) WARNING: -l exceeded. Automatically increasing from 270 to 280.
[2014/05/15@22:32:36.806+0400] P-12784 T-1 W IDXFIX 13: (5408) WARNING: -l exceeded. Automatically increasing from 280 to 290.
[2014/05/15@22:32:36.806+0400] P-12784 T-1 W IDXFIX 13: (5408) WARNING: -l exceeded. Automatically increasing from 290 to 300.
[2014/05/15@22:32:36.806+0400] P-12784 T-1 I IDXFIX 13: (-----) 1 indexes, 549670 blocks, 1429482 keys checked.
[2014/05/15@22:32:36.807+0400] P-12784 T-1 I IDXFIX 13: (4332) Index fix completed successfully.
[2014/05/15@22:32:36.812+0400] P-12784 T-1 I IDXFIX 13: (4975) Index fix made 16 index changes.

В скачанном мною Progress OpenEdge 10.2B08 Service Pack не вижу ISSUE c номером 225722, или это разные нумерации? Входит ли fix с устранением этой проблемы в SP8? С виду проблема устранена в ISSUE PSC00248436.

[George Профиль]

Копии базы, непокалеченной лечением, не сохранилось?

В скачанном мною Progress OpenEdge 10.2B08 Service Pack не вижу ISSUE c номером 225722, или это разные нумерации? Входит ли fix с устранением этой проблемы в SP8? С виду проблема устранена в ISSUE PSC00248436.

Это один и тот же баг - Progress просто поменял формат идентификаторов багов.

[owl77 Профиль]

Копия имеется.

[owl77 Профиль]

Если вернуться к нашей частной ситуации, то тот отчет который не работал, после idxfix начал корректно на первый взгляд формироваться. Суть отчета состояла в том, чтобы создать список открытых счетов, т.е. счетов у которых поле close-date не заполнено. В этот список попадал счет, у которого была проставлена дата заполнения, перестроение индекса устранило эту проблему.

[George Профиль]

Если таблица большая, то копию базы можно запустить в многопользовательской моде.

Запустить один процесс idxfix для работы первого пункта:
1. Scan records for missing index entries.

Для каждого индекса этой таблицы запустить свой процесс idxfix для работы второго пункта:
2. Scan indexes for invalid index entries.

Чтобы процессы не спотыкались друг на друге, всех их запускать с ключем -NL.

На вопрос "Fix indexes on Scan?" ответить спокойно, но отрицательно: N.

После завершения сканирования лог базы, .df файл таблицы и collation table (_tran.df) базы можно отправить в техподдержку Progress Technologies.