February 10, 2025 at 12:00 am
Comments posted to this topic are about the item Extended Event Comfort
February 10, 2025 at 8:22 am
I love the Extended Events and what it can do, but its tooling is so bad that I'm not surprised people are still clutching to the profiler.
Plenty of mission-critical problems can only be debugged via Extended Events (unless you know all the undocumented trace flags). But you definitely need to have some session definitions prepared in advance because you don't want to be messing with XE during an incident.
February 10, 2025 at 2:32 pm
By default on each server, I keep a handful of Extended Event sessions running continuously for occasional performance events like deadlocks, timeouts, CPU pressure, T-SQL errors, long running queries, etc. I also have a few SQL Audit sessions for login events, DDL events (looking for BlackOps deployments), SELECT events on certain protected tables, etc.
Both features are built on top of XE, but I've found that Extended Event traces are better for performance monitoring and SQL Audit is better for security audit related stuff. The GUI and tooling are different as well.
Both options have more functionality and more lightweight than the legacy Profiler Trace feature.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 10, 2025 at 9:10 pm
I have yet to find a problem that requires XE over a profiler trace. Until I do, I'll probably just stick with my trace.
Be still, and know that I am God - Psalm 46:10
February 11, 2025 at 12:56 pm
Also using extended events voor basic monitoring, but the tooling is not easy.
I would also like something that is able to read it without using sys.fn_xe_file_target_read_file in order to offload cpu when parsing it
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply