BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
Database servers (virtualized or otherwise) make extensive use of storage, and intense file access traffic can impair the database server's performance. File traffic typically occurs from two sources: data which generates a significant amount of random reads from disk, and log files which produce a large number of sequential writes to disk. In addition, the network itself can pose a bottleneck when storage occurs on a remote device like a SAN -- such as using Fibre Channel over Ethernet.
Before making any changes to a virtual database server, it's important to gather diagnostic information about the system's performance. Virtualization management tools -- like VMware vCenter Server --collect real-time performance metrics from each host that it manages such as a virtual database server. Tools like Windows Performance Monitor can also track a multitude of statistics (counters) for storage, network, processors, memory and so on. Review any performance metrics for the managed server and look for indications of storage or network latencies or other errors.
If the underlying performance issue seems related to the server itself -- such as overutilization of processor or memory resources -- system administrators can generally opt to allocate more server resources to the database, or perhaps free resources on the server by migrating other workloads to different servers in the environment. Practically speaking, important database servers typically have few other virtual machines running on the same box, but it's a point to check. Don't overlook the database's setup or configuration. Some products like Oracle may rely on discrete settings in a configuration file to establish resource usage.
If logs or other diagnostic reports suggest issues with storage throughput or latency, consider redistributing the storage traffic across different disks. For example, direct log file storage to a LUN on one physical disk (or RAID group) and utilize a different physical disk or group for the actual database data. This does nothing to stem the overall storage I/O, but can boost storage throughput by running more disk spindles simultaneously. An alternative might be to place the database data on a higher storage tier such as solid-state disk drives.
If the bottleneck appears related to network connectivity -- either between the database and storage, or the database and client systems -- it's usually easiest to boost bandwidth with additional ports (adapter teaming) or upgrade the virtual database server's network access with a faster network interface card and corresponding switch port. Network changes may require more detailed architectural consideration and deployment planning before implementation.
While these are just some generalized ideas, it's a good idea to refer to any troubleshooting guides or knowledge base files provided by the database vendor and search detailed guidance for your specific database product.
When not to virtualize SQL Server
Is a virtual database storage server a good idea?
Benefits of virtualization to mission-critical apps