Ошибка подключения к БД

[Stilet]

У информикса (может быть у его CSDK) есть хелп по ошибкам. Find Error кажись называется. Найди там описание этих ошибок.

[TYMON]

Я прочел он писал что нет файла одного, я из предыдущей версии кинул. Тоже самое

[Stilet]

Мой тебе добрый совет: Вызывай тяжелую артиллерию. Т.е. спеца по информиксу "на дом". То что ты описываешь не укладывается (у меня) ни в какие рамки. Что-то взял, куда-то кинул... Так не получится. Информикс это не MS Access, тут нужно четко знать что делаешь. Наобум не прокатит. И методы типа "Взять из предидущей" тоже не прокатят. Вернее чтобы их использовать нужно быть семи пядей во лбу, поскольку работа информикса не портируется. Как она однажды настроена так и будет работать, и ничего из него вот так просто не удастся выдернуть чтоб это работало в другой обстановке. Не выйдет так как ты хочешь, это уже должно быть тебе понятным.

[TYMON]

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

[Stilet]

Насколько я знаю логические журналы переупорядочиваются в результате той самой ontape. Хотя можно конечно еще с помошью onparams тупо поудалять из списка логирования эти журналы, но в этом действии никакого смысла нет. Кстати могу ошибаться, но по-моему команда SQL UPDATE STATISTICS тоже способствует правильному пищеварению в журналах. Хотя вот на ее счет не уверен, всетки это статистика а не журнал транзакций.
Обычно его не чистят.

Насчет физических журналов я не понял что имеется ввиду.

[TYMON]

Просто делаю команду onstat -l после заливки базы, и удачного апдейта, потом удалил а наполняемость осталась


Logical Logging
Buffer bufused bufsize numrecs numpages numwrits recs/pages pages/io
L-3 0 8 645571 19224 3923 33.6 4.9
Subsystem numrecs Log Space used
OLDRSAM 645571 72691492


address number flags uniqid begin size used %used
ca376a8 1 U-B---- 189 1002fb 500 500 100.00
ca376e0 7 U-B---- 190 500193 500 500 100.00
ca37718 2 U-B---- 191 1004ef 500 500 100.00
ca37750 8 U-B---- 192 500387 500 500 100.00
ca37788 3 U-B---- 193 1006e3 500 500 100.00
ca377c0 4 U-B---- 194 1008d7 500 500 100.00
ca377f8 5 U-B---- 195 100acb 500 500 100.00
ca37830 6 U-B---- 196 100cbf 500 500 100.00
ca37868 9 U-B---- 197 50057b 25000 25000 100.00
ca378a0 10 U---C-L 198 827e00 25000 18232 72.93
ca378d8 11 A------ 0 c00003 375000 0 0.00
ca37910 12 A------ 0 d00003 375000 0 0.00
12 active, 12 total

Как я понял из этой команды мы смотрим буферы логических и физических журналов. Почему они не очищаются? (я привел логические)

[Stilet]

наполняемость осталась

Так и должно быть. Более тебе скажу, этот "мусор" допустим во всех СУБД такого уровня как Информикс. MS SQL, Oracle... Даже FireBird допускают остатки информации без ее физического удаления. Это защита от фрагментации, которая для реляционных СУБД достаточно губительная.

Почему они не очищаются?

Почитай про фрагментацию. Если ты начнешь их очищать, то в чанках появятся дырки. Неиспользуемое пространство, которое затрудняет работу запросов.
Почитай как распределяются в БД данные. Кстати рекомендую книги Тома Кайта. Он специалист в этом деле, и пишет отлично. Там ты узнаешь про слябы, экстенты. И вообще как в базе распределяется место под записи. На словах трудно описать почему дырки в БД опасны.

А вообще, если хочешь дай свою емелю, я тебе скину РЭ по Информиксу на русском. Там отлично все описано.

[TYMON]

Спасибо за помощь)

[Stilet]

Книжки то дошли?
У меня еще есть. Могу основы выложить.