SQL Pass 2010 Trip Report

In addition to the two key things I picked up on at SQL Pass I also wanted to put together a more detailed trip report with a bit more detail.

The SQL Pass Summit 2010 conference was well run with an audience that is focused on Microsoft SQL Server.  The attendees were mostly SQL Server DBAs and all of the sessions were pretty technical from what I saw.  There were about 3000 attendees which is much smaller than the 40,000ish that were at Oracle Open World - but this conference is just for a single product, where Oracle Open World is actually the conference for Oracle DB, Oracle Apps, PeopleSoft, JD Edwards, Java, and the many others that Oracle has in it's portfolio.

I arrived on Sunday evening so that I would be there early Monday morning when the conference started.  I found out when I checked in a registration that Monday was a pre-conference day.  This meant that while there were sessions going on all day, you had to pay extra to attend them.  So I ended up working from my hotel room for the morning and then working from the very nice hotel lobby lounge in the afternoon.  The moral of the story is that SQL Pass has a pre-conference to the conference.  (There was also a post-conference day as well!)

On Tuesday I attended the opening keynote address which was very interesting.  Ted Kimmert from Microsoft talked about the next version of SQL Server - codename Denali.  Skip to about the 80% point in the keynote and watch Microsoft Distinguished Engineer Amir Netz.  Very good demo and presentation.  Amir manages to make managing a billion rows fun.

I then ended up spending the rest of the day in the VMware booth talking almost non-stop about virtualizing SQL Server.  Just about everybody was already doing some amount of virtualizing on vSphere and many had virtualized most of their SQL Server databases.  So the conversation usually centered on what SQL Server databases had not been virtualized yet.  These tended to be big and performance sensitive database instances.  This is where Storage I/O Control comes into play to be able to give these high performance databases a higher priority in terms of storage.  This is a big deal and gives a virtualization admin the ability to configure a VM to be able to support performance intensive database the storage performance it needs.

I also did quite a bit of talking about how important it is to understand exactly how the storage is configured and deployed for the SQL Server VM.  Mis-configured or under sized storage is the primary reason that I see for poor performance with SQL Server.  After some analysis of the storage configuration it usually tuns out that the SQL Server data is on the same physical disk spindles as a bunch of other stuff (file servers, web servers, dns servers, etc).  While this sharing of disks works out great in many scenarios, it can lead to a disaster with databases if there are not enough IOPS to go around.  The solution to this is to get to know your SAN and/or virtualization admins better.  Get them to understand that your storage requirements are more than just capacity in terms of gigabytes.  The number of IOPS and disk latency are important to ensuring good performance.

On Wednesday morning at 6:45am I was on panel with Brent Ozar, Donny, and Wanda He to answer questions on virtualizing SQL Server on vSphere.  Brent acted as the panel moderator and also answered most of the questions and generally did a great job (even though he was wearing a kilt!).

I spent some more time in the booth on Wednesday.  There was some discussion even at SQL Pass about Oracle change in their support stance for Oracle RAC.  I also talked to several DBAs about the perfmon counters that are added by VMtools to allow for more transparency in CPU and Memory usage for the VM from the vSphere ESX server level.  These counters give information that will indicate if they are in contention for resources with other VMs on the same host.  When having a discussion with the virtualization admin (or analyzing the performance if you are the virtualization admin) these perfmon counters are very useful.

I also went running every morning before the conference.  I ran down Pike street to the famous Pike Street Market.  One day I turned north and ran next to the water on sidewalks and pedestrian/bike lanes.  There was an incredible view of the mountains through a few clouds as the sun was coming up.  But it was kinda cold and windy running right next to the water.  So the next day I turned south at the market and ran down to the where the Seattle Seahawks play on Sundays.  Cool to see the stadium.  Even though it was cold (and just a tiny bit rainy one day) I would highly recommend running down in this area of Seattle if you get the chance.

Todd

Two Things from SQL Pass

I attended SQL Pass in Seattle last week and found the attendees to be a bunch of knowledgeable SQL Server DBAs.  While this may not be a surprising thing for me to say about THE conference for SQL Server, I did learn two things from talking and interacting with everybody I met.

One thing that didn't surprise me was that most SQL Server DBAs were already on board with running, at least some, production level SQL Server databases on VMware vSphere VMs.  What a lot of them wanted was a better understanding of the vSphere virtualized infrastructure that they were running on to be able to have more productive conversations with their vSphere and SAN administrators.  This leads to two things: special VM performance counters in the guest and Storage I/O Control (SIOC).

When VMtools is installed in a Windows VM it installs several things including a set of performance counters that are specific to that VMs performance.  These counters are populated with information from the ESX level for VM processor and VM memory usage.  These counters give an accurate look at how these resources are being used or consumed by the VM and not affected by the VM being virtualized.  They are under VM Processor and VM Memory in windows performance monitor (aka perfmon).  DBAs can use this performance information when talking to their vSphere admins to have a more productive conversation.

SIOC is a new feature with vSphere 4.1 that allows for VMs to be assigned different levels of priority to a given LUN.  It is coordinated across all of the vSphere hosts so that the priority is enforced even if the VMs are on different physical hosts.  For DBAs this means that if you have some SQL Server VMs that really need to be guaranteed higher levels of storage performance, you can use SIOC to ensure that a poorly written query on an unimportant DB doesn't take all of your I/O performance.

Todd

Support for Oracle RAC on vSphere - Removing the Barriers

I've been excited for a couple of days now.  Two days ago Oracle modified their official support stance for their products on VMware vSphere to include Oracle Real Application Clusters (RAC).  Previously RAC was the only product that Oracle had specifically called out as unsupported.  With the change of a couple of days ago - everything is supported (with a couple of caveats - like a specific version number and a few other things).

The reason this is exciting is that it removes a major barrier to the perception of vSphere as a platform for high performance enterprise applications.  Oracle RAC is a high performance cluster solution that is often used by customers for their most critical Oracle databases to ensure high availability and provide scale-out performance. The fact that RAC is now supported by Oracle running on VMware vSphere illustrates that vSphere is capable of running the most demanding and intensive applications.  Previously when a customer would hear that RAC wasn't supported on vSphere it would put plant a seed of doubt, but that is now gone.

This was the biggest unsupported statement from one of the biggest software companies and getting it reversed is a removal of a barrier to move to a more flexible, more efficient, and easily managed datacenter.

There is still plenty of work to be done to improve the support and licensing aspects of Oracle software on virtualized environments, but I think that this change with RAC support is a very positive step.

Todd

No Problem with More Cores for vSphere

I read a great blog a couple of weeks ago by Brent Ozar called SQL Server Virtualization: Mo Cores, Mo Problems.  I thought that it was cool because it talked about virtualization and performance and databases and, well that's just three of my favorite things.  Only problem was that the title made it sound like it wasn't a good idea to virtualize SQL Server on a system with lots of cores.

But that's not really what the blog says when you read it.  Brent is an expert on virtualizing SQL Server and what he actually says in the blog is a more detailed discussion.  He concludes that he prefers smaller servers over larger servers for SQL Server virtualization.  Despite the title I recommend you read his blog for the discussion.

In my opinion, which I admit is biased, the title should be something along the lines of "SQL Server Virtualization: vSphere is the best hypervisor to use when you have lots of cores because it does a good job of scheduling VMs on servers with NUMA architecture."  Of course this is a bit long, but I like it overall much better.  :-)

Todd