Oracle cloud part 3

Chapter 4. Schema Consolidation in Enterprise Manager 12c
Schema as a service provides database consolidation by allowing administrators to host multiple application schemas within a single database. This offers capability database as a service (DBaaS) to possibly hundreds of application users without creating database sprawl. Users can perform day-to-day actions such as provisioning, monitoring, and backup all from a single self-service console. Schema as a service leverages database features such as Oracle Resource Manager and Oracle Database Vault to isolate users of the cloud. These features are complemented by metering and showback/chargeback capabilities, which provide visibility and transparency into resource consumption by each user.
However, schema as a service also has problems, the main one of which (covered in detail later in this chapter) is namespace collision. Having said that, until the introduction of Oracle Database 12c with the multitenant option, schema as a service was really the only viable way of consolidating multiple applications into a single database, and many Oracle customers used it successfully.
Before we look at the details of using schema as a service, there are two areas we need to cover:
• We need to have an understanding of the components that make up the underlying architecture. This is important for both schema consolidation (covered in this chapter) and database consolidation (covered in Chapter 5, “Database Consolidation in Enterprise Manager 12c”).
• We also need to understand the deployment issues that have to be addressed when undertaking a consolidation exercise. Again, these are common to both schema and database consolidation, but the way we address those issues will vary between the different consolidation models. We’ll come back to these deployment issues after we’ve discussed setting up and using schema as a service.
Let’s start by looking at the architecture and components.
Architecture and Components
Oracle Enterprise Manager Cloud Control 12c delivers the complete spectrum of database consolidation, as depicted in Figure 4.1.
Figure 4.1. Consolidation models

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 is typically comprised of a host, an operating system, and an Oracle database. In a similar vein, when defining middleware as a service (MWaaS) zones, a zone comprises 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 new schemas in an existing database can be created. The databases can be either single instance or a Real Application Clusters (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 4.2.
Figure 4.2. Components of a platform as a service zone




Chapter 5. Database Consolidation in Enterprise Manager 12c
In Chapter 4, “Schema Consolidation in Enterprise Manager 12c,” you learned how to set up and use Schema as a Service and were introduced to the issue of namespace collision. Let’s move on now and look at an even better consolidation model that deals with the namespace collision issue using Oracle Database 12c’s multitenant architecture—the capability to host multiple schemas from different tenants within the same database. From the cloud perspective, this model is known as pluggable database as a service (PDBaaS). PDBaaS enables the highest degree of consolidation. A pluggable database (PDB), which can be described as portable sets of schemas, schema objects, and related structures that appear logically to an application as a separate database, provides enhanced database consolidation. Users can perform day-to-day actions such as provisioning, monitoring, and backup all from a single self-service console. Metering and showback/chargeback capabilities that provide visibility and transparency into resource consumption by each user complement pluggable databases.
The steps to set up PDBaaS can be broadly outlined as follows:
1. Enable database as a service (DBaaS), including setting up the software library, privileges, and users.
2. Set up one or more platform as a service (PaaS) infrastructure zones.
3. Create a database pool for PDBaaS.
4. Configure request settings.
5. Define quotas for each self-service user.
6. Create a database provisioning profile. This step is optional and is unnecessary if you are creating an empty pluggable database.
7. Create a service template, either for an empty pluggable database (i.e., created with an empty schema) or for a pluggable database from a profile (where you can import schemas from a database provisioning profile, including applications with data such as eBusiness applications).
8. Configure chargeback.
9. While deploying a database, select the service template that you have created.
Let’s look at the details.
PDBaaS Setup
Cloud administrators configure the PDBaaS cloud, define cloud governance with policies and quotas, expose it to certain users, and decide the total amount of resources each user can reserve before the self-service portal can be used.
The first step in the process requires the Oracle Software Library to be configured. The Software Library is a repository that stores software patches, virtual appliance images, reference gold images, application software, and their associated directive scripts. It allows different versions, maturity levels, and states of entities. The software entities can be automatically mass-deployed to provision software, software updates, and servers using Oracle Enterprise Manager Cloud Control 12c (EM12c) in a reliable and repeatable manner. These provisioning operations, which are unattended and can be scheduled, lead to substantial cost savings.
Besides acting as a repository for certified software entities, the Software Library is a logical interface between the deployment models and the automation framework required to perform a large number of patching and provisioning tasks. To configure the storage location for the Software Library, follow the path Setup → Provisioning and Patching → Software Library, and set a location for the Oracle Management Server (OMS) Shared File System, as shown in Figure 5.1.
Figure 5.1. Software Library setup

Defining Roles and Assigning Users
Roles are named groups of related system and object privileges. You can create roles and then assign them to users and to other roles. You can assign any of the existing roles and the associated privileges to a new role.
When creating database zones and service templates, selective access can be granted only to custom roles. The self-service portal is intended for end users to be able to provision and manage their own cloud services. As such, end users need only access to the self-service portal and the resources they are assigned. Such capabilities are inherent in the predefined EM_SSA_USER role. Since predefined roles cannot be assigned to database zones and service templates, you need to create a custom cloud user role based on the standard EM_SSA_USER role. To do this, follow the path Setup → Security → Roles. You can use either the Create or Create Like button to create a new role.
Tip
If you use Create Like, it maps the underlying roles and privileges for you. For example, the EM_USER_SSA role is composed of the EM_USER_SSA_BASE role and additional privileges. If you select the EM_USER_SSA role and do a Create Like, the role that will be mapped to your new role is the underlying EM_USER_SSA_BASE role, not the EM_USER_SSA role, as you might expect. Roles can be granted recursively, of course (but not circularly), so what the user interface has done is to unravel that recursive role until it gets to the underlying EM_USER_SSA_BASE role and added that to your new role.
In the example that follows, we create a role from scratch.
1. Click on the Create button (see Figure 5.2).
Figure 5.2. Creating a new role, step 1

3. Provide a name, such as DBaaS_Cloud_Users, and a description, and click Next (see Figure 5.3).
Figure 5.3. Creating a new role, step 2

4. Select the EM_SSA_USER role, then click the Move button to move the role to the list of Selected Roles, and then click Review, as in Figure 5.4. We don’t need the remaining wizard steps, so they can be skipped.
Figure 5.4. Creating a new role, step 3

5. Check that all the details are correct, and click Finish to create the role. You should then see a confirmation that the role has been created successfully.
It is highly recommended that each end user should have his or her own cloud user credentials, which enables effective monitoring of services and resource utilization, so the next step is to create an end user and grant that end user the DBaaS_Cloud_Users role.
1. Follow the path Setup → Security → Administrators. You can either select another administrator and click Create Like or just click Create (see Figure 5.5). I find it easier to do the latter, as you don’t need to remove any extraneous privileges that Create Like can bring with it.
Figure 5.5. Creating a cloud administrator, step 1

2. Provide a username (I used DBAAS in this example) and password, and click Next (see Figure 5.6).
Figure 5.6. Creating a cloud administrator, step 2

3. Select the DBAAS_CLOUD_USERS role you just created, click the Move button to add it to the Selected Roles list, and click Review (see Figure 5.7). The remaining wizard steps are not needed.
Figure 5.7. Creating a cloud administrator, step 3

4. Review the details to make sure they are correct, and then click Finish to create the DBAAS administrator. You should see a confirmation message that the administrator was created successfully
Creating a PaaS Infrastructure Zone
Before you enable or set up DBaaS or middleware as a service (MWaaS), you must create a PaaS infrastructure zone that enables you to define the placement policy constraints for a specified set of targets and the users to whom this zone will be available.
1. To create a PaaS infrastructure zone, you must log in using an account that has been granted the EM_CLOUD_ADMINISTRATOR role. Once you’ve done that, follow the path Setup → Cloud → PaaS Infrastructure Zone. On the PaaS Infrastructure Zone page, click the Create button (see Figure 5.8).
Figure 5.8. Creating a PaaS infrastructure zone step 1

2. Provide a name and, optionally, a description for the zone, determine placement policy constraints per host (i.e., maximum CPU utilization and maximum memory allocation allowed), and click Next (see Figure 5.9).
Figure 5.9. Creating a PaaS infrastructure zone, step 2

3. If you already have a named credential defined for the hosts you are about to add, select it from the Named Credential dropdown list, or click the + sign to create a new named credential (see Figure 5.10).
Figure 5.10. Creating a PaaS infrastructure zone, step 3

4. Enter the username and password for the named credential, optionally provide Run Privilege (such as sudo), give the named credential a meaningful name, and click OK (see Figure 5.11).
Figure 5.11. Creating a PaaS infrastructure zone, step 4

5. Add the host (or hosts) you will be putting in this PaaS infrastructure zone by clicking Add (see Figure 5.12).
Figure 5.12. Creating a PaaS infrastructure zone, step 5

6. You can either search for the host names or just select them from the list. This is a multiselect screen, so you can select multiple rows by holding down the Shift key as you select, then click Select (see Figure 5.13).
Figure 5.13. Creating a PaaS infrastructure zone, step 6

7. Now that you’ve added one or more hosts, you can select the named credential you defined earlier and click Test Credential (see Figure 5.14) to check that it works (actually, I think this screen should be redesigned and the Credentials part put after the Targets part, but let’s just work with what we have!).
Figure 5.14. Creating a PaaS infrastructure zone, step 7

8. You should get an informational message that the credential test succeeded (if not, you will need to exit the Create PaaS Infrastructure Zone wizard and follow the path Setup → Security → Named Credentials to fix it, so it’s best to get it right the first time!). Click OK to acknowledge the message (see Figure 5.15).
Figure 5.15. Creating a PaaS infrastructure zone, step 8

9. Click Next to move to step 3 of the wizard (see Figure 5.16).
Figure 5.16. Creating a PaaS infrastructure zone, step 9

10. The zone can be made available to a restricted set of users by selecting the role (or roles) that can access it. We need to add the role we created earlier, so click the Add button (see Figure 5.17).
Figure 5.17. Creating a PaaS infrastructure zone, step 10

11. Select the DBAAS_CLOUD_USERS role, and then click Select (see Figure 5.18).
Figure 5.18. Creating a PaaS infrastructure zone, step 11

12. Click the Next button (see Figure 5.19).
Figure 5.19. Creating a PaaS infrastructure zone, step 12

Finally, review the details and click Submit to create the PaaS infrastructure zone. You should now see a message that the PaaS infrastructure zone was created successfully.
Creating a Database Pool
A database pool is a collection of servers or clusters with preinstalled database software. Each server in a database zone has identical platform and database versions. For servers that support multiple ORACLE_HOMEs with different versions, a separate database zone must be created for each database version.
1. To create a database pool, follow the path Setup → Cloud → Database to go to the Database Cloud Self Service Portal Setup page. From here, select For Pluggable Database from the Create dropdown (see Figure 5.20).
Figure 5.20. Creating a database pool, step 1

2. Provide a name and, optionally, a description for the new pool. If you already have named credentials defined for this environment, you can simply select them from the dropdown lists to the right, but if not, click the + sign to create a named credential for the host (see Figure 5.21).
Figure 5.21. Creating a database pool, step 2

3. Enter a username and password for the credential, optionally provide the run privilege (e.g., sudo), give the credential a meaningful name, and click OK (see Figure 5.22).
Figure 5.22. Creating a database pool, step 3

4. Likewise, you can provide a named credential for the grid infrastructure (if you are going to use it) and for the database. You can also specify a container database wallet password if you want to support encryption for the pluggable database that will be created (I normally provide this regardless because it saves coming back to redo this later if you change your mind). Next, we need to add one or more container databases to the pool from a single PaaS infrastructure zone. The filters we select here cannot be changed once the pool is created, so select these carefully. Choose the East Coast Zone we just created, a target type of database instance (the other choice is a Real Application Cluster [RAC] environment, but this example is being built in non-clustered configurations), and set the platform and database version correctly. Then click Add (see Figure 5.23).
Figure 5.23. Creating a database pool, step 4

5. The Select and Add Targets pop-up provides a list of already existing databases, so simply select the cdb1 container database, and click Select (see Figure 5.24).
Figure 5.24. Creating a database pool, step 5

6. Click the Next button. If you want to set maximum ceilings for resource utilization, you can do it on this screen. I’m going to leave it at the defaults in this example and select Submit (see Figure 5.25). You should see a message saying the pool has been created successfully.
Figure 5.25. Creating a database pool, step 6

Configuring Request Settings
Next, we add some settings to restrict the scope for database requests.
1. Click Request Settings (see Figure 5.26).
Figure 5.26. Configuring request settings, step 1

2. In this case, we want to change the request purging duration (the period of time after which completed creation requests will be purged from the repository) to 3 days, so change that and click Apply (see Figure 5.27). Again, you should see a confirmation message.
Figure 5.27. Configuring request settings, step 2

Setting Quotas
Next, we add quota—the aggregate amount of resources that can be granted to each self-service user belonging to a certain role. This quota applies only to databases provisioned through the self-service portal.
1. To do this, click Quotas, then click on the Create button to create a new quota (or use an already existing one) (see Figure 5.28).
Figure 5.28. Adding a quota, step 1

2. Provide a role name and quota for the amount of memory and storage, as well as the number of database requests, schema service requests, and pluggable database service requests, then click OK (see Figure 5.29).
Figure 5.29. Adding a quota, step 2

Profiles and Service Templates
Next, we want to configure profile and service template definitions that can be used by self-service users to provision databases in selected zones.
1. Click Profiles and Service Templates. A database provisioning profile is not needed when creating an empty pluggable database, but we will walk quickly through the steps anyway. Click the Create button to create a database provisioning profile (see Figure 5.30).
Figure 5.30. Creating a profile, step 1

2. Click the magnifying glass to search for a reference target (see Figure 5.31).
Figure 5.31. Creating a profile, step 2

3. Select the cdb1 container database, and click Select (see Figure 5.32).
Figure 5.32. Creating a profile, step 3

4. Provide the relevant named credentials, and click Next (see Figure 5.33).
Figure 5.33. Creating a profile, step 4

5. Since we are creating a profile with structure only, step 2 of the wizard is skipped. On step 3, you can change the profile name, path, and scheduling, but for now, just click Next (see Figure 5.34).
Figure 5.34. Creating a profile, step 5

6. Review the information, and click Submit to create the profile. You can change the page to refresh every 30 seconds on the right, and you should fairly quickly see that the profile has been created successfully (see Figure 5.35).
Figure 5.35. Creating a profile, step 6

Now we need to create a service template:
1. Follow the path Setup → Cloud → Database to go to the Database Cloud Self Service Portal Setup page again, click Profiles and Service Templates, and then click For Pluggable Database from the Create dropdown (see Figure 5.36).
Figure 5.36. Creating a service template, step 1

2. We’re going to create a new service template to provision an empty pluggable database, so provide a name and, optionally, a description, select Create Empty Pluggable Database if not already selected, and then click Add (see Figure 5.37).
Figure 5.37. Creating a service template, step 2

3. In this case, we want to use the East Coast PaaS Infrastructure Zone created earlier, so select that row, and then click Select (see Figure 5.38).
Figure 5.38. Creating a service template, step 3

4. Now that the zone is added, we want to assign a pool to the template. Click Assign Pool (see Figure 5.39).
Figure 5.39. Creating a service template, step 4

5. Select the DB12c Pool created earlier, then click Select (see Figure 5.40).
Figure 5.40. Creating a service template, step 5

6. Now we want to add a prefix to the pluggable database name, so enter a prefix, and click Next (see Figure 5.41).
Figure 5.41. Creating a service template, step 6

7. On the Configurations page, you can set up the following parameters for the pluggable database service template:
• Workload: Here you can set up different workload sizes (e.g., small, medium, and large) based on the CPU, memory, number of sessions, and storage requirements of a particular pluggable database service. These workload sizes can be chosen by the self-service user at request time.
• Role: This is the database role that will be associated with the pluggable database for the service that will give it control over the service.
• Storage: A number of tablespaces can be created for each pluggable database. This is where you set up the storage requirements, such as initial size, for those tablespaces.
First, let’s create a workload. Click Create (see Figure 5.42).
Figure 5.42. Creating a service template, step 7

8. In this case, we are creating a small workload, so name the workload appropriately; optionally add a description; set values for the number of CPU cores, amount of memory, number of sessions, and amount of storage allowed for the workload; and click Create (see Figure 5.43).
Figure 5.43. Creating a service template, step 8

9. Back on the Configurations page, provide a more meaningful name for the role that will be created, leave the other values at their default, and click Next (see Figure 5.44).
Figure 5.44. Creating a service template, step 9

10. On the next screen, you can set specific initialization parameters for databases created using this template. For now, leave that alone, and click Next (see Figure 5.45).
Figure 5.45. Creating a service template, step 10

11. On the next page, you can specify custom scripts that will be executed either before and after creating the pluggable database or before and after deleting it. Again, leave that at the defaults, and click Next (see Figure 5.46).
Figure 5.46. Creating a service template, step 11

12. On the Roles step, click the Add button (see Figure 5.47).
Figure 5.47. Creating a service template, step 12

13. Select the DBAAS_CLOUD_USERS role, then click Select (see Figure 5.48).
Figure 5.48. Creating a service template, step 13

14. Click Next (see Figure 5.49).
Figure 5.49. Creating a service template step, 14

15. Review the template details, and click Create (see Figure 5.50).
Figure 5.50. Creating a service template, step 15

16. You should get a message confirming the template was created successfully (see Figure 5.51). You’ll notice that Chargeback can be configured next. We’ll leave Chargeback for now, as it is covered in Chapter 6, “Metering and Chargeback in Enterprise Manager 12c.”
Figure 5.51. Creating a service template, step 16

So there you have it. Now we have PDBaaS set up. Let’s look now at how you use all of this in the self-service portal.
Using the Self-Service Portal with PDBaaS in Enterprise Manager 12.1.0.4
Now let’s cover how you actually use the self-service portal to create on demand an empty pluggable database. The main reason we want to do this, of course, is to automate the more mundane database administration tasks associated with creating a database. If we can leave these sorts of tasks more to the end users, while ensuring they do not have free reign to go about willy-nilly creating databases, it removes these boring tasks from our hands, and at the same time, automates the tasks to ensure correct configuration, performance, and so on.
The first step is to log in as a self-service user. Provide the username and password of the user you created earlier, and click Login. This takes you to the standard Welcome screen. The first thing to do from here is make it easier for this user to get to the right place. EM12c allows you to define home pages on a per-user basis, so we need to get to the self-service portal first.
1. Go to Enterprise → Cloud → Self Service Portal (see Figure 5.52).
Figure 5.52. Accessing the Database Cloud Self Service Portal, step 1

2. Now you can select Set Current Page as My Home from the user menu on the top right of the screen next to Setup so that next time you log in, you see this page immediately (see Figure 5.53).
Figure 5.53. Accessing the Database Cloud Self Service Portal, step 2

3. You will see a confirmation message that the Home Page has been updated. Note that the default item to manage on this Infrastructure Cloud Self Service Portal is still set to Infrastructure - Oracle VM, so we need to swap that to Databases from the Manage dropdown list (unfortunately, this selection can’t be set as a default) (see Figure 5.54).
Figure 5.54. Accessing the Database Cloud Self Service Portal, step 3

Now you are on the Database Cloud Self Service Portal page, which is where you can see all the information about requests that have already been made. In this case, of course, there are none, so the first thing you need to do is request a pluggable database. Note that this is the only request you have available to you at this stage because of the way we defined the DBaaS user in the setup.
1. From the Request dropdown list choose Pluggable Database (see Figure 5.55).
Figure 5.55. Requesting a pluggable database from the self-service portal, step 1

2. You are asked to select a service template from a list of those that have already been defined. Again, the user has been granted access to only one, so choose that, and click Select (see Figure 5.56).
Figure 5.56. Requesting a pluggable database from the self-service portal, step 2

3. Next, you are presented with the Create Pluggable Database screen. There are a number of options to populate here:
• Request Name: The name given to the self-service request. This is populated with a default value, but you can, of course, change that to something more meaningful if you like.
• Zone: The PaaS infrastructure zone where the pluggable databases for this request will reside. Again, this will be populated by default, based on the zones the user has been given access to. In this case, the user can only use the East Coast Zone I created in my earlier post.
• PDB Name: Obviously, the name for the pluggable database that will be created. Make this something recognizable rather than something generic such as PDB6.
• Database Service Name: Again, use a meaningful service name because it will be used as the service name part of the connect string.
• Workload Size: Defines the resources allocated to the database service name and is also used to derive the database resource management plan. Again, in this example only one workload is defined.
• Schedule Request: The date and time that the request will be scheduled to be created (if not being created immediately), as well as the duration for its lifespan.
• Administrator Credentials: The pluggable database administrator account that will be created by the request for this pluggable database.
• Tablespace name: The name of the tablespace to be created as part of this request.
You can enter values for all of these fields (or accept the defaults) and then click Submit (see Figure 5.57).
Figure 5.57. Requesting a pluggable database from the self-service portal, step 3

4. Now you are returned to the Database Cloud Self Service Portal page, and the request you just created should be running (see Figure 5.58).
Figure 5.58. Requesting a pluggable database from the self-service portal, step 4

5. The default for this page is manual refresh, so you can change that by clicking the View Data dropdown list on the right side of the page. After a few minutes, you’ll see the new service instance listed in the Database Service Instances region of the Database Cloud Self Service Portal page (see Figure 5.59).
Figure 5.59. Requesting a pluggable database from the self-service portal, step 5

6. Notice on the left of the screen, there is additional information pertaining to notification, as well as usage values that will now have changed. EM12c uses green, yellow, and red to indicate usage that is at normal, warning, or critical levels. The notification section is designed to alert and notify the self-service users of pending expirations, as well as any new service templates that have been recently published and are available for use. The Usage section provides information regarding current utilization in relationship to the quotas (seen on the right end of each bar) defined by the cloud administrator. If you click on the service instance name, it takes you to the pluggable database page where you can see the connection details that can be used to connect to the database to perform application development tasks (see Figure 5.60).
Figure 5.60. Requesting a pluggable database from the self-service portal, step 6

And that’s it! Now you can concentrate on the more interesting parts of database administration life, like performance management, configuring high availability, eating donuts—okay, so maybe not eating donuts.
Deployment Issues
Chapter 4 introduced six deployment issues that need to be addressed in any consolidation exercise: security isolation, operational isolation, resource isolation, fault isolation, scalability, and high availability. Now that we’ve walked through the setup and use of PDBaaS, let’s look at how it addresses each of these deployment issues.
Security Isolation when Using PDBaaS
In any consolidated environment, taking the “least privilege” approach will provide the maximum benefit in tightening security. In the pluggable database environment, the effect of granting a privilege or role is contained to the pluggable database where the grant was made, thus ensuring greater security.
At the user level, administrators can be defined in two ways:
• PDB administrators: Pluggable database administrators have the ability to administer just the pluggable databases to which they have been granted access.
• CDB administrators: Container database administrators can administer all databases within the container database.
By defining most administrators as pluggable database administrators, security is again tightened. The end result is that PDBaaS provides a very high level of security isolation.
Operational Isolation when Using PDBaaS
Operational isolation requires that any maintenance being performed on either a database or the environment it operates in affects the smallest number of other databases in the same pool. As more databases are consolidated as pluggable databases into a single container database, it follows that operations that affect an ORACLE_HOME will affect more databases. This drawback can be offset to a certain extent by the ease with which a pluggable database can be unplugged and moved to a different container database. The administrator can move databases very easily in the situation where a container database is being patched and some pluggable databases will not be supported yet in the new release (this can happen when certain applications are only certified against specific database versions, for example).
Pluggable databases can also be both backed up and recovered individually and even recovered to different points in time. This advantage increases the operational isolation significantly.
Further enhancements were provided in the January 2015 version of the database plugin:
• Out-of-place patching for DBaaS enables administrators to standardize and maintain the cloud infrastructure by applying both major and minor updates seamlessly.
• A pool patching mechanism allows process pools to subscribe to database and grid infrastructure images.
• New images are automatically deployed to service in the pool, and self-service users or administrators can choose to migrate databases to the new home.
• Subscription-based, mass scale, out-of-place patching and upgrades with reduced downtime are enabled.
Resource Isolation when Using PDBaaS
Resource Manager has the ability to create a container database–level plan to determine how resources are shared among the pluggable databases in a specific container database. In particular, this container database–level plan can control
• CPU consumed by the pluggable database.
• Number of concurrent sessions.
• Amount of parallelization via the use of parallel server processes.
• File I/O, but only in the case of Exadata.
The system global area, program global area, and network I/O are not controlled by container database–level plans.
Fault Isolation when Using PDBaaS
Fault isolation is very straightforward in the pluggable database world. When an individual pluggable database experiences some sort of problem that may impact other pluggable databases in the same container database, the administrator can easily unplug the suspect pluggable database and plug it into another container database where the problem can be resolved in isolation. This solution would be much more complex in the traditional database architecture.
Once a fault has been isolated and resolved, fast recoverability and thus smaller mean time to recover (MTTR) can be improved using Flashback Database or point-in-time recoverability:
• Flashback Database: In the first release of the multitenant architecture, Flashback Database is an operation at the container database–level only. Future releases will enable Flashback Database as an operation at the individual pluggable database level.
• Point-in-time recoverability: Because point-in-time recovery can be performed at the individual pluggable database level, if you have multiple pluggable databases affected by an issue, you can issue parallel point-in-time recovery commands to improve MTTR.
Scalability when Using PDBaaS
All databases compete for the limited hardware resources (CPU, memory, and I/O) within a database pool, so you should ensure that a database is guaranteed sufficient resources and also doesn’t have a detrimental impact on other databases within the pool. There are a variety of ways to ensure customers in a PDBaaS environment are getting the services or resources they are paying for:
• Separation of resources at the pool level
• Quotas defining the amount of memory and storage and the number of database, schema service, and pluggable database service requests that can be allocated
• Workload definitions, based on the CPU, memory, number of sessions, and storage requirements, that can be chosen by the self-service user at request time
High Availability when Using PDBaaS
The topology of a complete database system architecture (e.g., a primary database along with multiple physical standby databases) is defined in the service template by the self-service administrator. If the “Enable Standby Locking” option is selected, self-service administrators can use this template to provision a primary database and then later submit a request to add or remove one or more standby databases to the existing service instance.
Alternatively, to enforce deployment standardization, locking the option will ensure that any provisioning performed using this service template will create (and delete, if selected) the primary database as well as all the standby databases at once.
Summary
PDBaaS provides the greatest level of database consolidation available, but of course it does require the use of the multitenant option in Oracle Database 12c. It also provides ways to address the common deployment issues that need to be faced by any consolidation exercise. The next step to look at is how we can measure the costs of using a database consolidation methodology and how we can either show the costs of those consolidated environments or charge those costs to the business owners of those environments. That’s done via the concepts of metering and chargeback. The next chapter explains how metering and chargeback is implemented in Oracle Enterprise Manager Cloud Control 12c.