Submit a ticketCall us

AnnouncementsTHWACKcamp 2018 is here

2018 is the seventh year for THWACKcamp™, and once again we’ll be live October 17 – 18 with packed session tracks covering everything from network monitoring and management, to change control, application management, storage, cloud and DevOps, security, automation, virtualization, mapping, logging, and more.

Register for online sessions.

Home > Success Center > Network Performance Monitor (NPM) > NPM - Knowledgebase Articles > SQL: Virtual or not - What is best?

SQL: Virtual or not - What is best?

Table of contents

Updated November 24th, 2016


SQL: Virtual or not - What is best?


All NPM versions


There are multiple components to an Orion installation:

  1. Primary Orion server
  2. Orion additional pollers / websites
  3. Orion DB (SQL Server)


The first and second above are absolutely fine to run on VMware.  In fact, we have thousands of customers running in that exact configuration. Where you run into trouble is trying to run SQL server in a VMware environment. Why? VMware storage is not optimized for the I/O requirements of storing monitoring data (at least in the majority of customers we've seen try to deploy the Orion DB on VMware), especially when you add the requirements of Orion NTA with heavy NetFlow data collection.   In most cases, VMware storage is on a SAN which is in use by many other applications and not optimized for SQL data storage, which creates contention when SQL needs to be optimized for heavy writes.  


This is why we strongly recommend running SQL server on a physical box with direct attached storage. SAN is also possible, but you have to know what you're doing. I've attached some SAN reference environments if you're interested in what other customers are doing.

SAN Storage Best Practices for SQL Server (© 2017 Brent Ozar Unlimited®, available at, obtained on April 11, 2017.)

Microsoft® SQL Server® in a VMware® Environment on Dell™ PowerEdge™ R810 Servers and Dell EqualLogic™ Storage (© 2017 VMware, Inc., available at, obtained on April 11, 2017.)

Understand SQL Server and IOPS On any server that hosts a SQL Server instance, it is very important that the server achieve the fastest response possible from the I/O subsystem. More and faster disks or arrays provide sufficient I/O operations per second (IOPS) while maintaining low latency and queuing on all disks. You cannot add other types of resources, such as CPU or memory, to compensate for slow response from the I/O subsystem. However, it can influence and cause issues throughout the farm. Plan for minimal latency before deployment, and monitor your existing systems.

Before you deploy a new farm, we recommend that you benchmark the I/O subsystem by using the SQLIO disk subsystem benchmark tool. Note that this tool works on all Windows Server versions with all versions of SQL Server. For more information, see SQLIO Disk Subsystem Benchmark Tool.

Stress testing also provides valuable information for SQL Server. For information about how to use the SQLIOSim utility and SQLIO for stress testing, see the TechNet video Stress testing using SQLIOSIM and SQLIO and How to use the SQLIOSim utility to simulate SQL Server activity on a disk subsystem.

For detailed information about how to analyze IOPS requirements from a SQL Server perspective, see Analyzing I/O Characteristics and Sizing Storage Systems for SQL Server Database

Applications -->

SQL Server Customer Advisory Team (© 2017 Microsoft, available at, obtained on April 11, 2017.)

Configuring Storage for Your SQL Server Environment (© 2017 Penton, available at, obtained on April 11, 2017.)




Last modified