ADG Оставить заявку
Блог Данные и аналитика 4 мин чтения

Oracle XE: бесплатная база данных с Oracle-совместимостью для небольших учётных систем

Oracle Database XE вышел как бесплатная редакция с лимитом 4 ГБ данных и 1 ГБ RAM. Мигрировали две учётные системы с MS Access - разработчики наконец перестали ругаться.

Контекст момента

Oracle Database XE (Express Edition) выходит как бесплатная редакция с ограничением 4 ГБ данных и 1 ГБ RAM

Несколько клиентов в последние месяцы приходили с одним и тем же запросом: хотим Oracle, потому что головной офис или партнёр работает на нём, нужна совместимость на уровне SQL и процедур - но платить за лицензию Standard Edition не готовы и не могут обосновать бюджет. Обычно в таких случаях мы разговаривали про PostgreSQL как разумную альтернативу. Но Oracle XE закрыл этот разговор иначе.

Что такое Oracle XE

Oracle Database Express Edition - бесплатная редакция, которую Oracle выпустил в прошлом году. Ограничения понятные: не более 4 ГБ пользовательских данных, не более 1 ГБ используемой RAM, один процессор. Устанавливается без лицензионного ключа, можно использовать в продакшене. Лицензия не разрешает перепродажу и использование в качестве инфраструктуры для SaaS, но для внутреннего учёта в небольшой компании - вполне.

Важная деталь: это настоящий Oracle, не какая-то облегчённая переделка. PL/SQL, sequences, materialized views, синтаксис запросов - всё работает так же как в Standard или Enterprise Edition. Миграция SQL-кода между XE и старшими редакциями - не квест.

Два кейса, которые мы закрыли

Кейс первый - торговая фирма. Учёт отгрузок и взаиморасчётов жил в нескольких связанных файлах Access. Классическая история: Access держался потому что «всё работает», но при росте числа пользователей начал сбоить, а общий файл по сети периодически портился при одновременном редактировании. Данных было немного - за несколько лет учёта хорошо если 200 МБ, поэтому лимит в 4 ГБ здесь даже не обсуждался.

Кейс второй - небольшое производство. Там была самописная система учёта материалов и заказов, написанная под Access-овый движок, с несколькими VBA-макросами для формирования отчётов. Разработчик, который её писал, хотел переехать на нормальную базу, но клиент не был готов платить за Oracle SE.

В обоих случаях объём данных укладывался в ограничения XE с большим запасом. RAM на серверах по 2-4 ГБ - выделить гигабайт под Oracle не проблема.

Как шла миграция

Переезд с Access на любую реляционную базу - это не просто экспорт таблиц. Access позволяет себе вещи, которые нормальная СУБД не терпит: имена полей с пробелами, таблицы без первичных ключей, типы данных вроде OLE Object, связи которые существуют только в мозге разработчика но не в схеме.

Первый шаг в обоих проектах - инвентаризация того что есть. Прошлись по каждой таблице, описали структуру, нашли места где связи предполагались но не были формализованы. В Access это встречается часто: два поля с одинаковым смыслом в разных таблицах, связь через код клиента, который хранится как текст с возможными пробелами.

Дальше - создание схемы в Oracle XE. Здесь PL/SQL Developer (бесплатной версии хватило) и штатный веб-интерфейс XE на порту 8080 использовались параллельно. Веб-интерфейс у XE простой, но для базовой работы с объектами и запросами достаточный - не надо ставить полноценный Oracle Client, что упрощает жизнь если работаешь с удалённой машиной.

Перенос данных делали через ODBC: Access как источник, Oracle XE как приёмник. Несколько итераций чтобы разобраться с кодировками и типами. Даты в Access - отдельная история: формат хранения другой, при экспорте через некоторые инструменты можно получить смещение на несколько дней. Проверяли руками на выборке.

В первом проекте уложились в три рабочих дня вместе с тестированием и переключением. Во втором - около недели, потому что там VBA-логика требовала переноса в PL/SQL-процедуры, и разработчик параллельно переписывал клиентскую часть.

Что в итоге

Ограничения XE в данных кейсах не являются проблемой. 4 ГБ для учётных задач небольшого предприятия - это много. Один процессор - тоже не узкое место при 10-20 одновременных пользователях и транзакционной нагрузке. Ограничение RAM в 1 ГБ надо держать в голове: если на том же сервере стоит что-то ещё, нужно следить за общим потреблением.

Разработчики в обоих проектах явно повеселели. PL/SQL после Access VBA - это другой уровень инструмента. Нормальные транзакции, нормальные индексы, EXPLAIN PLAN который что-то показывает, возможность писать хранимые процедуры без страха что база-файл заблокируется при сохранении.

Клиенты со стороны получили то, что хотели: Oracle-совместимую базу без лицензионных затрат. Если через несколько лет данные дорастут до лимита или понадобятся RAC и Partitioning - переход на Standard Edition будет прямым, без переписывания кода.

Интеграция и миграция данных между системами в таких проектах начинается с аудита того, что есть. Access как промежуточная ступень в истории многих учётных систем - явление распространённое, и правильный выбор целевой платформы определяется не только техническими критериями, но и тем, с какой экосистемой работают смежные команды.

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.