Database Underground | Sean McCown » Virtualizing DBs

November 08, 2006 | Comments: (0)

Virtualizing DBs

TAGS: General Database

Today Tom Yager wrote about going down the virtual rabbit hole. I'd like to go ahead and chime in because this is directly relevant to issues DBAs have to face every day.

I'll just tell you a story of what happened to me a couple years ago. We had a very distributed environment and we did pretty much everything through TS. I was asked to put move a production SQL box to a new server for space issues. They gave me the box, I connected through TS, installed SQL Server, and got the DBs up and running. It was actually pretty smooth. We then started having all kinds of problems on it. Problems that we'd never had on the old server. I traced activity, I ran Perfmon, etc. What I found was that we had severe disk contention that was unexplainable, and a miriad of CPU queues, and dropped connections. I asked them to point out the physical server to me in the server room and I went in there to investigate further. I was pretty sure I wasn't going to find anything that I hadn't already seen through TS, but it was worth a shot.

I got on the console and the first thing I did was go to SQL Server. It was missing. I was baffled because I could connect to it from my workstation. Then I figured someone had just removed it from the program menu. So I searched the hard drive for the bits, and SQL definitely wasn't there. I went back to my workstation and connected again... hmmm... ok, so I checked the machine name. Then I went back to the console and checked the machine name.

AH-HA!!! It was a different machine. I went to the Windows admin and told him he'd pointed me the wrong box. He said, no, you have to go to the VMWare session that holds that SQL box. OK, so now we're talking... this is a virtual instance of SQL... got it.

So what they'd done is give me a virtual server without even telling me about it. Nice. OK, so that definitely changes things now. It wasn't long after that before I pinned down that they had put several other production servers on that box as well, and there's where all the funniness was coming from.

So not only was Tom right on the money, I've experienced it first hand. Virtual instances of DBs should be kept to dev and or test and QA. It's also a good idea to use them in DR sites where you'd have to keep up and running during an outage, but not for long term processing. It can really bring the cost of a solid DR solution down. So don't be afraid to use virutalized DBs, but know when and where to use them. And at least try to be aware of the boxes that are real and virtual. From there on out, I asked them if a new server was real or not.

Posted by Sean McCown on November 8, 2006 09:53 AM

RATE THIS ARTICLE: