Наиболее критичной по времени выполнения в ИРБИС32 является операция СОХРАНЕНИЯ записи в АРМе Каталогизатор (т.е то, что происходит при нажатии кнопки СОХРАНИТЬ на плоскости ВВОД) – замедление других операций в конечном итоге определяется именно этой операцией.
Время выполнения операции СОХРАНЕНИЯ записи складывается из следующих операций:
- ФЛК записи (dbnflc.pft)
- Автоввод в запись (autoin.gbl)
- Собственно сохранение записи
- Актуализация записи (<dbn>.fst)

Решающее значение имеет операция АКТУАЛИЗАЦИЯ – т.е. при оценке общего времени выполнения операции СОХРАНЕНИЯ можно пренебречь временем выполнения трех первых операций.

Время выполнения операции АКТУАЛИЗАЦИИ в свою очередь зависит от следующих факторов:
1. Объем БД
2. Объем FST (т.е. кол-во терминов, которое генерируется на основе <dbn>.fst)
3. Мощность клиентской машины (т.е. машины, на которой работает АРМ Каталогизатор)
4. Мощность файл-серверной машины (т.е. машины, на которой находится БД)
5. Сетевой трафик (т.е. объем и скорость данных, «прогоняемых» по сети при выполнении АКТУАЛИЗАЦИИ)

Здесь безусловно решающим является 5 фактор.

При сетевой работе с большой БД (более 100 тыс. док-ов) время АКТУАЛИЗАЦИИ новой (!!!) записи может достигать 30 сек. и более. Разумеется, такое замедление работы может стать нетерпимым. В этой ситуации можно предложить три решения:
1. Использование АВТОАКТУАЛИЗАЦИИ в АРМе Администратор (см. релиз к версии 2004.1 – RELEASE_4_1.DOC). Недостаток этого решения – клиент «не знает», когда произойдет актуализация записи, которую он сохранил, поэтому, для того чтобы обнаружить обновление словарей в связи с этой записью, необходимо вручную их переоткрывать.
2. Ведение основной БД на основе периодического пополнения из транзитной (промежуточной) БД. Идея состоит в следующем: новые поступления вводятся в транзитную БД в течение некоторого периода (например, недели), в конце этого периода транзитная БД переливается в основную БД и опустошается; актуализация «влитых» в основную БД док-ов выполняется пакетно в АРМе Администратор. При вводе в транзитную БД можно использовать словари основной БД и ее же использовать для проверки на дублетность. (В принципе есть возможность использовать для ввода словари и транзитной, и основной БД, и их же использовать для проверки на дублетность). К недостаткам этого решения можно отнести необходимость проведения определенных настроек (в частности, изменение РЛ), требующих определенной подготовки от администратора БД, а также – дискретность поступления документов в основную БД.
3. Переход на ИРБИС64 – в котором благодаря клиент-серверной архитектуре отсутствует 5 фактор (сетевой трафик – см. выше) и АКТУАЛИЗАЦИЯ на больших БД идет на ПОРЯДОК (а то и на два) быстрее чем в ИРБИС32.

> При вводе в транзитную БД можно использовать словари основной БД

А каким образом?

Для этого необходимо откорректировать РЛ - в части правил подключения словарей (см. Приложение в Общем описании - Редактор РЛ).
Мы постараемся сделать некоторое типовое решение для работы через транзитные БД...

Спасибо

> 1. Использование АВТОАКТУАЛИЗАЦИИ в АРМе Администратор (см. релиз к версии 2004.1 – RELEASE_4_1.DOC). Недостаток этого решения – клиент «не знает», когда произойдет актуализация записи, которую он сохранил, поэтому, для того чтобы обнаружить обновление словарей в связи с этой записью, необходимо вручную их переоткрывать.

Какой именно клиент? Если каталогизатор, то ему вроде бы не надо при вводе обращаться к словарям (кроме варианта каталогизации путем поиска и копирования ранее введенных похожих записей из БД), а если читатель, то это действительно очень неудобно.

2-й вариант на первый взгляд кажется самым простым.
По-моему, можно и даже нужно просто копировать записи из транзитной (рабочей, служебной) БД (назовем ее WORK) в основную (читательскую) БД (назовем ее BOOK) с автоактуализацией через пакетные задания.

Александр Иосифович!
Можно ли сделать такой вывод, что предложения А.С.Карауша («Инструкция по переводу Системы «ИРБИС32» в режим полной автоматической актуализации баз данных ресурсами сервера») не нужны или ошибочны?



Отправка отредактированного (02-06-05 12:05)

Нет, такой вывод безоснователен. Предложения, выдвинутые А.С.Караушем давно уже обсуждались и они очень реальны. Если все так плохо, как описано в этой инструкции, то использование их будет наилучшим выходом из положения.

Можно тему про "мою" инструкции перенести в тему для этой инструкции?
Что расположена по адресу: [irbis.gpntb.ru]

Там бы я сказал, что данная инструкция - есть частный случай для увеличения работы конкретного АРМа Каталогизатор, причем только моменты сохранения в нем. Если в организации работает ИРБИС "целиком", т.е. с книговыдачей, то лучше купить мощнее компьютеры.