database standard edition cloud migration success stories

Copyright ©2019 Version 1. All rights reserved.1

Database Standard Edition

Cloud Migration Success Stories

UKOUG Techfest19

Presented By: Zahid Anwar, Principal Consultant

2nd December 2019

Company Classification: Public


A bit about myself

• Principal Consultant (15+ years experience)

• An Oracle Certified Master

• An Oracle Ace

• 10g, 11g and 12c Oracle Certified Expert RAC and Grid Infrastructure

• Exadata and ODA Specialist

• Follow me on:

– facebook.ZedDBA.com (page)

– twitter.ZedDBA.com or @ZedDBA

– LinkedIn.ZedDBA.com

– www.ZedDBA.com

http://facebook.zeddba.com/

http://twitter.zeddba.com/

http://linkedin.zeddba.com/

http://www.zeddba.com/


Version 1 at a Glance

€115M£105M

98%CUSTOMERRETENTION

3LEADING TECHNOLOGYPARTNERS

1300+EMPLOYEESIN UK, IRELAND & INDIA

#1ORACLE PARTNERVoted by UKOUG users

400+CUSTOMERS

Top 10WORKPLACES IN EUROPE (2017-2019)

9GLOBALACQUISITIONS

20 YEARS PROVING VALUE OF I.T.


Trusted to Deliver Customer Success


Database Standard Edition

Cloud Migration

Success Stories


Standard Edition License Policy Change #1

• The Oracle Cloud policy changed in January 2017 for “Authorized Cloud Environments” namely AWS an Azure

– Core factor changed from 0.5 to 1 for EE licenses

– Number of virtual cores (vCPUs) per socket changed from 4 to 2 for SE/SE1/SE2

– Halving the compute resource/doubling the cost

• However, Oracle Cloud remained the same

– Effectively becoming half the cost

https://blog.zeddba.com/2017/02/14/oracle-licensing-in-the-cloud-and-what-the-recent-changes-mean-for-you/

https://blog.zeddba.com/2017/02/14/oracle-licensing-in-the-cloud-and-what-the-recent-changes-mean-for-you/


Standard Edition License Policy Change #2

• The Oracle Cloud policy changed again in January 2018 for “Authorized Cloud

Environments” namely AWS an Azure, to add clarity for hyper-threading

– 2 vCPUs as equivalent to 1 Oracle Processor license if hyper-threading is enabled for EE

– 1 vCPU as equivalent to 1 Oracle Processor license if hyper-threading is not enabled for EE

– 4 vCPUs per socket for SE/SE1/SE2 regardless of hyper-threading

http://www.oracle.com/us/corporate/pricing/cloud-licensing-070579.pdf

http://www.oracle.com/us/corporate/pricing/cloud-licensing-070579.pdf


Standard Edition License Limitations SE

• SE

– 4 sockets max or 2 socket max for RAC (max 2 nodes)

– No core limit on premise

– 4 physical cores (OCPUs) limit per socket on Oracle Cloud

– 4 virtual cores (vCPUs) limit per socket on Azure/AWS (reverted back to 4, previously 2)

– Out of Support as of August 2016

– Terminal Version 12.1.0.1


Standard Edition License Limitations SE1

• SE1

– 2 sockets max (single server, no RAC option)




– Out of Support as of August 2016

– Terminal Version 12.1.0.1


Standard Edition License Limitations SE2

• SE2

– 2 sockets max or 1 socket max for RAC (max 2 nodes)

• RAC removed from 19c the long-term support release of 12c


• Uses a maximum of 16 threads or 8 when RAC



– Premier Support till July 2018 with Extended Support till July 2021

– Latest Versions available 12.1.0.2 and 12.2.0.1


Standard Edition License Upgrade

• Processor License

– SE: Zero-cost license migration

• No cost for upgrading license

• Accept T&C of SE2

• Same annual support cost

– SE1: Small-cost license migration

• No cost for upgrading license

• Accept T&C of SE2

• Annual support cost uplift of 20% (usually less then £500 per socket)

• Named User Plus

– SE/SE1:

• New minimum of 10 NUPs per server for SE2 (previously just 5 and not per server)


Standard Edition License Optimisation

• Use instances with hyper-threading disabled

– Utilises full core instead of interlaced thread

– Hyper-threading depending on workload only yields 35% performance increase

• https://itpeernetwork.intel.com/hyper-threading-on-or-off-for-oracle

• Great on premise, no harm enabled and getting the extra interlaced thread for free

• Not so great for Cloud when paying per vCPUs for licensing

• AWS – default on

– Hyper-threading on: any instance, default HT on (cost 0% more, 0% more power)

– Hyper-threading off: any instance, disable HT (cost ~100% more, ~65% more power)

• Azure – default off

– Hyper-threading on: v3 instance (cost 0% more, 0% more power)

– Hyper-threading off: v2 instance (cost ~33% more, ~65% more power)

https://itpeernetwork.intel.com/hyper-threading-on-or-off-for-oracle


DAE – before (on-premise)

• Physical Servers

• Microsoft Windows 2008 R2

• Oracle Database Standard Edition One 11.2.0.3

• Largest database ~250GB (POC) reduced to ~100GB (prior to migration)


DAE – requirements

• Upgrade to latest stable version

• Flexible on downtime

• Initially 20Mbps then 200Mbps with ExpressRoute


DAE – after (Azure)

• Infrastructure as a Service (IaaS)

• Microsoft Windows 2012 R2

• Oracle Database Standard Edition Two 12.1.0.2 (12.2.0.1 was unstable at time)

• Locations: Amsterdam & Dublin

• Instance type: DS12 v2

• Drives: G (ORADATA) & I (FRA)

– 2x 256GB Premium SSD Managed Disks

– To create storage pool with 512B sector size*

*DBCA Getting Error ORA-27047 Due to 4K Sector Disks (Doc ID 2097255.1)


DAE – method (Data Pump)

1. Create 12.1.0.2 database on target and preparations (Azure)

2. Stop applications (on-premise)

3. Listener on DB server (on-premise)

4. Data Pump export with FILESIZE to appropriate size e.g.

– DIRECTORY=dpexports

– DUMPFILE=export_<DB_NAME>_%U.dmp

– LOGFILE=export_<DB_NAME>.log

– FILESIZE=10G

– FLASHBACK_TIME=systimestamp

– SCHEMAS=X,Y,Z


DAE – method (Data Pump)

5. As the Data Pump export is running, use xcopy to transfer the export files

– Data Pump export files are not change after they are written with the exception of the first file that is changed after the export is completed

– e.g. xcopy g:\data_pump\ \\dc1sbxdb001\g$\data_pump /E /D /Y

– Run as bat file via the Windows Scheduler

6. Data Pump import and post steps

7. Start listener on DB server (Azure)

8. Change DNS so to point CNAME for database to Azure server

9. Start application (Azure)

Total downtime: 3-4 hours including testing


CUP – before (on-premise)

• Physical Servers

• Linux x86 64-bit

• Oracle Database Standard Edition 11.2.0.4 RAC

• Largest database ~1.2TB


CUP – requirements

• Minimal downtime very important

• Upgrade not priority

• Bandwidth: shared 1GB out to internet for VPN


CUP – after (AWS)

• Infrastructure as a Service (IaaS)

• Oracle Linux 7.6 (Version 1 AMI)

• Oracle Database Standard Edition 11.2.0.4 (non RAC)

• Locations: Dublin

• Instance type: m5.xlarge to m5.4xlarge

• EBS volumes for (sized for the provisioned IOPS):

– /u01 for binaries

– /u02 for ORADATA

– /u03 for FRA


CUP – method (manual standby)

• Based on MOS note:

– Alternative for standby database in standard edition (Doc ID 333749.1)

1. Create DB server in AWS with identical Oracle version and patchset to on-premise

2. Set archive_lag_target=1800 on database to switch logfile every 30 minutes (on-premise)

3. Setup rsync job in crontab to transfer archive logs from on-premise to AWS

4. Take RMAN compressed backup including archive logs (on-premise)

5. Transfer RMAN compressed backup from on-premise to AWS

6. Restore RMAN backup (AWS)

7. Recover database using archive logs (AWS)

8. Setup recovery job in crontab to recover database (AWS)



9. Stop application (on-premise)

10. Stop DB listener (on-premise)

11. Shutdown database and startup in restricted mode (on-premise)

12. Flush redo to archive logs (on-premise)

– alter system archive log current;

13. Transfer the final archive logs from on-premise to AWS

14. Recover database apply latest archive logs (AWS)

15. Open database read-only (AWS) and carry out comparisons to on-premise/smoke tests



16. If passed checks

– alter database open resetlogs;

17. Post steps

– Gather systems and I/O statistics

– Redo log optimisation (size, number of groups, etc)

– Re-install statspack

18. Start listener on DB server (AWS)

19. Carry out post migration checks

20. If passed checks

– Change DNS so to point CNAME for database to AWS DB server

21. Start application (AWS)

Total downtime: 1-2 hours including testing


Making migration successful

• Planning

– Capacity planning CPU, IOPS, memory

• Stats from statspack

– Licensing

• Ensure use correct entitlement

• Optimise

• Testing

– Carry out Proof of Concept

– Soak/functional/regression testing

– Carry out dry runs/dress rehearsals


UK HQ

6 Brownlow Mews,

London, WC1N 2LD

t: + 44 203 859 4790

w: version1.com

e: [email protected]

Ireland HQ

Millennium House, Millennium

Walkway, Dublin 1, D01 F5P8

t: +353 1 865 7800

w: version1.com

e: [email protected]

Thank you for [email protected]

Follow me on:facebook.ZedDBA.com (page)twitter.ZedDBA.com or @ZedDBALinkedIn.ZedDBA.comwww.ZedDBA.com

https://www.google.ie/maps/place/Version+1/@53.3469646,-6.2652364,17z/data=!4m12!1m6!3m5!1s0x48670e82fa5e0e7d:0x399dc20cab7b0ad!2sVersion+1!8m2!3d53.3469776!4d-6.2651484!3m4!1s0x48670e82fa5e0e7d:0x399dc20cab7b0ad!8m2!3d53.3469776!4d-6.2651484

http://facebook.zeddba.com/

http://twitter.zeddba.com/

http://linkedin.zeddba.com/

http://www.zeddba.com/

database standard edition cloud migration success stories

Documents