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
Benefits: - 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.
4. Quotas - 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.
6. Chargeback - 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.
|
