FETCH API_CURSOR - Récupérer le contenu du curseur

Bonjour,
Après moults recherches, je ne parviens pas a obtenir le contenu des FETCH API_CURSOR.
Le problème, c'est que ceux ci remontent en erreur depuis mon SQL Server Profiler et que la seule information que j'ai en ma possession, c'est le nom des curseurs en question. (FETCH API_CURSOR0000000000006351 par exemple)

J'ai bien essayé de suivre le tuto sur http://www.sqlskills.com/blogs/joe/h...p_cursorfetch/ mais le problème, c'est que je n'ai pas le Session ID posant problème et je me retrouve donc bloqué bien rapidement...

Quelques idées ?

Merci d'avance.

Vous devez lancer un profiler afin de voir les événement d'initialisation desdits curseurs

Bonjour,
Désolé pour le délai de réponse mais j'étais en congés.

J'ai bien un profiler qui tourne ce qui m'a permit de tracer les numéros de CURSOR mais en remontant le fil je ne parviens pas à retrouver l'initialisation.
Des pistes pour m'aiguiller ?

Merci d'avance.

(modif, je n'avais pas vu le lien vers l’article de Joe dans le premier post, my mistake).

Et en mettant juste 0 à la place de session_id ?

Bonjour,

En renseignant le SessionId à 0 je n'ai aucun retour.

Si sys.dm_exec_cursors ne renvoie aucune ligne c'est qu'il n'y a aucun curseur d'ouvert. Es-tu certain d'avoir le privilège VIEW SERVER STATE ?

Code:

---

1 2 3 4 5 6 7 8

declare @pHdl int, @pCsr int set @pHdl=-1 set @pCsr=0 exec sp_cursorprepexec @pHdl output, @pCsr output, N'',N'SELECT top (1) ProductID FROM AdventureWorks2012.Production.Product' GO   select * from sys.dm_exec_cursors(0) GO

---

En adaptant l'exemple à mon schéma, j'ai bien des retours :

Code:

---

1 2 3 4 5 6 7 8 9 10

session_id cursor_id name properties sql_handle statement_start_offset statement_end_offset plan_generation_num creation_time is_open is_async_population is_close_on_commit fetch_status fetch_buffer_size fetch_buffer_start ansi_position worker_time reads writes dormant_duration 107 180150005 NULL API | Snapshot | Read Only | Global (0) 0x020000006FD53C11AC901379E808F6C8D800F760962B06E5 2 -1 3 2014-05-27 15:29:19.993 1 0 0 -1 0 -1 1 1953 0 2 70 107 180150009 NULL API | Snapshot | Read Only | Global (0) 0x0200000011CBBA26BEB30F7EC34D5B7739BA86392AA0585B 0 -1 1 2014-05-27 15:29:20.000 1 0 0 0 1 1 1 0 0 0 63 107 180150013 NULL API | Keyset | Optimistic | Global (0) 0x02000000DBF4850EF08F45E445C337EBF6B5D80107F85516 0 -1 1 2014-05-27 15:29:20.000 1 0 0 0 1 1 1 0 0 0 64 107 180150015 NULL API | Snapshot | Read Only | Global (0) 0x02000000C1E8A438F255938CB85A1D56EC74FBA370ADCE53 70 -1 1 2014-05-27 15:29:20.003 1 0 0 0 1 1 1 0 0 0 64 107 180150017 NULL API | Snapshot | Read Only | Global (0) 0x020000000713BB0C5A41B7C4D7C08F0F1BE076115AA3E751 2 -1 86 2014-05-27 15:29:20.017 1 0 0 -1 0 -1 1 2929 0 0 28 135 180150003 NULL API | Keyset | Optimistic | Global (0) 0x020000004477D42D25846644E3D205BC4BED23E20DFA5A6E 0 -1 1 2014-05-27 15:28:38.350 1 0 0 -9 0 0 1 0 0 2 41716 135 180150005 NULL API | Keyset | Optimistic | Global (0) 0x020000004477D42D25846644E3D205BC4BED23E20DFA5A6E 0 -1 1 2014-05-27 15:29:20.060 1 0 0 -9 0 0 1 0 0 0 8 206 180150003 NULL API | Keyset | Optimistic | Global (0) 0x020000002B09081D78600E91FAAF0A45356DE3C41D8B9842 2 -1 1 2014-05-27 15:29:20.057 1 0 0 0 1 5 1 0 0 0 3

---

Dans ce cas en passant le sql_handle à sys.dm_exec_sql_text(), tu peux récupérer la requête SQL.

Excuse moi de poser une question idiote mais je n'arrive pas à suivre le cheminement entre le profiler et le dm_exec_cursors().
Lorsque j'étudie la montée en charge, je le fais "post mortem". Comprenez par là que j'ai un profiler qui tourne toute la journée et que je reçois un mail via un script Ps lorsque mon process IIS occupe un processeur complet plus de 20 secondes.

Du coup, la seule chose qui me permet de remonter le fil c'est le FETCH API_CURSOR lancé avant. Oserai-je te demander un peu plus d'éclairage ?

Merci d'avance.

Citation:

---

Envoyé par Metal29

Excuse moi de poser une question idiote mais je n'arrive pas à suivre le cheminement entre le profiler et le dm_exec_cursors().
Lorsque j'étudie la montée en charge, je le fais "post mortem". Comprenez par là que j'ai un profiler qui tourne toute la journée et que je reçois un mail via un script Ps lorsque mon process IIS occupe un processeur complet plus de 20 secondes.

Du coup, la seule chose qui me permet de remonter le fil c'est le FETCH API_CURSOR lancé avant. Oserai-je te demander un peu plus d'éclairage ?

Merci d'avance.

---

S'il s'agit de retrouver une action déjà terminée (pendant la nuit par exemple) dans ce cas il faudrait historiser les curseurs ouverts dans une table :

Code:

---

1 2 3 4 5 6 7 8 9 10

create table tempdb.guest.cursorshisto ( session_id int not null, cursor_id bigint not null, properties nvarchar(255) not null, creation_time datetime not null, is_open tinyint not null, sqltext nvarchar(max) not null );

---

Et dans un job, par exemple 1/minute:

Code:

---

1 2 3 4

INSERT INTO tempdb.guest.cursorshisto SELECT c.session_id, c.cursor_id, c.properties, c.creation_time, c.is_open, t.text FROM sys.dm_exec_cursors (0) c CROSS APPLY sys.dm_exec_sql_text (c.sql_handle) t ;

---

Et ensuite faire la corrélation entre ta trace SQL Trace et ta table d'historique. C'est une méthode préhistorique mais elle a le mérite de marcher. Après en 2008R2 il y a les évènements étendus, mais aucun évènement ne semble capturer le cursor_id qui doit te permettre d'identifier le curseur, donc...

Pfiou! Je comprends mieux pourquoi je n'ai pas trouvé l'instruction magique qui résoudrait ma problématique...

Je te remercie pour ton temps, je vais essayer ta méthode.

Bonne journée.