Соображения по переходу с Oracle на другие платформы RDBMS
Программное обеспечение Oracle известно как сложное, дорогое и даже громоздкое. Тем не менее, хотя унаследованные системы управления базами данных (СУБД), такие как Oracle, часто становятся разочаровывающими - во многих случаях из-за корпоративной инерции и изнашиваемости - недавний взрыв в основных базах данных с открытым исходным кодом (OSDB) быстро меняет эту динамику.
Больше, чем когда-либо прежде, организации, ранее принадлежавшие к монолитной системе Oracle, теперь серьезно ставят под сомнение свои клятвы. Потенциальная экономия затрат на лицензионные сборы, упрощение поддержки и снижение эксплуатационных расходов, а также стремление упростить платформу данных - все это является серьезным фактором, стимулирующим другие коммерческие или открытые СУБД, такие как MySQL, PostgreSQL или Microsoft SQL Server.
Но насколько легко перейти на альтернативную платформу, сохраняя при этом те же функциональность, надежность и производительность, а также экономя на затратах?
Ключевые моменты для рассмотрения
Есть три ключевых момента, которые в общем смысле могут сделать такие преобразования технически сложными:
- База данных Oracle в большинстве случаев является расширенным набором функций, предлагаемых альтернативами.
- Ни одна из альтернативных СУБД точно не соответствует архитектуре Oracle
- Изменение ваших приложений для работы с новым движком может потребовать даже больше работы, чем сама передача данных, включая изменения кода, изменения драйверов и т. д.
Вот почему для вашей организации очень важно тщательно оценивать как ваши текущие, так и желаемые системы.
Почему важно провести анализ TCO
Обязательным является проведение подробного анализа совокупной стоимости владения (TCO) как вашей текущей платформы Oracle, так и желаемой альтернативы экспертами в Oracle и желаемой целевой платформе. Поскольку преобразования Oracle могут показаться относительно простыми, они нередко тратят много лет усилий на завершение работы и стоят миллионы долларов - особенно если они плохо спланированы.
Ваш анализ должен выходить за рамки простого подсчета типов объектов. Уровень сложности имеет большое значение. Мы предлагаем провести более глубокий анализ с использованием таких инструментов, как Microsoft SQL Server Migration Assistant (SSMA) или Ora2Pg.
Также очень важно учитывать возможность тестирования (это может быть относительно легко, если вы используете, например, методы и инструменты DevOps CI / CD, но если нет, то это может оказаться еще одним значительным расходом), наряду с ожидаемыми усилия по переводу кода для вашей желаемой платформы. (PostgreSQL и MariaDB имеют схожие программные языки, которые могут минимизировать усилия по переводу кода, в то время как Transact SQL в Microsoft SQL Server сильно отличается).
Другие сложности, которые могут вызвать проблемы
Наряду с оценкой требований к функциональности и производительности организации упускают из виду, если они также не оценивают нефункциональные требования, такие как:
- Возможность восстановления: Oracle предлагает несколько функций, разработанных для администраторов баз данных для отката базы данных в случае ошибки, но большинство других платформ предлагают только некоторые из этих функций.
- Безопасность. Такие функции, как собственное редактирование базы данных, сжатие или надежный аудит, не всегда доступны на других платформах, а Oracle Database Vault просто недоступен.
- Поддержка: необходимость платить ежегодные сборы за обслуживание может быть непростой задачей, но есть и преимущества: вы можете открыть неограниченное количество тикетов и рассчитывать на поддержку Oracle в случае катастрофической ошибки.
- Доступность. Другие платформы часто имеют ограниченные возможности онлайн-обслуживания или зависят от внешних сторонних инструментов.
Почему облако может быть лучшим вариантом
Хотя это и не панацея, миграция в облако, в частности облако второго поколения Oracle, известное как Oracle Cloud Infrastructure (OCI), могла бы стать более надежным (и менее разочаровывающим) способом.