Читать статью полностью в pdf-формате
Предположим, что перед Вами встала во всей неотвратимости задача отказаться от любимой СУБД Oracle (или MS SQL Server) и начать использовать одну из «российских СУБД». Почему Вы вдруг можете оказаться в такой ситуации? Ну, например, из-за вступления в силу Федерального закона 188-ФЗ и связанного с ним постановления Правительства РФ №1236 «Об установлении запрета на допуск иностранного программного обеспечения при закупках для государственных и муниципальных нужд». Или из-за того, что ИТ-бюджет Вашей организации был составлен в рублях и Ваше руководство не готово его пересматривать, невзирая на существенное изменение стоимости поддержки иностранного ПО. Каковы будут Ваши первые действия?
Мы в компании Диасофт уже прошли этот путь (наша линейка банковского ПО теперь может работать без использования зарубежного системного ПО и, в частности, без использования зарубежных СУБД). И мы готовы поделиться с Вами накопленным нами опытом.
Для начала рекомендуем Вам проверить Реестр отечественного ПО . Там, отфильтровавшись по классу «Системы управления базами данных», среди множества вряд ли подходящих Вам вариантов, Вы сможете найти три более или менее приемлемых для замены Oracle (или MS SQL) альтернативы:
- форк СУБД PostgreSQL от компании Postgres Professional;
- созданную на базе СУБД Firebird, российскую СУБД «Ред База Данных»;
- 100% российскую СУБД ЛИНТЕР от воронежской компании РЕЛЭКС.
Мы не будем пытаться рекомендовать Вам какую-то одну из них (они все по-своему хороши, да простят нас их разработчики). Сами мы такой выбор делать отказались и в итоге научили свою банковскую линейку работать с каждой из них, но это во- многом связано с тем, что мы разработчики тиражируемого ПО и поэтому должны поддерживать разнообразие вкусов своих конечных заказчиков. Возможно, что у Вас ситуация другая и Вы сможете выбрать какую-то одну из них.
Но муки выбора между тремя весьма неплохими вариантами на роль Вашей «новой любимой СУБД» - это ничто, по сравнению с тем, что ждет Вас впереди.
Эффект от резкой вынужденной смены СУБД нельзя описать словами, их глубины все равно для этого не хватит и тот кто не испытал это на себе вряд ли поймет. И единственное средство пережить это и не сломаться — это сжать крепче зубы и завершить процесс миграции как можно быстрее.
И в этом Вам поможет наш комплекс технических средств для автоматизированной миграции приложений — Diasoft Database Adapter.
Для начала, Вы можете использовать входящую в продукт компоненту DB Migrator. Ее предназначение — это подключившись к исходной БД создать максимально эквивалентную ей по структуре БД в целевой СУБД, скопировать данные, перенести информацию о пользователях и их правах, а также сконвертировать в диалект целевой СУБД те хранимые процедуры, триггеры, функции и пакеты, которые могли существовать в Вашей исходной БД. Весьма вероятно, что выразительных средств целевой СУБД не хватит для того, чтобы впитать в себя всю мощь Вашего многолетнего творчества с использованием всех возможностей PL/SQL и служебных пакетов Oracle (T-SQL и расширенных хранимых процедур MS SQL Server) и потому DB Migrator придется установить на Вашу целевую СУБД набор дополнений и расширений, которые немного сгладят пропасть между «дополнительными возможностями», которые есть в каждой СУБД поверх предписанного стандартами. Наш DB Migrator — весьма умная утилита. Она знает грамматику диалектов каждой из поддерживаемых ею СУБД и потому свободно разбирает все, что Вы могли написать за годы творчества. Также она обучена широкому набору правил, позволяющих изобразить отсутствующие в целевой СУБД возможности исходной (к примеру, как изобразить «табличные типы» там, где их от рождения не было или как бороться с древовидными запросами, которые могли быть предусмотрены в БД Oracle).
Когда DB Migrator закончит свою работу, Вам останется совсем немного, чтобы «довести до ума» подготовленную им целевую БД.
Однако это лишь полпути - вряд ли Ваше приложение сразу заработает в новых условиях. Вероятнее всего, Вам придется что-то с ним сделать, чтобы «уговорить» его работать с СУБД PostgreSQL вместо Oracle или с ЛИНТЕР вместо MS SQL Server.
Вариант «переписать все запросы», мы не будем сбрасывать со счетов (иногда это совсем пустяк по сравнению с уже проделанной DB Migrator работой по конвертации сотен тысяч строк хранимых процедур, написанных на диалектах Oracle или MSSQL). Однако воспользоваться им можно лишь тогда, когда исходники приложения Вам доступны.
А если нет? А если Вам необходимо пересадить на новую СУБД продукт, от которого у Вас есть только бинарники? Или один или несколько таких продуктов смотрит в БД Вашего приложения напрямую или через db-link? Если кто-то (и может быть даже Вы) решал таким образом задачи интеграции между несколькими приложениями? А может быть у Вас просто нет времени или специалистов, чтобы возиться с переписыванием запросов в Вашем приложении с доступными для редактирования исходниками, а результат необходимо получить как можно быстрее? Тогда на помощь Вам придет DB Proxy — еще одна компонента в составе Diasoft Database Adapter.
В отличие от DB Migrator, который нужен лишь на время миграции, компонента DB Proxy работает в runtime. Она отвечает за то, чтобы приложения, рассчитывающие на работу с Вашей исходной БД смогли заработать на целевой.
Компонента DB Proxy виртуозно умеет изображать из себя развернутый в Вашей сети экземпляр СУБД Oracle (или MS SQL Server). Она делает это настолько ловко, что большинство приложений не в состоянии разобрать такую подмену. И потому с удовольствием работают с DB Proxy, считая что по-прежнему работают с исходной СУБД.
Получив запрос от приложения, компонента DB Proxy «на лету» разбирает запрос на составные части диалекта и параметры, подбирает для него функциональный аналог из целевой СУБД, собирает в синтаксисе нового целевого диалекта, отправляет запрос на целевую СУБД где происходит его выполнение, а возвращаемые результаты отдает приложению. Более того, эта компонента способна к самообучению. Она «на лету» преобразует все «незнакомые» ей запросы и запоминает результаты трансляции, а вот если SQL-запрос c точностью до параметров или констант совпал с уже «знакомым», то замена и вовсе будет мгновенной — оттранслированный вариант запроса будет взят из специальной таблицы в оперативной памяти. А потому в ситуации, когда все приходящие из Вашего приложения запросы уже «знакомы» этой компоненте, она работает очень быстро — практически ничего не добавляя к обычному времени исполнения запроса. И только при появлении «незнакомого» запроса проводится его глубокий анализ и преобразование. При этом DB Proxy «знает» о преобразовании диалектов и функциональных возможностей различных СУБД ничуть не меньше, чем DB Migrator. А потому даже сложные приложения, динамически создающие запросы к БД или использующие в них «дополнительные возможности», предоставляемые исходной СУБД поверх стандартов, будут работать через DB Proxy с целевой БД не хуже чем с исходной.
Разумеется, обе компоненты, DB Proxy и DB Migrator, можно использовать как совместно, так и раздельно. Мы сделали их для того, чтобы облегчить жизнь тем, кому нужно быстро мигрировать на СУБД из реестра отечественного ПО. Они слажено работают друг с другом, и вместе способны радикально снизить трудозатраты и сроки проекта миграции.
Мы опробовали их на самых разных приложениях, как собственного производства, так и разработанных сторонними разработчиками, и остались довольны результатами. Возможно, что и Вам использование этих компонентов нашего Diasoft Database Adaptor сильно облегчит жизнь. И, разумеется, мы непрерывно совершенствуем набор правил миграции для поддержки тех сложных случаев, с которыми нас иногда знакомят жизнь и наши клиенты. Поэтому каждая последующая версия нашего продукта знает все больше правил по миграции приложений между различными СУБД.
Для получения подробной информации по продукту «Database Adapter» свяжитесь с нами по форме обратной связи.
Успешной миграции!!!
Ипполитов Николай Николаевич
ООО «Диасофт» — Директор департамента