Oracle Cloud 12 part 1

Contents

Chapter 1. Database as a Service Concepts—360 Degrees
Cloud Computing: Definition and Classical View
DBaaS—A Special Case of Cloud Computing
Services Applicable to DBaaS
Architecture of an Oracle-Based DBaaS Implementation
Business and Technology Benefits of Having DBaaS Enabled
Great First Step for Transitioning into the Cloud
Summary
Chapter 2. The Database Cloud Administrator—Duties and Roles
DBA Responsibilities in a Traditional Environment
What’s Changed with DBaaS
The New Role of the Cloud DBA
Preparing to Be a Cloud DBA
Summary
Chapter 3. Cloud Computing with DBaaS—Benefits and Advantages over Traditional IT Computing
DBaaS Evolution: Pre–Database Cloud Strategies
Delivering DBaaS with Oracle Technologies
Cloud Computing with DBaaS
Summary
Chapter 4. Schema Consolidation in Enterprise Manager 12c
Architecture and Components
Schema as a Service Setup
Using Schema as a Service
Deployment Issues
Summary
Chapter 5. Database Consolidation in Enterprise Manager 12c
PDBaaS Setup
Using the Self-Service Portal with PDBaaS in Enterprise Manager 12.1.0.4
Deployment Issues
Summary
Chapter 6. Metering and Chargeback in Enterprise Manager 12c
Terminology
Setting Up Chargeback
Summary
Chapter 7. Manage and Administer the Database Cloud in Enterprise Manager 12c
The Cloud Home Page
The Cloud Adviser
Summary
Chapter 8. Cloning Databases in Enterprise Manager 12c
Full Clones
Snap Clones
Summary
Chapter 9. Virtualizing RAC 12c (DB Clouds) on Oracle VM—Grid Infrastructure
Database Clouds Based on RAC—The Necessary Ingredients
Virtualization—360 Degrees
What Are VM Monitors (Hypervisors)?
Types of Hypervisors
Types of Virtualization
OVM for x86—360 Degrees
Xen—Synopsis and Overview
OVM—Overview and Architecture
What Are OVM Templates?
OVM 3.x—A Brief Introduction
Virtualized RAC Using OVM Templates—Approach 1
Set Up and Configure a Virtualized RAC Database Cloud—Approach 2
Summary
Chapter 10. Virtualizing RAC 12c (DB Clouds) on Oracle VM VirtualBox—RAC Databases
OVM VirtualBox: A Brief Introduction
What Is Cloud Computing? Synopsis and Overview
Oracle’s Strategy for Cloud Computing
EM12c and OVM: Management and Virtualization Components for Oracle Database Clouds
RAC Private Cloud on OVM VirtualBox—Software and Hardware Infrastructure Requirements
Setting up, Installing, and Configuring an Oracle RAC 12c Private Cloud on OVM VirtualBox
EM12c: Implementing DBaaS
Summary

Chapter 1. Database as a Service Concepts—360 Degrees

To understand the basic principles and concepts of Database as a Service (DBaaS), we must understand the meaning of both database and service and how the two interact. We also must understand the relationship between cloud computing and DBaaS. Cloud computing encompasses the IT infrastructure resources, which include networks, storage, servers, applications, and services. DBaaS is a subset of the overall cloud concept, specifically focused on the last two resources, applications and service.
The goal of this chapter is to explain the cloud computing implementation as it relates to DBaaS. Although the concept of DBaaS is generic, this book focuses on using Oracle technologies to implement DBaaS.

Cloud Computing: Definition and Classical View

The National Institute of Standards and Terminology (NIST) defines cloud computing¹ as follows:
¹. http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf, p. 2.
Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. [emphasis added]
This definition articulates the service goals that a cloud computing environment is expected to deliver:
• Ubiquitous: The resources are available and ready for consumption.
• Convenient: The consumer has easy access to the resources.
• On demand: Resource requests need not involve resource approval and acquisition tasks.
• Shared pool: The resources are shared, not dedicated, which provides mobility and flexibility in terms of assigning resources.
• Rapid: The time window between a resource request and its fulfillment is shortened or eliminated.
These service goals drive the physical implementation of any cloud computing model. Specifically, they provide the basis for the following core aspects of any cloud computing model, which are also interdependent on each other:
• Roles applicable within cloud computing—Who is sharing the resource pool?
• Cloud type from a infrastructure persepctive—What is the shared resource pool, and how is it deployed?
• The security framework within a cloud computing model—What are the basic rules that govern how the resource pool is shared?
Let us first look at roles within a cloud computing model. There are primarily two roles: end user and provider. The end user is the entity that uses the hardware resources and associated services that exist in a cloud environment. The provider is the entity that owns the physical hardware and infrastructure resources and is responsible for the services associated with delivering these resources to the end user.
Next, we look at the three types of cloud computing models prevalent: private, public, and hybrid.
• Private cloud: A cloud infrastructure provisioned for exclusive use by a single organization or entity, maintained by the entity and within the entity’s network. The roles of provider and end user are represented by different groups within the entity.
• Public cloud: A cloud infrastructure provisioned in the public space such that multiple entities can use the infrastructure simultaneously. The provider is a third-party service provider that supports multiple clients or entities in the end user role.
• Hybrid cloud: A combination of the private and public cloud models.
The security model in a cloud environment must include the capability to define roles, responsibilities, and separation of duties for both the provider and end users. As a part of the overall cloud deployment model, the provider must develop, implement, and support a security system with proper access and privileges grants and administration in place.
The security requirements on all cloud environments follow the same basic model, with the difference that in a public cloud, the security controls have to be much wider and more stringent than in a private cloud. The security framework in both the public and private cloud models must also address data security and privacy protection between the provider and end users.
For public clouds, however, security usually requires a much stronger encryption algorithm than used in a private cloud as well as sufficient networking bandwidth to meet public needs. Furthermore, the administrator role at a provider is focused on managing the underpinning infrastructure of the private cloud itself.
To be able define and create such a security framework, it is important to understand the roles associated with who is using the cloud. Once we understand who is using the cloud, we can translate them into requirements around access levels, roles, responsibilities, and separation of duties. Following are examples of these requirements:
• The role of a provider’s cloud administrator is to manage the underpinning infrastructure of the cloud offering itself.
• The subscriber administrator role is filled individually by each subscriber entity on a cloud. The subscriber administrator manages resources and privileges for his or her own organization.
• The end user role applies to a specific user within a subscriber entity that requests and uses a subset of the resources.
Note
To the provider cloud administrator, the subscriber admnistrator role is the equivalent of an end user role with elevated privileges and rights.
To understand the impact and implementations of the security framework in a cloud environment, we also need to understand the models in which cloud services may be deployed. There are three main models:
• Software as a service (SaaS): SaaS allows the consumer to use the provider’s applications running on cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based email), or a program interface. The consumer does not manage or control the underlying cloud infrastructure—not the network, servers, operating systems, storage, or even individual application capabilities—with the possible exception of limited user-specific application configuration settings.
• Platform as a service (PaaS): PaaS allows the consumer to deploy any software or application onto servers deployed on cloud infrastructure. These applications may be consumer-created applications or consumer-acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure but has control over the deployed applications and possibly configuration settings for the application-hosting environment.
• Infrastructure as a service (IaaS): The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications and possibly has limited control of select networking components (e.g., host firewalls).

DBaaS—A Special Case of Cloud Computing

DBaaS is a very specific implementation of the broader and generic cloud computing. Now that we have defined cloud computing at a generic high level, let’s examine the characteristics that distinguish DBaaS.
To understand the principles of “database as a service,” it’s helpful to look at the terms database and service individually and then look at how they interact.
The Merriam-Webster online dictionary provides a definition of database that we are all familiar with: “a usually large collection of data organized especially for rapid search and retrieval (as by a computer).”
The term service is also one that we are familiar with. Merriam-Webster has quite a few definitions for this word, and following are some of the relevant ones that apply even in the specific case of DBaaS:
• “The occupation or function of serving”
• “The work performed by one that serves”
• “A facility supplying some public demand” such as “telephone service” or “bus service”
But these definitions are generic in nature and context. The core concepts of the definitions still apply in terms of an IT infrastructure as well—but with a few context-sensitive tweaks. In this section, we further explore the meanings and implications of database and service.
First, just to be clear, the concept we are discussing is not called “Oracle database as a service”—it is just “database as a service.” Conceptually speaking, we can deploy DBaaS using Microsoft SQL Server, DB2, PostGres, MySQL, or Oracle. They are all software technologies that we can use to build and deploy DBaaS. The design and implementation of DBaaS includes choosing the underlying technologies that we use to implement the service. Oracle is a leader in database technology, and Oracle 12c focuses largely on feature sets, utilities, and functionality that enable cloud computing, making Oracle 12c a leading contender in terms of implementing DBaaS.
Now let us look at the service element of DBaaS. We must understand what service the end user expects and what components the provider must manage and maintain in order to deliver the expected services.
Let’s start with the end users’ expectations of DBaaS. Based on NIST’s definition of cloud computing, we take the generic expectations implied by “services” and frame them around DBaaS-specific expectations.

Resource Utilization—Usage Instrumentation and Self-Service

One of the fundamental concepts of cloud computing is to provide end users of the cloud service the capability to monitor cloud resource usage and consumption. Therefore, a good cloud service should provide end users visibility into their resource usage, analytics, and chargeback.
With DBaaS specifically, the cloud service should provide the functionality or self-service capabilities to view resource usage and consumption as it applies to databases. The resources would include CPU consumption, storage consumptions, backup service consumption, and network bandwidth consumption.

Broad Network Access

By its definition, a core component of a cloud service is network access, or bandwidth. The cloud service network should be accessible over multiple devices and heterogenous platforms.
From a DBaaS perspective, the focus is on the protocols, quality, and efficiency of network access to the database. Network access concerns are applicable from an application standpoint as well as from an administration and management standpoint.

Resource Pooling

The reason a cloud service provides resource utilization statistics and analytics is to allow end users to tune consumption specifically to their needs. Remember, in a cloud, all the resources come out of a pool. End users should therefore be able to request additional resources when needed and reduce resource allocation and usage as needed. Remember, a cloud service must be able to optimize resources across the entire platform and at the same time maintain performance and availability according to service level agreements (SLAs) between the provider and end user.
Consequently, the service provider must enable end users to provision and decommission resources as needed without having to request resource increases or reductions through the provider. Based on resource usage statistics and business needs, end users should be able to manage and administer all resources, including, CPU, network, storage, and backups.
Multitenancy is a key construct of the implementation of any cloud service. The service provider supports multiple clients within a cloud solution. The type of the cloud solution (private, public, or hybrid) determines who the allowed clients (end users) are.
In a DBaaS environment, multitenancy means that the cloud solution supports multiple databases across multiple clients, and each client has one or more databases.
From a DBaaS perspective, the end users, as consumers of services, do not manage the availability of resources or capacity-related issues. These concerns fall under the service provider’s responsibility. The service provider must manage the resources at a holistic level across all the clients it supports.
However, there is a caveat here. The preceding statement is true as long as the end user requirements around security, privacy, and compliance are met. The provider has to ensure that the solution design meets the end user criteria.

Rapid Elasticity

Rapid elasticity is the logical next step and evolution of resource pooling. The cloud solution must be able to dynamically allocate or deallocate resources as requested by the end user. The service provided includes the ability to dynamically add or remove resource based on workload volume and nature. In other words, the solution needs to be adaptive and flexible in nature by being able to adjust resource requirements on the fly.

Measured Service

The culmination of all of the preceding concepts of resource usage intrumentation, pooling, and elasticity is the ability to measure resources across an entire service and at each individual cloud subscriber level. Therefore, resource usage should be monitored, controlled, and reported upon, providing transparency for both the provider and the consumers of the utilized service.
Another way to put this is that the cloud solution is based on multitenancy—multiple clients being supported from a single cloud solution, which leads to the question of who should be charged for resources. Obviously, the cost should be based on what resources are actually used. In other words, the cloud solution must be able to support chargeback capabilities. The chargeback can be based on what is provisioned or, more popularly, on what resources are actually used.

Services Applicable to DBaaS

We now have a solid foundational understanding of what cloud computing is and how it applies to DBaaS. In this section, we outline the specifics around services as they relate to DBaaS and what they mean to end users as well as to the provider in a cloud computing environment.
The services offered by the DBaaS provider to the end user fall into three main categories: provisioning, administrative, and reporting. Some of these services are optional, and others are mandatory.
Provisioning services provided to end users include some or all of the following:
• The ability to requisition new databases.
• The ability to choose database options as needed (partitioning, advanced security, Real Application Cluster, etc.).
• The ability to add resources (storage, CPU, network bandwidth, etc.) to existing databases. This includes the ability to scale up as well as to scale down.
• Database backup capability using provided backup resources.
Administrative services include some or all of the following:
• The ability to perform on-demand database restores and recoveries.
• The ability to perform database clones using existing database backups.
• Database monitoring capabilities, including basic 24/7 incident reporting management capabilities.
Reporting services include some or all of the following:
• Performance management, which is the ability to look at a database from a performance and tuning standpoint, whether in the form of reporting or in the form of application and GUI database restore and recovery capability.
• Resource consumption and usage reports, which let end users compare the resources provisioned and the actual usage so they can fine-tune resource needs to accommodate workload.
• The ability to view resource chargeback based on resource allocation and consumption.
• The ability to track provider compliance to the SLAs.
The ability to track provider compliance to the SLAs is an especially critical point to understand. To ascertain whether or not the requested services are being provided at an appropriate level, end users must first define what “appropriate level” means. For each service, there may be more than one SLA. The higher the SLA, the more technology and resources are needed to satisfy the SLA. Pricing is also affected by the level of service detailed in the SLA.
For example, for I/O performance guarantees, the SLA would specify the input/output operations per second (IOPS) and megabytes per second (MBps) would specify I/O service times. Based on the SLA, the provider determines the actual storage layer provided to the end user. It is the provider’s responsibility to ensure that the service delivered to the end user is within the accepted limits.
If we look at I/O performance as an example, the SLAs could be structured as follows:
• Bronze standard: Small block average I/O service times equal to or under 15 ms.
• Silver standard: Small block average I/O Service time equal to or under 10 ms.
• Gold standard: Small block average I/O service times equal to or under 5 ms.
• Platinum standard: Small block average I/O service times equal to or under 1 ms.
Based on these SLAs, the provider may choose to
• Place bronze customers on a low-end storage array’s using primarily serial advanced technology attachment (SATA) disks.
• Place silver customers on high-performance storage arrays using serial-attached SCSI (SAS) drives.
• Place gold customers on a high-end storage array’s with a combination of SAS and solid-state drive (SSD).
• Place platinum customers on a high-end storage array based entirely on SSD or flash memory.
The key is that, once end users make their choice, the provider has to
• Define the exact key performance indicators (KPIs) required to meet the service level expectation.
• Ensure that the KPIs required for the SLA are measured and monitored.
• Plan for expansion to continue to be able to meet and provide the expected KPI metrics both now and in the long term.
• Provide end users with reports that support or, if necessary, justify the provider’s service performance capabilities.

Architecture of an Oracle-Based DBaaS Implementation

DBaaS started primarily as a consolidation exercise for reducing capital expenditures (CAPEX), but as it evolved, organizations started looking into other key drivers, such as self-service, showback, and chargeback. Before we look at the details of how to implement DBaaS, we need to have some understanding of the underlying consolidation models and deployment issues that are common to all DBaaS flavors and some of the terminology that we use when defining DBaaS.

Consolidation Models

The various consolidation models that can be used to provide DBaaS are shown in Figure 1.1. The simplest and most prevalent form of consolidation exists around server virtualization. Server virtualization offers a simple way of running multiple operating system instances on the same hardware. A better model, platform consolidation, consolidates multiple databases on the same operating system, or a cluster. However, in both cases, database sprawl is still an issue that invariably leads to larger administrative overheads and compliance challenges. An even better consolidation model is the capability to host multiple schemas from different tenants within the same database, using Oracle Database 12c’s multitenant architecture.
Figure 1.1. Consolidation models

Before we describe such methodologies, however, it is important to have a common understanding of the components that make up the underlying architecture.

Architecture and Components

In Oracle terminology, hosts containing monitored and managed targets are grouped into logical pools. These pools are collections of one or more Oracle database homes (used for database requests) or databases (used for schema requests). A pool contains database homes or databases of the same version and platform—for example, a pool may contain a group of Oracle Database 12.1.0.1 container databases on Linux x86_64.
Pools can in turn be grouped into zones. In the DBaaS world, a zone typically comprises a host, an operating system, and an Oracle database. In a similar vein, when defining middleware as a service (MWaaS) zones, a zone consists of a host, an operating system, and an Oracle WebLogic application server. Collectively, these MWaaS and DBaaS zones are called platform as a service (PaaS) zones. Users can perform a few administrative tasks at the zone level, including starting and stopping, backup and recovery, and running chargeback reports for the different components making up a PaaS zone.
In the DBaaS view of a PaaS zone, self-service users may request new databases, or else new schemas in an existing database can be created. The databases can be either single instance or a Real Application Cluster (RAC) environment, depending on the zones and service catalog templates that a user can access.
Diagrammatically, these components and their relationships are shown in Figure 1.2.
Figure 1.2. Components of a PaaS zone

Deployment Issues

Now that we understand the architecture and components that are used in the different consolidation models, let’s examine some standard deployment issues that need to be addressed. These include security, operational, resource and fault isolation issues as well as scalability and high availability. It is very important to understand that delivery services and the SLAs around those services will drive the actual architecture, design, and implementation. Therefore, architecture, design, and implementation also play directly into the chargeback and metering aspect of the services.

Security Isolation

Security isolation is often the first point that management worries about in any cloud model. Is my data safe? What options do I have for securing my consolidated infrastructure? How can I prevent the cloud database administrator from accessing and viewing my data? How can I ensure that my network traffic is secure? Can I ensure I meet compliance regulations?
With all of these questions, security isolation has become an essential component of any cloud deployment. Security breaches can arise not only externally but also internally, so all aspects of your cloud infrastructure must be secure.

Operational Isolation

Operational isolation in a DBaaS cloud requires that any maintenance being performed on a database or on the environment the database operates in affects the smallest number of other databases in the same pool. Meeting this requirement clearly becomes more problematic for operating system or grid infrastructure maintenance, though the impact can be minimized by rolling upgrades where allowed. Isolation for patching an Oracle database kernel can be provided by minimizing the number of databases per Oracle home, but adding Oracle homes also increases management overheads. Database startup and shutdown would normally be considered database-dependent operations, but administrative errors such as setting the wrong ORACLE_SID can lead to unforeseen impacts on other databases. Again, isolation can be provided at the ORACLE_HOME level and by having different user IDs and group IDs at the kernel level, but this also leads to more management overhead, and, it must be said, more likelihood of human error.

Resource Isolation

In a DBaaS cloud, resource isolation deals with the allocation and segregation of resources such as CPU, memory, network (public and private), and storage (I/O per second and overall capacity). Management concerns include questions such as How does the CPU usage of my database affect other databases in the DBaaS cloud? How much memory should I allocate to a specific database? Can I restrict the network utilization, both at the public network and interconnect levels, to not impact other databases? Likewise, how can I guarantee storage capacity and IOPS for my databases?

Fault Isolation

Fault isolation in a DBaaS cloud is normally provided at the database level, since that is the unit of granularity in the multitenant architecture. Each database and its associated instance (or instances, in RAC environments) need to be isolated from other databases. Even when all databases are run from a single ORACLE_HOME, database faults are normally isolated to a failing instance, so fault isolation is maintained by fencing off the offending instance. However, other failures may require handling at different levels. For example, concerns include how to deal with a server, network, or storage failure. Such failures are normally handled by some form of redundancy such as multinode setups, active/passive switches, bonded networks, or redundant storage such as Automatic Storage Management (ASM) redundancy.

DBaaS Scalability

Scalability is a fundamental characteristic of DBaaS architectures by virtue of their support for self-service, elasticity, and multitenancy. Oracle’s database technologies provide a number of ways to support scalability when delivering database services, including resource management and quality of service, addition of extra storage through such functionality such as multiple Exadata Database Machine frames, horizontal scaling via RACs when service demands increase beyond the capabilities of a single machine, and scalable management resources where Oracle Enterprise Manager can add management nodes as the number of targets under management grows.

DBaaS High Availability

Not all consumers require the same level of availability in a cloud environment. Oracle’s DBaaS self-service catalog allows the capability to include different levels of availability using a metals model, as shown in Table 1.1.
Table 1.1. Availability Levels

For example, the bronze standard provides a single-instance database service (possibly via RAC One Node), whereas the other extreme, platinum, would normally include a RAC database with multiple standbys. These standbys might include a near standby in the same data center as your RAC database and a far standby in a completely separate remote data center. These measures help to improve the high-availability and disaster recovery goals you have for that database. In Oracle Enterprise Manager 12.1.0.4, with the added support for Data Guard, you now have the ability with just a few clicks to provision the primary and multiple standbys across different data centers. The standbys can be either single instance or a RAC configuration.

Business and Technology Benefits of Having DBaaS Enabled

DBaaS, or a database cloud, is becoming a very popular concept with organizations of all sizes across the spectrum of industry. Placing database infrastructure concerns with the DBaaS provider frees an organization’s IT and technology departments to focus at an organization level rather than at an application or department level. With the focus at an organizational level, the IT and technology teams are more closely aligned with the organizational and business needs. The fundamental requirements of an organization have never really changed—they have always aimed for lowered operational expenses (OPEX) and total cost of ownership (TCO). What has changed is the emergence of new platform architecture and software technologies that, working together, deliver on those needs. The opportunity to reduce OPEX and TCO is precisely what is driving the improved acceptance and adoption rate of DBaaS.
Let’s look at some of the intrinsic benefits of deploying DBaaS, which include the basic benefits associated with any cloud solution:
• Time-to-market: The nimbleness with which a company reacts and adapts to changing market conditions, competition, and consumer needs and expectations is critical. A core component of any cloud solution is self-service and automation. With a well-planned cloud solution, there is no need to deploy hardware for new projects, and with self-service and automation, the business units become more self-reliant.
• Scalability: The combination of inherent concepts of elasticity, consolidation, and resource pooling at a wider organizational level drives scalability in a cloud computing environment. For custom built solutions, the value and benefit of this automatic scaling is even more potent and impressive.
• Empowerment: Cloud computing solutions typically have a web-based interface for users. They can be accessed by employees, customers, and partners no matter where they are. With a cloud database, everyone gets to work with the same set of information, and spreadsheet chaos is a thing of the past.
• Availability: Combining the benefits of standardization (hardware, software, procedural best practices) and empowerment (self-service, on demand scalability) automatically delivers improved availability.
Let’s go a step further and look at why databases are worthy of their own class in the cloud solution world. We do not see phrases such as “application servers as a cloud” or “web servers as a service” or “exchange servers as a service.” Logically and technically, these concepts can exist, but they do not. Why is that?
Databases are used to store data. As we are all aware, the amount of data being generated, used, and stored is growing exponentially. This ever-growing volume of data needs to mined and analyzed to generate intelligent, actionable information. Now, more than ever, data means everything—it drives financial, operational, and tactical decisions and strategies in every business. But along with all this data come the headaches of tasks such as managing performance, scaling capacity, and backup and recovery strategies.
Databases are often considered the single point of serialization of application processing and logic, usually because application design is not focused on how databases work or the best way to use them. What this means is that designing, managing, and performance tuning databases represents a unique set of skills and talents.
From a computing perspective, resource consumption characteristics and performance needs of a database are unique in nature. Databases, especially untuned databases, can be resource hogs when it comes to storage, CPU, and network resources.
Scaling of databases also presents unique challenges. Scaling can directly impact expenditure on multiple components of the platform and infrastructure, including on the storage subsystem (due to storage volume or performance) and on throughput (in IOPS or MBps).
Database are a complex component of the application stack. Consequently, the underlying database technology can potentially have a severe impact, positive or negative, on the overall scalability, availability, business continuity, and performance aspects of any given application. When the applications in question are business critical and/or revenue generating, the potential for impact makes the databases a very visible, highly scrutinized component.
From an economics perspective, databases can prove to be one of the costliest, if not the costliest, component of any given application deployment. The database’s application stack, for example, can drive the overall solution cost in the following ways:
• Database licensing costs and annual support costs.
• Database-specific infrastructure costs, especially those driven by performance initiatives, such as high-performance compute servers, high-performance storage, and in some cases even high-performance networking.
• Staffing and resourcing costs for maintaining the database (design, administration, performance tuning, etc.).
• Cost of high-performance backup management, storage systems, and infrastructure based on the uptime, recovery point objectives (RPOs), and RTO expectations. (In today’s age of data explosion, databases tend be quite large, and database backup and recovery becomes key.)
Cloud computing, as a concept and a solution, is aimed at resolving these economic concerns. When you add the uniqueness of databases to the mix, you can see the value of deploying a database cloud, or in other words, deploying a DBaaS solution.

Great First Step for Transitioning into the Cloud

Moving an organization’s IT infrastructure from the old server-based model to a cloud-based model can be a daunting task, regardless of whether the destination is a private cloud or a public cloud. Implement a cloud solution on a very focused, self-contained technology stack, such as database technology, can be a very useful first step into cloud computing.
The toolkit available for database technologies is wide, extensive, mature, and multivendor in nature. The same is true for the infrastructure components, such as the server, storage, and backup infrastructures. Dedicated, fully contained, engineered appliances have been a part of the database technology stack for a while now.
Another key aspect to consider is the significant amount of automation that exists in the database arena. This is primarily due to the unique and complex nature of databases plus the sizes of the databases that are common nowadays.
Security is an important aspect of any cloud solution and is yet another consideration that has long been a part of any overall database solution. Databases have their own dedicated security model that is very mature and can fairly easily integrate into the larger organization model (single sign-on [SSO]- and Lightweight Directory Access Protocol [LDAP]-based authentication and integration, etc.). Database security models have matured to include data encryption for data backups, data at rest, as well as data in flight.
Finally, the amount of data existing within organizations is huge, and its rate of growth is exponential. Almost every application deployed will need a data repository or data store of some type. This growth in data must be supported by corresponding growth in infrastructure.
The combination of the mature toolkit, the engineering inherent to database solutions, the preexisting automation especially in the administration aspects of databases, and the existence of a mature security model provide a solid foundation upon which organizations can build and deploy their first cloud solution.
The existing domain knowledge and the highly experienced skill set available provide the technical basis for learning and fine tuning the various aspects of cloud computing.
According to some reports and surveys, database technology–related expenditure for midsize to large-size companies can be up to 40 percent or more of the annual IT budget. Having a defined organization-wide strategy for databases will help organizations manage the growth of data and at the same time keep database costs down. Considering that databases can drive up to 40 percent of the IT budget makes the database a very attractive focus area to use to kick off cloud computing as a long-term IT strategy.

Summary

Cloud computing is a generic architectural concept that encompasses the entire gamut of technology as it relates to infrastructure. Cloud computing is more than just another fancy term for “virtualization.” All of the new “as-a-service” models are implementations of cloud computing. Infrastructure, platform, database, software, network, and storage as a service all are implementations focusing on specific concepts of the technology stack within infrastructure. These terms are sometimes used interchangeably, but in reality, cloud computing is a concept, whereas the as-a-service models are implementations.
The very definition of “cloud computing” has introduced a fundamental change in thinking when it comes to ownership, roles, responsibilities, and expectations. This is not to say that ownership, roles, responsibilities, and expectations were missing or lacking before the advent of cloud computing. They have always existed, but cloud computing has change the lens through which they are seen.
Introducing the core concept of “service” into the overall architecture brings about these changes. We saw that in order to deliver a service that is meaningful, cloud computing had to introduce “elasticity, flexibility, and rapid and easy deployment” into its core concept and architecture.
DBaaS implementations are not much different from other cloud implementations. Database clouds have some unique challenges when it comes to cloud implementations, driven by their complex and temperamental nature. We need to understand these core concepts specifically as they apply to databases in order to deploy a successful and meaningful DBaaS.
This chapter is the beginning of understanding the cloud computing framework, specifically when it comes to database clouds or DBaaS.

Chapter 2. The Database Cloud Administrator—Duties and Roles

In Chapter 1, “Database as a Service Concepts—360 Degrees,” we introduced the core concepts that define and drive cloud computing in general. We went into some detail about how the concept of cloud computing applies to the database world in general. We talked about the roles and interactions that exist in a cloud environment at a very high level.
In this chapter, we explore what it means to be an Oracle database administrator (DBA) in the cloud computing world. The basic role and functions of the DBA working in a cloud environment are not much different than in a traditional, on-premises environment. What does change with the cloud paradigm is the thought process and viewpoint.