Oracle Enterprise Manager 12c provides a rich set of metrics for
monitoring database health and alerting when problems are encountered.
In this educational webcast we will demonstrate the steps needed to set
up and customize metrics monitoring in EM to meet the needs of your
business. We will also cover the use of management repository views to
access historical metrics data for performing additional analyses and
graphics presentation outside of EM. Join this webcast to learn how to:
• Identify and describe the steps needed to implement administration
groups / template collection associations in order to customize
monitoring requirements for various targets based on the needs of your
• Build queries using the EM management repository views to extract
metric data for historical analysis, trending, and graphing; and
• Identify how EM uses rollup tables to summarize metric data on an hourly and daily basis.
Oracle's Middleware as a Service (MWaaS) solution for enterprise private cloud provides a complete application development and deployment environment. It includes a complete runtime environment comprised of all services necessary to deploy and run an enterprise-class application, including services such as application hosting, persistence store, application integration and APIs that enable programmatic access to additional computing services that might be required by an application. Identity services are an example of APIs available within a PaaS environment. MWaaS facilitates cheaper and faster deployment of applications as developers need not deal with the complexities of the underlying hardware and software components.
Oracle recently published a cookbook for Middleware as a Service using Oracle Enterprise Manager 12c. This document explains the step-by-step instructions in provisioning a WebLogic domain using Oracle Enterprise Manager 12c . These steps include:
Security Configuration for Named Credentials, Roles and Accounts for Cloud Management
Using Out of Box WebLogic profiles shipped with Oracle Enterprise Manager 12c R2
Customizing WebLogic domain creation procedures to your environment and business requirements
Setting up the Middleware Zones
Setting quota limits for each cloud management roles
Definition of Service Templates to be used for middleware domain creation
Configuring chargeback policies for your middleware cloud infrastructure
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
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
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.
a Service at a Glance:
application schemas in a shared database deployment model
user (i.e. developers or testers) can provision one or more database
schema(s) with a dedicated database cloud service
can be based on workload characteristics and specifications
are guaranteed through Oracle Database Resource Manager
is done through quotas, retirement policies and chargeback plans
Oracle Data Vault for security isolation and control
when needs change
through ultimate consolidation of multiple database applications
productivity and increase efficiency with automated provisioning
Deploy schema as
a service implementations consistently using self-service profiles and
Metering and chargeback
helps keep track of resource consumption and usage for accountability
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
up Platform as a Service Zones
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.
each zone can be restricted based on the self-service user's credentials.
up 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.
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.
During this part
of the schema as a service set up, future reservations, archive retention
and duration of request can all be enabled.
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.
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
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
Recently we asked a group of testers what percentage of their testing time was spent on peripheral activities such as:
deploying the application under test
deploying a test tool
find/detect/log issues/bugs and/or
patching an application
Two thirds of those testers indicated they spent between 40% to 70% of their time on these peripheral activities.
When asked what the right solution could be to solve that enormous time consumption, the majority selected testing cloud solutions that combine capabilities for Infrastructure as a Service (IaaS) and Software as a Service. Let's look at each one :
Infrastructure as a Service ( IaaS ) based testing cloud : This solution is typically based on provisioning of virtual machines on provided infrastructure . This will only resolve the provisioning of applications under test and test tools which is only 10-15% of the total solution.
Software as a Service ( SaaS ) based testing cloud : This is Software ( for test automation ) as a service solution. This only addresses the test execution and ( possibly ) issue/bottleneck identification. It does not offer provisioning for applications under test . In many cases, it does not offer monitoring of internal applications.