Upgrading the Moovit App - RainFocus | Harness … in Moovit PL/SQL Packages Anchoring Business...

58
© COPYRIGHT 2016 MOOVIT Upgrading the Moovit App with Zero Downtime using Edition-Based Redefinition

Transcript of Upgrading the Moovit App - RainFocus | Harness … in Moovit PL/SQL Packages Anchoring Business...

© COPYRIGHT 2016 MOOVIT

Upgrading the Moovit App with

Zero Downtime using

Edition-Based Redefinition

Agenda

• About myself

• About Moovit

• Oracle in Moovit

• Application upgrades in Moovit

• The early days

• Adopting EBR

• Current state

• And more…

Where: TELEknowledge

When: Oracle 8i/9i [1998-2003]

What: DBA Group Manager

Who Am I? Chronology by “Oracle years”

Where: IAF

When: Oracle 6/7 [1991-1997]

What: Developer

Where: Golden Screens

When: Oracle 8 [1997-1998]

What: Server Group Manager

Where: Olista

When: Oracle 10g/11g [2004-2011]

What: VP R&D + Israel Site Manager

Database

Architect /

Developer / DBA

@DBoriented

http://db-oriented.com

REVOLUTIONIZING LOCAL MOBILITY

Founded : 2012

Employees : 95

Locations : Israel

San Francisco

Investors : Sequoia Capital

Nokia Growth Partners

BMW i Ventures

Vaizra

Keolis

LVMH

BRM

Gemini

Sound Ventures

8 Billion People

900 Million Cars

Transit is a big part of our lives…

Time spent on transit daily

Official data

Schedule

Service Alerts

POI

PT Agencies

GPS

Updates

Alerts

Crowd

Sourced Data

Trip Plan

Real-Time Data

Alerts

Mobility options

Multi Modal - Omni Search for the metro area

Combining Taxi / Carpool

/ car sharing

Real-Time alerts & delays

+45 Million Users

The World’s Leading Transit App

45 Languages

67 Countries

1,200+ Cities

4,500 Transit Operators

4.6 million Bus/Train Stops

>100 million Daily passenger reports

New city added every

18 Hours!

Budapest Venezia Napoli

Trieste Buenos Aires

Singapore Santiago Bogota

Torino Milano Blumenau

Salerno Pisa Juiz de Fora

Bolonia Porto Alegre Berlin

Paris NYC Tel Aviv Los

Angeles London Miami

Munich Dublin San

Francisco Venezia Napoli

Trieste Buenos Aires

Singapore Santiago Bogota

Torino Milano Blumenau

Salerno Pisa Juiz de Fora

• 75k+ Editors in 142 Countries

• Pipeline of 2,000+ Active Projects

Official App Rio Olympics

Oracle in Moovit

11gR2 Standard Edition

Amazon RDS ~4TB

Oracle

Oracle in Moovit Database Clients

Oracle

Application

Servers Mobile App

Web Trip

Planner

Community

Editor

Operative

Tools

Con.

Pool

Load Balancer

Oracle in Moovit Database Clients

Oracle

Various Data

Sources

Oracle

Oracle in Moovit Utilizing the Database Capabilities

PL/SQL

External

Tables

Locator Scheduler

Jobs Email

Sending

Enforcing

Business Rules

by Constraints

and Triggers

650 tables 120 packages 100,000 PL/SQL code lines

For

Internal

Tools

Functionality-Based

Subsystem

Core Infrastructure

Generic Utilities

Oracle in Moovit PL/SQL

Packages

Oracle in Moovit PL/SQL

Packages

Anchoring

Business Logic

Bulk Processing

Overloading

UDT

Conditional Compilation

Session-Level Cache

And much more…

Oracle in Moovit PL/SQL

App Server Oracle

JDBC

Only PL/SQL

Passing parameters by name

Getting ref cursor items by name

Exceptions

Application Upgrades in Moovit

• The early days

• Adopting EBR

• The opportunistic period

• Reaching zero downtime

• From great to excellent

• Current state

• Beyond online upgrades

The Early Days

• Online upgrades for “simple” changes

• Changes that don’t cause invalidations

• No API changes

Online Upgrades

App Server Oracle

Shutdown

Changing code objects

Recompiling invalid objects

Changing data objects

Startup

The Early Days Offline Upgrades

Seconds?

Minutes?

Hours?

The Early Days

• More and more users

• In more countries

• Across more time-zones

And Then…

The Early Days And Then…

alter procedure p compile;

begin

p;

end;

/

begin

p;

end;

/

begin

p;

end;

/

begin

p;

end;

/

begin

p;

end;

/

begin

p;

end;

/

begin

p;

end;

/

begin

p;

end;

/

Session 2

Session 3 begin

p;

end;

/

Session 1 Session 4 Session 5 Session 6 Session 7 Session 8 Session 9 Session 10

The Early Days

• More and more users

• In more countries

• Across more time-zones

And Then…

• No more online upgrades

• We want to avoid frequent downtimes

• We want to avoid long downtimes

The Early Days

• Must bundle changes together – not agile

• Must plan the downtime carefully (nights, weekends)

• Pre-upgrade to reduce the downtime (reduce, not eliminate)

• High stress during the upgrade (which also raises the chances to

make mistakes)

Upgrading Becomes a Nuisance

Adopting EBR

• A gradual process

• The opportunistic period

• Reaching zero downtime

• From great to excellent

Adopting EBR

• ALTER USER … ENABLE EDITIONS

• Retroactive

• Irreversible

• That was easy and went fine

Step 0

Adopting EBR The Opportunistic Period

create table ABC$T (...);

create editioning view ABC as

select ... from ABC$T;

create or replace package

...

procedure get_abc (...) is

begin

...

select ... from ABC where ...;

...

end get_abc;

...

Adopting EBR The Opportunistic Period

rename XYZ to XYZ$T;

create editioning view XYZ as

select ... from XYZ$T;

create or replace package

...

procedure get_xyz (...) is

begin

...

select ... from XYZ where ...;

...

end get_xyz;

...

App Server Oracle

Shutdown

Changing code objects

Recompiling invalid objects

Changing data objects

Startup

Adopting EBR The Opportunistic Period

Creating a new edition

Exposing the new edition

Shutdown

Startup

Creating EVs selectively

Seconds!

Adopting EBR

• Downtime length is limited now (“near-zero”)

• Making the changes in the new unexposed edition gives a

priceless peace of mind

• Cutover, not rollover

• No need for reverse cross-edition triggers

The Opportunistic Period

Adopting EBR Reaching Zero Downtime

Covering all the tables with

Editioning Views

and ne’er shall the code see a

table again

Adopting EBR Reaching Zero Downtime

No Shutdown

Rollover

Adopting EBR Reaching Zero Downtime

Oracle

App Server Version 1.1

create or replace trigger set_edition_on_logon

after logon on database

begin

if user like 'MOOVIT%' then

dbms_session.set_edition_deferred('V7');

end if;

end set_edition_on_logon;

App Server Version 1.1

App Server Version 1.1

V7

V7

V7

V7

V7

V7

V7

V8

Adopting EBR Reaching Zero Downtime

Oracle

App Server Version 1.1

App Server Version 1.1

V7

V7

V7

V7

V7

V7

V8

create or replace trigger set_edition_on_logon

after logon on database

begin

if user like 'MOOVIT%' then

dbms_session.set_edition_deferred('V8');

end if;

end set_edition_on_logon;

App Server Version 1.2 V8

Adopting EBR Reaching Zero Downtime

No Shutdown

Rollover

Reverse

Cross-Edition

Triggers

Adopting EBR Reaching Zero Downtime

Oracle

App Server Version 1.1

App Server Version 1.1

V7

V20140101

V7

V7

V7

V7

V8

create or replace trigger set_edition_on_logon

after logon on database

begin

if user like 'MOOVIT%' then

dbms_session.set_edition_deferred(‘V8');

end if;

end set_edition_on_logon;

App Server Version 1.2 V8

V8

Adopting EBR Reaching Zero Downtime

Backward

Compatible

APIs

No Shutdown

Rollover

Reverse

Cross-Edition

Triggers

Adopting EBR Reaching Zero Downtime

Why don’t you

use services?

Adopting EBR From Great to Excellent

Oracle

App Server Version 1.1

App Server Version 1.1

App Server Version 1.1

V7

V7

V8

App Server

App Server Version 1.2 V8

V7

V7

V8 service

S2

V7

service

S1

Adopting EBR The Current State

All the tables are covered by

editioning views

Regular views are based only on

editioning views (and on other

regular views), never on tables

(Regular) triggers are defined

on editioning views

Program units never refer to

tables, only to views

Connections are done via services

Enabling

Online

Upgrades

Adopting EBR The Current State

Scripts for upgrading non-

editioned objects are written

with full attention to keep the

upgrade online

Development

Writing code objects requires

no special considerations

Preventing invalidation of

objects in exposed editions

Using crossedition triggers to

synchronize pre-upgrade and

post-upgrade representations

Adopting EBR The Current State

Performing

Upgrades

Upgrades are done in

new editions

Upgrades are done whenever needed

on average once every 3 days

sometimes twice a month

sometimes twice a day

Upgrades are always done online, with zero downtime

New versions are exposed

via services

EBR as part of our development life

create table metro_area_aliases$t(

metro_area_id number(10) not null

constraint fk_metro_area_aliases_metros

references metro_areas$t(metro_area_id),

alias nvarchar2(100) not null,

constraint metro_area_aliases_pk

primary key (metro_area_id,alias)

)

organization index;

create or replace editioning view

metro_area_aliases as

select metro_area_id,

alias

from metro_area_aliases$t;

EBR as part of our development life

EBR as part of our development life

EBR as part of our development life

Some Examples

alter table banks$t add (

sort_order integer

);

create or replace editioning view banks

as

SELECT country_id,

bank_code,

bank_name,

branch_max_length,

account_max_length,

sort_order

FROM banks$t;

PROCEDURE get_metro_banks

(

p_metro_area_id IN metro_areas.metro_area_id%TYPE,

get_banks_refcur OUT SYS_REFCURSOR

) IS

BEGIN

OPEN get_banks_refcur FOR

SELECT b.bank_code,

b.bank_name,

b.branch_max_length,

b.account_max_length

FROM metro_areas ma,

banks b

WHERE ma.metro_area_id = p_metro_area_id

AND b.country_id = ma.country_id

ORDER BY

b.sort_order,

b.bank_name;

END get_metro_banks;

adding a new column

Some Examples

alter table task_types$t add (

description_new varchar2(100)

);

create or replace editioning view task_types

as

SELECT task_type_id,

description_new as description

FROM task_types$t;

PROCEDURE add_task_type

(

p_task_type_id IN task_types.task_type_id%TYPE,

p_description IN task_types.description%TYPE

) IS

BEGIN

INSERT INTO task_types

(task_type_id,

description)

VALUES

(p_task_type_id,

p_description);

END add_task_type;

modifying a column

Some Examples

alter table task_types$t add (

description_new varchar2(100)

);

create or replace editioning view task_types

as

SELECT task_type_id,

description_new as description

FROM task_types$t;

CREATE TRIGGER task_types_fce

BEFORE INSERT OR UPDATE OF description ON task_types$t

FOR EACH ROW

FORWARD CROSSEDITION

DISABLE

BEGIN

:new.description_new := :new.description;

END task_types_fce;

/

ALTER TRIGGER task_types_fce ENABLE;

CREATE OR REPLACE TRIGGER task_types_rce

BEFORE INSERT OR UPDATE OF description_new ON task_types$t

FOR EACH ROW

REVERSE CROSSEDITION

DISABLE

BEGIN

:new.description := :new.description_new;

END task_types_rce;

/

ALTER TRIGGER task_types_rce ENABLE;

modifying a column

alter table task_types$t

set unused (description);

Some Examples

USERS$T USERS2$T

USERS

Forward C.E. Trigger

Reverse C.E. Trigger

USERS

Pre-Upgrade Edition

adding an index to a big active table

Post-Upgrade Edition

Zero Downtime

• You should know what may cause invalidation (in older

editions) when changing non-editioned objects

• Sometimes you don’t have to use a new service

• It is not as easy as developing for offline upgrade

• You have to think and to understand

• Not as easy, but… it’s not hard either

Not Zero Work

Beyond Online Upgrades

• Upgrades can be done at any time

• Upgrades can take as long as needed

• DB-side upgrade can be done independently of App Server upgrade readiness

• Flexible exposure of new versions

• Testing of the new version before it is exposed to the end users

• Different types of App Servers may use different editions

REVOLUTIONIZING LOCAL MOBILITY

© COPYRIGHT 2016 MOOVIT

REVOLUTIONIZING LOCAL MOBILITY