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 >>
Virtualization
Avoid the confusion and tension that can arise from virtualization. Read more >>
Disaster recovery
Ensure that your database runs smoothly FOREVER. Read more >>
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.
15 Comments.
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?
Sreekanth – support said the bug has been fixed in Windows Server 2012.
Thanks Brent!
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
Jason – short answer: it’s cheaper to get higher capacity with magnetic drives. While Stack did get funded, it’s not unlimited moolah. 😉
ahh ok, I thought maybe it was due to the MTBF characteristics of the two media types. I was reading too deep into the diagram. Thanks for clarifying.
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.
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.)
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!