Добрый всем день.
Помогите, если сможете, найти причину проблемы.
Ситуация следующая:
Есть сервер №1 с IB6.0, на котором лежит n-ное кол-во баз *.gdb Клиенты подключаются к ним и все работает, хоть и медленно.
Есть сервер №2 с FB2.1.3.18185 SS, на который переносятся эти рабочие базы. Клиенты подключаются, работают, но 1-2 раза в день вылетает какая-то из баз с ошибкой: Summary of validation errors Number of index page errors и кол-во ошибок. После бэкап/рестор база опять в строю, но через нек-ое время может опять вылететь. Что характерно, если база вылетела, то с достаточно большой вероятностью она вылетит еще раз в ближайшее время. При возврате на сервер №1 все опять работает без ошибок.
Подскажите, с чем такая ситуация может быть связано? Что может помочь?
С уважением, Дмитрий.
"Сыпятся" индексы
Re: "Сыпятся" индексы
поясните, как это Вы базы переносите с 2.1 на IB 6.0?
проверяли-ли Вы железо на сервере N 2, например, event log, тестировали-ли память?
проверяли-ли Вы железо на сервере N 2, например, event log, тестировали-ли память?
я так понимаю, что эта информация из gfix. Вы базы каким образом перенесли от IB 6.0 на FB 2.1 ? в interbase.log на сервере 1 ошибок нет, и gfix ошибок не находит?в день вылетает какая-то из баз с ошибкой: Summary of validation errors Number of index page errors и кол-во ошибок.
Re: "Сыпятся" индексы
Без изысков (возможно это и не верно), просто копирую, как с IB на FB, так и наоборот . База в этот момент не используется.kdv писал(а):поясните, как это Вы базы переносите с 2.1 на IB 6.0?
проверяли-ли Вы железо на сервере N 2, например, event log, тестировали-ли память?
ругается пользовательская программа (информация в логе) и ту же информацию выдает gfix.kdv писал(а):я так понимаю, что эта информация из gfix. Вы базы каким образом перенесли от IB 6.0 на FB 2.1 ? в interbase.log на сервере 1 ошибок нет, и gfix ошибок не находит?
По поводу interbase.log на сервере №1 - есть ошибки типа:
Server1 (Server) Mon Nov 30 18:38:58 2009
Database: D:\BASA.GDB
Index 1 is corrupt on page 3459 in table UNDEF_ADDRESS (143)
при этом данные ошибки на работоспособность клиентской программы не влияли. На втором сервере в firebird.log есть ошибки типа:
Server2 (Server) Tue Dec 22 09:44:40 2009
Database: D:\BASA.GDB
Index 2 is corrupt on page 4084 level 1. File: ..\..\..\src\jrd\validation.cpp, line: 1659
in table PLATEGY (138)
Server2 (Server) Tue Dec 22 09:44:40 2009
Database: D:\BASA.GDB
Index 2 is corrupt on page 4084 level 1. File: ..\..\..\src\jrd\validation.cpp, line: 1649
in table PLATEGY (138)
Server2 (Server) Tue Dec 22 09:44:40 2009
Database: D:\BASA.GDB
Index 2 has orphan child page at page 4084 in table PLATEGY (138)
но таблица совсем иная, чем в ошибках на сервере №1.
Также была одна машина (клиент), база которой сыпалась просто рекордное (несколько за день) число раз. Не помогла даже замена базы на абсолютно новую. Поэтому у меня возникло предположение, что, возможно, общая проблема связана с качеством канала связи, хотя все-равно не понятно, почему возникают ошибки в индексах на сервере.
Re: "Сыпятся" индексы
есть еще ошибки типа:kdv писал(а):поясните, как это Вы базы переносите с 2.1 на IB 6.0?
проверяли-ли Вы железо на сервере N 2, например, event log, тестировали-ли память?
я так понимаю, что эта информация из gfix. Вы базы каким образом перенесли от IB 6.0 на FB 2.1 ? в interbase.log на сервере 1 ошибок нет, и gfix ошибок не находит?в день вылетает какая-то из баз с ошибкой: Summary of validation errors Number of index page errors и кол-во ошибок.
Server2 (Server) Tue Dec 22 20:26:12 2009
INET/inet_error: read errno = 10054
Re: "Сыпятся" индексы
ODS 10 в FB 2.x хоть и поддерживается, но никакие тесты не проводятся.
Переводи БД в родную для FB ODS, тогда будет о чём говорить.
Переводи БД в родную для FB ODS, тогда будет о чём говорить.
Re: "Сыпятся" индексы
Влад уже ответил про ODS, я лишь хотел проверить свои подозрения на тему "переноса" баз.
у Вас база УЖЕ ПОВРЕЖДЕНА на IB 6.0, а Вы ее переносите на 2.1.Index 1 is corrupt on page 3459 in table UNDEF_ADDRESS (143)
одно цепляется за другое.но таблица совсем иная, чем в ошибках на сервере №1.
это исключительно проблемы железа сервера. И никакое "качество канала связи" на это влиять не может, т.к. клиент с файлом базы не работает. С ней работает только сервер.Также была одна машина (клиент), база которой сыпалась просто рекордное (несколько за день) число раз.
в первых своих вопросах я дал намек на кривое железо. Его и исследуйте.не понятно, почему возникают ошибки в индексах на сервере.
воспользуйтесь поиском по этому форуму, и по сайту. не поможет - в гугле. Эта ошибка уже давно расписана подробнейшим образом.INET/inet_error: read errno = 10054