Database as a Service (DBaaS) using Enterprise Manager 12c Cloud Control

One of the challenges faced today in the database provisioning process is time to deliver.

Consider a normal workflow in this case.

A developer requests a database. It then goes to his manager for approval.Once that stage is passed the DBA comes into the picture and the DBA in turn will contact the Storage and System Admin to request the hardware and storage. There could be OS and Network setup involved as well and then finally the DBA will create the database and then provide access to the developer.

Typically this can take days and sometimes weeks as well – using DBaaS with EM12c we reduce the time to deliver to minutes!

Not only is this time consuming and inefficient but this very process has caused the problems we face today around database and server sprawl, multiple versions and patch levels, high cost of deployment and operation, poor resource utilization – the current state of most database deployments is largely siloed and complex.

In this example we see a use case of DBaaS where a Developer is able to create an Oracle 12c pluggable database without any intervention of the DBA by submitting a Service Request using a Service Catalog– but the DBA still controls what the developers can and cannot do.

We will introduce DBaaS concepts like Platform as a Service (PaaS) Infrastructure Zones, Database Resource Pools, Service Templates, Quotas, Service Catalogs and finally an example of Chargeback and Metering as well.

We have created two users for the example – CLOUD_ADMIN and DEV_SSA and a CLOUD_SSA Role as well.

Connect as the CLOUD_ADMIN user
 
From the Setup –Cloud –PaaS Infrastructure Zones menu
 

 
A PaaS Infrastructure Zone is a collection of Host targets or an OVM zone. Hosts are targets identified in Enterprise Manager and a single host can be a member of only one PaaS Zone.

We also associate the SSA role we created earlier so as to regulate access to the PaaS Infrastructure Zone.

We also have to provide the host credentials of the members the PaaS Zone is comprised of.

Placement policy constraints can be used to specify a ceiling or limit on the amount of resources any host in the zone can use

 
The next step is to create a Database Resource Pool – this will be based on databases and Oracle Homes existing on the hosts that make up the PaaS Infrastructure Zone.

A Database Pool is a collection of resources (homogenous databases and Oracle Homes) to provision a database instance within a PaaS Infrastructure Zone – so basically the same platform, type and version.

We can create a Database Pool for Database as a Service, Schema as a Service or PDB as a service.

Also at the Database Resource Pool level we can specify some placement constraints to control resource utilization.

Through the use of Quotas we can also control and limit resource utilization at the SSA user or role level.

From the Setup – Cloud – Databases menu
 

The services that are offered to SSA Cloud users are defined via Service Templates. A Service Template can be also based on a database provisioning Profile.

In this example we are creating a service template for provisioning an EMPTY PLUGGABLE DATABASE.

The PaaS Infrastructure Zone earlier created is associated with the Service Template and we also assign the Database Resource Pool as well. In this way we are regulating which hosts or OVM zones can be used by a particular SSA user as well as the type of database that can be created via the Self Service Portal.

The Service Template can also define other things like the number of tablespaces which will be created in the pluggable database, the total size of the PDB, init.ora parameters and other resource limits like number of database sessions etc.

Next connect as the DEV_SSA Cloud SSA user

From the Cloud menu select Self Service Portal

The DEV_SSA user will request the creation of a 12c Pluggable Database from the Service Catalog available via the Self Service Portal.

Note that the DEV_SSA user has been provided in this example a limit of just one single service request and a quota of 1 GB of RAM and 1 GB of disk space and this quota is exhausted when he submits the service request for the creation of the pluggable database.

After submitting the service request the user can track the progress of the request.

After the request completes a Pluggable Database has been created and is now available for use by the developer.

So in this case a developer has created a 12c Pluggable Database with no involvement of the DBA or the System Administrator or Storage Administrator in a few minutes. The DBA or Cloud Administrator still controls which physical host the database is created on ,which Container Database the pluggable database is a tenant of, how much resources can be allocated in terms of disk space, RAM and CPU.

This is EM12c enabling Database as a Service!

Let us take a brief look at how Chargeback and Metering work in a DBaaS model.

Simply put,based on resource usage charges are calculated and then allocated or metered to individual cost centers who are consumers of the Database as a Service offering.

In this example we create a charge plan for the Pluggable Database entity and the metric being used to calculate the charges is Uptime of the database.

The user is being charged a rate of 10$ per hour of database uptime.
 

 
 
The SSA user can also view a number of reports of the Metering and Charges and there is an Enterprise Manager job which runs once in a 24 hour period collecting such data which is displayed in the reports.

In this case we are forcing the manual collection of data and once the job completes we can see a number of graphical reports on Chargeback data showing the usage or consumption and amount which is payable for usage of the service and the same is displayed on a daily basis as well in case the user wishes to get a day by day breakdown of the Chargeback.