Проблемы с отображением в АРМ "Каталогизатор" зарегистрированной периодики в режиме "Оперативные режимы - Номера", в списке отображаются не все введённые годы и номера, а в АРМ "Книговыдача" невозможно выдать эти номера.
В версии 18 всё было нормально.

Решилось выгрузкой базы и обратной загрузкой с перестроением словаря.

Отсюда вопрос: получается, что переход с версии 18 на 19 всё же требует перенос данных через экспорт-импорт ?

И, когда уже словари будут строиться за разумное время ?

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

Гена, там указано, что экспорт-импорт только при переходе с версии 17 и ниже на 18 и выше, о необходимости экспорта-импорта при переходе с 18 на 19 ничего не сказано.

Здравствуйте! Переходим на новую версию 2019. При "создании словаря полность" при процессе сортировки идёт бесконечное разбивание файла (в окне так написано). Процесс идёт уже 14 часов. БД конечно большая, это нормальное состояние?

Сколько документов в БД, в том числе с полными текстами? Процесс загрузки выполняется НЕПОСРЕДСТВЕННО на сервере (т.е. АРМ Администратор запущен на сервере)?

Это бд Марс, там записей больше 2млн. Сейчас начался уже процесс создания файла словаря. О, закончился процесс, время работы 16 часов 15 мин.

Вы не ответили на мой вопрос - АРМ Администратор запускался непосредственно на сервере? Если да, то сколько ядер на серверной машине и какие еще задачи в это время выполнялись на этом компьютере?

Не на сервере, так как бд большая, делала на простом компьютере, он чистый (i5, 8 памяти), ни чего кроме загрузки на нем в это время не делалось. не дают мне выкл сервер на такое большое время, поэтому пришлось делать так.

olga_jukova написал(а):
-------------------------------------------------------
> Не на сервере, так как бд большая, делала на
> простом компьютере, он чистый (i5, 8 памяти), ни
> чего кроме загрузки на нем в это время не
> делалось. не дают мне выкл сервер на такое
> большое время, поэтому пришлось делать так.
Т.е. АРМ Администратор-серверный Вы стартовали на "простом" компьютере, а БД находилась на сервере? Вы понимаете, что это значит? Если нет - обратитесь к своим сис.админам. Это АБСОЛЮТНО недопустимый режим работы. Так можно запускать загрузку словаря только через АРМ Администратор-клиент.

Я конечно тоже сталкивался с ситуациями, когда серверный АРМ Администратор запускался не на сервере, а с другого компьютера по локальной сети... Безусловно Александр Иосифович прав - это недопустимо. Но больше, чем уверен, что в данном случае речь не идет о подобном случае. Увеличение времени индексирования БД это в целом проблема версии 64+. В ИРБИС64+ к сожалению гораздо дольше работают процессы индексирования записей БД ЭК, даже при отсутствии файлов полных текстов. Это стало платой за включение полнотекстового функционала, который ранее требовалось приобретать отдельно и крторый в ИРБИС64+ стал встроенным в сервер.

Проблему призвана решить новая версия сервера ИРБИС, а также новый инструмент irbistool, при использовании которого процессы индексирования проходят в РАЗЫ быстрее (в разных ситуациях при тестировании данного модуля получали результаты импорта записей и индексирования БД от 4 до 20 раз быстрее, чем в аналогичные процедуры в АРМ Администратор).
Ждем официального выпуска нового функционала. Этот функционал уже в тестировании у дилеров.

ну нет у меня дополнительного сервера, что мне делать? нужно максимально быстро перевести библиотеку на новую версию, для этого у меня 2 ночи и 1 рабочий день. Поэтому установила новую версию на комп. максимально все подготовила на нем заранее. на ночь выкл сервер, экспортировала БД самые нужные для работы и эти записи уже импортировала в новую версию. Все БД загрузились быстро, кроме Марса, т.к. она уж очень большая. Но в итоге внедрить не получилось, обновление снова перенеслось. Придется все выгружать по новому.
Напишите, как сделать правильно в моем случае.

olga_jukova написал(а):
-------------------------------------------------------
Но
> в итоге внедрить не получилось, обновление снова
> перенеслось.
Это как понимать? Вы читали "Инструкция по переходу на новую версию.doc"?

по инструкции и делала. Внедрить не получилось, потому что не все успела загрузить. Пришлось снова вкл старую версию.

Ольга, могу предложить вам немного другой подход. Я так понимаю, что загрузить длительной работой с базой в 2 000 000 основной сервер вы не можете. Потому что станут все остальные процессы. Если так, то этот процесс можно разбить следующим образом:

1. На основной сервер ставите новую версию
2. Создаете базы данных для своих записей (по списку старых баз)
3. Переносите свои настройки (ини, мну, раб.листы, словари и т.д.)
4. Загружаете все основные базы, кроме большой базы на 2млн записей
5. Запускаете сервер в работу и ваши коллеги начинают выполнять повседневные задачи (создание записей, выдачу литературы и т.д., кроме операций с базой МАРСа!)
6. загружаете базу МАРСа в созданную базу
7. В ини-файле АРМа Администратор ставите ограничение на количество одновременных потоков создания словарей. Ограничение нужно поставить меньше, чем у вас ядер на сервере, что бы всегда оставались свободные ядра для работы библиотекарей. Например, если у вас сервер на 8 ядер, поставьте ограничение на 4 ядра. Тогда при создании словарей АРМ Администратор создаст только 4 потока, он будет создавать словарь медленнее, но позволит при этом работать остальным пользователям.

Да, при этом у вас начнется работа у всех, кто не связан с этой базой, но это по крайней мере даст возможность работать.


Другой вариант, без перенастройки АРМа Администратор
Делаете как и выше все пункты 1-5, а потом создаете пустую базу для МАРСа и временно останавливаетесь.

1. Берете любую другую машину, которая есть у вас в распоряжении и которая может работать не выключаясь.
2. Ставите на нее копию Ирбиса, загружаете туда базу и запускаете создание словарей
3. когда через несколько дней база словари создадутся, копируете папку базы (Внимание! только одной этой базы, а не всех!!!) на флешку, переносите ее на основной сервер и вставляете ее с заменой файлов

из-за того что не могу остановить работу ирбиса, а за один день не успеваю все подготовить для перехода на новую версию, поэтому и установила новый ирбис на простом компьютере, чтобы все сделать не останавливая процесс в работе библиотеки. Потом хотела тупо перенести папку ирбис целиком на сервер, заранее конечно установив на нем новую версию. На это мне хватило бы 1 дня.

Придется делать по 2 варианту предложенному Вами :) Спасибо!

У меня еще один вопрос: клиентские армы версии 2017 могут работать с новой версией? У нас 24 филиала разбросаны по городу, быстро обновить не получится.

> У меня еще один вопрос: клиентские армы версии
> 2017 могут работать с новой версией?
Нет.

Ольга, в вашей ситуации с филиалами в любом случае нужно менять подход. Есть несколько разных подходов к управлению версиями АРМов на клиентских компьютерах.

1. Если у вас все компьютеры в локальной сети, то можно сделать следующее:
а) на сервере делаете папку, в которую копируете только исполняемые модули клиентов и библиотеки (dll)
б) делаете папку сетевой, но с доступом по паролю и с правом ТОЛЬКО на чтение
в) на всех компьютерах пользователей в планировщик заданий добавляете пакетное задание, которое раз в день при первом включении компьютера будет копировать файлы из сетевой папки на свой компьютер. В идеале можно добавить проверку, что бы копировались только файлы, которые отличаются от исходных.

В таком случае вам достаточно любые новые обновления скопировать на сервере в одну папку, а на следующий день при включении компьютера все обновления перенесутся всем пользователям.

2. Если компьютере работают с подключением через Интернет, то в качестве источника обновлений можно использовать Гугл-диск/Яндекс-диск и специальное ПО для синхронизации файлов. Только нужно будет отключить синхронизацию ини-файлов, иначе у вас пользователи будут жаловаться на сбитые персональные настройки связанные с размерами АРМов, окон, выбранных в текущей сессии режимов и т.д.

3. Так же очень рекомендую на всех без исключения компьютерах держать ПО для удаленного управления, что-то типа VNC, AnyDesk, TeamViewer. Последний платный, но я чаще им пользуюсь, AnyDesk в большинстве случаев меня устраивает.

Почему стоит сделать вот эти операции? Кроме того, что раз в год выходит новая версия, и при этом однозначно нужно делать установку новых АРМов, в течении этого года выходят промежуточные обновления. Их чаще всего бывает где-то до 10. Каждый раз объезжать все филиалы - утомительное занятие.

Gena, Спасибо огромное за развернутые ответы

Gena написал(а):
-------------------------------------------------------
> Ольга, могу предложить вам немного другой подход.
> Я так понимаю, что загрузить длительной работой с
> базой в 2 000 000 основной сервер вы не можете.
> Потому что станут все остальные процессы. Если
> так, то этот процесс можно разбить следующим
> образом:
>
> 1. На основной сервер ставите новую версию
> 2. Создаете базы данных для своих записей (по
> списку старых баз)
> 3. Переносите свои настройки (ини, мну, раб.листы,
> словари и т.д.)
> 4. Загружаете все основные базы, кроме большой
> базы на 2млн записей
> 5. Запускаете сервер в работу и ваши коллеги
> начинают выполнять повседневные задачи (создание
> записей, выдачу литературы и т.д., кроме операций
> с базой МАРСа!)
> 6. загружаете базу МАРСа в созданную базу
> 7. В ини-файле АРМа Администратор ставите
> ограничение на количество одновременных потоков
> создания словарей. Ограничение нужно поставить
> меньше, чем у вас ядер на сервере, что бы всегда
> оставались свободные ядра для работы
> библиотекарей. Например, если у вас сервер на 8
> ядер, поставьте ограничение на 4 ядра. Тогда при
> создании словарей АРМ Администратор создаст только
> 4 потока, он будет создавать словарь медленнее, но
> позволит при этом работать остальным
> пользователям.
>
> Да, при этом у вас начнется работа у всех, кто не
> связан с этой базой, но это по крайней мере даст
> возможность работать.
>
>
> Другой вариант, без перенастройки АРМа
> Администратор
> Делаете как и выше все пункты 1-5, а потом
> создаете пустую базу для МАРСа и временно
> останавливаетесь.
>
> 1. Берете любую другую машину, которая есть у вас
> в распоряжении и которая может работать не
> выключаясь.
> 2. Ставите на нее копию Ирбиса, загружаете туда
> базу и запускаете создание словарей
> 3. когда через несколько дней база словари
> создадутся, копируете папку базы (Внимание! только
> одной этой базы, а не всех!!!) на флешку,
> переносите ее на основной сервер и вставляете ее с
> заменой файлов

Гена, извини, но при всем уважении я не сильно понимаю, чем это предложение принципиально отличается от того, что делалось Ольгой (на отдельном компьютере почти 16 часов создавался словарь отдельно взятой БИБЛИОГРАФИЧЕСКОЙ (не полнотекстовой) БД...).
Создавать словарь вместо 16 часов 32 часа это сомнительное удовольствие...

В остальном ты прав, нужно автоматизировать процессы обновления файлов.
Хорошо бы расширить функционал Deposit_user, который если правильно понимаю историю вы с Максом Панёвым выпросили у Александра Иосифовича лет 10 назад (за что всем большое спасибо!). Хорошо бы этот принцип на все прочие директории распространить (использовать файлы из {имя директории}_user, а затем из {имя БД} и потом из Deposit, если не нашли).
тогда бы можно было облегчить обновление и переходы на новые версии.
Если перенести все общие файлы для БД ЭК/ЭБ в Deposit, то еще проще бы стало работать. Но это уже мечты...

В ситуациях, подобных той, которую описала Ольга мне кажется нужно решать проблему кардинально, изучив ситуацию и условия подробнее.
К примеру, если БД содержит только аналитические описания по проекту МАРС, то стоит исключить из IFS/FST файлов лишние сценарии. Насколько знаю, коллеги в ГУНБ Краснярского края и ГПНТБ СО РАН (у них многомиллионные Бд) именно так и поступают. Одно только это уже в разы сократит время создания словаря для БД в 2 млн. записей.

Один раз стоит адаптировать настройки одной отдельно взятой БД (или нескольких БД).

Далее по ресурсам - возможно (если не применяется профессиональный RAID массив) стоит для таких целей использовать SSD диск (это также ускорит процесс импорта записей и создания словарей, если до этого использовался обычный HDD).

Для того, чтобы процедуры установки обновлений или переход на новую версию протекали быстрее и автономно (без необходимости вручную запускать процедуры для каждой БД: создание новых БД по образцу существующих, импорта записей и создания словарей) стоит один раз подготовить файлы пакетных сценариев (IBF) и подготовив нужные файлы запускать нужные процедуры сценарием CMD один раз, получив по его завершении письмо по электронной почте об окончании выполнения.

Самый простой пример в приложении.

- Файл формата (report_email.pft) надо переместить в Deposit,
- создать для АРМ администратор учетную запись с нужными логином и паролем (в примере mail - mail) c профилем для клиентского АРМ администратор - REPORT_EMAIL.ini,
- задать параметры электронной почты в REPORT_EMAIL.ini,
- скорректировать файл REPORT_EMAIL.ibf, указав нужные параметры (заголовок, адрес на который слать письмо, тему)
- скорректировать пути в ярлыках.

Запускать нужно файл reloaddb.cmd

Пути и состав команд можно и нужно настраивать под конкретные сценарии и задачи.

P.S. при тестировании функционала irbistool мы с коллегами убедились в том, что все это происходит ЕЩЕ элегантнее и главное - ГОРАЗДО БЫСТРЕЕ!!!
возможности расширенного языка форматирования XPFT просто потрясающие!
Поэтому ждем выпуска всего этого великолепия с нетерпением, прямо как те психи, что ждут выпуска нового айфона, занимая очередь за неделю под стенами официального шопа.



Редактировано 3 раз. Последний раз 22.10.2020 01:54 пользователем А. Роман.

> P.S. при тестировании функционала irbistool мы с
> коллегами убедились в том, что все это происходит
> ЕЩЕ элегантнее и главное - ГОРАЗДО БЫСТРЕЕ!!!
> возможности расширенного языка форматирования XPFT
> просто потрясающие!
> Поэтому ждем выпуска всего этого великолепия с
> нетерпением, прямо как те психи, что ждут выпуска
> нового айфона, занимая очередь за неделю под
> стенами официального шопа.

Небольшое замечание. Все это "великолепие" (без всякой иронии) очевидно будет реализовано в ИРБИС128, в серверной части под Linux, в каком-то новом продукте, но не в том, который сейчас называется ИРБИС64+ (имеется в виду серверная часть ИРБИС64+ под Windows)

Здравствуйте!
Проблема в АРМ Каталогизатор - при совместной работе на двух серверах – в ИРБИС_плюс в.19 и ИРБИС в.15 :
Для работы в Каталогизаторе с корпоративными базами мы прописываем их в списке доступных баз наряду со своими - в dbnam2.mnu, указывая имя БД и ip-адрес другого сервера (корпорации КСОБ).
Хотя Александр Иосифович и писал когда-то, что это устаревший способ, до перехода на ИРБИС_плюс он работал корректно и удобно:
В версии 15 ИРБИС– работа в одном АРМе Каталогизатор с базами разных серверов корректна:
- данные в полях записи ЭК КСОБ видны полностью,
- сами записи выводятся на просмотр корректно, в т.ч. в области кратких описаний,
- в корпоративной базе корректен просмотр и выбор в поле терминов из Авторитетных файлов КСОБ.

Ноябрь 2020 - библиотека перешла на ИРБИС_плюс 19 версию, а в КСОБ остаётся ИРБИС ~ версия 15.

Теперь проблемы при переходе в одном АРМе Каталогизатор на базы КСОБ:
- данные в полях записей ЭК видны НЕ полностью, например, не виден код РЛ (хотя он есть),
и соответственно,
- записи в области кратких описаний и на просмотр выводятся НЕ корректно, в упрощённом РЛ,
- при попытке ввести термин из Авторитетных файлов КСОБ – в словаре выводятся пустые строки и такой термин ввести в поле проблематично.

Примеры, как это выглядит, можно посмотреть в файле.
Вопрос:
что мы можем сделать для корректной совместной работы в одном АРМе Каталогизатор ИРБИС_плюс в.19 и ИРБИС в.15?

Извините, не прикрепила файл

БД версии 2017 и ниже НЕСОВМЕСТИМЫ с БД версии 2018 и выше. Т.е. в Каталогизаторе НЕЛЬЗЯ одновременно работать с БД 2017 и ниже и БД 2018 и выше.