There are often times when you as a DBA are managing resources hosted on hardware for which you have no control, and perhaps, not even access. This can be expressed in different ways. For example, your database engine may be hosted on a virtual machine that is assigned to you. You may be administrator on the VM, but not have access to the underlying physical hardware to understand how the VM is configured, or how the physical resources are allocated to your VM and other clients of the host.
Another scenario is often found when your database engine does not have physically attached disk; instead it is using a shared resource such as a SAN. There are a lot of pieces connecting the server to the disk host, both hardware and software, and much if not all of that may be out of your control. At best you may be provided with one or more LUNs you may attach as drives for your system, but you do not know the disk configuration supporting those LUNs.
All of these things make a difference in how your database is performing. The more you know, the better you are able to tune things for the best database performance. In today’s world there is so much specialization or offloading of configuration for cost reduction (think of cloud services) such that you have little knowledge and/or control of key resources that directly impact your database performance,
When you have access to try and find areas to tune on your database server you’ll probably look at CPU utilization, disk wait queue lengths, page faults and things like that. These kinds of metrics can help you determine if you have enough memory, CPU or even if your disk access speeds are capable of meeting your load.
Now I’ve set the foundation for the questions I really want to ask.
What do you do when performance is slow and you don’t have the necessary access or available resources to determine what are the bottlenecks?
How to you communicate with others responsible for systems your database depends on that are not performing according to your need?
How to you identify and communicate the issues?
For example, it’s easy to blame the SAN when your database is slow. Before the SAN, it was the easy thing to do to blame the database when things weren’t working correctly. It was the default problem, ie. guilty until proven innocent. SAN administrators are the new whipping kid of problems. So, how are you going to communicate your need in a way that it doesn’t just sound like someone else screaming, your SAN is killing my performance. Or, your VM isn’t keeping up with my load!
Do you have some examples that have worked for you? This would be a great time to leave a comment.
Cheers,
Ben