Oracle Enterprise Manager 12.1.0.4 (or simply put EM12c R4) is the latest update to the product. As previous versions, this release provides tons of enhancements and bug fixes, attributing to improved stability and quality. One of the areas that is most exciting and has seen tremendous growth in the last few years is that of Database as a Service. EM12c R4 provides a significant update to Database as a Service. The key themes are:
Comprehensive Database Service Catalog (includes single instance, RAC, and Data Guard)
Additional Storage Options for Snap Clone (includes support for Database feature CloneDB)
Improved Rapid Start Kits
Extensible Metering and Chargeback
Miscellaneous Enhancements
1. Comprehensive Database Service Catalog
Before we get deep into implementation of a service catalog, lets first understand what it is and what benefits it provides. Per ITIL, a service catalog is an exhaustive list of IT services that an organization provides or offers to its employees or customers. Service catalogs have been widely popular in the space of cloud computing, primarily as the medium to provide standardized and pre-approved service definitions. There is already some good collateral out there that talks about Oracle database service catalogs. The two whitepapers i recommend reading are:
Service Catalogs: Defining Standardized Database Service
High Availability Best Practices for Database Consolidation: The Foundation for Database as a Service [Oracle MAA]
EM12c comes with an out-of-the-box service catalog and self service portal since release 1. For the customers, it provides the following benefits:
Present a collection of standardized database service definitions,
Define standardized pools of hardware and software for provisioning,
Role based access to cater to different class of users,
Automated procedures to provision the predefined database definitions,
Setup chargeback plans based on service tiers and database configuration sizes, etc
Starting Release 4, the scope of services offered via the service catalog has been expanded to include databases with varying levels of availability - Single Instance (SI) or Real Application Clusters (RAC) databases with multiple data guard based standby databases. Some salient points of the data guard integration:
Standby pools can now be defined across different datacenters or within the same datacenter as the primary (this helps in modelling the concept of near and far DR sites)
The standby databases can be single instance, RAC, or RAC One Node databases
Multiple standby databases can be provisioned, where the maximum limit is determined by the version of database software
The standby databases can be in either mount or read only (requires active data guard option) mode
All database versions 10g to 12c supported (as certified with EM 12c)
All 3 protection modes can be used - Maximum availability, performance, security
Log apply can be set to sync or async along with the required apply lag
The different service levels or service tiers are popularly represented using metals - Platinum, Gold, Silver, Bronze, and so on. The Oracle MAA whitepaper (referenced above) calls out the various service tiers as defined by Oracle's best practices, but customers can choose any logical combinations from the table below:
Primary
Standby [1 or more]
EM 12cR4
SI
-
SI
SI
RAC
-
RAC
SI
RAC
RAC
RON
-
RON
RON
where RON = RAC One Node is supported via custom post-scripts in the service template
A sample service catalog would look like the image below. Here we have defined 4 service levels, which have been deployed across 2 data centers, and have 3 standardized sizes. Again, it is important to note that this is just an example to get the creative juices flowing. I imagine each customer would come up with their own catalog based on the application requirements, their RTO/RPO goals, and the product licenses they own. In the screenwatch titled 'Build Service Catalog using EM12c DBaaS', I walk through the complete steps required to setup this sample service catalog in EM12c.
2. Additional Storage Options for Snap Clone
In my previous blog posts, i have described the snap clone feature in detail. Essentially, it provides a storage agnostic, self service, rapid, and space efficient approach to solving your data cloning problems. The net benefit is that you get incredible amounts of storage savings (on average 90%) all while cloning databases in a matter of minutes. Space and Time, two things enterprises would love to save on. This feature has been designed with the goal of providing data cloning capabilities while protecting your existing investments in server, storage, and software. With this in mind, we have pursued with the dual solution approach of Hardware and Software. In the hardware approach, we connect directly to your storage appliances and perform all low level actions required to rapidly clone your databases. While in the software approach, we use an intermediate software layer to talk to any storage vendor or any storage configuration to perform the same low level actions. Thus delivering the benefits of database thin cloning, without requiring you to drastically changing the infrastructure or IT's operating style.
In release 4, we expand the scope of options supported by snap clone with the addition of database CloneDB. While CloneDB is not a new feature, it was first introduced in 11.2.0.2 patchset, it has over the years become more stable and mature. CloneDB leverages a combination of Direct NFS (or dNFS) feature of the database, RMAN image copies, sparse files, and copy-on-write technology to create thin clones of databases from existing backups in a matter of minutes. It essentially has all the traits that we want to present to our customers via the snap clone feature. For more information on cloneDB, i highly recommend reading the following sources:
Blog by Tim Hall: Direct NFS (DNFS) CloneDB in Oracle Database 11g Release 2
Oracle OpenWorld Presentation by Cern: Efficient Database Cloning using Direct NFS and CloneDB
The advantages of the new CloneDB integration with EM12c Snap Clone are:
Space and time savings
Ease of setup - no additional software is required other than the Oracle database binary
Works on all platforms
Reduce the dependence on storage administrators
Cloning process fully orchestrated by EM12c, and delivered to developers/DBAs/QA Testers via the self service portal
Uses dNFS to delivers better performance, availability, and scalability over kernel NFS
Complete lifecycle of the clones managed by EM12c - performance, configuration, etc
3. Improved Rapid Start Kits
DBaaS deployments tend to be complex and its setup requires a series of steps. These steps are typically performed across different users and different UIs. The Rapid Start Kit provides a single command solution to setup Database as a Service (DBaaS) and Pluggable Database as a Service
(PDBaaS). One command creates all the Cloud artifacts like Roles,
Administrators, Credentials, Database Profiles, PaaS Infrastructure
Zone, Database Pools and Service Templates. Once the Rapid Start Kit has
been successfully executed, requests can be made to provision
databases and PDBs from the self service portal. Rapid start kit can create complex topologies involving multiple
zones, pools and service templates. It also supports standby databases
and use of RMAN image backups.
The Rapid Start Kit in reality is a simple emcli script which takes a bunch of xml files as input and executes the complete automation in a matter of seconds. On a full rack Exadata, it took only 40 seconds to setup PDBaaS end-to-end. This kit works for both Oracle's engineered systems like Exadata, SuperCluster, etc and also on commodity hardware. One can draw parallel to the Exadata One Command script, which again takes a bunch of inputs from the administrators and then runs a simple script that configures everything from network to provisioning the DB software.
Steps to use the kit:
The kit can be found under the SSA plug-in directory on the OMS: EM_BASE/oracle/MW/plugins/oracle.sysman.ssa.oms.plugin_12.1.0.8.0/dbaas/setup
It can be run from this default location or from any server which has emcli client installed
For most scenarios, you would use the script dbaas/setup/database_cloud_setup.py
For Exadata, special integration is provided to reduce the number of inputs even further. The script to use for this scenario would be dbaas/setup/exadata_cloud_setup.py
The database_cloud_setup.py script takes two inputs:
Cloud boundary xml: This file defines the cloud topology in terms of the zones and pools
along with host names, oracle home locations or container database
names that would be used as infrastructure for provisioning database services. This file is optional in case of Exadata, as the boundary is well know via the Exadata system target available in EM.
Input xml: This file captures inputs for users, roles, profiles, service templates, etc. Essentially, all inputs required to define the DB services and other settings of the self service portal.
Once all the xml files have been prepared, invoke the script as follows for PDBaaS:
emcli @database_cloud_setup.py -pdbaas
-cloud_boundary=/tmp/my_boundary.xml
-cloud_input=/tmp/pdb_inputs.xml
The script will prompt for passwords a few times for key users like sysman, cloud admin, SSA admin, etc. Once complete, you can simply log into EM as the self service user and request for databases from the portal.
More information available in the Rapid Start Kit chapter in Cloud Administration Guide.
4. Extensible Metering and Chargeback
Last but not the least, Metering and Chargeback in release 4 has been made extensible in all possible regards. The new extensibility features allow customer, partners, system integrators, etc to :
Extend chargeback to any target type managed in EM
Promote any metric in EM as a chargeback entity
Extend list of charge items via metric or configuration extensions
Model abstract entities like no. of backup requests, job executions, support requests, etc
A slew of emcli verbs have also been added that allows administrators to create, edit, delete, import/export charge plans, and assign cost centers all via the command line.
More information available in the Chargeback API chapter in Cloud Administration Guide.
5. Miscellaneous Enhancements
There are other miscellaneous, yet important, enhancements that are worth a mention. These mostly have been asked by customers like you. These are:
Custom naming of DB Services
Self service users can provide custom names for DB SID, DB service, schemas, and tablespaces
Every custom name is validated for uniqueness in EM
'Create like' of Service Templates
Now creating variants of a service template is only a click away. This would be vital when you publish service templates to represent different database sizes or service levels.
Profile viewer
View the details of a profile like datafile, control files, snapshot ids, export/import files, etc prior to its selection in the service template
Cleanup automation - for failed and successful requests
Single emcli command to cleanup all remnant artifacts of a failed request
Cleanup can be performed on a per request bases or by the entire pool
As an extension, you can also delete successful requests
Improved delete user workflow
Allows administrators to reassign cloud resources to another user or delete all of them
Support for multiple tablespaces for schema as a service
In addition to multiple schemas, user can also specify multiple tablespaces per request
I hope this was a good introduction to the new Database as a Service enhancements in EM12c R4. I encourage you to explore many of these new and existing features and give us feedback.
Good luck!
References:
Cloud Management Page on OTN
Cloud Administration Guide [Documentation]
-- Adeesh Fulay (@adeeshf)
