Can anyone suggest options we might have in capturing all SQL statements being sent to our SQL Server, outside of running Profiler? I'm aware of a couple ways of doing it, but want to make sure I'm not overlooking something, such as an existing DM view etc.
Thanks very much.
5条答案
按热度按时间neskvpey1#
Extended Events in SQL Server 2008. These seem fairly underused. Perhaps due to a lack of UI support but are more flexible than SQL Traces (more events and better filtering possibilities) more light weight (due to better filtering and possibility to drop events rather than block)
Example syntax is below. There are lots more events, actions, predicates and output target possibilities than that though.
And to review the results
yvgpqqbh2#
If your problem with Profiler isn't that you don't want to use it, but that you can't use it, perhaps you could use Profiler for Microsoft SQL Server 2005/2008 Express Edition It's free and open source.
4dc9hkyq3#
I think your options are
There are DMV's that collect information such as long running queries, but I don't think that there is one that will give you everything.
ix0qys7i4#
You can use Tracing to capture the output programmatically: Programmatically receiving profiler events (in real time) from SQL Server 2005
jogvjijk5#
For what its worth, the book "Inside Microsoft SQL Server 2008 T-SQL Programming" has a GREAT chapter written by Greg Low that looks at all of the logging and auditing options in SQL Server 2008. It discusses when each should be used and the pro and cons of each. Having said that, what you have done is probably best.