SQL Server features and VMWare
-
At a meeting the other day a developer mentioned how some SQL Server features become either insignificant or obsolete in some environment set ups. (What I mean by obsolete, is that the MS recomendations as cited in books online, are not relevant) For example, the recomendation to separtate the transaction log and data log to different spindles to relieve read write arm contention I/O does not necessarily apply when your storage is SAN with a shared block level scheme. Right? Sorry, in advance if this example reveals my lack of knowlege.
What I'm wondering, is if anyone has considered more of a dynamic BOL based on environment variations.
Is there a best practice document for SQL Server when deployed on VM? Something that points to which features might be more relevent? which do not carry as much impact?
Best and thanks in advance
John
SQL 2012 Standard VPS Windows 2012 Server Standard
-
-
Alex, do you mean the manufacturer of the VM where when you say 'depends on the environment' or other? Do I need to become a VM expert to DBA in a virtual environment? I'm tyring to get a feel for DBA responsibilities in this new environment.
SQL 2012 Standard VPS Windows 2012 Server Standard
-
No i meant your SAN/VM configurations depend on what kind of database system will be running on that VM like OLTP, 3rd party Application databases like payroll or salesforce or DataWarehouse.
For example our companies 3 OLTP sites are running on a 4 node Virtual Cluster consisting of 2 ESX hosts with storage on NetApp V3210.
Each SQL Server 2008 R2 EE VM has Windows Server 2008 with 4CPU and 64GB of RAM.
similar to this pic
You need to understand how VMware works with storage and networking.
Alex S -
You shouldn't have to worry about a VM environment as a SQL Server admin, unless you have perf problems. Tracking those down can be challenging since you need to somehow relate the virtual counters to physical ones on the host.
Even in a SAN environment, separation of the log and data matters when you are under load. What a "load" is depends on your system. The separation may or may not provide significant benefits (or hindrances) on a SAN, but a SAN is still a bunch of disks. It's not a magic box that eliminates all disk contention. It can be much faster than local storage, or it can be slower when it's heavily loaded.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply