Discussion :

[Metal29]

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.

[iberserk]

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

[Metal29]

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.

[dbaffaleuf]

(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 ?

[Metal29]

Bonjour,

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

[dbaffaleuf]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Metal29]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[dbaffaleuf]

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

[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.

[dbaffaleuf]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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...

[Metal29]

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.