Jayanth_Kurup (10/2/2012)
Thanks !! i wasnt aware the filters in a server side trace was applied only after the info was collected.
Yes, this is one of the fundamental architectural differences between Trace and Extended Events. Extended Events evaluate the predicate at the earliest point possible, and then collect additional data from actions after the event is guaranteed to fire and be consumed by an event session.
I suggested the server side trace mainly to avoid the network overhead.
There isn't a network overhead with Extended Events though, so I don't understand this statement. Even in 2012 where you can use the streaming target with the Live Data viewer in SSMS, the memory buffers are duplicated server side to prevent the live stream from impacting performance of the server workload. If the live stream gets behind, the engine will kill it, disconnecting the client. The entire implementation is designed to try and prevent negative impacts from default configurations with a few exceptions around expensive events.
On a related note , how about data collectors , do they work the same as a trace ( i guess they would coz you can create a template for a dc from a trace).
If it is a trace data collector yes, but you can have other data collectors as well which wouldn't function like trace.
Jonathan Kehayias | Principal Consultant | MCM: SQL Server 2008
My Blog | Twitter | MVP Profile
Training | Consulting | Become a SQLskills Insider
Troubleshooting SQL Server: A Guide for Accidental DBAs[/url]