This is the first part of a blog series about using vRealize Operations to optimize Oracle Database workloads running on VMware. In this series we will be focusing on virtualized Oracle Databases and using vRealize Operations with the Management Pack for Oracle EM to identify possible optimization opportunities.
The vRealize Operations Management Pack for Oracle Enterprise Manager from Blue Medora merges the virtual environment and your Oracle Databases while maintaining the same level of customization you’re familiar with inside vRealize Operations. This marriage of VMware and Oracle data provides the necessary foundation to begin optimizing your virtualized databases. vRealize Operations then provides the visual components and data analysis power needed.
With your production database virtualized, it is now sharing physical server resources with other virtual machines on the same hypervisor. We’ll call these other virtual machines siblings. This sharing makes it necessary to understand the resource needs of your database as well as its new siblings. A great way to ensure your database doesn’t starve for critical resources is to pair it up with favorable siblings (especially if your database is mission critical!). Optimizing for good siblings is a trivial project using historical performance data in vRealize Operations.
There are many ways of identifying good siblings ranging from custom dashboards to custom reports. We’re going to look at a simple version using the built-in metric selector view that vRealize provides.
First, log into vRealize Operations and verify the Management Pack for Oracle Enterprise Manager is successfully collecting.
You can do this by going to “Administration” > “Solutions” then selecting “Oracle EM Adapter” from the list of installed management packs.
As a rule of thumb, the longer the Oracle EM pack has been running and collecting the better vRealize Operations will be at identifying the trend of resource consumption.
Return to “Home”, then navigate to “Environment” > “Oracle Enterprise Manager” > “VMware VMs hosting: OEM Monitored Hosts”. Expand this final section by clicking the triangle to left. Now select your desired Virtual Machine (where your Oracle Database resides).
We’ve selected em-oel6-d2.
While you can certainly mix non-Oracle Database workload VMs into this optimization, we typically see Oracle on VMware in a dedicated VMware Cluster (sometimes its own vSphere environment) in an effort to isolate Oracle for licensing reasons.
Now that you have selected the VM housing your critical Oracle Database, select “Troubleshooting” > “All Metrics.”
Expand and double-click the key metrics you want to find a good fit for. Likely this will be some combination of memory, CPU, network, or disk metrics.
If you already know your most constrained resource (the one most likely to cause problems for your database), stick to that for simplicity. The historical trends will appear to the right. Modify the time frame to your desired history and enable the trending line if needed.
Background knowledge on the other VM workloads may help to identify ideal sibling candidates. If you have background on certain VMs, you can use vRealize Operations to verify whether or not it would be a good sibling. For example, if your subject database backs an internal application used by employees, it’s likely going to need a lot of resources during the workday. If you know there is another Virtual Machine running nightly backups or reports, this would be a good candidate due to the limited overlap of resource needs.
Select another VM from the list on the left and repeat the process of double-clicking the same metric(s). Our second VM, oradb-d2, can be seen in the screenshot below. These new metrics will now stack in the graphing area with the same time period as before. Keep an eye out for VMs that do not share peak hours or compete for resources simultaneously as these make excellent siblings!
After selecting multiple VMs you can start to identify which ones don’t share peak hours or have very minimal resource spikes. You can repeat this as many times as you like until you find the ideal siblings.
By default, after selecting the same metric for multiple VMs you will have a graphical view as shown below. Note the top-left corner has a red and green line icon selected. When you hover over this, it says “Split Charts.”
Click this to merge the charts so that you can compare each VM’s value for the selected metric while they share the same X and Y-axis.
We can see here that oradb-d2 has a consistently low and stable memory footprint compared to em-oel6-d2. We’ve found a possible match, so we’ll remember this pairing for sibling optimization.
One last view that vRealize Operations provides is a stacked view. This is particularly useful when you have selected all the VMs you want to put on a hypervisor together.
Click the solid red and green icon in the upper-left, one to the right of the “Split Charts” icon.
This view is a great way to identify your hypothetical peak usage if your selected VM’s had been running on the same hypervisor. In this example we can see our peak usage would have been about 6,000,000 KB of Guest Active Memory. With a 20% resource buffer, we can now estimate that we need the Hypervisor to have at least 7,200,000 KB of memory available to the VMs.
If you would like more information about managing your Oracle Database workloads or a free trial of the Management Pack for Oracle Enterprise Manager, please visit the product page.