As we deal with Database as a Service use cases, we often find that consumers do not need dedicated databases of their own. Developers of a home-grown application, for example, might be satisfied with a logical slice of the database. This logical slice, leads us to the concept of Schema as a Service—a new capability offered in the latest release of Oracle Enterprise Manager 12c Release 2 Plug-in Update 1.
Schema as a service is the ultimate and extreme in consolidating multiple schemas in a shared database model. Cloud users can request one or more schemas, with or without seed data, from Oracle Enterprise Manager 12c’s out-of-the-box self service portal. It offers excellent manageability, not only for its fast efficient provisioning, but because administrators only need to manage a small number of databases.
Schema as a Service: Consolidate Multiple Schemas in a Shared Database Cloud Services Model
However, consolidation comes at the expense of isolation, because the operating system and database are not isolated among the database consumers. While enabling Schema as a Service, it’s important to isolate the workloads as much as possible to make sure that one user doesn't run away with all the database resources. Administrators can guarantee this does not happen by using Oracle Enterprise Manager 12c’s CPU monitoring capabilities built in to Oracle Database Resource Manager to maintain service levels.
For security, the more consolidated you get, the more concerns administrators have about data isolation and security. Using Oracle Data Vault can help resolve these issues. It is integrated with Oracle Enterprise Manager 12c, and administrators can use Oracle Data Vault to enable fine grain control based on roles and privileges within the database cloud service.
For reporting purposes, metering and chargeback capabilities can be implemented to help IT organizations gain in-depth visibility into resource consumption and expenses incurred with each schema as a service deployment. This is useful for regulatory compliance requirements as well.
Schema as a Service at a Glance:
Consolidate multiple application schemas in a shared database deployment model
Each application user (i.e. developers or testers) can provision one or more database schema(s) with a dedicated database cloud service
Automated placement can be based on workload characteristics and specifications
Service levels are guaranteed through Oracle Database Resource Manager
Service governance is done through quotas, retirement policies and chargeback plans
Integrated with Oracle Data Vault for security isolation and control
De-provision schemas when needs change
Save resources through ultimate consolidation of multiple database applications
Boost administrator productivity and increase efficiency with automated provisioning
Deploy schema as a service implementations consistently using self-service profiles and templates
Metering and chargeback helps keep track of resource consumption and usage for accountability and reporting
Minimize administrative overhead and compliance challenges by preventing database sprawl
How To: There are several steps involved when setting up and deploying database schema as a service in Oracle Enterprise Manager’s self service portal. Here is a quick summary of what’s involved. For more details be sure to review the resources below.
1. Setting up Platform as a Service Zones
Before deploying your schema as a service, you first need to create a Platform as a Service (PaaS) infrastructure using Oracle Enterprise Manager 12c’s self-service portal. A PaaS Zone comprises multiple hosts, i.e. servers with Oracle Enterprise Manager 12c agent installed.
Use the portal to create a PaaS zone and organize it by function type (i.e. based on geography, line of business (sales, development) or application lifecycle. (i.e. dev, test, QA, production)
Next expose the PaaS zone to the self-service cloud users in the portal. For example, developers can now have the option to select a development PaaS zone or testers can select a QA zone.
Visibility of each zone can be restricted based on the self-service user's credentials.
2. Setting up Database Pools
Database pools are a collects of databases used to host schema as a service.
To create a new database pool, you can use a portion of resources that are available to the zone. Keep in mind that all members of the database pool need to be the same target type. For example, a single database instance or database cluster; platform, or same database version. This ensures provisioning consistency during deployment.
Next configure placement constraints and policies for the database pool. For placing databases within the pool and controlling how resources are utilization, you need to first create a placement constraint and set its policies. This provides protection for the database members within the pool for resource consumption. For example, a production database pool might enforce more conservative constraints whereas a development pool might allow liberal limits.
You can set a constraint for each database in the pool by services or by workload associated with the service request based on CPU and memory. You can also enable Oracle Database Resource Manager for the database pool to control your CPU usage and the underlying service levels.
3. Request Settings
During this part of the schema as a service set up, future reservations, archive retention and duration of request can all be enabled.
Controlling quotas and setting limits for users based on role level can be assigned in this step of the process. Oracle Enterprise Manager supports quota based on CPU, memory and number of database services.
5. Profiles and Service Templates
A service template is standardized definition that is offered to self-service users to create a database or schemas within the deployment. A service template defines the workload characteristics and schema details that can be generated with or without seed data.
To create a service template with seed data, you need to create a profile. A profile is an entity that captures source database information for provisioning purposes. Once you create your service template it becomes part of a collection which makes up the service catalog. This catalog is then exposed to cloud users in the self-service portal.
Next, you can either export the seed data from the source database or export the schema definitions without the data. Once you decide, a Data Pump Export job will be created.
You can now map your newly created profile and service templates to the required zone(s) and database pools.
The final step in deploying schema as a service is to configure resource metering and chargeback.
Setting up metering and chargeback can easily be done in order to track resource usage within the schema as a service implementation.
For more information on how to set up chargeback we recommend reading this white paper.