Making a Difference
Many people wrote in asking about roles and responsibilities ("do I need to do analyst work to be an asset for the company??") and how this plays into the editorial from yesterday. Well, I don’t think we should revisit the job title and responsibilities thing right now (we just completed a really good discussion about that), but I will say that that’s not what I meant, not really.
This is a time to really kind of ignore the titles and responsibilities and help your company or companies get the most from their systems. Doesn’t really matter if you’re the analyst or admin, if you can leverage what you know about databases, if you can contribute anything more at all, now’s the time to do so. Step up, teach people how to pull more from the information, look for new uses, new reports, updated information presentation. There is a lot that can be added when someone new that "thinks database" gets involved, no matter what their official title.
So, What WAS That Tool?
Last week I wrote about some performance issues we were chasing. The issues were revolving around a symptom of disk queues growing, system performance lagging in spurts, etc. We were having trouble getting real visibility into all of the possible causes, in a cohesive, single look kind of way. It was one thing to look at queries running, another to check counters, yet another to look for lock/blocking… you get the idea. Pulling it all together was challenging. All the while, we had pressure to get things back going correctly.
I had twittered (twitter.com/swynk) about some of the things we were seeing and what we were doing to investigate a bit. The folks over at SQL Sentry jumped on that and helped us out – they helped show off their new performance dashboard tools and at the same time shine some serious light on our server and the issues we were seeing. Literally as soon as we fired it up we could see what was happening. Not the cause, but the symptoms across the various impacted areas of the servers. That’s step 1 – gather information.
Step 2, of course, is to solve the issue. Clicking on the graph where the performance hit kicked off, then selecting "Top SQL" shows exactly what’s running. Now we’re getting somewhere. From there, we could readily see that the full-text queries were running *every* time the issue occurred, and we could also correlate that execution time on the SQL with the disk graph… needless to say we quickly narrowed down the possibilities.
If you’re curious, and may have missed it, we ended up moving the full text indexes to different drives. We also ended up messing with stats. Check out the editorials for more info.
The key here was that the SQL Sentry Performance Advisor – a dashboard tool that does an amazing job helping us dive in to correlated information points – sort of "show me a complete system picture at this point in time" – and it led to fact-based troubleshooting that solved our problems.
Get more information about their software here (there is a free trial – fire it up and point it at your servers to get a great feel for how things work).
This isn’t an ad, not a review. It was just a truly critical piece in understanding what was going on – and many people wrote asking what we used.
Thanks to the SQL Sentry team for the assist – we appreciate the help!
Featured White Paper(s)
7 Ways to Improve Your Database Server’s Performance by 60%-80%
Sql Power Tools White Paper reviews 7 steps you can take to improve your database server’s performance. With production datab… (read more)
SQL Server Fragmentation Explained
As the data in Microsoft SQL Server tables changes, their indexes change. Over time, these indexes become fragmented. This fr… (read more)