Supporting Hardware - Expert Consolidation in Oracle Database 12c - page 89

Up to this point all the configuration about control groups are transient. In other words, if your server reboots,
the control group configuration will all be gone. This will be a serious headache because it might prevent databases
from starting if the processorgroup_name parameter is set, but the corresponding control group is not defined at the
operating system level. Thankfully you can dump your configuration into a file to be read by the cgconfig service.
Use the cgsnapshot utility to write the configuration to standard output and cut/paste the relevant bits into the main
configuration file /etc/cgconfig.conf. This time the configuration will be read and applied during the system boot.
In addition to the processor_group_name parameter, a little bit of additional setup work needs to be performed.
First of all, it is recommended to set another initialization parameter named use_dedicated_broker to true and
also enable the new connection broker in the listener configuration file by setting DEDICATED_THROUGH_
BROKER_ listener_name to on, followed by a reload of the listener. Note that if you are using the new multi-threaded
architecture, the use_dedicated_broker parameter is already set to true. You can read more about the multi-threaded
architecture in Chapter 2.

Benchmarks
When building a consolidated platform, you might want to consider testing hardware from different vendors to ensure
that your choice optimally fits your environment, standard operating procedures, and deployment process. Getting
hardware on loan for evaluation is a great way of testing combinations of hardware, software, networking, and storage.
From the outset of this testing, you should ensure the following:

• Availability of dedicated resources. For example, if you are evaluating a storage solution, you

need resources from storage engineering or whoever is responsible. If necessary, you need
operating system support to compile drivers and package them in form of RPMs. If you are
resource-constrained, it might be better to postpone the evaluation until more continuous
time from the respective teams is available. There is nothing more frustrating than having to
return the hardware without having been able to come to a conclusion.

• Define a test plan. Your evaluation should be planned well in advance. Benchmarks,

workloads to be run, and (performance) statistics to be gathered need to be defined and
documented for each iteration. A minimum number of iterations should be defined as well to
minimize statistical outliers.

• Ensure that the hardware can be installed and configured. Your data center needs to have

enough rack space, network ports, electricity, etc. The raised floor must support the weight
of the hardware, etc. This sounds trivial, but neglecting these factors can lead to significant
delay. In reference back to the first bullet point, your data center management also needs to be
available to add cables and to configure the essential remote access console for the engineers
to take over. If Fiber Channel based storage is required, then the servers need to be connected
to the right fabric switches, and initial zoning needs to be performed.

• Vendor support must be secured, at least for the duration of the evaluation. The support you

get during the evaluation must be at least adequate. Bear in mind that the vendor ought to be
very keen to sell. A poor support quality during the proof-of-concept phase might well be an
indication of the things to come. Potential support problems should be treated seriously and
put on the critical path if necessary.

• If you are migrating to a different hardware platform such as x86, then you need support from

the operational team in case you have any questions about the application after the migration
has taken place. This favor can easily be returned to the operational team by scripting the
migration process or at least documenting it to a good, detailed standard.

There are a number of benchmarks you can employ, with varying degrees of meaningfulness. The best
benchmarks for Oracle workloads are your own applications. No synthetic benchmark, regardless of how well it is