Независимо дали мигрирате база данни или приложение от Oracle към PostgreSQL само с един тип познания за база данни, има няколко неща, които трябва да знаете за разликите между двете системи за бази данни.
PostgreSQL е най-модерната база данни с отворен код в света. PostgreSQL общността е много силна и те непрекъснато подобряват съществуващите PostgreSQL функции и също така добавят нови функции. Според db-engines.com, PostgreSQL е СУБД на 2017 г.
Има някои несъвместимости в Oracle и PostgreSQL. Поведението на някои функции е различно между Oracle и PostgreSQL.
Защо да мигрирате от Oracle към PostgreSQL
- Цена:Както може би знаете цената на лиценза на Oracle е много скъпа и има допълнителни разходи за някои функции като разделяне и висока наличност. Така че като цяло е много скъпо.
- Гъвкаво лицензиране с отворен код и лесна достъпност от публични доставчици на облак като AWS.
- Възползвайте се от добавки с отворен код, за да подобрите производителността.
Предварителна проверка
Както може би знаете, миграцията от Oracle към PostgreSQL е скъпа и отнемаща време задача. Важно е да разберете коя част трябва да мигрира. Не губете време за мигриране на обекти, които вече не са необходими. Също така проверете дали има необходими исторически данни или не. Не губете време в копиране на данни, които не са ви необходими, например архивни данни и временна таблица от предишна поддръжка.
Оценка на миграцията
След предварителна проверка, първата стъпка от миграцията е да се анализира приложението и обекта на базата данни, да се открият несъвместимостта между двете бази данни и да се прецени времето и разходите, необходими за миграция.
Инструментът Ora2pg е много полезен за оценка на миграцията. Той се свързва с базата данни на Oracle, сканира я автоматично и извлича данните, генерирайки отчета за миграцията на базата данни. Можете да проверите примерен отчет в Ora2pg.
Какво трябва да знаете
Разберете разликите между Oracle и PostgreSQL и го преобразувайте с помощта на всеки инструмент. Няма инструмент, който да конвертира 100% база данни на Oracle в PostgreSQL, необходими са някои ръчни промени. Моля, проверете по-долу някои от важните разлики, които трябва да знаете, преди да мигрирате.
Съпоставяне на типове данни
PostgreSQL има богат набор от типове данни. Някои от важните преобразувания на тип данни между Oracle и PostgreSQL са както следва.
Oracle | PostgreSQL | Коментар |
---|---|---|
VARCHAR2(n) | VARCHAR(n) | В Oracle ‘n’ е брой байтове, докато в PostgreSQL ‘n’ е брой знаци |
CHAR(n) | CHAR(n) | В Oracle ‘n’ е брой байтове, докато в PostgreSQL ‘n’ е брой знаци |
NUMBER(n,m) | NUMERIC(n,m) | Типът NUMBER може да се преобразува в NUMERIC, но ако използвате SMALLINT, INT и BIGINT, тогава производителността ще бъде по-добра. |
ЧИСЛО(4) | SMALLINT | |
НОМЕРА (9) | INT | |
НОМЕРА (18) | BIGINT | |
NUMBER(n) | NUMERIC(n) | NUMERIC(n) ,Ако n>=19 |
ДАТА | TIMESTAMP(0) | И двете бази данни имат тип DATE, но типът DATE на Oracle връща дата и час, докато типът DATE на PostgreSQL връща само дата без час. |
ПЕЧАТА ВРЕМЕ С ЛОКАЛНА ЧАСОВА ЗОНА | TIMESTAMPTZ | Типът PostgreSQL Timestamptz(Timestamp с часова зона) е различен от Timestamp на Oracle с часова зона. Това е еквивалентно на Timestamp на Oracle с местна часова зона, но тази малка разлика може да причини проблем с производителността или грешка в приложението. |
CLOB | ТЕКСТ | Текст тип PostgreSQL може да съхранява до 1 GB текст. |
BLOB RAW(n) | BYTEA(1 GB ограничение) Голям обект | В Oracle типът данни BLOB съхранява неструктурирани двоични данни в базата данни. Типът BLOB може да съхранява до 128 терабайта двоични данни. PostgreSQL BYTEA съхранява двоични данни, но само до 1 GB. Ако данните са над 1 GB, тогава използвайте голям обект. |
Транзакции
Базата данни на Oracle винаги използва транзакции, но в PostgreSQL трябва да активирате това. В Oracle транзакцията започва при изпълнение на произволен израз и завършва, когато се изпълни оператор COMMIT. В PostgreSQL транзакцията започва при изпълнение на BEGIN и завършва при изпълнение на оператор COMMIT. Дори нивата на изолация също нямат проблем. PostgreSQL базата данни знае всички нива на изолация, които базата данни на Oracle знае. Нивото на изолация по подразбиране на PostgreSQL е Read commited.
Пример:
Оракул:
DELETE FROM table_name WHERE id = 120;
COMMIT;
PostgreSQL:
BEGIN;
DELETE FROM table_name WHERE id = 120;
COMMIT;
Двойна маса
В Oracle клаузата FROM е задължителна за всеки оператор SELECT, така че базата данни на Oracle използва DUAL таблица за оператор SELECT, където името на таблицата не се изисква. В PostgreSQL клаузата FROM не е задължителна, така че таблицата DUAL не е необходима. Двойната таблица може да бъде създадена в PostgreSQL като изглед за премахване на проблема с пренасянето. Инструментът Orafce е внедрил това, така че можете да използвате и Orafce.
Пример:
postgres=# SELECT CURRENT_TIMESTAMP FROM DUAL;
ERROR: relation "dual" does not exist
LINE 1: SELECT CURRENT_TIMESTAMP FROM DUAL;
^
postgres=# SELECT CURRENT_TIMESTAMP;
current_timestamp
-------------------------------
2018-03-16 09:36:01.205925+00
(1 row)
След инсталиране на модула Orafce:
postgres=# SELECT CURRENT_TIMESTAMP FROM DUAL;
current_timestamp
-------------------------------
2018-03-16 09:36:01.205925+00
(1 row)
SYSDATE
Функцията SYSDATE на Oracle връща дата и час. Поведението на функцията SYSDATE е различно на различните места. PostgreSQL няма функция, съответстваща на функцията SYSDATE. В PostgreSQL има множество методи за получаване на датата и часа и се основава на целта на приложението.
Метод за извличане на време | Функция, която да се използва |
---|---|
Начален час на SQL | Statement_timestamp() |
Начален час на транзакцията | сега() или
Transaction_timestamp() |
Време, когато функцията е внедрена | Clock_timestamp() |
В примера по-долу clock_timestamp() връща времето, когато действителната функция е изпълнена, а другият statement_timestamp() връща времето, когато SQL операторът е започнал изпълнението си.
postgres=# SELECT now(), statement_timestamp(), current_timestamp, transaction_timestamp(), clock_timestamp();
now | statement_timestamp | current_timestamp | transaction_timestamp | clock_timestamp
-------------------------------+-------------------------------+-------------------------------+-------------------------------+-------------------------------
2018-03-16 09:27:56.163154+00 | 2018-03-16 09:27:56.163154+00 | 2018-03-16 09:27:56.163154+00 | 2018-03-16 09:27:56.163154+00 | 2018-03-16 09:27:56.163281+00
(1 row)
TO_DATE(два аргумента)
Функцията TO_DATE на Oracle връща стойност на тип DATE (година, месец, ден, час, минута, секунда), докато TO_DATE (two_argument) на PostgreSQL връща стойност от тип DATE (година, месец, ден).
Решението за тази несъвместимост е да конвертирате TO_DATE() в TO_TIMESTAMP(). Ако използвате инструмента Orafce, тогава не е необходимо да променяте нищо, тъй като Orafce внедри тази функция, така че получаваме същия резултат с Oracle.
Оракул:
SELECT TO_DATE ('20180314121212','yyyymmddhh24miss') FROM dual;
PostgreSQL:
SELECT TO_TIMESTAMP ('20180314121212','yyyymmddhh24miss')::TIMESTAMP(0);
СИНОНИМ
CREATE SYNONYM не се поддържа в PostgreSQL. В Oracle CREATE SYNONYM се използва за достъп до отдалечени обекти, докато в PostgreSQL можем да използваме SET search_path, за да включим отдалечената дефиниция.
Оракул:
CREATE SYNONYM abc.table_name FOR pqr.table_name;
PostgreSQL:
SET search_path TO 'abc.table_name';
Поведение на празен низ и NULL
В Oracle празните низове и NULL стойностите в низовия контекст са еднакви. В резултат на конкатенацията на NULL и низ се получава низ. В PostgreSQL резултатът от конкатенацията е нулев в този случай. В Oracle операторът IS NULL се използва за проверка дали низът е празен или не, но в PostgreSQL резултатът е FALSE за празен низ и TRUE за NULL.
Последователности
Има малка разлика в синтаксиса на последователността в Oracle и PostgreSQL.
Оракул:
Sequence_name.nextval
PostgreSQL:
Nextval(‘sequence_name’)
За да промените този синтаксис, можете да създадете скрипт или да го промените ръчно.
SUBSTR
Поведението на функцията SUBSTR в Oracle и PostgreSQL е различно. Функцията SUBSTR работи в PostgreSQL без грешка, но връща различен резултат. Тази разлика може да причини грешки в приложението.
Оракул:
SELECT SUBSTR(‘ABC’,-1) FROM DUAL;
Returns ‘C’
PostgreSQL:
postgres=# SELECT SUBSTR('ABC',-1);
substr
--------
ABC
(1 row)
Решението за това е да използвате функцията Orafce SUBSTR, която връща същия резултат като Oracle в PostgreSQL.
Изтриване на изявление
В Oracle изразът DELETE може да работи без клауза FROM, но в PostgreSQL не се поддържа. Трябва ръчно да добавим клауза FROM в оператора DELETE на PostgreSQL.
Оракул:
DELETE table_name WHERE column_name = 'Col_value';
PostgreSQL:
DELETE FROM table_name WHERE column_name = 'Col_value';
Външно свързване +
Oracle използва оператор + за ляво и дясно свързване, но PostgreSQL не го използва.
Оракул:
SELECT a1.name1, a2.name2
FROM a1, a2
WHERE a1.code = a2.code (+);
PostgreSQL:
SELECT a1.name1, a2.name2
FROM a1
LEFT OUTER JOIN a2 ON a1.code = a2.code;
ЗАПОЧНЕТЕ С..СВЪРЗВАНЕ ОТ
Oracle използва START WITH..CONNECT BY за йерархични заявки. PostgreSQL не поддържа оператор START WITH..CONNECT BY. PostgreSQL има WITH RECURSIVE за йерархични заявки, така че преведете израза CONNECT BY в оператор WITH RECURSIVE.
Оракул:
SELECT
restaurant_name,
city_name
FROM
restaurants rs
START WITH rs.city_name = 'TOKYO'
CONNECT BY PRIOR rs.restaurant_name = rs.city_name;
PostgreSQL:
WITH RECURSIVE tmp AS (SELECT restaurant_name, city_name
FROM restaurants
WHERE city_name = 'TOKYO'
UNION
SELECT m.restaurant_name, m.city_name
FROM restaurants m
JOIN tmp ON tmp.restaurant_name = m.city_name)
SELECT restaurant_name, city_name FROM tmp;
Преобразуване от PLSQL в PLPGSQL
Езикът PL/pgSQL на PostgreSQL е подобен на езика PL/SQL на Oracle в много аспекти. Това е блоково-структуриран, императивен език и всички променливи трябва да бъдат декларирани. И в двете бази данни присвояванията, циклите, условните условия са сходни.
Основните разлики, които трябва да имате предвид, когато пренасяте от PL/SQL на Oracle към PL/pgSQL на PostgreSQL
Изтеглете Бялата книга днес Управление и автоматизация на PostgreSQL с ClusterControl Научете какво трябва да знаете, за да внедрите, наблюдавате, управлявате и мащабирате PostgreSQLD Изтеглете Бялата книгаИнструменти за мигриране
Има някои инструменти, които са много полезни за миграцията на Oracle към PostgreSQL. Можете също да създадете свой собствен инструмент като разширение и да го използвате в PostgreSQL.
Orafce
Съвместимите с Oracle функции, тип данни и пакети могат да се използват както е в PostgreSQL. Това е инструмент с отворен код с BSD лиценз, така че всеки може да използва този инструмент.
Повечето от основните функции са обхванати в Orafce.
Приложенията обикновено използват тези функции с множество поява. Можете да намалите разходите за модификация на SQL, като използвате този инструмент.
Всички функции и пакети са имплементирани правилно и е добре тестван.
Някои от функциите:
- Dbms_output
- dbms_random
- utl_file – функции, свързани с файловата система
- Dbms_pipe и dbms_alert
- PLVdate,PLVstr, PLVchr
- Съвместим с Oracle тип данни DATE и функции като ADD_MONTHS, LAST_DAY, NEXT_DAY и така нататък.
- NVL функция
- Функция SUBSTR и SUBSTRB
- Поддръжка на VARCHAR2 и NVARCHAR2
- ДО_ДАТА()
Ora2pg
Ora2Pg е безплатен инструмент, използван за мигриране на база данни на Oracle към съвместима с PostgreSQL схема.
Той се свързва с базата данни на Oracle, сканира я автоматично, извлича нейната структура или данни и след това генерира SQL скриптове, които можете да заредите във вашата база данни PostgreSQL.
Оценката на разходите при миграцията на Oracle към PostgreSQL не е лесна.
Ora2Pg проверява всички обекти на базата данни, всички функции и съхранени процедури, за да открие дали все още има някои обекти и PL/SQL код, които не могат да бъдат автоматично конвертирани от Ora2Pg.
Този инструмент е много полезен за следните преобразувания:
- Преобразуване на схема
- Преобразуване от PLSQL в PLPGSQL
Тестване
Тестването на цялото приложение и мигрираната база данни е много важно, тъй като някои от функциите са еднакви и в двете бази данни, но поведението е различно.
- Трябва да се проверят някои често срещани сценарии:
- Проверете дали всички обекти са преобразувани правилно или не.
- Проверете дали всички DMLS работят правилно или не.
- Заредете някои примерни данни в двете бази данни и проверете резултата. Резултатът от SQL от двете бази данни трябва да е един и същ.
- Проверете производителността на DML и я подобрете, ако е необходимо.