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
Copyright ©2019 Version 1. All rights reserved.2
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
Copyright ©2019 Version 1. All rights reserved.3
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.
Copyright ©2019 Version 1. All rights reserved.4
Trusted to Deliver Customer Success
Copyright ©2019 Version 1. All rights reserved.5
Database Standard Edition
Cloud Migration
Success Stories
Copyright ©2019 Version 1. All rights reserved.6
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/
Copyright ©2019 Version 1. All rights reserved.7
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
Copyright ©2019 Version 1. All rights reserved.8
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
Copyright ©2019 Version 1. All rights reserved.9
Standard Edition License Limitations SE1
• SE1
– 2 sockets max (single server, no RAC option)
– 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
Copyright ©2019 Version 1. All rights reserved.10
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
– No core limit on premise
• Uses a maximum of 16 threads or 8 when RAC
– 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)
– Premier Support till July 2018 with Extended Support till July 2021
– Latest Versions available 12.1.0.2 and 12.2.0.1
Copyright ©2019 Version 1. All rights reserved.11
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)
Copyright ©2019 Version 1. All rights reserved.12
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)
Copyright ©2019 Version 1. All rights reserved.13
Copyright ©2019 Version 1. All rights reserved.14
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)
Copyright ©2019 Version 1. All rights reserved.15
DAE – requirements
• Upgrade to latest stable version
• Flexible on downtime
• Initially 20Mbps then 200Mbps with ExpressRoute
Copyright ©2019 Version 1. All rights reserved.16
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)
Copyright ©2019 Version 1. All rights reserved.17
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
Copyright ©2019 Version 1. All rights reserved.18
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
Copyright ©2019 Version 1. All rights reserved.19
Copyright ©2019 Version 1. All rights reserved.20
CUP – before (on-premise)
• Physical Servers
• Linux x86 64-bit
• Oracle Database Standard Edition 11.2.0.4 RAC
• Largest database ~1.2TB
Copyright ©2019 Version 1. All rights reserved.21
CUP – requirements
• Minimal downtime very important
• Upgrade not priority
• Bandwidth: shared 1GB out to internet for VPN
Copyright ©2019 Version 1. All rights reserved.22
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
Copyright ©2019 Version 1. All rights reserved.23
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)
Copyright ©2019 Version 1. All rights reserved.24
CUP – method (manual standby)
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
Copyright ©2019 Version 1. All rights reserved.25
CUP – method (manual standby)
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
Copyright ©2019 Version 1. All rights reserved.26
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
Copyright ©2019 Version 1. All rights reserved.27
UK HQ
6 Brownlow Mews,
London, WC1N 2LD
t: + 44 203 859 4790
w: version1.com
Ireland HQ
Millennium House, Millennium
Walkway, Dublin 1, D01 F5P8
t: +353 1 865 7800
w: version1.com
Thank you for [email protected]
Follow me on:facebook.ZedDBA.com (page)twitter.ZedDBA.com or @ZedDBALinkedIn.ZedDBA.comwww.ZedDBA.com