Tara Kizer wrote this chapter, and it is relevant for us developers.
Tara briefly explains how to use the GUI, the Profiler, and states that it can heavily impact the performance on the server. Then she explains how to set up a server-side trace which should incur less overhead, and I noticed that the working example which she provided is quite similar to the one our team is using.
There is one minor thing, however, that we do differently: our T-SQL is self-documenting. For example, instead of the following:
EXEC sp_trace_setevent @traceid , 10, 1, @on
We use this:
EXEC sp_trace_setevent @traceid =@traceid,
@eventid=@RpcCompleted, @columnid=@Cpu, @on=@on;
After describing how to set up a trace, Tara demonstrates several real life ways to use its output, such as finding missing indexes, stale statistics, and parameter sniffing causing problems.
I have found this section of the chapter practical and useful for developers. We need to be proficient with this tool, we need to practice using it, so that we can quickly use it whenever the need arises. This chapter provides a good, short and useful, practical introduction to becoming proficient. I would recommend developers to read it.
Later Tara proceeds to describe Extended Events. I am not qualified to review that, since I do not have enough real life experience with them.
This completes the chapter review, which is followed by my personal opinion on deprecating of the Profiler.
I am disappointed that that the familiar and convenient interface of the Profiler and server side traces is going to disappear, rendering all the experience using it useless, and forcing lots of people to spend precious time to master the next thing that replaces it.
I understand that the old implementation might have to go, but I also think that it might be feasible to have the old interface invoke the new implementation.
In my narrow experience, even if some application has just ten or twenty users, it may be cheaper to keep the old interface unchanged, even when we completely replace the implementation, such as migrating from SQL Server to PostgreSql. As a result our users do not have to relearn how to do the same thing with the new tool, and can do something more useful instead. The math is simple: a day of developer's time spent on backward compatibility is cheaper than two hours of user's time spent on relearning multiplied by the number of users.
Because the Profiler and server side traces have a huge number of customers, I think that SQL Server would be a more useful product if it kept providing the old interface even if the old implementation needs to be replaced with a new one.
The time and resources spent on keeping the old interface would probably be just a tiny fraction of the time and resources spent by the huge amount of users relearning how to do the same thing with the new tool.