Délais d'expiration de la connection random SQL 2005 / meilleure pratique concernant les timeouts d'attente de la database

J'utilise le type SqlCommand ADO.Net et je mets le CommandTimeout à 30 secondes.

Mon problème est que la connection / command empêche le dépassement de time provoquant des exceptions non gérées qui font planter mon système!

Les données que j'essaie de récupérer sont critiques pour le système. Je souhaite donc corriger les timeouts d'attente plutôt que d'append une logique de réessai de gestion des exceptions.

Donc, ma question est: Comment évitez-vous / corrigez-vous les problèmes de timeout d'attente de database?

Je ne veux pas définir le timeout d'attente à une valeur supérieure à 30 secondes car j'ai du code critique de time.

Merci

  1. Gérez l'exception pour ne pas planter votre système
  2. Corrigez les appels de votre database pour qu'ils ne soient pas interrompus

Les deux problèmes ci-dessus doivent être mis en œuvre. Un appel de database peut toujours lever des exceptions, quelles que soient les précautions que vous prenez, vous devez donc gérer l'exception, point.

Si vos appels durent plus de 30 secondes, cela signifie que vous effectuez BEAUCOUP de traitement ou que vous êtes bloqué tout le time. Très probablement vous êtes bloqué tout le time. Pour réduire le blocage, réduisez la scope et la durée de vos verrous. Donner une réponse plus détaillée pour une telle question générique signifierait essentiellement réitérer à travers tous les principes de la théorie de traitement des transactions …

Mon application a été installée sur un réseau client qui était TRÈS peu fiable … nous avons dû réessayer l'exécution d'une command après une connection perdue parce que la deuxième fois qu'elle passait généralement (nous parlons de SQL Server 2005 ici).

Assumming vous utilisez des transactions (sinon vous devriez), voici mon wrapper Commit Transaction qui gère assez bien les connections perdues (pourrait être optimisé je suppose … mais c'est juste un copyr / coller de mon code):

Public Shared Function SafeCommitRollback(ByVal Trans As SqlClient.SqlTransaction, Optional ByVal Action As TROperation = TROperation.Commit, Optional ByVal QuietMode As Boolean = False) As Boolean SafeCommitRollback = False Dim TryRollback As Boolean = False Dim ConnLost As Boolean = False Dim msgErr As Ssortingng = "" If Action = TROperation.Commit Then Try Trans.Commit() SafeCommitRollback = True Catch ex As SqlClient.SqlException When ex.Class = 20 OrElse (ex.Class = 11 And ex.Number = -2) ConnLost = True Catch ex As System.InvalidOperationException When ex.Source = "System.Data" 'AndAlso ex.Message.StartsWith("Timeout expired.") ConnLost = True Catch ex As Exception TryRollback = True msgErr &= clsErrorHandling.ParseException(ex, True) End Try If ConnLost Then Try Trans.Commit() SafeCommitRollback = True Catch ex2 As Exception TryRollback = True msgErr &= clsErrorHandling.ParseException(ex2, True) End Try End If Else TryRollback = True End If If TryRollback Then Try Trans.Rollback() If Action = TROperation.Rollback Then SafeCommitRollback = True Catch ex3 As Exception msgErr &= clsErrorHandling.ParseException(ex3) End Try End If If Not QuietMode AndAlso msgErr.Trim <> "" Then clsMessageBox.ShowError(msgErr) End Function 

J'espère que ça aide…

D'accord avec Remus, gérer le timeout s'il se produit.

Il y a beaucoup de possibilités d'optimiser la requête de la database. Ce n'est pas spécifique à less d'avoir des détails, mais vous pouvez essayer

Utiliser le profil sql pour optimiser les requêtes Utiliser les procédures stockées, pas le code en ligne Optimiser le schéma de la database, inclure l'index où la colonne pourrait aider. Essayez la pagination si vous renvoyez beaucoup de lignes Ne renvoyez que ce dont vous avez besoin. Si le timeout d'attente n'est pas dû au blocage, voici un excellent article –

http://searchsqlserver.techtarget.com/generic/0,295582,sid87_gci1339694,00.html

http://vyaskn.sortingpod.com/sql_odbc_timeout_expired.htm