Описание ошибок в INTERBASE.LOG

Последнее обновление – 21.11.2001.

Ошибки идут под буквой E (error), описание ошибки – D (description), возможное решение проблемы – как S (solution).

Описания ошибок приведены на момент существования IB 7.0. Часть ошибок могут проявляться только в предыдущх версиях (6.x, FB,Yaffil, 5.6, 5.5, 5.1, 5.0).
 

E: internal gds software consistency check (partner index description not found (175))

D: "пропал" индекс первичного или вторичного ключа.
D: построен уникальный индекс по полю, по которому уже есть FK (т. е. неуникальный индекс).

S: Теоретически "пропавший" индекс можно обнаружить при помощи запроса
Constraint без индекса (пустое поле REALINDEX) и окажется "битым". Его нужно попытаться удалить. Если удалить constraint не удается, то следует попытаться создать индекс, имя которого указано в столбце REFINDEXNAME. Уникальность индекса должна соответствовать типу constraint – уникальный для первичного ключа, и неуникальный для вторичного.

Если же речь идет о лишнем (уникальном) индексе, то один из индексов рекомендуется удалить.
 

E: gds__free: attempt to release bad block
E: gds__alloc: memory pool corrupted

D: какие-то проблемы с памятью, или некорректно работающей UDF.

S: Решение проблемы неизвестно.
S: В более ранних версиях IB (4.2 и ниже) эта ошибка была известна как баг 8349, проявлявшийся при больших размерах файла сортировки. Т. е. при наличии запросов, обрабатывающих большие объемы данных, и имеющих сортировку ORDER BY без соответствующего индекса.

Кроме того, ошибка может появляться в multithread-приложениях из-за закрытия соединения не в том thread, в котором оно было открыто.
 

E: WNET/wnet_error: ReadFile end-of-file errno = 109 (win)
E: INET/inet_error: send errno = 10054 (win)
E: Inet/inet_error: send errno=104 (unix)

D: обрыв клиентского соединения. WNET – по NetBEUI, INET – по TCP/IP.

S: Для начала надо сделать upgrade на максимально последнюю версию IB (например, для 5.x это 5.6, для 6.x это 6.0.1.6 или 6.5, для Firebird – релиз v1 и так далее). Затем убедиться, что на сервере, если это NT (или W2K), стоит самый последний Service Pack. Если клиенты – NT (или W2K) Workstation, то на них поставить тот же сервиспак, что и на сервере. Если клиенты – Windows 95/98, то скачать с www.microsoft.com самые последние обновления для netbeui и tcp/ip.

Вообще при работе по tcp/ip таких ошибок должно быть существенно меньше, чем по netbeui.

Собственно, слово WNET в сообщении об ошибке означает ошибку при работе по протоколу по netbeui (строка вида \\server\c:\dir\data.gdb), а INET – по протоколу tcp (строка вида server:c:\dir\data.gdb).

Если ошибки 109 или 10054 продолжают появляться, то нужно искать дефектное сетевое оборудование – хаб, свитчер, или сетевую карту. Теоретически в этом может помочь использование какого-либо SNIFFER, но методика пока неизвестна. Также см. утилиту ibconsvc.zip, которая заносит информацию о коннектах и дисконнектах (только tcp) прямо в interbase.log, что позволяет отследить станции или хабы, генерирующие ошибку 10054.

Почти то же самое написано в документе: http://community.borland.com/article/0,1410,25340,00.html

Еще один вариант, который иногда помогает устранить обрывы коннектов – изменение параметров CONNECTION_TIMEOUT и DUMMY_PACKET_INTERVAL в IBCONFIG (или isc_config на UNIX) на значения, отличные от умолчательных, например, 170 и 50 соответственно. В некоторых случаях на UNIX помогает установка connection_timeout в 0.
 

E: INET/inet_error: accept errno = 10093
E: INET/inet_error: read errno = 10038

D: ошибка при попытке инициализации подсистемы tcp/ip (NetBEUI), вызвана частыми появлениями ошибок 10054 (109). Как правило после этой ошибки сервер аварийно завершает работу. Для перезапуска сервера возможно требуется рестарт NT.

S: решение такое же, как и для ошибок 10054 или 109 (см. выше).
 

E: SCH_validate -- not entered
E: SCH_validate -- wrong thread

D: неверно работающая UDF

S: скорее всего, если функция написана на Delphi (Pascal), то в модуле не указано IsMultiThread:=True. Т. е. библиотека должна быть проинициализирована для безопасной работы с несколькими threads, поскольку сервер обращается к DLL UDF именно из разных threads.
Также следует избегать использования threadvars на серверах с двумя и более процессорами, т. к. в коде Delphi (по крайней мере 4) есть ошибки с использованием TLS. Вместо threadvars рекомендуются прямые вызовы функций работы с TLS в Win32.
 

E: Page 34672 is an orphan

D: возможно, что при операциях записи на диск сервер завершил работу аварийно или произошел сбой системы по питанию

S: Ничего не нужно делать. Осиротевшие страницы (orphan pages) будут использованы повторно для размещения новых данных.
 

E: internal gds software consistency check (error during savepoint backout (290))

D:

S:
 

E: internal gds Software consistency check (size of opt block exceeded (286))

D:

S:
 

E: internal gds software consistency check (invalid SEND request (167))

D:

S:
 

E: internal gds software consistency check (decompression overran buffer (179))

D: обычно ошибка возникает при попытке прямого копирования базы данных с одной платформы на другую, например, из-под NT на Netware.

S: перенос баз данных между платформами должен производиться только путем backup/restore. Если ошибка возникла при backup, то необходимо сделать проверку базы данных при помощи gfix с проверкой record fragments, и после этого опять попытаться сделать backup (возможно с опцией ignore checksum errors).
 

E: internal gds software consistency check (Too many savepoints (287))

D: возникает при большом количестве insert/update/delete (явном или косвенном, через триггеры) в одной длительной транзакции. Возможно влияние количества вызываемых триггеров и процедур в этой транзакции.

S: в компоненте соединения с БД (например, IBDatabase) нужно указать параметр isc_tpb_no_auto_undo. В этом случае сервер не будет пытаться сохранять все изменения через механизм savepoints. Делать это следует только для тех коннектов, где заранее известно, что количество изменений в одной из транзакций будет большим (явно или через триггеры, по количеству изменяемых записей – больше 10-100 тысяч).
 

E: internal gds software consistency check (wrong record length (183))

D: может возникнуть при UPDATE полей, по которым построен unique индекс.

S: ошибка исправлена в IB 5.6 (bugs N 60135, 60537).