Running Profiler traces against multiple servers becomes a painful process when it’s time to collate and filter all that data. It would be time-consuming, frustrating and messy if Laerte hadn’t written this handy PowerShell script (complete with examples) to help you out.
Deanna Dicken examines a SQL Server Profiler event to determine object access...who is using the object, when, and how. This gives the SQL developer or database administrator much needed information for impact analysis prior to a change or the decommissioning of a SQL Server object.
We've all had them. One of those stored procedures that is huge and contains complex business logic which may or may not be executed. These procedures make it an absolute nightmare when it comes to debugging problems because they're so complex and have so many logic offshoots that it's very easy to get lost when you're trying to determine the path that the procedure code took when it ran. Fortunately Profiler lets you define custom events that you can raise in your code and capture in a trace so you get a better window into the sub events occurring in your code.
In Part 2 of our series we will examine how to create custom templates and how to save collected trace data.
Many SQL Server developers and DBAs have, in the past, had their own favourite diagnostic Stored Procedures for investigating blocking issues. But since SQL Server 2005, it's a good idea to use the SQL Profiler for all but the most complex problems. Brad McGehee takes us through the steps...