Oracle to Postgres Schema Migration Guide

© Copyright EnterpriseDB Corporation, 2020. All rights reserved.
Oracle to Postgres
Schema Migration
Hustle
Raghavendra Rao; Managing Consultant
Marc Linster; SVP, Product Development and
Support
1

Webinar Series
Jan 22 2020 How to monitor Postgres like a Pro
Feb 5 2020 Oracle to Postgres Migration Hustle
Feb 19 2020 Data Migration from Oracle to Postgres
March 4 2020 Using Terraform to deploy highly available Postgres
March 18 2020 5 things to know about Postgres.conf
2

Agenda
● Who is EDB?
● Migration Overview
● Migration Preliminary check
● Oracle vs PostgreSQL Compatibility differences
● Oracle schema migration hurdles
○ First, what schemas to target first
○ Schema objects Classification
○ Incompatibility challenges
● Tools
● Q & A
© Copyright EnterpriseDB Corporation, 2020. All rights reserved.3

4
Get your EDB
Socks!
Ask a question and give us your
business address in the US - and
we will send you a pair of EDB
Socks!

WHO IS EDB?
A global leader in
open-source based Postgres
software and services
5
• Founded in 2004
• Recognized RDBMS leader by:
• Gartner
• Forrester
• Customer base > 4000
• 300+ employees
• Offices worldwide
• Major PostgreSQL community contributor

ONLY OPEN
SOURCE BASED
RDBMS IN
GARTNER MQ
EDB Recognized 7 Years
In A Row on Gartner’s
Magic Quadrant
6
CONFIDENTIAL © Copyright EnterpriseDB Corporation, 2020. All rights reserved.

7
Customers working SMARTER, reducing RISK and being more PRODUCTIVE with EDB.
OVER 4,000 CUSTOMERS
U.S Customers
EMEA Customers APAC Customers
102
of the
Fortune 500
337
of the Forbes
Global 2000

EDB OPEN SOURCE LEADERSHIP
NAMED EDB OPEN SOURCE COMMITTERS AND CONTRIBUTORS
8
● CORE TEAM ● MAJOR CONTRIBUTORS ● CONTRIBUTORS
Akshay
Joshi
Amul
Sul
Ashesh
Vashi
Dilip
Kumar
Jeevan
Ladhe
Mithun
Cy
Devrim
Gündüz
Amit
Kapila
Bruce
Momjian
Dave
Page
Robert
Haas
Ashutosh
Sharma
Rushabh
Lathia
- designates committers

Migration overview
Database Migration
It means moving definitions, data and stored procedures from
one platform to another. There are many reasons to move to a
different platform, it might be cost, support or so on.

Migration Preliminary Check
● Client
● Application/Data Access
● Database

Oracle vs PostgreSQL differences
• Oracle uses the proprietary "TNS" protocol
with the default TCP port 1521 and the OCI
library as native call interface
• Transactions are not auto committed.
• Supports all Isolation Levels
• Drivers: JDBC, ODBC, .NET and many more.
• Concept of Packages/Procedures/Global
• Supports many other languages
• Partitioning(Horizontal)
• Replication: Master-Master and Master-Slave
• Postgres uses its own "frontend/backend" protocol
with the default TCP port 5432 and the libpq library
as native call interface
• Transaction to control COMMIT/ROLLBACK should
start with BEGIN
• Supports all Isolation Level, but default to READ
COMMITTED, which is sufficient
• Drivers: JDBC, ODBC, .NET and very few other
drivers.
• No concept of Package/Global.
• Good set of languages are supported
• Declarative Partitioning(only Range and List)
• Replication: Only Master-Slave

Oracle Schema Migration Hurdles

First, Which Schemas to Target
● Good targets...
○ Choose the smallest schemas with few PL/SQL objects
○ Then choose the most representative, on the basis of the experience
○ Add on: if team having multiple database skill set will reduce the conversion human-days.
● More difficult targets....
○ Don't choose Oracle application databases, that are closely tied with OCI
○ Don’t choose application using proprietary software (like Oracle forms)
○ Don’t choose spatial schemas, they need a lot of manual work.

Schema Object Classification
● Every RDBMS offers the ability to store data and code objects. They are classified as
○ Storage Objects : Objects that holds the data(with reference integrity): Table, Constraint,
Index, Type, Sequence and Synonyms
○ Code Objects: Objects that holds program code to access/modify data: Views, Triggers,
Procedures, Functions, Packages

Incompatibility Challenges
● Schema
○ In Oracle, users and schemas are essentially the same thing. A user is the account used to
connect to a database, and a schema is the set of objects (tables, views, etc.) that belong to
that account.
○ In Postgres, users’ objects are created in a specific schema (or namespace). When the user
connects the default search_path is “$user,public” schema. “Public” is the default schema
assigned to a user.
■ User can create different schemas, no need to create separate users
■ Users can grant permission to create objects in one of his schema to some other user.
■ Allows flexibility to divide application logically.

Incompatibility Challenges...
● Identifiers
○ In Oracle, all identifiers are in UPPER CASE, unless quoted.
○ Postgres converts them to lower case, unless quoted. Identifiers in Postgres are case
insensitive, unless quoted.
■ If application quotes the identifiers then it might lead to some manual work at both the
ends.

● Storage Objects
○ Tables - Mostly compatible, except
■ Global Temporary Table (use Local Temp or Unlogged Tables)
■ KEEP/CACHE/IOT/EXTERNAL/COMPRESSED/CLUSTER/NESTED - They are normal
tables, and functionality need to be handled by Postgres supported modules.
■ Partition (Only Range/List supported)
○ Constraints
■ All constraints are supported(No foreign key support on Partition Table key)
○ Indexes
■ Most of the indexes are supported
■ Reverse Key(A functional based index can be used to reverse the order)
■ Global (Not yet supported)

● Storage Objects.. contd
○ Type
■ CREATE DOMAIN or CREATE TYPE with some limitations(Use ARRAYs)
○ Sequences
■ Oracle supports 2^63 as max value(PostgreSQL supports upto 2^63)
■ NOCACHE, NOORDER not supported
■ .nextval, .curval (need to call nextval(),currval() function on sequence name)
○ Synonyms
■ Not supported in PostgreSQL (use “search_path”)

● Data Types
Oracle PostgreSQL Comment
varchar,varchar2, nvarchar,
nvarchar2
varchar or text
char,nchar char
clob,long varchar or text
number bigint, int, smallint,
real, double
precision
Limited control of scale
binary_integer, binar_float integer, float
blog, raw, long raw bytea Size limitation

Oracle PostgreSQL Comment
Date Date or timestamp Postgres, returns timestamp with
date
Timestamp with time zone Timestamptz

● In Code objects
○ RETURN statement becomes RETURNS
○ EXECUTE IMMEDIATE becomes EXECUTE
○ SELECT becomes PERFORM
○ Functions
■ MUST choose a language
■ %TYPE and %ROWTYPE supported
■ cursor_name%ROWTYPE not yet supported; Use RECORD
○ Autonomous Transaction
■ use DBLINK module (slight performance overhead due to loopback connection)
○ COMMIT/ROLLBACK in PROCEDURE
■ Use EXCEPTION handling

● In Code objects
○ REVERSE LOOPs (must rewrite with start/end condition)
○ Packages
■ Use schema to group functions/procedures (no support for private variable/function)
■ No built-in package. Use Orafce library, which support some of the standard packages
(https://github.com/orafce/orafce)
○ Accessing Remote Objects
■ DBLINK module or Foreign Data Wrapper(oracle_fdw) to access any other database
○ Optimizer Hints
■ Postgres doesn’t have them, its discarded. No conversion required.

● In Code objects
○ Query Conversion
■ OUTER Joins(+) marks at the NULL augmented side - (Use FULL OUTER JOINS
or UNION)
■ Pseudocolumns
● ROWNUM - Use LIMIT clause in the query(SELECT * FROM table LIMIT 10)
● ROWID - Its ROW Physical Address in Oracle (CTID in PostgreSQL, use
ROW_NUMBER OVER() windows function)
■ Hierarchical Queries - START WITH… CONNECT BY
● Need to convert using CTE or Tablefunc module, which has support of LEVEL
and PATH

● In Code objects
○ Empty Strings vs NULL
■ In Oracle Empty String and NULL are treated as NULLs, but in PostgreSQL both are not
treated as NULL. (Need special attention of queries comparing empty strings.)
○ Usage of Oracle Built-in functions
■ NVL - Use COALESCE()
■ DECODE - Use CASE clause
■ SYSDATE - Use current_timestamp

Other option
● EDB Postgres Advanced Server
○ EDB has developed database compatibility for Oracle based on popular features across many
versions of Oracle. EDB Postgres Advanced Server database behave or produce the
identical result as they would in Oracle. It natively support some of the Oracle functionalities in
the database which makes migration exercise easy to migrate the existing Oracle Database
Objects as is and work with similar functionality and performance.
○ What all natively supported in EDB Postgres Advanced Server ?
■ All Data types (except BINARY_FLOAT, BINARY_INTEGER,.,..)
■ Sequences/Synonyms/Database Links
■ Partition/Sub-Partition
■ Some of standard Oracle built-in Packages and Functions
■ Security(DBMS_RLS/SQLProtect/Policies)
■ User defined Packages/Procedures/Type(UDT)
■ Supporting Drivers (JDBC, ODBC, .NET

Tools

Tools
● Assessment and Conversion Tools
○ Open Source
■ ora2pg (https://github.com/darold/ora2pg)
○ Free to use
■ AWS Schema Conversion Tool (https://aws.amazon.com/dms/schema-conversion-tool/)
■ EDB Migration Portal (https://www.enterprisedb.com/edb-postgres-migration-portal)
■ EDB Migration ToolKit (https://www.enterprisedb.com/downloads/edb-migration-toolkit)
(No Assessment)
● Migration Supporting tools
■ orafce - support only Packages/No Conversion (https://github.com/orafce/orafce)

Ora2Pg Sample Report

EDB Migration Portal Sample Report

AWS SCT Sample Report

Tools
Assessment
Migration of
data objects
Migration of
code objects
Migration
Data
Approach Target
EDB Migration Portal Use EDB
MTK
Native +
Transformation
Postgres
Advanced
Server
EDB MTK
Native Only Postgres
Advanced
Server
AWS SCT Transformation
Only
PostgreSQL
Ora2Pg Transformation
only

Overall Migration steps

QUESTIONS

Oracle to Postgres Schema Migration Guide

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Oracle to Postgres Schema Migration Guide

Similar a Oracle to Postgres Schema Migration Guide (20)

Más de EDB

Más de EDB (20)

Último

Último (20)

Oracle to Postgres Schema Migration Guide