The Query Analyzer is the replacement to isql/w.  Many of the same features you've come to expect in isql/w are still in Query Analyzer.  The main differences are in the color coded syntax and graphical showplan.  If you've never taken a look at the graphical showplan, you should take some time in there.  You can get an incredible amount of data from the showplan.  Just looking at one doesn't give you much feedback.  If you point at any of the objects or relations, you will get a popup window that gives details of time, number of rows, type of query, etc.

The Index Tuning Wizard is a welcome addition.  This wizard gives a very powerful interface for identifying unneeded indices and also additional indices to improve performance.  It accomplishes this analyzing a select group of queries and then making recommendations.  You need to have sufficient data in order for it to perform at an optimal level.  This is normally accomplished by setting up a trace and storing the output.  You then hand that trace to the Index Tuning Wizard for analysis.

At this point, Gert walked through several demos to demonstrate the topics just covered.  Three demos leveraged the tracing capabilities and SQL Server Profiler.   These were setup to identify poorly performing queries, profile a stored procedure, and analyze a deadlock.  The stored procedure tracing was interesting, because it then gave you the ability to step through the proc line by line and step into nested procs and any triggers that are executed.  The last demo centered on the Index Tuning Wizard.

After the demos, we went through several strategies for monitoring.  The main theme to keep in mind is that monitoring will put a load on your server.  You need to be selective about what you monitor and how much data you collect.  If you are monitoring around the clock with no filtering, you can impose a severe load on the server which will dramatically affect system performance.  One of the best ways to minimize the impact is to leverage SQL Server Agent.  The Agent can detect certain events through its alerting mechanism.  It can then start up a trace for that event to capture the details.  A good example of this is a deadlock alert.  You can then use the trace output to replay the event and isolate your problem.