Overview

Δεν είναι σπάνιες οι φορές όταν κάνουμε performance tuning investigation χρησιμοποιώντας διάφορα εργαλεία όπως Profiler, sp_whoisactive, dbcc inputbuffer να συναντάμε σαν query text είτε FETCH API CURSOR είτε exec sp_cursorfetch με κάποιες παραμέτρους. Φυσικά με αυτά δεν βγάζουμε άκρη. Για αυτό στο άρθρο αυτό θα σας εξηγήσω πως μπορείτε να βγάλετε άκρη και κυρίως να δείτε το πραγματικό query που εκτελείτε πίσω από αυτά.

Explain by 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 που μας δίνει άμεσα τις πληροφορίες που χρειαζόμαστε.

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