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 пользователем А. Роман.