Discussion :

[Kropernic]

Hello,

Aujourd'hui, je dois faire un delete dans une table contenant des transactions caisses (car il avait des erreurs dans la DB de notre maison mère) pour pouvoir réimporter les données corrigées.

Si j'ai bien pu faire un "backup" des données erronées dans une autres tables via une requête SELECT...INTO...FROM...WHERE... qui a pris 2 secondes à s'exécuter, lorsque j'execute la requête DELETE, elle s'exécute "sans fin" (jusqu'à présent).

Par curiosité, je vais voir dans l'activity monitor de SSMS et là, je constate que mon process est en état SUSPENDED. N'y connaissant rien du tout à tout cela, j'ignore ce que je dois faire. J'ai bien été voir ce que signifiait le wait type PAGEIOLATCH_EX mais c'est du chinois pour moi :-/

Que puis-je faire pour débloquer cette situation ???

[Arkhena]

Bonjour,

Votre requête attend qu'un verrou soit relâché (sur la table ou sur l'index). Assurez-vous que personne n'a de transaction ouverte sur cet(te) table(index).

Cordialement,

Arkhena

[Kropernic]

Ah, les verrous... Première fois que j'ai ce genre de problème...

Et je me rends compte aussi que j'ai oublié de mettre la pièce jointe dans mon message d'ouverture. Je la mets donc ici.

Comment puis-je détecter "où se trouve" le verrou afin de dévérouiller ?

EDIT : Etes-vous certain qu'il s'agit d'un problème de verrou ? Car d'après l'activity monitor, je suis le seul avec un process sur la DB concernée... Ou bien les verrous restent-ils même une fois le process terminé ? Je navigue complètement dans le noir

[Arkhena]

Oups effectivement, j'avais complètement obturé le PAGEIOLATCH...

Dans ce cas-là, la tâche est en attente d'IO. Votre base tempdb est-elle sur le même disque physique que votre base Tickets ?

La doc sql server indique qu'il est possible que votre disque soit défectueux :

Long waits may indicate problems with the disk subsystem.

(cf http://msdn.microsoft.com/en-us/libr...aspx#WaitTypes)

Rapprochez vous de l'équipe d'infrastructure, de stockage ou système si l'une d'elle existe ou regardez les compteurs Avg. Disk Sec/Read et Avg. Disk Sec/Write.

• Inférieur à 10 ms -> très bon
• Entre 10 et 20 ms -> OK
• Entre 20 et 50 ms -> Lent
• Plus de 50 ms -> Gros problèmes

Si vos valeurs sont bonnes, il faudra envisager de séparer les fichiers de log des fichiers de données sur des disques distincts et également séparer la base tempdb des autres.

Cordialement,

Arkhena

[Kropernic]

Oups effectivement, j'avais complètement obturé le PAGEIOLATCH...

Dans ce cas-là, la tâche est en attente d'IO. Votre base tempdb est-elle sur le même disque physique que votre base Tickets ?

Non, la base tempdb est sur le disque C (disque où a été installé SQL SERVER) et la db est sur le disque D (et le log et les indexes sur le disque F)

La doc sql server indique qu'il est possible que votre disque soit défectueux :
(cf http://msdn.microsoft.com/en-us/libr...aspx#WaitTypes)

Rapprochez vous de l'équipe d'infrastructure, de stockage ou système si l'une d'elle existe ou regardez les compteurs Avg. Disk Sec/Read et Avg. Disk Sec/Write.

• Inférieur à 10 ms -> très bon
• Entre 10 et 20 ms -> OK
• Entre 20 et 50 ms -> Lent
• Plus de 50 ms -> Gros problèmes

Où trouver ces compteurs ?

Si vos valeurs sont bonnes, il faudra envisager de séparer les fichiers de log des fichiers de données sur des disques distincts et également séparer la base tempdb des autres.

C'est déjà fait mis à part index et log qui sont sur le même disque (faute de place suffisante sur le serveur parait-il)

[SQLpro]

C, D et F sont-ils des disques PHYSIQUEMENT distincts ? ou bien des partitions ???

A +

[Arkhena]

Je parle bien de disques physiques différents, non de disques logiques. Edit : Les messages se sont croisés

On peut trouver les compteurs de performances dans le moniteur des performances quise trouve là : %systemroot%\system32\Perfmon.exe.