Chapter 3. Cloud Computing with DBaaS—Benefits and Advantages over Traditional IT Computing

We have covered the basic ideology and concepts around cloud computing and understand that database as a service (DBaaS) is a special case of infrastructure as a service (IaaS) and platform as a service (PaaS). We know that with DBaaS, the roles and responsibilities of the DBAs need to be adjusted.

In this chapter, we look at the various technologies and options that Oracle has developed that make it possible to deliver DBaaS along with all of its demands and expectations. We will see how these technologies can enable and benefit an organization, allowing it to manage infrastructure resources efficiently while at the same time delivering the expected performance with resource demand elasticity on demand.

DBaaS Evolution: Pre–Database Cloud Strategies

When it comes to managing databases and the infrastructure supporting them, the focus has been on database consolidation. One approach to database consolidation is to consolidate multiple databases into one physical database, which can be done in two ways:

• Convert independent databases into dedicated schemas within a single database, or

• Use pluggable databases, a new feature of Oracle 12c, and combine multiple databases into a single, larger-container database.

A second approach is to consolidate multiple databases onto a single piece of hardware, which also can be done in two ways:

• Consolidate multiple databases, as is, on fewer, larger servers and hardware, or

• Use virtualization technologies to convert physical servers to virtual servers sharing server resources via the hypervisor.

Consolidating databases as schemas has some obvious drawbacks and restrictions, because of which, schema-level consolidation is not a scalable and manageable option. Schema-level consolidation assumes that

• The candidate databases do not have any object namespace collisions. We can avoid this if we qualify object names with the schema owner prefix, but that solution impacts the portability to a large extent.

• The candidate databases do not have object ownership or security privileges and permission-level collisions.

• All the candidate databases have the same performance, uptime, and availability requirements. Another key aspect to consider is the peak load times when consolidating databases. Multiple databases with the load peaking at the same time may present a capacity and scaling issue.

Object name, user, and security privilege collisions can either imply application-level modifications or expose security risks. We cannot combine a database that has an 8 a.m. to 5 p.m. uptime expectation with another that has a 24/7 uptime expectation without compromising on uptime.

An alternative approach is to consolidate multiple databases onto a physical server that is larger in terms of both memory and CPU power. Once again, we must consolidate databases that share the same uptime requirements or risk failing to meet the uptime or flexibility requirements database.

In either case, we still must handle the problem of resource allocation and management. In a combined database (multitenant) environment, it’s possible that one of the databases issues a query or runs a process that can get out of control and consume more than its share of resources, negatively affecting the other tenant databases. Until now, the toolkit to measure, quantify, and throttle resource consumption across databases has had limited capabilities.

To overcome some of these challenges, a new alternative was developed: consolidating databases on a virtualized platform. Assuming a one-to-one correlation between database and the virtual server, virtualization allows us to allocate resources (CPU and memory) to a database by allocating the resources to the virtual servers they run on. However, there is one caveat to this approach: oversubscription of resources is a real possibility. Oversubscription of resources is the case where the sum of virtual resources allocated is larger than the sum of the physical resources available.

It is important to keep in mind that oversubscription almost always occurs. Not having oversubscription directly implies excess capacity not being used and thus being wasted. The key with a cloud deployment is how to combine workloads to share resources efficiently.

In other words, in a situation where the workload on the virtual servers is high across multiple virtual machines (VMs) simultaneously, resource starvation and contention occurs, which in turn can lead to performance and stability issues.

Comparatively speaking, it is relatively easy to manage memory by ensuring oversubscription does not occur, especially since the servers are capable of scaling to more than 1 TB in memory. CPU resource usage is directly related to processing workload. Processing workloads can vary by time of the day as well as by workload type. In other words, demands on and usage of CPU resources are not uniform but rather temporal and time sensitive in nature.

If we were able to add the capabilities of moving CPU resources around in a dynamic fashion, while at the same time guaranteeing performance, virtualization becomes an extremely viable alternative.

Delivering DBaaS with Oracle Technologies

Oracle has developed new or enhanced existing hardware technologies, database software options, and features as well as ancillary software options and features that are aimed specifically at delivering DBaaS. These technologies and enhancements are best used in conjunction with existing Oracle database features:

• Pluggable databases, new in Oracle 12c, to support multitenancy

• Oracle Flex Clusters and Flex Automatic Storage Management (ASM), new in Oracle 12c

• Oracle Enterprise Manager

• Oracle Engineered Systems

• Oracle Exadata Database Machine and Oracle Database Appliance are specifically targeted for database implementations.

• The Oracle Virtual Compute Appliance is a more generic, multipurpose converged appliance with virtualization technologies built in using Oracle Virtual Machine.

What Is Database Multitenancy?

Multitenancy is a generic term referring to the situation in which multiple individual entities reside in the same physical space and share the same resources. Schema-level consolidation, server consolidation, and server virtualization represent earlier methods and techniques used to achieve multitenancy.

With Oracle 12c, Oracle introduced a new approach, with the same goal of resource optimization. This approach is called pluggable databases and represents a hybrid approach between schema-based and server-level consolidation. Pluggable databases represents the single most important fundamental and conceptual change in Oracle’s approach to database consolidation. The shared resource unit is an Oracle database (container database), and tenants are fully self-contained databases (pluggable databases).

The core concept of database-level multitenancy is not new; it has long been a part of the SQL Server and Sybase core architectures and structures. Pluggable databases represents an adaptation of the SQL Server and Sybase multitenancy model into the Oracle database architecture. The fundamental concepts that differentiate Oracle in the database space (V$ performance views and wait events model, read consistency model, row locking, and nonescalating locks) have not changed. In other words, the pluggable databases represents the best of both breeds (architectures).

Oracle’s 12c multitenancy option addresses the issues and concerns that have proven to be challenges with the server consolidation approaches available to date. Pluggable databases have taken the benefits of the various options that have been used in the past and adapted them specifically to focus the implementation on Oracle databases and at the same time eliminate the challenges of the current approaches.

Pluggable Databases—Multitenancy in Oracle 12c

The Oracle 12c database multitenancy architecture requires that we add a few new terms to the Oracle lexicon:

• The container database (CDB) is the database that is capable of supporting multitenancy.

• The noncontainer database (non-CDB) is used to identify the databases as we know them from previous releases. These databases do not support the Oracle 12c multitenancy architecture.

• A CDB has a root container that is used to manage CDBs and to maintain system metadata and objects only. The root container is also referred to as CDB$ROOT.

• The application databases that contain user data and metadata are called pluggable databases (PDBs).

The primary goal of using multitenancy is to address some very common but key customer challenges:

• Maximize consolidation density by using the shared resources more efficiently.

• Reduce operating expenses by simplifying administration tasks. Administrative tasks that are normally performed and repeated at the non-CDB or PDB level are now performed at the CDB level. The gains are a result of consolidating and eliminating repeated tasks into a single task. Examples of tasks that can be simplified include backups, patches, and upgrades.

• Simplify database provisioning.

• Simplify and capacity management.

The word pluggable is used to describe multitenancy in Oracle 12c for a very specific reason: a PDB can be unplugged from one CDB and plugged into a separate CDB with little effort and impact to the rest of the system (see Figure 3.1). A PDB is a complete database from a logical and application standpoint, whereas the root container’s primary function is to store and manage the metadata needed for PDBs.

Figure 3.1. Oracle 12c multitenancy—Unplug and plug in a pluggable database

A single CDB can support up to 252 PDBs all connected to and managed by the root container. In order to achieve this mobility, CDBs have to be able to support the mobility of the metadata appropriately. At the same time, we also need to be able to support administering both the CDB as a whole and the individual PDBs.

Therefore, in the case of CDBs, some central structures, such as control files, online redo logs, undo tablespace, and system metadata (i.e., data dictionary), are owned by the root container. These are then either logically or physically virtualized by the CDB from the root container to the PDB (see Figure 3.2).

Figure 3.2. Oracle 12c multitenancy pluggable database model

Basic Concepts of Pluggable Databases

The resources under the CDB that are common and shared across all the PDBs go beyond just physical CPU and memory. Following are some of the core functional aspects of an Oracle database:

• Most of the background processes are shared.

• The memory structures associated with the system global area (SGA) are shared by the PDBs. The SGA for each PDB is a logically virtualized view of the SGA managed by the CDB.

• The V$ or GV$ views are based primarily on the contents of the SGA and therefore now contain a CON_ID field, which identifies the database context for the information.

• The internal structures and objects that any database requires to function are managed and maintained at the CDB level. These include SPFILEs, control files, online redo logs, standby redo logs, and undo tablespace.

• Users and privileges can be maintained at the CDB layer or can flow down to an individual PDB from the CDB.

The chart in Figure 3.3 is taken from an Oracle white paper,¹ which gives us an idea of the gains pluggable databases are capable of delivering from an overall capacity and performance standpoint.² The comparison is between consolidation of traditional standalone databases and consolidation using pluggable databases.

¹. “Oracle Multitenant on SuperCluster T5-8: Scalability Study,” April 2014, www.oracle.com/technetwork/database/multitenant/learn-more/oraclemultitenantt5-8-final-2185108.pdf.

². “Oracle Multitenant,” June 2013, www.oracle.com/technetwork/database/multitenant-wp-12c-1949736.pdf.

Figure 3.3. Scaling with pluggable databases

Following are the key points to take away from this example:

• Using pluggable databases, we can consolidate 50 percent more databases while maintaining the same throughput (168 versus 252).

• Comparing throughput when consolidating 252 databases in each method, pluggable databases delivered an 81 percent improvement in transactions per second (TPS).

• The improved throughout was delivered with a 33 percent reduction in CPU resources required (192 cores reduced to 128 cores).

• With pluggable databases, the same throughput was delivered and at the same time eliminated approximately 63 percent of the I/O (355,000 I/O operations per second [IOPS] reduced to 131,200 IOPS).

The data dictionary of an Oracle database contains metadata about both the Oracle system structures and the application (see Figure 3.4). In the case of a CDB, the data dictionary is physically partitioned between the PDB and the root. The root contains system metadata only, and the PDB contains application-specific metadata only.

Figure 3.4. Data dictionary virtualization in a pluggable database/container database

A new CDB-specific set of data dictionary views have been added. For each DBA_* data dictionary view, there is now a CDB_* view. The CDB_* views contain information for all objects in the CDB across all the PDBs.

Oracle 12c pluggable databases are compatible with all other Oracle technologies, including Oracle Real Application Cluster (RAC), Data Guard, GoldenGate, and Data Pump. In other words,

• We can use pluggable databases with the CDB being Oracle RAC aware. The PDBs also automatically become Oracle RAC databases.

• We can setup GoldenGate replication between PDBs or between a PDB and a non–CDB.

• Recovery Manager (RMAN) database backups are executed from the context of the CDB (not the PDB). However, RMAN allows us to perform a point-in-time recovery (PITR) restore of a PDB without impacting the availability of the other pluggable databases.

• Data Guard works exactly the same way but is configured and set up at the CDB level. What this means is that when we execute a switchover or failover operation, the entire CDB undergoes the role change.

The reason RMAN and Data Guard are configured and managed at a CDB level is that they are dependent on the online redo logs, which are defined and managed at the CDB level. The online redo logs (as well as the undo) are logically virtualized; that is, each redo log entry is annotated with the CON_ID of the CDB where the change occurred. The undo tablespace is also virtualized the same way as from a database recovery perspective; the undo and redo go hand in hand.

From an application perspective, there is no difference between a PDB and a regular database. The application will connect to the PDB directly over SQL Net in exactly the same as always. The use of pluggable databases does not place any requirement upon the application to be CDB, root container, or pluggable container aware.³ The security model associated with PDBs is covered later.

³. Certain limitations and requirements exist when creating CDB-level users. For example, the username for the common user must be prefixed with C## or c## and contain only ASCII or EBCDIC characters.

With the base assumption that the application has been tested and validated against a non-CDB Oracle 12c database, Oracle guarantees that the application will see no change in behavior or response from a pluggable databases versus a non-CDB database. In other words, any application SQL against its application-owned objects will execute and perform exactly the same way, PDB or not. This guarantee comes with a caveat and, in the opinion of the authors, a technically sound and valid one at that.

There is a very small, specific subset of SQL statements that are database-context aware and sensitive and that cannot be issued when connected to a PDB. These commands are almost entirely administrative in nature and will generate an ORA-65040 error code when issued against a PDB:

• Alter system commands modifying initialization parameters marked as non

• Creating a pluggable database when the user is not connected to the root container

• Attempting to close the SEED PDB

However, if the application code is designed and developed following industry-accepted best practices and standards, there is no reason it would need to execute such statements. The only exception to this statement would be if database administration tools and software, such as Enterprise Manager, should require such capabilities.

Reasons such as these are why we strongly recommend application-level regression testing prior to the actually going live with PDBs.

Pluggable Databases Features

The ability to unplug a database from a CDB and plug it into another CDB by itself is a huge game changer. The benefits derive from the flexibility and simplicity inherent in this ability. The reason patching exercises are simplified with this approach is that the PDB application metadata is separated from the CDB root container metadata. Remember, the PDB inherits the core Oracle system information from the root container.

With PDBs, patching and upgrades become a lot easier and incur a lot less downtime. To patch a database, you simply unplug the PDB from the lower-version CDB and plug it into higher-version CDB. This same unplug/plug functionality can also be used in the reverse to downgrade or back out a database patch. The existing rules for downgrades and backing with respect to the setting of the “compatible” parameter being at an equal or lower version than the target still apply. Effectively, the time and effort to create a new CDB at the higher patch level is a one-time effort and is amortized across the entire database upgraded using the CDB.

Another way to perform patching exercises is to patch a CDB that owns and manages multiple PDBs. With one patching exercise, all the PDBs within a single CDB are patched simultaneously. If a CDB contained 10 PDBs, it would take the same amount of time, effort, and outage windows to patch 10 PDBs as it would take to patch one non-CDB database. Effectively, we have saved the time, effort, and outage time of nine non-CDB patching exercises.

From an availability perspective, we can react quickly to situations such as server or CDB loss. With the simple task of unplugging and plugging, a PDB can be relocated to another server. This relocation exercise may be in response to a capacity planning decision or it may be due to server loss or the loss of a CDB.

Pluggable databases also simplify and speed up processes related to provisioning. Each CDB comes with a seed database, which is used to instantiate a new PDB within a CDB. All that needs to be provided in the “create pluggable database” command, apart from the name of the database, is a valid path prefix and creation of local administrative roles.

PDBs also come with many options and methods of cloning a PDB to create a replica. This ability is extremely useful when it comes to development and test database refreshes. The multitenant architecture allows for

• Cloning to be created within the same CDB.

• Cloning across CDBs using Oracle SQL Net connectivity.

• Cloning based on storage-level snapshot functionality if available.

Another important point to note is that PDBs are fully compatible with and extend existing Oracle database functionality and features. As stated earlier, Oracle RMAN and Data Guard are supported and managed at the CDB itself. By managing database backups and Data Guard at a CDB level, the administrative overhead is significantly dropped. Once again, the operating cost of managing backups and DR for all PDBs is reduced to that of managing one non-CDB database. This cost of administering one non-CDB is amortized across all the PDBs—managing backups of one PDB or 10 PDBs is the same.

PDBs are fully RAC compliant and compatible. The difference is that the CDB in such a case is a RAC-enabled, RAC-aware CDB. The PDBs inherit the RAC functionality when plugged into a RAC CDB. The PDBs can be made available across all the nodes or across a subset of nodes. Access to the PDBs is managed exactly as it would be in single-instance configuration using Dynamic Database Services. Combining RAC with PDBs gives us local high availability, capacity management, and scalability from Oracle RAC and the flexibility and ease of administration of PDBs.

Database resource management has been enhanced now to be CDB/PDB aware. The ability to create a resource governance plan has been around for a while, since each PDB is a fully compliant database by itself. With Oracle 12c, under the multitenant architecture, we can now create resource governance plans at a CDB level. The CDB resource governance plan can be used to control the number of concurrent sessions, CPU usage, and parallel server process usage across PDBs. With Exadata, file I/O resources can also be controlled with CDB-level directives, as it is used with I/O Resource Manager (IORM).

The resource governance is based on the share and cap model. Resources are broken into shares, and each resource is given a set of resources to use but can also be capped on the high side of resource usage. For CDB-level plans, the resource shares and caps are assigned to the various PDBs by creating CDB plan directives.

Security under Multitenancy

A pluggable database maintains and extends the already existing strong database security model to include and support Oracle 12c multitenancy. As we can see in Figure 3.5, we can have users at different levels, with access and privileges at either a CDB level or at each individual PDB level. Similarly, application accounts can be created individually for each PDB.

Figure 3.5. Security model under pluggable databases model

A user ID (usually called a USERID) can be created at the CDB level. All user-defined common user IDs must be created with a prefix of C##. You can give the common user access to a specific subset of PDBs by granting the user the “create session” privilege. The privileges granted to the same common user can vary across each of the PDBs the user has access to. The common user’s schema on each PDB he or she has access to is unique at a PDB level.

Local user accounts, by contrast, are created individually at the PDB level. The standard user naming convention applies to local user names. The same local user can exist on different PDBs, but these USERIDs have no other commonality between them. Local users can access only the PDB in which they are created and have no access to any of the other PDBs or even to the CDB.

The same concept also applies to roles. A common role is a database role, defined and created in the root container. A common role can be assigned only to “common users,” and all the privileges cascade down to the PDB level. A local role, on the other hand, is created at the individual PDB level and can only contain roles and privileges applicable to administering at the individual PDB.

The same concept is used to extend the standard database auditing features and functionality. A common audit configuration is created at the CDB level and visible to and enforced for each of the PDBs within the CDB. A local audit configuration is defined and created at the individual local PDB level and therefore applies only to the specific PDB it was created in.

Other Oracle Database Technologies and Features

Pluggable databases and multitenancy are key features of Oracle 12c, especially from a consolidation and database cloud perspective. Other features of Oracle 12c are useful and applicable specifically to database cloud implementations and initiatives.

Oracle RAC functionality is core to database cloud implementations for obvious reasons. First, Oracle RAC has a lot of potential for high availability because Oracle RAC, by definition, provides the ability to withstand and survive a cluster node loss or a database instance loss situation. The second reason is that Oracle RAC provides scalability and capacity planning. We can scale the environment out horizontally by adding additional servers to the RAC cluster.

Another important feature in the Oracle clustering space is Oracle Flex Clusters. Oracle Flex Clusters is an enhancement to the core Oracle Clusterware functionality available through the grid infrastructure. It is not an enhancement of Oracle RAC.

Oracle Flex Clusters basically contain two kinds of cluster nodes: hub and leaf nodes (see Figure 3.6). Regardless of the node type, each node belongs to the basic grid infrastructure cluster and uses the private interconnect for interprocess communication. The hub nodes are tightly coupled and have access to the shared storage as well. Leaf nodes are a part of the grid infrastructure cluster but do not have access to the shared storage. Each leaf node communicates with a dedicated hub node that it connect to for data requests. In a Flex Cluster, we can have up to 64 hub nodes and a much higher number of leaf nodes.

Figure 3.6. Oracle Flex Cluster

What this means is that the hub nodes with access to the shared storage are where the databases are running. The leaf nodes are not part of the database cluster, since they do not have access to the shared storage. The leaf nodes are used to run application-level software that uses the core grid infrastructure functionality to provide fault tolerance for the application tier in much the same way as it does for the database tier.

In a Flex Cluster, the grid infrastructure provides additional functionality that allows us to change the role or mode of a node, going from a leaf node to a hub node, or vice versa. As a part the role change, the grid infrastructure Clusterware will start and stop the services as needed.

In a more traditional RAC, all nodes in the database cluster will be running their own ASM instances. Therefore, the background processes on each database node in the cluster communicate with the local ASM instances to execute and implement the I/O requests at the storage level. In the event an ASM instance is lost, the database instances would also crash. More important, during patching updates, the ASM instance is also shut down, which results in service interruptions to the databases.

Within Oracle clustering, there is another concept called Flex ASM (see Figure 3.7). Flex ASM is a solution to many of the availability-related issues discussed previously. In order to run Flex ASM, the cluster needs to be configured in Flex mode. In Flex ASM, the one-to-one relationship between ASM and database instances is decoupled. ASM is actually running on only a few of the hub nodes. The database instances are talking to the ASM instances remotely over a separate network called the ASM network. In the event an ASM instance is lost, all the database instances will be redirected to a surviving ASM instance and the loss will not cause an interruption of service.

Figure 3.7. Oracle RAC with Flex ASM

Oracle Enterprise Manager Cloud Control 12c (EM12c) is another key component to deploying Oracle database in a DBaaS model. EM12c supports all the database functionality available and makes administration much easier. In addition, EM12c is focused on delivering an administration tool that is cloud aware and includes support for a lot of the cloud computing functionality. EM12c functionality and applicability to database clouds is covered extensively in later chapters, so we do not go into much detail here.

Following are some of the other features that can be used to great advantage when it comes to deploying Oracle 12c:

• Enhanced functionality for resource management and allocation using RMAN.

• Use of instance caging to limit CPU resource allocation at a database level. This helps ensure that no single database is causing a CPU bottleneck by consuming more than its fair share of resources.

• In Oracle RAC, there is a concept of admin-managed versus policy-managed clusters. Admin-managed configurations basically use the standard Oracle RAC administration and configuration functionality. Policy-managed configurations use the concept of server pools. A server pool is an arrangement of the Oracle RAC nodes into logical groups. Database instances are then mapped to the server pool. Based on load, new servers can be added to or removed from a server pool.

Oracle Engineered Systems

Apart from the software stack, Oracle also has a complete array of hardware that is database aware, tuned specifically from the point of view running an Oracle database. These systems are able to provide some extreme-level performance and have a significant amount of capacity as well as expansion capabilities. Depending on the requirements and expectations, one or more of these platforms may be applicable to a given scenario.

At the entry level, Oracle has the Oracle Database Appliance (ODA) X5-2. Each ODA consists of two compute nodes, and each node has two sockets of an 18-core Intel processor. Additionally, included with ODA is a storage shelf that can deliver up to 64 TB of raw space. An additional storage cabinet can be added to the configuration, which in effect doubles the raw storage capacity.

At the next level, Oracle has introduced the Virtual Compute Appliance (VCA). This is an engineered system with built-in Z File System (ZFS) storage, capable of supporting up to 25 compute nodes, and it uses Oracle Virtual Machine (OVM) as the virtualization platform. The VCA comes with an appliance manager that simplifies the administration, provisioning, and scaling of servers under the umbrella of OVM.

Last but not least, Oracle delivers the Exadata Database Machine, which is a highly specialized Oracle database–focused black-box appliance that includes storage, network, and compute capacity needed to run the solution. The Exadata provides a lot of database-aware features and tuning that help it deliver extreme performance. Even the storage in an Exadata is database and SQL aware, and consequently can thoroughly optimize the performance. Specific to database consolidation and database clouds, the Exadata also includes I/O resource manager (IORM). IORM allows the Exadata administrator to specify and control I/O prioritization at an inter-database level and not just an intra-database tier.

Another key point built into the Exadata model is its capacity scaling model. An organization can start with what is known as an eighth rack and scale up to a quarter rack, half rack, full rack, and across eight full racks. In terms of compute capacity, using the X5 model standards, that is equivalent to saying that we can start with two compute nodes with 18 cores each (eighth rack), expand to two compute nodes with 36 cores each (quarter rack), expand further to four compute nodes with 36 cores each (half rack), then to eight compute nodes with 36 cores each (full rack), and all the way up to 64 compute nodes, each with 36 cores (8 full racks daisy chained). With Exadata X5, Oracle enhanced the licensing model to be more flexible and based on capacity.

Cloud Computing with DBaaS

The hardware and software required to deliver robust, scalable, manageable DBaaS functionality using Oracle as the database platform exists. Any organization of any size can deploy a DBaaS service that will deliver on the following primary goals:

• Agility: Respond to requests and resource needs in a fast, real-time manner.

• Availability: Deliver a service that meets the defined goals of performance and availability.

• Elasticity: Provide the ability to shrink or expand resource footprints as needed to meet computing demands.

• End user reporting and accounting: Provide the ability to capture and present usage metrics, performance against key performance indicators, and so on.

Benefits and Advantages

The benefits to an organization that can successfully deploy a DBaaS solution can be measured in two ways: by operating costs and by customer satisfaction criteria.

Operating costs can be lowered by

• Deploying a database architecture that can scale in the just-in-time (JIT) model. The organization saves in infrastructure and licensing costs by not having to acquire resources well in advance of their actual need. A combination of consolidation using engineered systems and deploying and Oracle 12c multitenant architecture, Flex Clusters, and RMAN models are key here.

• Deploying an architecture that is agile enough to relocate idling resources to the areas of demand. A combination of policy-managed clusters and Oracle 12c multitenant architectures will drive the reduction of costs from an agility perspective.

• Deploying a solution that is standardized and has the toolkit available to monitor, alert, and administer the environment efficiently. A combination of technologies such as Oracle RAC, Oracle 12c multitenant architectures, and EM12c can be used to drive this administrative aspect of cost reduction.

• Deploying a highly resilient, flexible architecture to drive down outage windows (both planned and unplanned) and thus drive down costs associated with outages. Oracle 12c features such as RAC, Flex ASM, and multitenancy are key to driving down outage costs.

• Deploying an Oracle database–aware consolidation strategy to streamline and thereby reduce the capital expenditure in infrastructure costs. Oracle RAC and the multitenant architecture will play an essentially key role here.

• Deploying a user-friendly, portable system that allows end users to review, report, and manage their resource allocation. Such a deployment will drive down resource costs by eliminating wait times and streamlining processes and procedures.

Customer satisfaction will be a direct outcome of being able to design and deploy a solution that

• Reduces downtime and outages.

• Improves time to respond to user requests and questions.

• Provides the end user with tools to achieve self-sufficiency and control.

The same set of technologies that drive operating cost savings will go a long way to promoting customer satisfaction.

Challenges

The path to achieving the suggested goals and requirements requires careful upfront planning and design. As a part of the planning process, we recommend scheduling periodic checkpoints to validate that your organization is on track to achieve the target platform and environment.

Another aspect to consider during planning is the dedication of resources focused entirely on the design and build out of the new architecture. Without this focused effort, the probability for distraction is extremely high, and resources would be sucked right back into the day-to-day administrative tasks.

We also recommend that the organization plan for building and training the team in the new technologies being introduced. No matter how good the implementation, with a properly skilled staff to administer and deliver the service, the service is doomed to failure.

Standardized processes, procedures, and offerings contribute greatly to the success of DBaaS. These processes should be defined early and evangelized with the remainder of the organization from day one.

Summary

In this chapter, we looked at the various technology offerings available that can help an organization design, build, and deploy a robust DBaaS or database cloud solution. This chapter discussed several technologies that subsequent chapters will cover in more detail.

Oracle 12c has a host of new features that are perfectly suited for this purpose. The key new features included with Oracle 12c are

• Pluggable databases

• Resource Management

• Oracle Flex Clusters

• Oracle Flex ASM

EM12c not only supports these new features, but its design and architecture are focused on supporting the core concepts associated with cloud solutions in general and database clouds in particular. The proper design and implementation of this combination is the key to a successful database cloud implementation.

At an infrastructure level, Oracle-engineered systems provide a platform that can be useful in deploying a database cloud service, but we do not imply that this is the only way to implement a database cloud. Virtualization technologies such as VMware also have functionality and tools that can be used to implement a database cloud solution. The new features in Oracle Database 12c and EM12c can also be used to complement and enhance these solutions.