Chapter 7. Manage and Administer the Database Cloud in Enterprise Manager 12c
Now that we’ve covered in some detail how to set up and configure the various database cloud models in Enterprise Manager Cloud Control 12c, you may be thinking that there really is no need for a database administrator (DBA) in the cloud world. After all, once the pools, zones, profiles, and templates are set up, database creation (and even destruction) is now in the hands of the self-service user. Depending on whether you are using a public or private cloud model, many of the time-consuming tasks such as installation, setup, and configuration may now be in the hands of cloud providers rather than DBAs.
In fact, nothing could be further from the truth. DBAs are still very much in demand in cloud environments. Moving to a cloud environment may remove much of the tactical work that DBAs have had to manage for so many years, but that simply frees them up to move to a more strategic position where they can focus on areas that are of more value to the business.
Although the creation and destruction of databases may now lie in the hands of self-service users, it will be a long time before users take on some of the other roles of the DBA, such as performance tuning (if indeed they ever take it on!). Old habits die hard, and it has long been the habit of users to reach out immediately to the DBA when they run into a performance problem. “The database is slow!” has been the catch cry for many years, even though it is often not the fault of the database. With so many technology layers between the end user and the database, one of the main reasons that users will still turn to the DBA for performance problems is that they simply lack the knowledge and skills to identify where the problem lies, let alone to understand and address the problem.
It may be more difficult in the cloud environment for the DBA to identify what sorts of performance issues are occurring. The reason for this added difficulty will largely be that DBAs are more remote from the day-to-day running of these databases than they may have been previously. One of the main roles of the DBA in the non-cloud world is to ensure databases are up and running, available to end users, and performing well. To that end, many DBAs have developed their own scripts that they run as cron jobs in the *nix world (or batch jobs in the Windows world), or they use tools such as Enterprise Manager to perform similar sorts of functionality. Of course, DBAs traditionally have had some form of access to the databases they are looking after, either by directly logging onto the machines that hold the databases or by accessing the databases across the network. In the cloud world, self-service users can create databases (up to the quotas that they have been provided with, of course) without the DBA even knowing the databases exist, let alone where they are. Thankfully, there is a straightforward answer to this issue—the Cloud Home page.
The Cloud Home Page
Once you have completed the setup of your cloud services and self-service users have started submitting requests, the Cloud Home page is useful for getting a cohesive view of all the different service types. To access the Cloud Home page, follow the path Enterprise → Cloud → Cloud Home, and you will see a screen like that shown in Figure 7.1
Figure 7.1. The Cloud Home page
From here you can see a number of regions—General, Request Status, Incidents, Top Resource Providers, Top Requested Services, and Top Charge Trends (data is displayed in the Charge Trends region only if you have enabled chargeback), so you get a good overview of the health of your cloud infrastructure. If you want to drill down to look at more details of what service instances you have available, you can click on the number to the right of Service Instances. This link will show you exactly what service instances are defined in your cloud environment, their status, the service type, the resource provider, the service template, and even who owns it (see Figure 7.2).
From here you can also click on the name of the service instance (for example, crm00001) to drill into the home page for that particular target, or you can simply select the row containing that target to do the following tasks:
• Start or stop the instance. Which one of these options is available depends on the status the instance is currently in. For example, if the service instance is already started, the Start option will remain grayed out.
• Examine the history of the service instance by clicking the History icon. This feature shows all the operations that have taken place against this particular service instance since it was created.
• Delete the service instance if it is no longer required. Obviously, caution should be taken before deciding to perform this operation.
You may find that the two most important links are the ones that show failed requests (the red slice of the pie chart in Figure 7.1) and the heat map (which you get to by clicking View Map on the top right of the screen shown in Figure 7.1). The failed request statuses are ones you’ll want to investigate further to see what went wrong. Sometimes, this task is as simple as an attempt to start a database that’s already started, but at other times, you’ll find more complex issues that need further investigation and follow-up. You should also check here for requests that failed due to insufficient quota or resources and investigate whether more quota or resources need to be allocated.
The heap map is a way to graphically view which resource providers (such as platform as a service [PaaS] infrastructure zones and database pools) are using the most resources. Even in the relatively simple environment we’re using as a demonstration, the heat map (see Figure 7.3) shows that the host allocation for the Salt Lake City PaaS infrastructure zone, at 66 percent utilization, is starting to reach a level that may require adding more PaaS infrastructure zones. In more complex environments, you may see resource providers that show up as red. If you select that resource provider, you’ll see what the problem is in the Metric Details region shown below the heat map, and you can drill into the Value link to discover more details.
Figure 7.3. Heat map from a simple cloud environment
There is also a menu of items that you can select from using the Oracle Cloud menu on the top left of the Cloud Home page. Several items in this menu are useful from an administration and management perspective.
Members → Topology
This menu item shows use a graphical representation of how the different items in your cloud environment are related. It is particularly useful when the environment becomes more complicated, as it allows you to see at a glance how items are related to each other. By clicking on one of the items, you can see specific details listed under the Metric History region on the bottom right (see Figure 7.4 for an example).
Figure 7.4. Configuration Topology
Resource Providers, Service Templates, Service Instances
Each of these menu items takes you to a list of the different entities. From here, it is easy to select and edit each particular entity. You can also get to each of these pages by clicking the links next to each one in the General region of the Cloud Home page. From each page, you are also able to create new items or delete existing ones. Figure 7.5 shows an example from the Resource Providers page.
Figure 7.5. The Resource Providers page
Requests
If you click on Show All under Requests, you can see a complete list of the requests that have been made in your cloud environment, as shown in Figure 7.6. From here you can do the following:
• Select an individual request and look at the details for it.
• Reschedule the request if it hasn’t already been executed.
• Delete the request.
If you click on Requests: → Dashboard, you’ll be taken to a more graphical representation of the request trends over the past seven days, as shown in Figure 7.7. Note that you can click on the Settings spanner on the top left to change this time period to one more suitable to you (Figure 7.7, for example, shows the last 31 days’ worth of requests). This page is particularly useful for showing request trends to management.
Figure 7.7. The Request Dashboard
The Cloud Adviser
The information we’ve covered so far in this chapter is really the bread and butter, the day-to-day life of a cloud administrator. However, one of the main advantages of moving to a cloud environment is that it frees up a lot of the DBA’s time. No longer do you need to focus on the mundane tasks of creating databases, looking after backups, and so on. The time that you used to spend working on these tasks is now available for you to take on a much more important role—the cloud adviser.
What is the cloud adviser’s role? Well, it’s a role that many of us have been performing for years—the senior DBA role—expanded into the cloud environment. Since most of our business users do not have the technical background to be able to make informed decisions on technical issues, they still come to the DBA to provide that advice. Those technical issues fall into a variety of broad topics, which the rest of this chapter examines.
Security
Security is of paramount importance in the cloud world, because if you get the security model wrong in the cloud environment, you may not have an environment to administer and manage for very long! We’ve all no doubt heard of the security breaches that seem to be increasingly common in the cloud environment. Security breaches might involve stolen usernames and passwords from cloud providers and, more seriously, stolen data. Oracle database technology is used the world over to secure large volumes of confidential data—financial data, employee data, customer information, and so much more. Securing that data, and ensuring it remains secure, is an essential part of the DBA’s role. Following are some of the tools that can be used to assist with this task:
• Transparent Data Encryption (TDE): TDE is a way to stop would-be attackers from bypassing the database and reading sensitive information directly from the files that make up the Oracle database. This protection is extended to any backups that have been made of the database as well. TDE allows encryption of individual columns right up to entire tablespaces, so you can choose how much of your data to secure.
• Data Masking and Subsetting: As you move to the cloud environment, one approach that is often taken for security reasons is to migrate development and test environments to the cloud first, as these environments are often seen as lower risk. However, at the same time, you want to ensure that your developers and quality assurance (QA) engineers have environments that are as close to production as possible so they have a realistic environment to test performance on. Those two requirements may at first glance seem antithetical, but Enterprise Manager contains Data Masking and Subsetting tools that can be used to address the issue. Oracle Data Masking and Subsetting allows you to sanitize copies of production data for development and QA environments so that your production data is not compromised. It also allows you to use subsets of the data in cases where you simply do not have enough storage to take a full copy of your production data into these environments.
Of course, you need to secure your data against more than just external attacks. Most studies of security breaches indicate that these breaches are more often the work of insiders than of external hackers (regardless of the fact that the most reported-on breaches are external). So from a security perspective, you must have tools and technologies that can be used to both track and secure against internal attacks as well. Some of the Oracle products that help to address this space include Transparent Data Encryption, Oracle Audit Vault, and Oracle Database Vault.
Server and Database Sizing
In theory, scaling a database in the cloud world is as simple as requesting more processing capability. In reality, we all know that service providers, be they an internal IT department or an external hosting provider, will have limitations as far as the hardware they have available to them. One of the value-add roles that a DBA can perform is to determine the amount of resources required now to meet current needs as well as to scale to meet future requirements. Enterprise Manager 12c has a number of tools that can be used to assist the DBA in this arena, including the following:
• Consolidation Planner: Consolidation Planner is a tool that can be used to plan a cloud architecture for server consolidation or for any other consolidation model. It allows you to identify source and destination targets and applicable technical and functional constraints, such as where the application can reside. You can also use Consolidation Planner to determine whether source environments can be consolidated onto hardware that you have not yet purchased, providing greater confidence that machines you are looking at purchasing will be suitable for the workloads you plan to put on them.
• Chargeback: As we covered in Chapter 6, “Metering and Chargeback in Enterprise Manager 12c,” chargeback is an accounting tool that provides a way to aggregate the enormous amount of metrics data that Enterprise Manager collects, a way to report to consumers of those metrics how much they have used of those particular resources, and, if you have set it up to do so, a way for the IT department to charge those consumers for the resources they have used. However, its usefulness is not restricted to these functions. Once the chargeback application is configured and running, you accumulate a history of how many resources have been used by specific applications or databases, which in turn allows you to project some form of capacity planning figures for future growth. Obviously, you still need to talk to the application owners to get an idea if any new functionality may impact those figures, but at the very least, you have a starting point that can be used to predict future resource requirements.
Performance Tuning
As mentioned at the beginning of this chapter, contacting the DBA is all too often the first port of call for users complaining about performance, even before they can identify the database as the source of the performance issue. Of course, if we’ve ensured server and database sizing has been done correctly, we shouldn’t see too much in the way of performance issues. Nevertheless, we all know that server and database sizing is far too often a reactive rather than proactive exercise, so we still need to undertake the same sorts of performance problem identification and resolution exercises that we are familiar with from the non-cloud environment. This topic is far too large to cover here—indeed, whole books have been written about Oracle performance tuning—we won’t go into more detail now. Suffice it to say, you will still need to perform this role but with the added complexity of not necessarily knowing beforehand what other environments may be directly impacting yours. Consequently, you should become familiar with the pages covered at the beginning of this chapter, particularly the Cloud Home. It’s there that you can get an overview of what cloud instances have been created and can drill down to see all the different service entities that have been created and removed.
Summary
Oracle Enterprise Manager Cloud Control 12c should be your tool of choice when monitoring, administering, and managing the Oracle database cloud environment. As you’ve seen over the past few chapters, it provides the capability to set up both schema as a service and database as a service as well as to configure the chargeback application. Additionally, as we’ve seen in this chapter, Enterprise Manager 12c allows you to perform the ongoing management and administration of the cloud environment you have set up. One final step remains as an often undertaken task in the cloud environment: cloning of databases from one environment to another. That’s the subject of our next chapter.