ИРБИС-64, 2012.

Здравствуйте!

После установки версии 2012 на этапе "Создать словарь заново" этот процесс для всех баз , кроме БД - картотека трудов сотрудников, прошел успешно. А для указанной БД после запуска этого процесса никаких изменений не происходит, т.е. записи остаются в статусе неактуализированных. Если же запустить процесс "Акутуализировать словарь", то они переходят в статус актуализированных, но в АРМе Каталогизатор эта БД пустая (не видно записей)!!! Подскажите, пожалуйста, в чем может быть причина и как исправить эту ситуацию?

Спасибо!

Проведите диагностику этой БД.

Диагностику провели - Ошибок не обнаружено!



Редактировано 1 раз. Последний раз 09.08.2013 07:10 пользователем New.

Выполнила режим - "Актуализировать словарь" вместо "Создать словарь заново". Прикрепляю файл - в АРМе не видно записей.



Редактировано 1 раз. Последний раз 09.08.2013 07:46 пользователем New.

Проверьте в папке KTUI наличие файлов
KTUI.FST
BRIEF.PFT
KTUI.IFS

Проверила на локальной ИРБИС - все сработало, на рабочей - по прежнему нет.

Что означает Ваш ответ???
Я просил проверить наличие указанных файлов...

Спасибо большое все заработало!!!

Возможно ли актулизировать словарь только по одной строчке fst недавно добавленной. Задача состоит в добавлении нового вида поиска (словаря). Т. е. актуализировать отдельный словарь. Сейчас приходится актуализировать всю БД целиком.

woodyfon написал(а):
-------------------------------------------------------
> Возможно ли актулизировать словарь только по одной
> строчке fst недавно добавленной.
Нет, нельзя.

Планируется ли реализация такой возможности в будущем? Акуально для слабых машин с большим количеством записей в БД.

woodyfon написал(а):
-------------------------------------------------------
> Планируется ли реализация такой возможности в
> будущем?
Нет.
Акуально для слабых машин с большим
> количеством записей в БД.
Абсолютно неактуально - если используется <dbname>.ifs

Цитата:

Абсолютно неактуально - если используется <dbname>.ifs

Возможно, я неправильно что-то делаю. Но у меня актуализация на БД в 450 тыс. записей на машине с процессором частотой 1.6 ГГц и двумя ядрами проводится почти 2 часа. Это нормально? Можно ли ускорить актуализацию и полностью отказаться от файла <dbname>.fst, перейдя полностью на новую технологию. Файлик ТВП полностью переписан используется 8 словарей (ключей).



Редактировано 1 раз. Последний раз 21.11.2013 13:18 пользователем woodyfon.

если 450 тысяч записей и два часа на актуализацию, то для библиографической базы это ОЧЕНЬ быстро. Если это спец база с небольшим ТВП, то все зависит от того, какие именно форматы и как оптимально они работают. В ТВП вообще может быть только один ключ и создание словарей заново будет невероятно долгим, если формат не оптимальный и долговыполняемый.

Пришлось оптимизировать код перед запуском актуализации и удалить редко используемые ключи словарей. На ТВП по умолчанию вычислительное время выполнения актуализации БД более суток. Оставить машину на ночь включенной не представляется возможным. Поэтому, повторюсь, что необходимо оптимизировать файл словаря. И все таки эт остается актуалным и после появления файликов ifs. Каждый ключ словаря держать в отдельном файле. Тогда при полной актуализации БД обновление fst будет затрагивать только один файл или создавать новый.
+
Оказывается, что я не первый, которое хочет такое видеть. Раньше вы, Гена, также предлагали что-то подобное. Сейчас можно констатировать, что ИРБИС не годится для больших баз. Слишком долго идет обработка данных при существующих принципах работы.
+

Цитата:

Абсолютно неактуально - если используется <dbname>.ifs

Но он же используется только при измении записи, для полной актуализации и создании словаря заново применяется файл *.fst. Или я опять что-то недосмотрел в документации или документация не так посмотрела на меня.



Редактировано 3 раз. Последний раз 21.11.2013 14:57 пользователем woodyfon.

Суть в том, что на имеющейся модели БД это невозможно. Да, я предлогал вариант, при котором каждый отдельный поисковый словарь формировался бы в отделный файл. Но это требует больших переработок серверной части Ирбиса. Константин Олегович на Либкоме говорил, что некоторые похожие идеи в воздухе витают, но вот когда они будут предварены в жизнь - сказать не смог. На счет очень больших баз - тут требуется уточнение, что на больших базах при работе 8 часов в сутки. У меня на базе в 440 тысяч записей на сервере с 8 ядрами и 8 Гб ОЗУ словари полностью создаются где-то за два-три часа. И это при том, что у меня стандартный ФСТ! Большие базы требуют и большей производительности от сервер

Заметил, что для ИРБИСа значение оперативной памяти некритично, главное какой процессор. Чем больше ядер и частота, тем лучше.

Да, оперативка не кретична, так как процесс расформатирования записей не требует очень большого количества терминов. А вот процессор действительно чем больше ядер - тем лучше. И свзанно это с тем, что любая операция расформатирования от любого клиента пораждает на сервере процесс, который чаще всего на какое-то время съедает всё ядро, в котором он запустился. Потому и лучше иметь больше ядер, что бы остальные клиенты не ждали очереди.