inet_error: listen errno=10022 (Комп отверг запр. на подкл.)
inet_error: listen errno=10022 (Комп отверг запр. на подкл.)
Всем привет!
Народ! Подсобите советом, плиз! Ситуация следующая.
На двупроцессорной машине стоял Firebird 1.0.0.32 Beta (ОС: W 2000 Server SP 4). Клиенты - W98, W2000 Server, W XP. Юзеры цеплялись по TCP протоколу (server:c:\...). Периодически производилось выключение-включение Firebird Guardian (через команду net stop\start ...) для копирования БД.
Поставил Firebird 1.5.1.4481 Классик. На всех клиентах переставил фб-клиент тоже, кнечна .
После установки работает нормально до первой остановки Firebird Guardian. После включения службы при попытке подключения к базе на машине клиента выдается след. последовательность сообщений:
"Обрыв с сервером БД
Unknown database
Unable to complete network request to host "<имя_сервера_БД>"
Failed to establish connection.
Подключение не установлено, т.к. конечный компьютер отверг запрос на подключение.
Alias: DATA.GDB"
В firebird.log на сервере при этом появляются след. записи:
"SERVER (Client) Thu Dec 09 12:06:16 2004
Guardian starting: C:\...\fbserver.exe
SERVER Thu Dec 09 12:07:06 2004
INET/inet_error: listen errno = 10022
SERVER Thu Dec 09 12:07:06 2004
Database:
Unable to complete network request to host "server".
Error while listening for an incoming connection.
Получен недопустимый аргумент."
Причем исправляется данная ситуация только перегрузкой сервера.
Еще один нюанс. Обратил внимание, что после отключения Firebird Guardian в памяти сервака остаются еще процессы fb_inet_server#... Причем их нельзя закрыть из диспетчера программ (нет доступа). Что самое веселое - некоторые еще показывают и ненулевую активность в мониторе системы!
При смене CS на SS проблема исчезает.
Подскажите плз - где проблему искать можно... Может кто сталкивался уже...
Заранее спасибо!
Народ! Подсобите советом, плиз! Ситуация следующая.
На двупроцессорной машине стоял Firebird 1.0.0.32 Beta (ОС: W 2000 Server SP 4). Клиенты - W98, W2000 Server, W XP. Юзеры цеплялись по TCP протоколу (server:c:\...). Периодически производилось выключение-включение Firebird Guardian (через команду net stop\start ...) для копирования БД.
Поставил Firebird 1.5.1.4481 Классик. На всех клиентах переставил фб-клиент тоже, кнечна .
После установки работает нормально до первой остановки Firebird Guardian. После включения службы при попытке подключения к базе на машине клиента выдается след. последовательность сообщений:
"Обрыв с сервером БД
Unknown database
Unable to complete network request to host "<имя_сервера_БД>"
Failed to establish connection.
Подключение не установлено, т.к. конечный компьютер отверг запрос на подключение.
Alias: DATA.GDB"
В firebird.log на сервере при этом появляются след. записи:
"SERVER (Client) Thu Dec 09 12:06:16 2004
Guardian starting: C:\...\fbserver.exe
SERVER Thu Dec 09 12:07:06 2004
INET/inet_error: listen errno = 10022
SERVER Thu Dec 09 12:07:06 2004
Database:
Unable to complete network request to host "server".
Error while listening for an incoming connection.
Получен недопустимый аргумент."
Причем исправляется данная ситуация только перегрузкой сервера.
Еще один нюанс. Обратил внимание, что после отключения Firebird Guardian в памяти сервака остаются еще процессы fb_inet_server#... Причем их нельзя закрыть из диспетчера программ (нет доступа). Что самое веселое - некоторые еще показывают и ненулевую активность в мониторе системы!
При смене CS на SS проблема исчезает.
Подскажите плз - где проблему искать можно... Может кто сталкивался уже...
Заранее спасибо!
А не подскажите как тогда провести копирование базы с одного сервака на другой? (backup-restore не позволяет делать размер базы и интенсивность работы со второй базой - она должна быть доступной практически постоянно)kdv писал(а):2. классику guardian ВООБЩЕ не нужен.
Отключением-включением гардианов на серверах достигалась идентичность баз после копирования, а копирование "на ходу", с работающими в копируемой базе юзерами ведь неизбежно приведет к порче скопированной базы, а то и обоех...
Хм... Меня терзает смутное сомнение, что я недопонимаю механизм работы Классика... С SS все понятно - когда служба ФБсервера останавливается - завершается процесс fb_inet_server и все юзеры, соответственно, вываливаются... А как в CS? - подскажите плиз где можно прочитать про механизм остановки сервера с CS архитектурой (либо - блокировки сервера или БД для всех пользователей, чтобы они не могли изменять содержимого БД на нек. время).kdv писал(а):2. классику guardian ВООБЩЕ не нужен.
Сорри - оговорился! Я имел в виду fbserver.exe для SS, конечно . Два сервера я одновременно на одной машине не запускаюkdv писал(а):процесс супера - это fbserver.exe. процесс классика - fb_inet_server.exe
По копированию:
БД - около 4 Гб, копирование чистым временем занимает ок. 6 минут, с запасом на "всякий случай" и на запугивание юзеров (дабы большинство вышло из программы до отрубания сервера) - 10 минут.
gbak -b -g -v -y ... выполняется около 43 минут. Но это то время как раз не критично, т.к. пользователи могут нормально работать с обеими базами в это время. А вот рестор (gbak -с ...) выполняется порядка полутора часов, притом, что в это время ощутимо замедляется работа на том сервере, на котором этот рестор делается.
И последнее - после проведения рестора базу ведь нужно поместить в то место, где лежит вторая база, с которой работают юзеры, а для этого все равно нужно отключить всех пользователей - т.е. опять приходим к проблеме отключения всех юзеров от БД на нек. время...
Так вот как бы решить последнюю?..
П.С.: Кстати, с днем Конституции всех!
это случайно не на тот же винт, где и база лежит? 43 минуты - ОЧЕНЬ медленно. даже на приличной workstation с ide-дисками не должно быть дольше 20-30 минут.gbak -b -g -v -y ... выполняется около 43 минут.
дальше - у тебя юзеры работают с базой круглосуточно, без перерывов? это плохо.
по крайней мере есть возможно более быстрое решение - shadow.
читай www.ibase.ru/devinfo/doc_calford_1.htm
Ага, на тот же... Хотя он сказевый... Понял ошибку, сенкс.kdv писал(а):это случайно не на тот же винт, где и база лежит?
... Увы и ах... Их, кнечно, можно выгонять, но не на полтора часа...kdv писал(а):у тебя юзеры работают с базой круглосуточно, без перерывов? это плохо.
Спасибо за совет и за ссылку - щас изучу.kdv писал(а):читай www.ibase.ru/devinfo/doc_calford_1.htm
Изучил я этот вариант gbak-заменителя с помощью Shadow (кстати, статья - супер! Оч. много полезностей - всем рекомендую!).
Все замечательно, но вот фраза:
"...затем остановить Interbase, переименовать первый файл shadow, рестартовать Interbase... "
В этом то и вся проблема. Как "остановить" и "рестартовать" Интербейз сервер под CS архитектурой? Экспериментировал с CS, пытался остановить его через стоп службы Firebird Server тогда, когда к базе был подключен юзер... Стоп службы убил один процесс, порожденный этой службой, а вот 2 таких же процесса, порожденные этим пользователем - не тока остались живыми, так еще и прекрасненько работали с БД, изменяли данные в ней... Понятно, что о замене БД в таких условиях речи быть не может.
Так вопрос в следующем - как же все ж таки остановить и рестартовать сервер CS так, чтобы при этом все пользовательские процессы отвалились бы и дали возможность произвести нужные действия с БД?
Нда... При создании темы я думал, что эт в принципе - нормальное дело, и для этого достаточно остановить службу и затем стартануть ее заново, а то, что после этого при попытке подключения к серверу выдается ошибка прослушивания коннектов есть глюк...
Все замечательно, но вот фраза:
"...затем остановить Interbase, переименовать первый файл shadow, рестартовать Interbase... "
В этом то и вся проблема. Как "остановить" и "рестартовать" Интербейз сервер под CS архитектурой? Экспериментировал с CS, пытался остановить его через стоп службы Firebird Server тогда, когда к базе был подключен юзер... Стоп службы убил один процесс, порожденный этой службой, а вот 2 таких же процесса, порожденные этим пользователем - не тока остались живыми, так еще и прекрасненько работали с БД, изменяли данные в ней... Понятно, что о замене БД в таких условиях речи быть не может.
Так вопрос в следующем - как же все ж таки остановить и рестартовать сервер CS так, чтобы при этом все пользовательские процессы отвалились бы и дали возможность произвести нужные действия с БД?
Нда... При создании темы я думал, что эт в принципе - нормальное дело, и для этого достаточно остановить службу и затем стартануть ее заново, а то, что после этого при попытке подключения к серверу выдается ошибка прослушивания коннектов есть глюк...