Les requêtes SQL simples ne se terminent pas [fermé]

Je ne sais pas trop comment formuler la question parce que nous ne savons pas encore grand-chose, mais je voudrais poser plus tôt que tard car cela ressemble à quelque chose à ne pas négliger.

Cette semaine, nous avons commencé à avoir des problèmes avec notre serveur de base de données. Cela semble être un problème de cohérence des données et il se manifeste par des délais d'attente, même sur des requêtes très simples et de petites tables. Nous avons «résolu» le problème en redémarrant le serveur plus tôt cette semaine et il est parti, mais il semble maintenant qu'il revient et cette fois sur des tables plus cruciales. Par exemple, je viens de faire une enquête et je regarde une requête comme celle-ci:

SELECT * FROM table WHERE id = 1234

pour un ID particulier. Le tableau comprend environ 30 millions de lignes. Mais il semble que cela ne se produise que pour une petite fraction des enregistrements. Je parie que lorsque je redémarre le serveur ou sauvegarde et restaure la base de données sur un autre serveur, tout ira bien. Mais je vais essayer.

À ce stade, je cours:

DBCC CHECKTABLE ('table', NOINDEX)

mais il semble que ça va durer éternellement. Quand nous avons touché les problèmes la première fois, j'ai vérifié le tableau incriminé et tout allait bien. Cette nouvelle table est beaucoup plus grande.

Quelques informations techniques de base:

• SQL Server 2008 R2, Windows Server 2008 R2
• AWS / EC2, m2.2xlarge, 32 Go de RAM, 4 x 1 To RAID 0
• presque aucun disque IO, il semble que la plus grande partie de la base de données soit en mémoire
• taille totale de la base de données: 100 Go

Les volumes ELB sont "neufs". Nous les avons créés cette semaine.

Edit: je viens d'utiliser la commande suivante:

SELECT
    sqltext.TEXT,
    req.session_id,
    req.blocking_session_id,
    req.wait_type,
    req.wait_time,
    req.last_wait_type,
    req.wait_resource,
    req.open_transaction_count,
    req.transaction_id,
    req.total_elapsed_time
FROM
    sys.dm_exec_requests req
CROSS APPLY
    sys.dm_exec_sql_text(req.sql_handle) AS sqltext

et a constaté que ma requête attendait un verrou partagé (LCK_M_S) où la session de blocage attend un autre verrou partagé bloqué par une session qui n'existe pas.

Edit 2: OK, la session existe (je l'ai trouvée en utilisant sys.dm_exec_sessions), mais elle ne semble rien faire maintenant.

Edit 3: Je ne trouve rien d'intéressant sur la session. Je vois de quel serveur Web il s'agit, mais pas grand chose d'autre.

Edit 4: Edit 4: Nous avons trouvé un bogue possible dans notre code: une fonction qui ne s'assurait pas qu'une connexion à la base de données était fermée. D'un autre côté, il semblait que la transaction utilisée par la fonction était correctement éliminée, auquel cas tous les verrous auraient dû être effacés. Ce n'est toujours pas très clair pour moi, mais cela semble être la raison probable. Nous allons corriger le bug et garder un œil dessus.

Pour moi, ce problème est dû à une connexion à la base de données laissée ouverte par Visual Studio interrompue en mode débogage. L'arrêt du processus de débogage a permis à la requête de se terminer immédiatement.

Quel est le type d'attente pour la requête lorsqu'elle est suspendue? Cela vous dira exactement ce qu'il attend. Allez rechercher et installer sp_whoisactive sur le serveur et exécutez la procédure stockée lorsque vous rencontrez le problème. Cela vous montrera le spid et vous donnera le type d'attente.

Il y a de fortes chances que vous soyez bloqué par une personne écrivant sur cette ligne ou sur une autre ligne de cette page ou que vous attendiez que le disque réponde.

Essayez d'exécuter DBCC CHECKDBsur la base de données du problème et attendez qu'il se termine. S'il y a une incohérence des données physiques qui produit un comportement aussi étrange, alors il est trop dangereux de travailler avec cette base de données car vous risquez de perdre toutes vos données.

1. Effectuez la sauvegarde dès que possible.
2. Vérifiez la base de données.

MAIS

Si la table a des colonnes BLOB avec des quantités de données relativement importantes, il est absolument normal que les vérifications par rapport à cette table prennent beaucoup de temps.

Je ne sais pas vraiment ce que vous attendez comme réponse, mais si le tableau contient plus de 30 millions de lignes, il est prévu que la commande DBCC s'exécute pendant longtemps.

Quand tu dis:

Mais il semble que cela ne se produise que pour une petite fraction des enregistrements

vous voulez dire que vous craignez que toute la table ne soit pas scannée? C'est normal si vous avez un index sur ID, l'index serait analysé, ce qui entraînerait moins de lectures.