DBASchool – Will You Be Attending?
I’ll be teaching the 3-day classes that covers security, performance, best practices and all sorts of things you’ll want to know about SQL Server. Get a look at the site for specific areas covered, and make sure you get your registration in – time is short, and seating is extremely limited (only a few seats remain).
[Find out more here]
Featured Article(s)
Undocumented SQL Server 2008 System Cursor Views
In this article, Alexander Chigrik describes four undocumented SQL Server 2008 system cursor views.
Best Practices, Performance Tips, Business Intelligence How-To…
SQL Server tips, best practices, tools, tuning and much more. Business Intelligence tips, approaches and specific how-to information, SharePoint information on setting up and administering SharePoint systems – all of this and a ton of different, entirely new and fresh sessions. Where else can you attend a conference online – a REAL conference – with 75+ sessions, and a lot of interaction, live chat, session replays, session transcripts and downloads…
Mark your calendars now for April 7, 8 and 9th – and get more information or register here. (Yes, group discounts are available too! Here’s the form.)
Continuing Virtualization Feedback
Steve writes – "We have a heavy hitting 500 gb production system with 200+ user activity and when monitoring these I’ve found that even with top of the line equipment disk IO is still a critical bottleneck in the SQL software. We are as optimized as you can get and still I see disk IO at a fraction of the performance that it needs to be at so that I would feel comfortable with adding the virtual server overhead to the mix.
Of course we [are running] lower quality SANs that contribute to this but I believe that if you focusing on the disk IO as the key factor in performance you’ll find that in all but the most heavily used systems that the virtual server option is viable. As we move our systems toward virtualizations I’ll be taking a hard looks at the performance with a focus on Disk IO as the primary limiting factor."
From Greg: "I thought a bit more about the virtualization aspect, and a few more thoughts came to mind after reading the other comments from people… I can relate to much of what Rick mentioned in a way. As far as I know, we aren’t using iSCSI anywhere at this point, but we have EMC SANs, and both our SQL cluster and the vmWare boxes use that for storage. I’m a little fuzzy on details on how it all is put together.
But it was put together by the people focused on O/S things, Active Directory, hardware, and general server admin. And, although Rick didn’t say this, it sounds like he may have the same kind of problem I have… General server admin sets up the vmWare/storage aspects, without regards to application-specific needs. And then has to prove the performance problem is with the server/storage area, instead of the application, yet doesn’t have access to see anything about the vmWare/storage side that can really help to troubleshoot the problem? And it sounds like he has no way, nor do the VM admins, to monitor the I/O in an application-oriented way?
How I was able to relate to that…
When we got our student system in about 4 years ago, it was to use SQL 2005 on physical boxes (and still is, sorry for the non-virtual slant here as well, but I’ll relate it to the virtual side of things soon). The physical boxes store their data on an EMC SAN. DB size is roughly 16gb I believe. During the initial meetings, I wanted a RAID 1 volume for the transaction logs.
A Dell Technical Sales guy was in the meeting, and said RAID 5 is the industry standard for RAID. Our vmWare/SAN guy agreed, and said it would be a RAID 5 volume. It wasn’t until we got some outside input from a DB guy in Oakland using the same system, who suggested we use RAID 1 for the tran logs, that the vmWare guy then said ‘okay, since the database expert (the outside guy) said to use RAID 1, we’ll do that.
So, I believe our performance probably would have been worse had our tran log SAN volume been a RAID 5 volume. Correct? But proving that?
And that’s one of the things I’ve seen that has caused me grief… Our vmWare/SAN setup is not really handled by somebody that is real application-aware. He’s more of a general server admin. And when it comes to SQL, and other apps like Exchange, they need to be optimized for their special needs – in my opinion. So, possibly the virtualized setups, in a technical and performance kind of way, could actually be doing better if the person adminning them was stronger on the application-specific needs?
That is actually one of the reasons I wanted to start with our migration of the business system to Linux/SQL 2008 on physical servers. I wanted a baseline performance level to begin with. And then if the servers are later virtualized, we’ll have a better feel for what performance should be like on the application/SQL side, and will be able to see how that changes after virtualizing if they are eventually virtualized.
I’d probably be okay with more virtualizing, even of SQL, if I had more control and understanding of what was happening with the setup.
But in my world, virtualizing is causing me problems, as it makes it harder for me to be able to troubleshoot things, and seems to add more finger-pointing opportunities than when things were physical and better defined."