SQL Server 2008 - Mise à jour Délai de requête

Question

J'utilise SQL2008 et .NET 4.

Voici UPDATE requête provoque des erreurs de délai d'attente.

Tableau Les pages ont 600 000 enregistrements.

Erreur:

System.Data.SqlClient.SqlException (0x80131904): Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

Requête:

UPDATE Pages 
SET Checked = 1 , LastChecked = GETDATE() 
OUTPUT Inserted.ID, Inserted.Title INTO @Updated 
WHERE ID in 
(SELECT TOP (@Count) ID 
    FROM Pages 
    WHERE Checked = 0 and FileID = @FileID 
    ORDER BY ID) 

SELECT * FROM @Updated 
END 

Sur un autre thread I Insérer des enregistrements à Pages table, cela va sans cesse (une page est ajoutée toutes les 1 sec ou moins).

INSERT INTO Pages (Title ,.......) 
VALUES (@Title , .......) 

Pourquoi est-ce que j'obtiens l'erreur de délai d'attente et comment puis-je la résoudre?

SQL ne pas attendre indéfiniment sur la situation de blocage?

Answer 1

C'est votre commande/client qui expire, plutôt que SQL Server lui-même.

Ajustez votre SqlCommand.CommandTimeout à une valeur supérieure?

myCmd.CommandTimeout = 360; //seconds 

Mises à jour:

Êtes-vous sûr que votre deuxième déclaration UPDATE 1 est celui qui est bloqué/temporiser? Peut-être qu'il y a quelque chose d'autre qui vient d'être exécuté?

Avez-vous regardé SSMS pour déterminer ce qui est bloqué/bloqué? Cliquez avec le bouton droit sur votre serveur, sélectionnez "Moniteur d'activité".

Qu'est-ce que SQL Profiler vous montre comme étant en cours d'exécution? Comme le dit (+1) p.campbell, le timeout vient de .NET, pas de SQL.

Answer 2

Quelle indexation avez-vous en place? Sans une couverture appropriée des colonnes "Vérifié" et/ou "ID", votre sous-requête (SELECT TOP ...) devra lire chaque page de la table, pour obtenir tout d'abord où Checked = 0 et ensuite les trier par ID. S'il est grand et régulièrement mis à jour, cela pourrait le retarder.

S'il n'est pas nécessaire de les trier par ID, la suppression de ORDER BY peut entraîner la lecture des lignes uniquement jusqu'à ce que @Count leur soit associé.

Si vous avez SQL 2008, une requête filtrée (... WHERE Checked = 0) pourrait accélérer les choses.