Problems We Solve

Got a slow or unreliable SQL Server?
We’ll help you make it faster and safer.

No matter what thwarts you, our prescription at Brent Ozar Unlimited consists of three main elements:

  •  Applying scalpel-sharp techniques to identify and isolate your problems
  • Teaching you how to solve your problems
  • Developing a strategic plan to prevent future problems and maintain SQL health

Contact us to get started, or read about some of the common problems we encounter:

Slow SQL Server

Gain the tools and skills to bring your SQL Server up to speed. Read more >>

SAN tuning

How does chocolate play a key role in SAN tuning? Read more >>

AlwaysOn Availability Groups

Stop the painful, unpredictable outages and slow performance. Read more >>

Peak usage problems

Focus your efforts towards solutions that improve peak usage performance. Read more >>


Avoid the confusion and tension that can arise from virtualization. Read more >>

Disaster recovery

Ensure that your database runs smoothly FOREVER.

Unwieldy databases

Gain control over your database and develop the skills to maintain it in the future. Read more >>

Cloud transitions

Find out if the cloud is right for you and how to avoid common obstacles. Read more >>

kCura Relativity

Fix the slow searches and lower your SQL Server licensing costs. Read more >>

All our solutions begin with our SQL Critical Care®. Read about our consulting or contact us to sign up.


  • Anonymous Coward
    September 24, 2012 12:28 pm

    Rampant FLOSS fanboy insists that the entire set up could be replaced with a single MySQL server in 3…2…1…

  • Brent – Am curious,are you aware of any similar Issues with Windows Server 2012 Clusters(Bug in Cluster Code for Race Condition) or did MSFT said, it’s just with Win 2008R2?

  • Brent I know this wasn’t the focus of the blog post; but can your talk more about the rationale of using SSD’s in the primary and magnetic in the secondary machines. Maybe I’m reading too much into the diagram. Great Post

  • Thank you for posting this. Though we are not in 2012 yet, always a pleasure to expand knowledge and learn from a guy who has made expensive mistakes on other people’s hardware. Hehe

  • Brent – Thanks for sharing your experiences with the overwhelming majority of us for whom AlwaysOn Availability Groups remain something we are only familiar with on an academic level. A very generous contribution by you. It amazes me how many times I have to learn that there is no easy button for these types of complex problems. MS marketing fools you once, shame on them. MS marketing fools you every three years for your entire career… well…

  • Image trying to implement and support it on servers using Windows Core.

  • Jerry Cutshaw
    October 2, 2012 8:17 am

    We are re-architecting our SQL infrastructure and this time around we’ve decided to go with stand-alone SQL Servers that take full advantage of VMWare clustering for HA. The reasoning. . .fewer complexities related to clustering setup/maintenance, immediate failover isn’t a necessity and we don’t have the necessity to scale-up vs. scale-out so we can take advantage of commodity hardware (dual hex-core w/ 96 GB RAM).

    Does anyone familiar with these variables have any input for or against this solution?

    • Jerry – how do you plan to handle Windows patches, SQL patches, and full-C-drive conditions? (Like some bozo downloads a bunch of ISO files to the C drive or Windows Updates fill it up and knock the machine offline.)

      • Jerry Cutshaw
        October 2, 2012 8:48 am

        That thought occurred to me as well. For short term recoverability I’ll be snapshotting the VMs. For long term recoverability I’ll leverage vRanger backups (nightly) to cover the OS/Server backups and of course a good SQL Server backup policy.

        The only bozo that would fill up the C drive is is me! I’m told that with Windows 2008R2 you can now extend any volume (even the C volume through diskpart).

        Thanks for the response. Much love.

  • On the worker threads issue, were the HADRthreads in SUSPEND, if so what caused them to go into suspension?

    So are you saying that once there were available worker, the threads responsible for syncing AG data did not come out of suspension, and did so only after the AG was reset because of change in settings?

    Was the Secondary Sync or Async?

    How much time did you wait before Nick changed the settings?

    I ask all this because I am trying to recreate the same issue with AG for similar loads.

    • Rohan – we worked with Microsoft to recreate the scenario, and they had difficulties with it, so I don’t think it’s productive for us to try here. We spent weeks working with them, and explaining the whole scenario is beyond what I can do in a blog comment. It’s pretty elaborate. Thanks though!