Presented at MariaDB Roadshow Paris 2017

1. Migration: Replacing
Oracle Database at an
international bank
Migration d’une base de données
Oracle vers MariaDB par une Banque
de renommée international
Dr. Alexander Bienemann
Migration Practice Manager
Paris, 30.06.2017
Professional Services

2. Asia’s Safest, Asia’s Best Bank
is migrating their application from Oracle
to MariaDB.
DBS Bank | Singapore

3. Why migrate
to MariaDB?
What is different now?
Professional Services

4. Why migrate now?
MariaDB is ready for enterprise-grade migrations from Oracle and DB2:
• New features added in 10.2 and 10.3. Migrations are faster and easier than ever before.
– MariaDB is highly PL/SQL compliant now
– MariaDB has a sound HA and distribution concept
• Cloud flexibility. No CPU fees, flexible topologies, the works.
• Well-proven. Some of the biggest companies migrate.
• Cost. We offer a much lower TCO.

5. We are ready for enterprise-grade migrations from Oracle
• MariaDB is feature-rich:
– Through customer projects, we identify & close gaps
– We develop features and solutions
– Community and customers contribute actively
• Examples:
– SQL_MODE = ORACLE (10.2, 10.3)
– PL/SQL parser
– Returning tables from procedures
– Migrations of CONNECT_BY_ROOT, ISLEAF
– MaxScale for HA and Load Balancing
• SQL 2003:
– CTE’s / WITH
– Window Functions
• MariaDB is highly productive:
– TA throughput > 1 million queries/sec
– Data sizes of multiple TB
– CONNECT storage engine
– Fast data ingest with LOAD DATA INFILE
– JSON functions
• MariaDB helps with compliance:
– Encryption of data (data-at-rest)
– Encrypted connections with TLS, certificates
– Audit Plug-In for accountability
– World-class support

6. • Standard, widely used SQL.
– Think of the 80/20 Pareto principle!
– We are a relational DB - how many frills do you really use?
• Common Table Expressions.
– WITH construct, recursive and non-recursive, e.g. CONNECT_BY_ROOT, ISLEAF
– Having MariaDB 10.2, we implement directly 1:1 in MariaDB’s own database code
• Window Functions. For analytic queries: NTILE, RANK, DENSE_RANK etc.
• SQL_MODE = ORACLE. Procedure syntax extremely close to PL/SQL.
Features that make migrations easier

7. Features that are better than your legacy system
• Distributed, shared-nothing architecture. ColumnStore. Connect engine.
• Easy partitioning.
• Native replication. Choice of Galera, Master-Slave, or both.
• Solutions with MaxScale. Promotion of slaves to master with various topologies.
And, last but not least:
• Lower TCO. For instance, 70% lower according to our customer!

8. Ongoing migration
DBS Bank Singapore
Professional Services

9. • DBS Bank Singapore. One of the biggest banks in Southeast Asia.
– 12 applications have already been successfully migrated to MariaDB by 2016
– 15 application in pipeline for 2017 → 3 of which are the most complex ones
• Heavy-duty transactional data mart for OLTP applications
– Data is then provided to customer-facing applications
– 16 countries, 250 tables, 130 procedures, 4 TB hot data, 15 TB cold data (approx.)
• Online corporate banking application
– 9 countries, several million financial TA/month
• Integrated payment engine
– 9 countries, several million financial TA/month
Migration projects at DBS Bank

10. • Phase 1: Migration of the Transactional Data Mart
– Started with Migration Assessment (analysis of feature gap and major challenges)
– Feature development started in Sept. 2016 => SQL_MODE = ORACLE
– Migration work started in January 2017
– Go-live in July/August 2017
• Phase 2: Design for hot and cold data incl. ColumnStore
– PoC for the target architecture is completed
– Scheduled for Q3-Q4 2017
– Go-live in Q1 2018
Example of migration: Transactional Data Mart

11. • Migration Assessments:
– Gap analysis in the beginning
– Mid-project assessment for streamlining the migration
• Feature development:
– Analysis results lead to prioritization and Statement of Work
– Features are customer-driven and community-driven => the community benefits in this way
• Application migration:
– Database experts of the Customer are trained by MariaDB
– Application adaptation by Customer’s own developers
– Direct migration to high extent with SQL_MODE = ORACLE
– Migration validation, in particular on procedural level
• Migration consulting by MariaDB:
– Knowledge transfer to the Customer
– Additional know-how on specific topics, e.g. HA architectures
How we conduct the migration
Joint work of the DBS and MariaDB

12. • Necessity of a Proof of Concept:
– Solution: One of the most complex application cases was deliberately chosen.
• Density of internal application knowledge:
– Live application which has been growing over years → hundreds of procedures etc.
– Solution:
• 1:1 migration whenever possible
• analysis of legacy semantics in the few cases where necessary
• Complexity due to Oracle features used:
– Oracle-specific features had been used, e.g. CONNECT BY, PIPE ROW, non-1NF custom types
– Solution:
• feature development for frequently used constructs → tradeoff “development cost vs. migration cost”
• solution/workaround development for less frequently used constructs, e.g. collections
• Complexity due to long-term growing architecture:
– Tight couplings and dependencies with neighboring systems
– Direct access to tables from/to other applications, i.e. bypassing application calls
– Solution:
• analysis of the architecture “as is”, check for optimal options in sync with migration plan
• develop a REST interface and/or use dedicated slaves
Challenges and how we managed them

13. How do we migrate?
The general idea
Professional Services

14. How to choose first candidates for migration
• What requires further analysis:
– Applications highly dependent on
DBMS-specific constructs, e.g.
• Functions monitoring of DBMS internals
• Parallelism issues etc.
– Documentation of semantic differences
between MariaDB and Oracle types is
available
• Customers can work with MariaDB to resolve
some of the documented differences where
necessary
• Good candidates for a migration:
– Application stacks where the DBMS is used by
well-documented interfaces, e.g.
• Oracle with Java
• Oracle with C++
• Vendor-neutral, as long as they maintain clear
or documented interfaces
– We are open to work with new vendors
who do not support MariaDB yet
• Application logic remains unchanged
→ We adapt the data access layer

15. • Migration process:
– Migration Questionnaire
– Migration Assessment
– Migration project planning,
migration doing, and QA
– Switchovers, forward and rollback
planning, points of no return
– Pilot phase
• Migration project planning,
migration doing, and QA:
– Deepened analysis of existing DB
application and IT infrastructure
• Migration of schema
• Migration of interfaces to other systems
• Choice of the right tools
• Analysis of slow-running queries
• Tuning opportunities
– MariaDB migration expertise,
validation of application behavior
• Performance, load, parallelism tests
• User Acceptance Tests (UAT)
• System Integration Tests (SIT)
The migration process

16. • Starting point of a migration:
Migration Assessment Package
– Approx. 10 days
– Our consultants analyze your database
applications
– Target architecture is developed based
on MariaDB and MaxScale and further
products if necessary
– Tasks and effort estimation
– Findings can be refined later on during
actual migration project
First step: Migration Assessment
• Benefits of this service:
– Ensure a precise, non-biased, externally
objective analysis of your applications
– Minimize the risk of wrong planning and
non-purposeful activities
– Ensure a purposeful, straightforward
procedure, and prioritization of steps
– Benefit from the broad experience and
deep technical insight of MariaDB
consultants, comprising knowledge in both
MariaDB as well as Oracle

17. • In order to plan a migration:
– Migration Assessment Package
– Proof of Concept of Target Architecture
• In order to conduct a migration:
– Adaptation of Procedural Code
– Data Migration Package
– Performance Tuning
– Integration Tests and Switchovers
• It is crucial for us to make you successful with your migration
How we help customers to succeed in migrations

18. Some of our
best practices
Migration Practice
Professional Services

19. Customized quality criteria
• Customized quality criteria based on the application environment and usage:
– specific for every single case
• Various tests are developed and conducted:
– Functional tests
– Load tests
– Parallel operation tests
– User acceptance tests
– Integration tests — including interfaces to neighboring systems
• Criteria on process change
• Criteria on the change of monitoring systems
• On project and team level: tolerances

20. MariaDB:
use payroll
select * from hr.employee;
Oracle:
connect payroll/<password>
create synonym employee for hr.employee;
select * from employee;
• In Oracle, you need synonyms and database links usually to access objects that are
outside of your user-specific “schema”
• In MariaDB, objects in different databases can be accessed directly
• Thus, before migrating one should check if synonyms/links will actually be needed
Best practice: Migration of SYNONYM

21. Solution 2: Synonym access on the same
server with VIEWs
CREATE VIEW LOCALDB.LOCALNAME (
`ID`,
`ATTR`,
`WHEN_CREATED`,
)
AS
SELECT `ID`, `ATTR`, `WHEN_CREATED`,`
FROM DBNAME.TABLENAME;
Solution 1: Synonym access between two
servers with FederatedX
CREATE SERVER 'MariaDB_Link_NAME' FOREIGN DATA
WRAPPER 'mysql' OPTIONS
(
HOST '<ip_address>',
DATABASE '<DBNAME>',
USER '<username>',
PASSWORD '<password>',
PORT 3306,
SOCKET '',
OWNER '<owner>'
);
CREATE TABLE LOCALDB.LOCALNAME (
`ID` varchar(11),
`ATTR` varchar(35),
`WHEN_CREATED` timestamp(6)
) ENGINE=FEDERATED DEFAULT CHARSET=latin1
CONNECTION='MariaDB_Link_NAME/TABLENAME';
• If you need synonyms and database links, we provide a solution for migrating it
depending on the application case
• Example for table/view synonyms:
Best practice: Migration of SYNONYM

22. Best practices for proprietary solutions
• Legacy applications may contain specific proprietary technical solutions, e.g.
– Replication protocols (other than those of database systems)
– Backup solutions
• We analyze and help to decide how these solutions can be supported in the best way: by
state-of-the-art technical constructs,
– e.g. MariaDB replication
• Depending on the specific case, preserving existing legacy mechanisms may be
temporarily helpful
• A roadmap for improvements can be defined

23. Conclusions
Possible migration scenarios
Professional Services

24. • Experts from MariaDB Corporation
perform both preparation work and
actual migration
• We are responsible for the actual
migration process
• We coordinate all accountable parties
and stakeholders involved
Complete migration PoC migration plus own work
• Experts from MariaDB Corporation
perform the Migration Assessment and
a Proof of Concept migration
• The customer is responsible for the
actual migration process
• The customer coordinates all
accountable parties and stakeholders
involved
• MariaDB provides advisory capacity
Different scenarios for using our migration services
→ See our packages

25. Assessment in the beginning:
• Experts from MariaDB Corporation
analyze the legacy application
• We analyze the feature gap (if any) and
develop an optimal target architecture with
MariaDB
• We provide an effort estimation
Assessment in the middle of a project:
• Experts from MariaDB Corporation analyze
the already ongoing migration project of the
customer
• We analyze and improve the chosen target
architecture
• We analyze and improve the migration
process of the customer, especially:
– optimize the software adaptation process
– secure the switchover planning
– provide best practices
Real-life examples of Migration Assessment usage

26. • Implementation of legacy functionalities
with existing MariaDB constructs
• When a feature is missing, we discuss
together with the customer whether to
– develop the feature, or
– provide a workaround/solution
• Advantages for the Customer:
– faster time-to-market through
development of Oracle-compatible features
– optimal migration cost as only selected
features needed to be developed
• Implementation of legacy functionalities
with existing MariaDB constructs
• When a feature is missing, we provide a
solution, i.e. a workaround on the basis of
current MariaDB version
Migration without new features: Migration with closing feature gap:
Migration scenarios

27. Thank you