8i | 9i | 10g | 11g | 12c | 13c | 18c | 19c | 21c | 23c | Misc | PL/SQL | SQL | RAC | WebLogic | Linux

Home » Articles » Misc » Here

Oracle Databases in the Cloud

This article presents an overview of options for deploying Oracle databases in the cloud.

Terms
A Word about Pricing
General Oracle Licensing for Cloud Providers
Oracle Cloud
Amazon AWS (EC2 and RDS)
Microsoft Azure
Google Cloud Platform
Quick Tips
Concerns
Middle Tier in the Cloud

Terms

Some common terms used in this article.

Infrastructure as a Service (IaaS): Virtual hardware supplied by the cloud vendor. This can include Virtual Machines (VMs), Storage, DNS, load balancers, VLANs and VPN amongst other things. This is like having your machines in someone else's data center. Your day-to-day job will be unchanged. (read more)
Platform as a Service (PaaS): Typically a whole environment packaged as a service. For example, operating system and database, or operating system and application server. Some vendors now supply whole development environments, including development tools, in this manner. This should come with tooling to make your day-to-day job easier. It will probably also limit your access to the underlying infrastructure. (read more)
Software as a Service (SaaS): Applications delivered over the cloud. You have no involvement in the installation, upgrades or management of the service. You are just a user. (read more)
Database as a Service (DBaaS): The database is hosted and managed by the cloud provider. Typically this will include cloud-based tooling to reduce the work done by system administrators and DBAs. DBaaS is a PaaS offering.
Bring Your Own License (BYOL): You buy the Oracle licenses directly from Oracle, so the cloud provider is not responsible for charging or validating your licenses.
On-Demand License: The cost of the cloud service includes the Oracle licensing. This is useful for short-term PoCs, but ultimately ends up being more expensive than BYOL.
Proof of Concept (PoC): Short term tests to prove something is possible. Systems will typically be scrapped at the end of the PoC.

A Word about Pricing

I've avoided mentioning pricing in this article for the following reasons.

Some of the DBaaS offerings include the On-Demand Licensing costs, which make them seem incredibly expensive at first sight. Some allow a switch to BYOL, some do not.
Oracle list prices are not indicative of the actual costs.
Cloud pricing varies depending on a number of variables, including performance, disk space, memory, network traffic, length of contract. The cost and viability of a cloud database would have to be judged on a case-by-case basis.
Many cloud services are priced by the hour, but reserving a service for an extended period of time (1-3 years) will give a heavily discounted price.
High Availability costs money. Failover to another host in the data centre is normal. Failover to a different data centre is an extra cost. The level of availability has to be factored into the costs.

General Oracle Licensing for Cloud Providers

For certified cloud providers (Oracle, AWS, Microsoft Azure) Oracle products are licensed based on a physical core on the cloud. The relationship used to be a physical core in the cloud was the equivalent of a physical Intel core.

Physical Cores = vCPUs

How the physical cores are presented in the cloud depends on the cloud provider.

AWS : If hyperthreading is enabled, each vCPU is associated with a single thread, so 2 vCPUs equal 1 physical core. If hyperthreading is not enabled, 1 vCPU equals 1 physical core.
Azure : If hyperthreading is enabled, each vCPU is associated with a single thread, so 2 vCPUs equal 1 physical core. If hyperthreading is not enabled, 1 vCPU equals 1 physical core.

The licensing multiplier for Intel cores is “0.5”. Prior to the update on the 23-Jan-2017 the cloud licensing policy could be described as follows.

Type            vCPUs    Physical Cores    Licenses
============    =====    ==============    ===========
AWS HT             16                 8    8 * 0.5 = 4
AWS Non-HT          8                 8    8 * 0.5 = 4
Azure HT           16                 8    8 * 0.5 = 4
Azure Non-HT        8                 8    8 * 0.5 = 4
Physical          N/A                 8    8 * 0.5 = 4

The cloud licensing policy document changed on 23-Jan-2017 to say that, "When counting Oracle Processor license requirements in Authorized Cloud Environments, the Oracle Processor Core Factor Table is not applicable." This suggests the following licensing approach.

Type            vCPUs    Physical Cores    Licenses
============    =====    ==============    ===========
AWS HT             16                 8              8
AWS Non-HT          8                 8              8
Azure HT           16                 8              8
Azure Non-HT        8                 8              8
Physical          N/A                 8    8 * 0.5 = 4

All features/options are licensed in the normal way, based on the above formula. Licensing for Standard Edition is based on sockets. The relationship between physical cores and sockets is described in the document linked below. This licensing policy is described in the following document.

Licensing Oracle Software in the Cloud Computing Environment

You should always confirm your licensing requirements with Oracle Licensing Management Services (LMS) or an official licensing partner before embarking on any work with Oracle products in the cloud. It is important you have a contract specifying what you will be using and what you will pay to use it!

Oracle Cloud

The Oracle Cloud Database offerings and pricing structure are described here.

Oracle Database

Oracle currently offer a number of distinct cloud database services. They change all the time.

Database Cloud Service - Virtual Machines : A virtual machine with the Oracle software pre-installed and tooling to simplify the management. This is a customer managed service.
Database Cloud Service - Bare Metal : Similar to the VM offering, but the database isn't running inside a virtual machine. This is a customer managed service.
Exadata Cloud Service : An Exadata system housed in an Oracle data centre, with additional tooling. This is a customer managed service.
Exadata Cloud at Customer : The same Exadata Cloud Service experience, but the server(s) are located in your own data centre.
Autonomous Data Warehouse : A fully managed warehouse solution based on the Oracle database running on Exadata.
Autonomous Transaction Processing : A fully managed OLTP solution based on the Oracle database running on Exadata.
Autonomous JSON Database : A fully managed JSON database solution based on the Oracle database running on Exadata.
MySQL Service: A MySQL cloud service.
NoSQL : A NoSQL cloud service.
Big Data (SQL) Cloud Service : Cloud services based on the Hadoop ecosystem. That can include the Oracle Big Data SQL functionality

You can see examples of using some database services here.

Amazon AWS (EC2 and RDS)

Amazon’s cloud platform is called Amazon Web Services (AWS), which amongst many other services allows Oracle databases to be run in two distinct ways.

Elastic Compute Cloud (EC2) : A conventional virtual machine that is self-managed. You pay for the VM (compute power, storage and network traffic) like any AWS VM. Oracle licensing is your responsibility, BYOL.
Relational Data Services (RDS) for Oracle : A DBaaS offering, with no OS system administration and tooling to greatly reduce DBA work. This can be licensed using BYOL or On-Demand Licensing. Some functionality, including file system access, is restricted or prevented entirely, as is typical of many DBaaS offerings. There are also RDS offerings for MySQL, MariaDB, Amazon Aurora, PostgreSQL and MS SQL Server.

Both methods allow SQL*Net access to the database, so existing applications can connect without modification to the technology stack.

You can see examples of using EC2 and RDS here.

There are other targeted data services, which are not based on Oracle technology.

DynamoDB : A NoSQL solution.
ElasticCache : An in-memory caching solution.
Nepture : A graph database solution.
Redshift : A focused data warehouse solution.
DocumentDB: A document database, based on MongoDB.

Microsoft Azure

Oracle certifies and supports many of their products on Microsoft’s hypervisor (Hyper-V) and their cloud services called Azure.

There is no DBaaS offering for Oracle, so if you want to use Azure, you would be responsible for the management of the operating systems and database in the virtual machines.

You can see an example of using Azure here.

Installation of an Oracle Database on Azure

There are a number of Azure data services not based on Oracle.

SQL Server on VM : As the name suggests, this is a virtual machine with SQL Server installed on it.
Azure SQL Database : A managed service based on SQL Server.
SQL Data Warehouse : A managed service focused data warehouse solution.
Azure Database for MySQL : A managed service based on MySQL.
Azure Database for MariaDB : A managed service based on MariaDB.
Azure Database for PostgreSQL : A managed service based on PostgreSQL.
A number of additional focused products for NoSQL, Caching, distributed architectures and enterprise scale data management.

Google Cloud Platform

The Oracle database isn't supported to run on Google Cloud Platform, although it would certainly work if you installed it on a Linux or Windows virtual machine.

Google offer a number of data services to target different use cases.

Cloud Bigtable : A scalable NoSQL solution.
Cloud Datastore : A NoSQL document store.
Cloud SQL : Managed MySQL and PostgreSQL solutions.
Cloud Spanner : A highly scalable and highly available relational database solution.
BigQuery : A fully managed data warehouse solution with SQL support.

Quick Tips

Using X emulation from most cloud providers is incredibly slow and painful, but it's easy to avoid it.

Get used to doing silent installations! Build a response file on a client using the Oracle Universal Installer (OUI).

$ ./runInstaller -record -destinationFile /tmp/11gR2.rsp

Use the response file on the cloud server to perform a silent installation.

$ ./runInstaller -silent -ignoreSysPrereqs -responseFile /tmp/11gR2.rsp

In a similar way, you should get used to using the Database Configuration Assistant (DBCA) in silent mode. You can either specify all parameters on the command line, or use a response file.

$ dbca -silent -createDatabase \
 -templateName General_Purpose.dbc \
 -gdbname cdb1 -sid cdb1 -responseFile NO_VALUE \
 -characterSet AL32UTF8 \
 -sysPassword OraPasswd1 \
 -systemPassword OraPasswd1 \
 -createAsContainerDatabase true \
 -numberOfPDBs 1 \
 -pdbName pdb1 \
 -pdbAdminPassword OraPasswd1 \
 -databaseType MULTIPURPOSE \
 -memoryMgmtType auto_sga \
 -storageType FS \
 -ignorePreReqs

Connections to cloud services are over public networks (the internet), so you need to make sure all connections are encrypted. This is easy to do with Oracle using Native Network Encryption or TCP/IP with SSL/TLS.

Concerns

There are a number of concerns associated with moving any service to the cloud. These have to be considered on a case-by-case basis.

Legal Jurisdiction : Jurisdiction is not as simple as it may seem. The laws in the European Union are relatively clear cut, but depending on the service you are offering, the data may be considered to be owned by the user, not your company, in which case jurisdiction is based on the location of the user, not your company or the cloud provider’s location.
Security : How happy are you to have the systems off site? Remember, encrypt everything!
Network Latency : The databases cannot be considered in isolation. At minimum, the locations of the application servers need to be considered, see below, but this is the tip of the iceberg. The latency of DB-to-DB communication (DB links) could be an issue if both databases are not hosted by the same cloud provider. Data loads from ETL tools will also be affected if they are not collocated. Latency issues will need to be investigated.
Traffic Costs : Some cloud services charge for network bandwidth usage. Any data transfers between servers will have a cost implication. Transfer of unnecessary data will have a cost implication.
Transfer Technology : Some DBaaS offerings will not allow access to the server file system, so any batch scripts or sFTP operations will not be possible. This may affect the choice of a service.
Migration : Even if a service provides exactly what you need, you have to consider the impact of trying to migrate to that platform. Uploading datafiles can be very time consuming.
Cost : As explained earlier, it is actually quite difficult to judge the realistic cost of some services, since they incorporate factors we do not normally consider, like network traffic, and on-demand licensing. The Total Cost of Ownership (TCO) must also take into account the savings associated with automation. System administrators and DBAs can now manage much greater numbers of services if some of their workload is removed due to use of DBaaS offerings. In some cases, the use of DBaaS may actually reduce the need for system administrators and DBAs to the point where their roll to be taken over by the development teams directly.

Middle Tier in the Cloud

One of the concerns about moving a database to the cloud relates to the latency and data transfers between the application servers and databases. All the cloud providers listed above would allow you to run WebLogic, Apache and Tomcat in the cloud, thereby minimizing any latency issues between them.

The impact of possible separation of the between the database and application server must be assessed on a case by case basis.

For more information see:

Hope this helps. Regards Tim...

Back to the Top.