A Fine Slice Of SQL Server
After receiving the alert, I verified that there were multiple databases on the same instance that were in the “Recovery Pending” state. A review of the SQL Server error log showed that the folder on the L drive was inaccessible, so transaction log files could not be read.
Click through for the troubleshooting steps leading to a happy ending.
Leave a CommentSean Gallardy provides an explanation:
Sparked by my friends at Straight Path SQL, we’re going to look at a rare cause of non-yielding scheduler dumps. This is another one of those items that I meant to write about a long time ago when I worked in Support and then, well, I suck and clearly forgot about it. This should give you an idea of how rare this specific issue hits.
Read on to see what might cause this scenario and why you’re likely never to see it in the wild.
Though now that I’ve typed it, I’m sure someone will take that as a challenge.
Leave a CommentSandra Delany has misplaced some subscriptions:
After migrating SSRS from SQL 2016 Enterprise Edition to SSRS SQL 2022 Standard Edition Data-driven subscriptions disappeared from within the SSRS web portal. However, I could see the subscriptions in the ReportServer.dbo.Subscriptions table.
SSRS was migrated from an EC2 instance where SQL and SSRS, etc. was installed by a DBA to an EC2 instance that was built using a template where all components were installed. When this was originally built out, we asked that they test. They said they did some testing, but they did not look at subscriptions in the portal nor did they create a subscription.
Click through to see how Sandra was able to troubleshoot and resolve the issue. But then how that led to the next issue, and how Sandra resolved that. And so on. This is what I refer to as an IT shaggy dog story. I don’t mean it in a negative sense for Sandra (or any author) but more along the lines of, “I want to solve problem X, which should take about 5-10 minutes. As I start to solve problem X, I now need to solve problem Y to solve X. But as I start to solve Y, now I need to fix Z. Oh, and then here come problems A, B, and C to make my life a pain. Three days later, I finally got X done.” It seems like the life of your average IT professional is one shaggy dog story after another.
Leave a CommentSean Gallardy digs into an issue:
Someone asked if I’ve ever had a CU install where you run it and it goes through the extraction process, then right as it hits 100% just exists and nothing happens. Well, that’s pretty weird, and no, I hadn’t. I was, however, intrigued! Since I love my readers, I made a repro of what the person this was occurring to, saw.
Click through for the expectations and what it actually turned out to be.
Leave a CommentOlivier Van Steenlandt troubleshoots an issue:
To continue the development of my mobile app, whose core ability is to scan barcodes of consumable articles and send them over for analytics, I’m resuming my capacity, starting to scan barcodes again, sending them to my Eventstream, and finally saving them in my KQL database.
After a couple of minutes, I wanted to validate all the scanned results in my KQL database and navigate to my scanned_barcode table.
Read on to see how Olivier diagnosed and corrected the problem.
Comments closedKoen Verbeeck said something bad:
A while ago I blogged about a use case where a pipeline fails during debugging with a BadRequest error, even though it validates successfully. If you’re wondering, this is the helpful error message that you get:
Click through for an image of the 400 Bad Request message, how Koen fixed it originally, and then a different scenario in which that 400 message popped up.
Ultimately, a 400 Bad Request comes down to “You sent me information that doesn’t make sense and I can’t fulfill your request, so fix it, dummy.” 400 status codes are very rude and insulting. Especially 418–that thing has a mouth like a sailor’s.
Comments closedReitse Eskens runs into a problem:
This warning felt benign; more like you can run into errors. Well, as I found out, this lets you run into an SQL Server installation that just fails.
The error logs fill up with stack dumps and a fatal error that makes no sense. The installation log, however, shows you a more meaningful error.
Click through for the error message, as well as one way to fix the problem.
Comments closedWe were setting up a brand-new SQL Server 2022 instance and couldn’t connect remotely using valid Windows credentials. Every attempt gave us the same error: “Login is from an untrusted domain and cannot be used with Windows authentication.” The client only has one domain. Permissions and firewalls checked out. Local connections with domain accounts worked fine. So why was the server rejecting us from every remote machine, no matter how we connected? The answer turned out to be a change in Windows Server 2025 that more and more DBAs are going to run into.
My advice for every DBA is as follows: make sure you have at least a rudimentary understanding of SPNs, including what they are, what can go wrong when they aren’t set correctly, what “set correctly” even means, and how to set them. You don’t need to be an expert on Kerberos, but I think you do need to be a technician who can note a specific error code and troubleshoot the issue from there.
If you ever had to deal with SSRS or SSIS double-hop issues, you’ve likely already dealt with SPNs in some fashion. Just bite the bullet and spend a few hours boning up on the topic.
Comments closedSean Gallardy troubleshoots an error:
The symptoms of this issue were interesting, every so often the instance would just kind of get “stuck” – at least that is how it was described to me. Nothing would work, cancelling queries, attempting to kill queries, submitting anything new, nothing seemed to really do anything except restarting the service. Once the service was restarted, the instance (and AG) would hum along nicely… until some random time later when submitting different queries would just grind to a halt. Fun.
The answer is just as dumb as you’d think. But I won’t spoil the punch line here.
Comments closedSSIS packages provide great flexibility for integration between systems, but when they go wrong you can end up digging through logs or reports because every package logs differently. A standarised framework for tracking failures can drastically cut down troubleshooting time.
I reminisced recently about old code, I said “it’s not enough to make it work correctly. It needs to fail correctly too”. So in this post we’ll demonstrate a simple way to consistently track errors and failures in packages to help make troubleshooting much easier.
My recollection is that this kind of failure logging is less important if you have the SSISDB catalog, as it collects a lot of the information as well. But then again, I haven’t really used SSIS in a while, so that memory could be fuzzy.
Comments closed