AndronПосмотрел приложенный onstat -u, вполне коррелирует с выводом onstat -g ckp, много нитей ждут на чекпоинте. Но что интересно, нить Btree scanner имеет просто таки большое кол-во чтений nreads:
395ffa9c8 ---P--B 616 ******** - 0 0 0 913350569 608541
и если связать это как то с тем что ранее написал яфшуеі про
http://www-01.ibm.com/support/docview.wss?uid=swg1IC61144 то напрашивается вывод что возможно имеет место баг?
На моих серверах Informix с uptime в неск.месяцев нигде нет такого большого значения для чистильщика индексов, хотя пользователи активно работают с данными. Какой uptime у твоего информикса?
Как часто в выводе onstat -g act есть нитка Btree когда возникает проблема а также когда проблемы нет? Еще бы неплохо вывод onstat -C
в тему - не в тему но отвечу
сейчас аптайм 14 часов (это я перезапускал что бы получить момент просветления. до начала проблем он приближался к году)
нить сканёра то есть то нет
onstat -c
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
B-tree Scanner Information
Profile
=======
Active Threads 1
Global Commands 0
Number of partition scans 3611
Main Block 0x00000003956d9dc0
BTC Admin 0x0000000000000000
BTS info id Prio Partnum Key Cmd
0x396653a88 0 High 0x00500179 1 10000000 Scan index
Number of leaves pages scanned 1657712675
Number of leaves with deleted items 2950976
Time spent cleaning (sec) 40036
Number of index compresses 134615
Number of deleted items 27721632
Number of index range scans 0
Number of index leaf scans 1509
Number of index alice scans 25630
совсем в теории ему есть чего делать - перед новым годом мы заводит новый dbspacе log.20xx и настраиваем туда по условию порции таблиц и индексов для тех логов которые хорошо делятся по годам (а не нужный поза-поза-прошлый год архивируем и отстреливаем)
это вполне может вызвать нужду в перетасовке индексов но уже февраль и все процессы давно закончится должны были
других причин массово менять индексы нет
