I am using it for auditing purposes to track what is going on.
(select text from master.sys.dm_exec_sql_text(sys.dm_exec_connections.most_recent_sql_handle )) as sqlscript,
(select db_name(dbid) from master.sys.dm_exec_sql_text(sys.dm_exec_connections.most_recent_sql_handle )) as databasename,
(select object_id(objectid) from master.sys.dm_exec_sql_text(sys.dm_exec_connections.most_recent_sql_handle )) as objectname
from sys.dm_exec_sessions inner join sys.dm_exec_connections
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.
The system table, "sysperfinfo," is the representation of the internal performance counters of SQL Server. This article demonstrates how to retrieve and store information from "sysperfinfo" to a CSV file, so that it can be analyzed.
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.
SQL Server will autogrow your databases as they run out of space. But the process doesn't manage space, nor does it check the free space on the drive. Allowing autogrow to grow unchecked and unmanaged will eventually use up all the free disk space and potentially crash your server. New author Mark Nash brings you his system for monitoring space usage and generating a report that eases this process.