Latest release of cloud plug-in (part of EM12c R4 Plug-in Update 1) brings the ability to define sizes for database cloud services (Schema and PDB services already support definition of size). Prior to this ability, customers were required to define a new template for each size – small, medium, large, etc. This will help in significantly reducing the number of templates required.
So lets see how to use them.
1. The CRUD operations for database size are performed via emcli verbs. To create a new size, we run:
./emcli create_database_size -name=Tiny -description="tiny size"
-attributes="cpu:2;storage:20;memory:2"
The 4 attributes supported for size are – cpu, memory, processes, & storage. All attributes are optional, and minimum name and description need to be provided.
To list all sizes, we run:
./emcli list_database_sizes ____________________________________________ Name:tiny Description:tiny size CPU(cores):2 Memory(GB):2 Processes(COUNT):Not Specified Storage(GB):20 ____________________________________________
Had this size been assigned to any service templates, we could have provided the -details flag and gotten that list as well.
Editing this size is equally easy. We run:
./emcli update_database_size -name=tiny
-description="Tiny database size"
-attributes="storage:remove;processes:500"
____________________________________________
Name:tiny
Description:Tiny database size
CPU(cores):2
Memory(GB):2
Processes(COUNT):500
Storage(GB):Not Specified
____________________________________________
Few things to notice are:
- name is the only fixed identifier, both attributes and description can be changed
- to remove an attribute, set its value to remove
- to set new attribute values, or change existing one, simply specify the new values
Finally, to delete a size, we run:
./emcli delete_database_size -name=tiny Are you sure you want to to delete?(yes/no) yes Database size tiny has successfully been deleted
Since delete is a destructive operation operation, you get the “Are you sure?” prompt.
2. Once sizes are defined, we can see them while creating or editing service templates. Note that by default, no sizes are attached with the service template. The administrator needs to explicitly associate a size with the template, as shown in the screenshot below.
3. Once the association is complete, and the template is saved. Any cloud consumer accessing the template via the cloud portal will see size as an additional input.
If you are using REST APIs, then database size will have to be provided as an additional input to the POST request.
A commonly asked question is that how are these values enforced? The answer depends on the the type of attribute:
- cpu – this translates to cpu_count and is set as the DB init parameter
- memory – this translates to memory_target and set as DB init parameter (This is a good time to mention that the memory attribute is only supported for DB version 11g and above. Other attributes work for 10g and above.)
- storage – this is used only for monitoring purposes, and not enforced. So at the time of provisioning we ensure that the storage requirements for the service are within the quota limits of the consumer, but these limits are not set on the database.
- processes – this is set as DB init parameter
In summary, the ability to define size as an external entity will help drastically reduce the number of templates required to be defined by the cloud administrators.
Additional Resources:
Musings 