|
 |
Gail wrote:
>
> No, it's not.
> In my experience though, the majority of DB servers that have
> bottlenecks have IO ones, even on physical machines. Virtualising those
> means needing separate IO paths, separate physical raid arrays, etc or
> the virtuals will compeate with one another for IO.
Yep, but think about a small firm, just started. They want reliable
hardware, they need 2 servers, one for databases and one for something
else that's not so IO-sensitive (authenticating etc). Now, would they
get better performance for the DB's by buying 2 individual servers or by
using all that money on one server, from which they could utilize most
of the IO from the DB-engine?
I'd probably go with the latter one. Probably, not surely.
> I know that all the
> SQL MVPs who have given an opinion on this have recommend not
> virtualising a production DB, especially not a large one with lots of
> activity.
> I'd happily virtualise a dev or test environment. Not happy about doing
> it to a heavily-utilised prod server though. Not right now.
Yep, there's a huge scale on the db-sized used over the globe. Even if
you'll count out the 2-5 -table one-query-per-day -style ones I
mentioned earlier.
> Well, VMWare's joined the SVVP
> (http://www.windowsservercatalog.com/svvp.aspx?svvppage=svvp.htm), so
> there'll have to be some level of support. How much remains to be seen.
Ahh, nice.
> SQL's not supported at all on existing MS virtualisation products
> (virtual server, virtual PC)
As said, AFAIK those are the ones that run over the main OS, they really
can't pass any unemulated/virtualized command straightly to the hardware.
> and it's not currently supported on Hyper-V
> (which has been available for a month or so)
Hyper-V is still pretty new and at least I wouldn't be sure if they have
actually had the time to test it enough. I'd guess the support on
Hyper-V would get better after some time.
--
Eero "Aero" Ahonen
http://www.zbxt.net
aer### [at] removethis zbxtnetinvalid
Post a reply to this message
|
|
