[Ruslan_Mars] О решении проблем с зависанием службы Руслан.

[zelenina]

Коллеги, всем добрый вечер еще раз...

Поделюсь своим опытом работы с "Русланом" с 2004 года.
Стала этим заниматься в 2006 году, когда моя сотрудница, поняв, что
этот такое - "сопровождение", ушла на более хлебосольные, чем в высшем
образовании, хлеба...

Последние версии клиентов 3.7.8.1 и 3.5.1 тоже  работают с сервером
2.16.0, который входит в дистрибутив ruslan_s_3_5_246.exe.
ORACLE - 11i. Количество подключений - 26.
Более половины работает с АРМом КК: комплектование - 3 станции,
обработка - 5 (это полный рабочий день),  5-8 станций - активный
ретроввод фонда в разных корпусах (по 3-5 рабочих часов).
5 станций - работа в МАРСе - аналитическая роспись - в свободное от
обслуживания читателей время (в  5 комп. классах библиотеки).

Почти половина  соединений - книговыдача с 8.30  утра до 18 вечера.
2 корпуса - только автоматизированная книговыдача,  3 точки выдачи -
учебные абонементы.
Сеть библиотеки в 5 корпусах университета в разных концах города.

Объем базы архива книговыдачи за учебный год - более 150 тыс. Сейчас
на руках - около 40 тыс... По решению руководства библиотеки бумажных
формуляров и пр. документов, где бы читатель расписался за взятые
книжки, с 2007 года нет...

Проблемы были  следующего характера:
1. Зависание службы сервера Руслан с ошибками в системном журнале и
авт. перезагрузкой самого сервиса.
2. Невозможность установить соединение с СУБД - с дальнейшей
перезагрузкой базы, инициированной службой Руслана.
3. Систематические ошибки в журнале, типа "не возможно установить
соединение", "тип зависшей операции" и т.п...
К сожалению, описаний этих сообщений, при каких условиях они
появляются,  в документации системы нет... А хотелось бы иметь.
Разработчики говорили, что если таких ошибок более 5 за сутки, это
серьезная проблема...

Ситуация была, когда СУБД, Руслан, Web-сервер библиотеки с АРМом
читателя, а также домен сети библиотеки одного из корпусов были на
одной железке... Журнал приложений был весь красный, включая иногда
ночь. 

Ошибок стало на порядок меньше, когда СУБД и Руслан вынесли с web-а и
домена на новое железо. В это же время была сменена СУБД  с 9.2.0.7
на 11i.

При появлении ошибок 3 характера анализирую статистику сервера
"Руслан". Выбираю время, когда появляется ошибка в журнале приложений,
библиотекарей и статистику по ошибкам... Анализ описан в
документации...
В дополнительной информации ошибки смотрю, кто из библиотекарей в это
время что делал... Обычно конкретный библиотекарь (логин) работает на
конкретной машине...  Если ошибок для библиотекаря много, разговариваю
во время еженедельного обхода по корпусам, какие были проблемы и что
при этом делали.
Жалобы типа "долго списывается книжка", "медленно привязывается ШК" и
т.п., как говорили разработчики  и как показал мой опыт,  обычно являются
следствием плохих физических соединений. 
Помогает (ошибки уходят для данного места полностью!) смена сетевой
карты на станции на внешнюю, даже если старая (обычно встроенная)
пропускает пинги. Их длительный запуск на сервер (10 тыс.  и более)
как правило показывает, что пакеты идут не стабильно.

Перед началом  каждого учебного года третий год подряд создаю
отдельную базу архива книговыдачи - это был совет Д. Совы. Для этого
создается новая область хранения.
Данные и индексы этой служебной базы - на разных физ. дисках,
отдельных от дисков с областями хранения библиографических баз.
Это тоже совет разработчиков.

Недавно ошибки 1 и 2 типа, а также не понятное "зависание" службы
Руслана, когда ее нельзя было перезапустить - надо было всю систему
перегружать, появились снова... Причем, время зависания было почти
одинаковое - утро, с 8 до 9...  После смены центр. коммутатора (он
давно подавал признаки отказа работы - отваливались отдельные порты),
зависания прекратились...

Может быть кому-то опыт нашей библиотеки поможет решить свои
проблемы... 

У меня вопрос к Рыбалко  Андрею...
А при ваших зависаниях службы Руслана что в логах ORACLа? есть
какие-то сообщения?  СУБД при этом нормально работает?
Мне кажется, автоперезапуск службы, когда она "висит" для читателя, но
при этом библиотека работает на запись в СУБД, не очень "приятно" даже
для ORACLe...
---------------------------------------------------------------------------
С уважением, Галина Николаевна Зеленина, 
начальник отдела автоматизации Научной библиотеки 
Челябинского государственного университета.

Почтовый адрес: 454001, г. Челябинск, ул. Братьев Кашириных, 129. 
                Челябинский государственный университет. Научная библиотека
Телефон: (351) 799-70-94, 799-70-95
http://www.lib.csu.ru
e-mail: Zelenina на csu.ru