19.04.2024
С 2022 года количество отечественных программных решений стремительно растет (в 2022 году в реестр российского ПО включили 3728 решений, а в 2023 — уже 4333). При этом многие компании не переходят на импортонезависимые аналоги: на иностранный софт было потрачено много денег, а внедрение нового несет за собой непредсказуемые риски.
В то же время импортонезависимые решения выгодны в долгосрочной перспективе, так как в случае ужесточения санкций или внедрения новых законов бизнес не пострадает. С какими ошибками можно столкнуться при миграции (например, при переходе с Windows + Microsoft SQL Server на Astra Linux 1.7 + Postgres Pro Standard 13) и как их избежать, расскажет Валерий Лямо, руководитель практики ИТ и сервисов ALP Group.
С нехваткой памяти на устройствах или в облачных хранилищах сталкивались многие. Часто достаточно либо увеличить память, либо удалить ненужные файлы. При переводе баз данных на новое ПО нередко возникает похожая проблема, но решение будет более замысловатым.
Рассмотрим конкретный случай. В импортонезависимое окружение была загружена база данных в виде файла формата .dt, взятая со старого софта. После этого появилась ошибка 54000 — «Нехватка памяти. Не удалось увеличить строковый буфер». Первым решением было увеличить размер памяти и поменять настройки операционной системы и системы управления базами данных. Однако это не дало результатов. После анализа логов в процессе загрузки был выявлен запрос к конкретной таблице (InfoRg<>...). Оказалось, в указанной таблице был тяжелый файл (более 1 Гб), при этом максимальный размер данных в одном поле таблицы на Postgres Pro — 1 Гб. После удаления «виновника» все заработало.
Такая ошибка возникла из-за того, что в Microsoft SQL ограничение по размеру больше — 2 Гб. Первый способ решить эту проблему — проверить размер файлов в базе данных при перемещении ее в независимое окружение и установить ограничение на размер файла на будущее. Второй — хранить прикрепляемые файлы в томах на диске.
При тестировании базы данных 1С и прикрепленных файлов, хранящихся, как следует, в томах, файлы все равно могут не открываться. Причина этому не в длине файлов, как может показаться, а в длине их названий. В Astra Linux имя файла не должно превышать 100 кириллических символов (да, ограничение распространяется только на кириллицу). Ошибка кажется простой, но она может отнять у разработчиков неделю рабочего времени. Запуск автоматического переименования файлов с помощью соответствующей обработки решит проблему. Избежать же ошибки просто: установите внутрикорпоративный стандарт по формату файлов.
Длина названия не единственная проблема, которая может возникнуть с именем файла. Даже после стандартизации названий, часть файлов может не открываться. Тогда стоит обратить внимание на знаки препинания в именах, а именно — на точки. Если для Microsoft SQL точка в начале названия — просто символ, то для Astra Linux она означает «скрытый файл». Получается некий «эффект бабочки»: даже небольшая точка может в будущем отнять много времени. Чтобы избежать этой проблемы, нужно добавить в корпоративный стандарт названий запрет начинать их с точки.
Для проверки работы системы в импортонезависимом окружении используется встроенная подсистема «Тест-центр». Она является кроссплатформенной, то есть работает как с Windows, так и с Linux, однако для последнего версия «Тест-центра» должна быть самой актуальной. Иначе при проведении многопользовательских нагрузочных испытаний будет возникать ошибка из-за невозможности подключить внешнюю компоненту.
Когда вы уже перевели систему в импортонезависимое окружение, следующий шаг — проверить работу базы данных с популярной у корпоративных заказчиков BI-системой (QlikView). Если в названиях используются разные регистры, система не будет видеть ранее загруженные исторические данные. Например, вы хотите проанализировать, сколько у сотрудников уходило времени на выполнение задач в разные периоды, но видите отчет только за текущий день. Система воспринимает строчные и заглавные регистры как разные. Для QlikView названия «91bf0050560118ed11ec5f348a440a01» и «91BF0050560118ED11EC5F348A440A01» ID объектов — отдельные сущности. Эта проблема решается унификацией регистров. Примечательно, что ошибка изначально появилась, потому что при загрузке в Postgres Pro идентификаторы объектов во всех справочниках и документах не были автоматически преобразованы из верхнего регистра (стандарт Microsoft SQL) в нижний. В результате в BI-системе возник конфликт между старой и новой информацией.
Иногда отечественное ПО может выдавать непонятные формулировки ошибок. «Целое вне диапазона» — одна из них. При обработке аналогичного пользовательского сценария в Windows-среде ошибка становится более понятной: «У пользователя недостаточно прав на исполнение операции над базой данных». Это означает, что у воображаемого пользователя есть ограничения в системе на уровне записей (Raw Level Security). Следовательно, пользователь пробует работать с таблицами, на которые у него нет прав, и возникает ошибка. Для решения этой проблемы необходимо корректно настроить доступ профилей и групп в базе с импортонезависимым окружением.
Такая ошибка актуальна, если в исходной системе у вас заложена функция исключения при попытке осуществления отдельных регламентных заданий. С этой функцией при попытке обмена данными с другой системой срабатывает специальная ошибка со стороны безопасности, сигнализируя пользователю, что прав на выполнение этой операции у него нет.
В Linux команда «ВызватьИсключение» осуществляется некорректно: при срабатывании ошибки происходит зависание фонового задания, что приводит к невозможности входа в конфигуратор базы данных системы. Чтобы решить проблему, нужно переписать часть кода, чтобы команда «ВызватьИсключение» в рамках работы фонового задания не запускалась.
Значение NULL символизирует отсутствие данных, оно полезно при сортировке. В Microsoft SQL все поля с NULL автоматически уходят вниз таблицы, а в Postgres Pro — перемещаются наверх. Эта разница становится существенной, если речь идет, например, о таблице с задачами на выполнение. Задачи должны быть отсортированы по убыванию приоритета, но при переносе таблицы в Postgres Pro вверху окажутся поля с отсутствием данных.
Решение этой проблемы несложное: необходимо найти все поля со значением NULL с помощью конструкции ЕСТЬNULL. Таким образом, вы получите корректный результат вне зависимости от используемой системы управления базами данных.
Из приведенных выше ошибок видно, что половина из них решается с помощью простого обучения сотрудников, другая же лежит в зоне ответственности разработчиков софта. Это объяснимо: российское ПО еще молодое, и, соответственно, у разработчиков было мало времени для выявления багов. Однако это не значит, что перехода на импортонезависимый софт стоит опасаться. Проблемы не требуют сложных системных решений — опытные компании-интеграторы быстро их устранят. Если с самого начала обратиться к опытному подрядчику, то подобных ошибок и вовсе можно будет избежать. Это сэкономит деньги, время и ресурсы.
