A Fine Slice Of SQL Server
Joe Fleming summarizes the latest T-SQL Tuesday:
I was excited to host my first T-SQL Tuesday to find out how you solve problems. It’s a big topic, and I imagine it’s difficult to fully put to paper how your brain works, but I am thankful for the folks who did. Here’s my T-SQL Tuesday Round Up on troubleshooting weird problems.
Click through for breakdowns of each of the participants’ posts.
Leave a CommentChad Callihan says sometimes, the best answer is not to play the game:
After some database infrastructure changes related to phasing out the use of linked servers, I encountered issues with a setup tool used to build out new databases and other related features. One section of the tool was failing, and the errors indicated that there were still stored procedures utilizing linked servers, which was causing the problem. I asked myself a few questions on how best to proceed. Does the setup tool need to be updated? Do the related database procedures using linked servers need to be updated? Do the linked server changes made need to be rolled back altogether?
Read on for a proper Gordian Knot solution.
Leave a CommentGrant Fritchey knows one way to solve the problem:
A client asked us to tell them when a query ran long. Simple. We have a long running query alert, all built in to Redgate Monitor, so, done. No, see, we like getting alerted when queries run long, but not really long, plus we’re more concerned with just one database.
Click through for the story and how Grant was able to help out the client. Also, read the comments for an entry by Special Guest Star Erik Darling.
Leave a CommentRob Douglas will reboot many things, but not the database server:
I am taking a slightly different tangent. My problem is neither strange or unique – in fact it’s infuriatingly common and it stems from one of the most common troubleshooting techniques in IT. While asking users “Have you tried turning it off and on again?” is a common go to for tech support call handlers, it is not a great idea when the “it” you are talking about is a database server
Click through for a cautionary tale, as well as an explanation of why this usually isn’t the smart play.
Comments closedAndy Levy manages some SQL Agent entries:
Thank you to everyone who contributed to this month’s T-SQL Tuesday!
Here’s a roundup of the posts.
Read on for nine posts on the topic of managing SQL Agent jobs.
Comments closedChad Callihan shares a pair of tips:
These aren’t the most technical SQL Server Agent job topics, but two that came to mind were managing who jobs belong to and making sure the right steps are followed when jobs are removed.
Click through for more thoughts on both of these topics.
Comments closedDavid Wiseman shows off an open-source product:
For T-SQL Tuesday #186, Andy Levy asks, “How do you manage and/or monitor your SQL Server Agent jobs?”
This is a great opportunity for me to discuss how DBA Dash can help monitor SQL Agent jobs. DBA Dash is a free and open-source monitoring tool for SQL Server, created by me. It’s used to monitor thousands of SQL Server instances within Trimble alone, and it’s gaining popularity in the SQL Server community.
Read on to see how the product can help if you have a series of SQL Agent jobs.
Comments closedI used to work in a fairly large enterprise (5,000+ people, 500+ production SQL instances) with a small staff. It was 2-3 of us to manage all these systems, as well as respond to questions/queries/issues with dev/test systems. As a result, we depended heavily on SQL Agent.
We decided on a few principles which helped us manage jobs, with a (slow) refactoring of the existing jobs people randomly created with no standards. A few of the things we did are listed below. This isn’t exhaustive, but these are the main things I remember.
Read on for Steve’s list.
Comments closedTodd Kleinhans does not believe that green is good:
Far too many times, I have seen DBA(s) and others have this false sense that if the Agent run status shows green, then everything must be ok.
Click through for a funny story about a gas station robbery and examples of how a SQL Agent job can report success but actually fail. You also see this a lot with replication or tasks that are asynchronous in nature: the task is reporting that we successfully started whatever operation, but that doesn’t mean the operation itself succeeded.
Comments closedDeborah Melkin has three laws for robots, or at least SQL Agent jobs:
How do I manage this all?
I have scripts to create and modify SQL Agent jobs.
And those scripts get checked into source control.
And those scripts get added to the deploy process.
And most importantly, those scripts get tested in all environments from development through production.
Read on for more context around this.
Comments closed