LutzM (12/22/2010)
Gagne (12/22/2010)
...Lutz, that sounds like you're saying that generally speaking, virtualizing a SQL Server will impact performance and that it's all a question of whether it will slow it down enough to be noticeable or not. Did I interpret this correctly ?
...
On a 30GB database I had a 15GB transaction log and it wouldn't go a day without expanding when I was backing it up every 12 hours. I think that falls well into the high I/O category 😀
Virtualization basically means to share hardware resources, or to allow other "processes" (= virtual machines) utilize free resources on a given machine.
There are basically two scenarios:
1) your (formerly dedicated SQL) server will be used as a host for virtual machines. Then you'd have to share resources. Example: As long as your current system never exceeds 90% CPU utilization and you don't have anI/O issue at all, you'd hardly recognize a VM utilizing 5% of the CPU with low I/O impact. It won't impact the SQL Server performance in general.
2) Your server will be moved to a (more powerful) hardware, but will run in a virtual machine. Assuming you'd have to share the hardware with other systems consuming much less CPU and I/O and your system had hardware driven performance issues before, you could even benefit from going virtual.
It all depends. Therefore, there's no "generally speaking". Unfortunately.
Regarding your transaction log: you might want to perform a transaction log more frequently (the setting on our production system is 15 minutes...). But that's a different story. More or less (because of the file size issue).
Here's another aspect to consider: just because you viritualize you server doesn't necessarily mean you HAVE to share the underlying hardware. We've virtualized a LOT of our servers, simply because it becomes much easier to swap out the "underlying plumbing" without huge conversion routines/server moves/etc....
I am not sure of all of the magic our intrastructure guys pull to make this happen, but they've done a really good job of just that. A week ago, the hardware our big primary DB ran on started showing signs that some of the hardware was going, so they "moved" it from one physical box to another while the server was up. Sp the virtual instance stayed up even after the physical hardware was taken out.
So the question might turn into - how do they plan on making the virtualization work? can they make sure you odn't lose the performance edge you need, etc....
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?