Часто задаваемые вопросы по OpenEdge RDBMS
II. Основные вопросы
5. Что плохого в использовании старых версий OpenEdge?
Есть два ответа.
Ответ №1. В зависимости от того, что вам нужно. Для многих людей, использование последней версии OpenEdge важно потому, что:
- Новые версии содержат множество новых и полезных функций, возможностей языка, базы данных и в прочих областях. Несколько примеров: новые типы данных, шифрование базы данных, аудитинг, области хранения данных второго типа, поддержка больших ROWID, поддержка веб-сервисов, объектное программирование, .NET UI, и драйвер JDBC 4, и всё это только в 10.2B. Версия 11.x содержит еще больше.
- Новые версии почти всегда содержат улучшения производительности, которые часто можно использовать без каких-либо изменений в вашем приложении.
- Новые версии активно поддерживаются службой поддержки Progress Software (PSC) и инженерной группой OpenEdge. Исправление ошибок и выпуск обновлений (Service Pack) выполняются на регулярной основе.
- Даже если служба поддержки PSC сможет ответить на вопросы и попытается найти обходной путь для проблемы, старые версии никогда не получат обновлений или исправления ошибок. Детальные знания о старых версиях со временем забываются, как в самой PSC, так и среди большого сообщества пользователей. (За исключением Юрия Потемкина, который никогда ничего не забывает)
- Новые релизы работают лучше на новых версиях операционных систем. В то время как старые версии OpenEdge могут совсем не работать на таких ОС (пример, Progress 9 не работает на Windows 7 или Windows 8).
- Переход на новую версию с текущей версии выполнить намного проще, чем сделать переход с очень старых версий.
- Архитектурные лимиты в новых версиях намного выше, чем в их предшественниках (например, увеличены максимальное количество rowid в области, максимальное размер индекса, размер сегмента r-кода, максимальная ширина окна и т.п.).
Ответ №2. «Если это работает, не трогай это» – мы все помним эту старую поговорку. Но, тем не менее, что будет, если то, что работает нормально сейчас, не сможет удовлетворить вашим потребностям спустя несколько лет? Многие системы содержат программное обеспечение, созданное разными компаниями. В конечном итоге эти компании прекращают поддержку старого программного обеспечения (Политика жизненного цикла Progress исторически подразумевает поддержку основных версий (например, 8, 9, 10) в течение, как минимум, пяти лет. Версии 9 и 10 поддерживались гораздо дольше, чем 5 лет.) и железа, или же, они станут взимать плату за продолжение поддержки, завышенную в десятки раз. Затраты могут подняться, даже в случае, если вы ничего не меняете и ничего у вас не выходит из строя.
6. Какая самая последняя версия OpenEdge?
Последняя версия OpenEdge 11.5, вышла в декабре 2014 года.
7. Какой номер последнего обновления для версии 10-ой серии?
Последнее обновление 10.2B08. Это последнее обновление для данной версии – больше обновлений для OpenEdge 10 не будет (!)
8. Какой последний релиз для версии 9-ой серии?
9.1E04. Выпущена в апреле 2006 г., это финальный релиз. Первый релиз 9-ой серии (9.0A) был выпущен в декабре 1998 г. Если вы используете 9.1E или более раннюю версию, вы определенно должны выполнить обновление.
9. В чем разница между редакциями OpenEdge RDBMS Workgroup и Enterprise?
Редакция Workgroup предназначена для использования в инсталляциях, в которых количество пользователей не более 30, размер базы данных достаточно мал, и требования к производительности незначительны. Редакция Workgroup имеет следующие ограничения:
- Максимальное количество одновременных подключений к базе данных 65. Это подразумевает: 5 фоновых процессов и по 2 подключения для каждого из 30 пользователей (1 для приложения и 1 для инструментов запросов и отчетности). Ограничение в 65 подключений, это жесткое ограничение.
- Максимально рекомендуемые размер базы данных примерно 5 Гб. Это не жесткое ограничение.
- Максимальный размер экстента базы данных 2 Гб. Это жесткое ограничение. Область данных и область Primary Recovery (Before Image Log) должны разделяться экстентами по 2 ГБ (или меньше).
- Размер блока базы данных не может быть выбран при создании новой базы данных. С тех пор, как размер блока по умолчанию был увеличен, это теперь не важное ограничение.
- Нельзя использовать фоновые процессы ввода/вывода Asynchronous Page Writers, Before-Image Writer и After-Image Writer (Тем не менее, механизм After-Imaging можно использовать, и так было всегда.) .
- Чекпоинты (Checkpoints) синхронные, а не асинхронные. Это означает, что вы не можете использовать размер кластера Before-Image больше чем 128 Кб, так как синхронные чекпоинты происходят каждый раз, когда кластер заполнен. Чем больше размер кластера, тем больше будет нагрузка ввода/вывода в конце чекпоинта. Размер кластера по умолчанию 512 Кб.
- Нельзя использовать параметры конфигурации –spin, -nap и –napmax.
- Нельзя использовать параметр конфигурации альтернативного буферного пула (-B2). Любые таблицы и индексы, которым указано использовать альтернативный буферный пул, будут проигнорированы, и для них будет использоваться только первичный буферный пул.
- Использование параметра конфигурации –semsets не допускается.
- Использование NFS для хранения базы данных не допускается.
- Использование функции Quiet Point для выполнения раздельного зеркального резервного копирования (split-mirror backup) и выполнения резервного копирования созданием снимков файловой системы (snapshot backup) не допускается
- Функция шифрования базы данных Transparent Data Encryption недоступна.
- Функция кластерного менеджера Failover Cluster недоступна.
- Возможность участия в распределенных транзакциях, охватывающих множественные X/Open XA ресурсы с использованием JTA (Java Transaction API) недоступна.
- Для релизов старше 10.1B функция репликация базы данных (OpenEdge Replication) недоступна.