Overview
Δεν είναι σπάνιες οι φορές όταν κάνουμε performance tuning investigation χρησιμοποιώντας διάφορα εργαλεία όπως Profiler, sp_whoisactive, dbcc inputbuffer να συναντάμε σαν query text είτε FETCH API CURSOR είτε exec sp_cursorfetch με κάποιες παραμέτρους. Φυσικά με αυτά δεν βγάζουμε άκρη. Για αυτό στο άρθρο αυτό θα σας εξηγήσω πως μπορείτε να βγάλετε άκρη και κυρίως να δείτε το πραγματικό query που εκτελείτε πίσω από αυτά.
Explain by sample
Sample
Όπως βλέπουμε στην παραπάνω εικόνα έχω εκτελέσει την δημοφιλή sp_whoisactive του Adam Machanic και στο sql_text βλέπω το FETCH API CURSOR.
Αυτό όμως δεν μου δείχνει την πραγματικά εκτελείται και για να το βρω θα πρέπει να κάνω query στο sys.dm_exec_cursors DMF με παράμετρο το session id.
Το DMF αυτό μου δίνει αρκετές πληροφορίες για το cursor και μπορείτε να δείτε περισσότερα στα BOL.
Από αυτό μας ενδιαφέρει το sql_handle το οποίο χρησιμοποιώ σας παράμετρο στο αρκετά γνωστό DMV sys.dm_exec_sql_text στου οποίου τα αποτελέσματα το text field περιέχει το πραγματικό statement που εκτελείται.
All in one query
Αν τώρα όλα αυτά τα ενώσουμε μεταξύ τους τότε έχουμε το παρακάτω query που μας δίνει άμεσα τις πληροφορίες που χρειαζόμαστε.
SQL Script
select
creation_time
, cursor_id
, c.session_id
, c.properties
, c.creation_time
, c.is_open
, substring(st.text,
(c.statement_start_offset/2)+1,
((case c.statement_end_offset
when -1 then datalength(st.text)
else c.statement_end_offset
end - c.statement_start_offset) / 2) + 1) as statement_text
from
sys.dm_exec_cursors(0) as c
inner join
sys.dm_exec_sessions as s on c.session_id = s.session_id
cross apply
sys.dm_exec_sql_text(c.sql_handle) as st
go