While SQL Server's Profiler is a great tool, it can be hard to work with and we can easily miss information in the results. New author Solomon Rutzky brings us a short article that can help you to better configure your traces to get the information you need.
In this series of articles, you will learn the basics of installing Microsoft Operations Manager 2005 as well as how to use MOM to monitor SQL Server. This article takes advantage of virtualization. We will use VMware Workstation 5 to create the lab to introduce you to the basics of installing MOM to monitor SQL Server.
Part I of this article illustrated how to monitor CPU usage of running processes on a local machine or from a remote machine. This article illustrates how to monitor the CPU usage of different running processes on different machines and collect the information in a database.
SQL Server Profiler can correlate Microsoft Windows System Monitor (Performance Monitor in Windows NT 4.0) counters with SQL Server or SQL Server 2005 Analysis Services (SSAS) events. Windows System Monitor logs system activity for specified counters in performance logs. The first thing to remember is in order to have correlating information you need to obviously be in sync - in other words you must start the perfmon trace and profiler trace at the same time or else they won't match up.
SQL Server excels at quickly acquiring and releasing locks to allow as much concurrency as possible on the server. However there are times that one user will block another, which can be a source of great user frustration as well as making the system appear to be slow. Leo Peysakhovich brings us some great information and code on how you can monitor and deal with blocking on your SQL Server 2000 server.
Andrew Zanevsky shares his trace-scrubbing procedures that make it easy for you to handle large trace files and aggregate transactions by type–even when captured T-SQL code has variations.
SQL Server Profiler is a veritable treasure trove when it comes to helping DBAs optimize their T-SQL code. But, the surfeit of riches (I'm reminded of the Arabian Nights tale of Aladdin) can be overwhelming. I recently had one of those "sinking" feelings when I first tried to make sense of the enormous amount of data collected by traces on a client's servers. At this particular client, the online transactions processing system executes more than 4 million database transactions per hour. That means that even a 30-minute trace that captures "SQL Batch Completed" events results in a table with 2 million rows. Of course, it's simply impractical to process so many records without some automation, and even selecting the longest or most expensive transactions doesn't necessarily help in identifying bottlenecks. After all, short transactions can be the culprits of poor performance when executed thousands of times per minute.
Auditing in SQL Server is something that is becoming more and more prevelant, and will likely become more regulated over time. Dinesh Asanka brings us a new article on the basics of SQL Servers most powerful auditing configuration, C2 level auditing.