Voice of the DBA

Tag: Performance

  • Help with Performance

    One of the things that so many people working with SQL Server struggle to do is identify what is happening on their servers. Despite all the DMVs, DMFs, and other tools available, I regularly see questions posted about the trouble people have with digging into SQL Server and finding out what is wrong. There is so much information available that often people are not sure where to start looking.

    In the past few weeks I noticed two great posts that should help you to better understand what is happening on your SQL Server. One is about the release of “Who Is Active v 10” from Adam Machanic, which is a great tool. The other is a series of queries from Glenn Berry that give you a lot of diagnostic information about your instance.  Both of these are tools that you should add to your toolbox and learn to use.

    In addition to having tools to dig into what might be going on right now in your instance, monitoring your server instances is also critical for being able to determine what kinds of problems you have. After all, if you don’t know what’s normal, how can you tell what’s not normal? Many of the consultants I know have to spend hours at new clients getting a feel for the environment because they’re not familiar with it. You have no such excuse for your own servers.

    The sign of a good DBA is having monitoring in addition to knowing how to troubleshoot performance issues. A great DBA will also use this information to look ahead and anticipate problems.

    Steve Jones

    If you don’t want to build your own system, be sure to take a look at SQL Monitor, a new tool from my employer, Red Gate Software. It can help you keep track of multiple servers and provide you the history and reporting to understand what is “normal” for your instances.

  • Live Monitoring

    My employer, Red Gate Software, recently released a new product called SQL Monitor. This is the 2.0 version of SQL Response, enhanced and renamed after a lot of feedback and input from various DBAs around the globe. It’s very cool and in preparation for the release, they asked if we could install the software on the SQLServerCentral servers. I was happy to have it on the servers for additional monitoring. Even though I don’t have to manage the databases, I wanted to make sure whoever is managing them has some tools.

    Then my boss asked if we could make the data public. He mentioned that the early look at the console showed a lot of alerts, potentially some less than optimal configurations, and more. I said we should definitely show the site, and at The Future of Monitoring, the try it online link shows the live SQLServerCentral database cluster.

    That’s live, as in a few seconds delay to process the data, but if you look at instance 1, the graphs are changing in real time. Keep in mind that it might appear slow with the huge SQLServerCentral community checking the servers, but you probably don’t have a million wannabe administrators checking out your servers.

    We haven’t changed much at all in the configuration since we made the data public, but over the next few months we are going to slowly tune and configure the server live, informing you of the changes, and showing the before/after data. If you’re following along, you can track the performance differences yourself as well. This is a real world performance because just like most of you, we have resource constraints while managing and tuning servers. We can’t optimally design, build, and manage our servers as that’s not our primary job, but we’re trying to get better by using SQL Monitor to help us keep better track of the servers and work more efficiently.

    One of the coolest things I’ve seen is that our IT staff actually has iPads to watch over servers, and they love it. There’s a slide show on the front page of the monitoring site showing lots of people running SQL Monitor with tablets. Maybe I should take on some DBA chores and see if they’ll get me one. Maybe you can convince your boss to get an iPad with a copy of SQL Monitor as well. 😉

  • Powershell and Performance Monitoring

    When I was doing performance monitoring of servers, I typically struggled with a good way to get the data. In years past it was cumbersome to keep track of server information and rarely was it done well. So often I found that many problems were the result of simple mis-configuration settings, or a lack of patches. Once a DBA or sysadmin can’t remember everything about every instance, it invites chaos.

    Allen White is showing how to better track a “server inventory” to learn all about the setup, configuration, and performance of SQL Server using Powershell. It’s easy to find this information in an ad hoc manner, but keeping track of it and catching exceptions requires something more formal. Powershell is a great way to do that in a repeatable way.

    Based on an article at Simple Talk, Allen shows how you can put your servers in an XML file and then read that in from Powershell and use it to drive a series of queries against a particular instance and machine.

    Most of this session gives you a good look at a script that will gather various information, including performance data, from your instances.  One of the more practical sessions that can really help you understand a large Powershell script in detail.

    However Powershell takes some practice. It’s a set of fairly concepts that are designed to be put together, but you need to take a little time to understand how the scripts work.

    If you get the chance to see Allen speak, it’s worth it. He does a good job of walking through code and helping you understand how it works.

  • Plan for Capacity

    In many applications, it seems that performance often falls off a cliff at some point because no one is planning for capacity increases. Everyone talks about the potential load on the system when it’s first being built. However since we often over-buy hardware, we rarely monitor the load until something goes wrong.

    I was reminded up this with a write-up from Simon Sabin recently that examined a lesson on capacity planning from FourSquare. Apparently FourSquare had some capacity issues with their MongoDB server. Despite the realization that they were growing and the addition of a second node to their database, they didn’t learn the lesson and didn’t add a third or fourth node until they were over capacity.

    Most of us don’t experience this type of hyper-growth in our systems. The majority of applications I’ve seen have undergone a quick growth in load at some point, but then leveled off to a steady, or slowly growing load on the system. However that doesn’t necessarily change the planning needed for growth. It just means that you need to grow your system at different times than if you were doubling in size every few months.

    A solid monitoring plan, and buy-in from management that you will periodically need to upgrade your servers, is necessary. Typically you will add storage over time, perhaps RAM, and potentially new CPUs or servers. You might not be able to exactly predict when you will have performance issues, but you can plan for issues. You can proactively let management know that space is running low, or that you may run into issues if data sets continue to grow in size.

    Funding is often hard to get, but by preparing people in advance that your database will need improvements over time, you are more likely to be able to respond quickly when there are performance issues.

    Steve Jones