Transaction (ID de Processus 84) a été bloquée sur les ressources par un autre processus et a été choisie comme victime du blocage

J'ai développé une application de Surveillance. Donc là, j'ai utilisé une fonction de Minuterie afin de vérifier certaines valeurs dans une Table SQL.

mais il y a tellement de fonction il donne l'erreur suivante pour une fonction appelée getLogEntry()

message>Transaction (Process ID 84) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.</message>
<innerMessage>
</innerMessage>
<source>.Net SqlClient Data Provider</source>
<stackTrace>at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
   at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
   at System.Data.SqlClient.SqlDataReader.HasMoreRows()
   at System.Data.SqlClient.SqlDataReader.ReadInternal(Boolean setTimeout)
   at ShiftAlertSystem.DBAccess.getLogEntry(Int32 nEventLogIdn, connections cn)</stackTrace>
    <createdAt>2012/06/18 13:10:47</createdAt>

C'est la mise en œuvre de la fonction

public LogEntry getLogEntry(int nEventLogIdn, connections cn)
{
lock (_objLock)
{
LogEntry lgEntObj = new LogEntry();
SqlConnection NewCon3 = new SqlConnection();
SqlCommand newCmd2 = null;
SqlDataReader dr = null;
try
{
string connectString;
//Configuration config = ConfigurationManager.u
string DataSource = cryptIT.Decrypt(cn.DataSource_bio);
string initialCatalog = cryptIT.Decrypt(cn.InitialCatalog_bio);
string user = cryptIT.Decrypt(cn.user_bio);
string password = cryptIT.Decrypt(cn.password_bio);
bool intergratedSecurity = cn.IntegratedSecurity_bio;
if (intergratedSecurity)
{
connectString = "Data Source=" + DataSource + ";Initial Catalog=" + initialCatalog + ";Integrated Security=True";
}
else
{
connectString = "Data Source=" + DataSource + ";Initial Catalog=" + initialCatalog + ";User ID=" + user + ";Password=" + password;
}
NewCon3 = new SqlConnection(connectString);
NewCon3.Open();
newCmd2 = NewCon3.CreateCommand();
newCmd2.Connection = NewCon3;
newCmd2.CommandType = CommandType.Text;
newCmd2.CommandText = @"
SELECT [nUserID]
,[sUserName]
,dateadd(s,[nDateTime],'1970/1/1') AS LogDateTime
,[nEventIdn]
,[nTNAEvent]
,[TB_READER].[nReaderIdn]
,[sName]
FROM 
[TB_EVENT_LOG]
,[TB_USER]
,[TB_READER]
WHERE 
[nEventLogIdn] = " + nEventLogIdn +
@" AND
[TB_EVENT_LOG].[nUserID] = [TB_USER].[sUserID]
AND
[nFlag]= 1
AND
[TB_EVENT_LOG].[nReaderIdn]=[TB_READER].[nReaderIdn]"
;
dr = newCmd2.ExecuteReader();
if (dr != null && dr.Read())
{
lgEntObj.nUserID = dr.GetInt32(0);
lgEntObj.nUserName = dr.GetString(1);
lgEntObj.LogDateTime = dr.GetDateTime(2);
lgEntObj.nEventIdn = dr.GetInt32(3);
lgEntObj.nTNAEvent = dr.GetInt16(4);
lgEntObj.nReaderIdn = dr.GetInt32(5);
lgEntObj.sName = dr.GetString(6);
}
dr.Close();
newCmd2.Dispose();
//NewCon.Close();
NewCon3.Close();
return lgEntObj;
}
catch (Exception exc)
{
CenUtility.ErrorLog.CreateLog(exc);
return null;
}
finally
{
if (dr != null)
dr.Close(); 
if(newCmd2 != null)
newCmd2.Dispose();
NewCon3.Close();
}
}
}

Merci d'avance

Vous pourriez vouloir prendre en compte les suggestions faites dans cette réponse: stackoverflow.com/questions/2382410/.... Nous avons mis en œuvre avec succès de la requête tentatives si la requête initiale est dans l'impasse.
Aussi, combien d'entrées de journal écrivez-vous? Si vous écrivez beaucoup, peut-être que vous êtes juste à entraver les SÉLECTIONNER avec un grand nombre de plaquettes.
Par cette application, rien n'est écrit dans ces tables, mais un autre Logiciel écrit les données dans ces tables.
S'il vous plaît obtenir le graphique de blocage et les ajouter à votre question. Si vous êtes sur 2008 vous pouvez obtenir ce à partir de la valeur par défaut des Événements Étendus trace sinon, vous aurez besoin de mettre en place un suivi de le capturer.

OriginalL'auteur Tharik Kanaka | 2012-06-19

c#deadlock sql sql-server

15

Vous pouvez vous référer à cette question pour plus de suggestions utiles.

J'utilise le schéma suivant pour la base de données de tentatives; dans cet exemple, nous retournons une DataTable, mais le motif est le même, peu importe; vous détecter une SqlDeadlock ou le Délai d'attente basé sur la SqlException Nombre, et de réessayer, jusqu'à un nombre maximal de n fois.
```
    public DataTable DoSomeSql(int retryCount = 1)
{
try
{
//Run Stored Proc/Adhoc SQL here
}
catch (SqlException sqlEx)
{
if (retryCount == MAX_RETRY_COUNT) //5, 7, Whatever
{
log.Error("Unable to DoSomeSql, reached maximum number of retries.");
throw;
}
switch (sqlEx.Number)
{
case DBConstants.SQL_DEADLOCK_ERROR_CODE: //1205
log.Warn("DoSomeSql was deadlocked, will try again.");
break;
case DBConstants.SQL_TIMEOUT_ERROR_CODE: //-2
log.Warn("DoSomeSql was timedout, will try again.");
break;
default:
log.WarnFormat(buf.ToString(), sqlEx);
break;
}
System.Threading.Thread.Sleep(1000); //Can also use Math.Rand for a random interval of time
return DoSomeSql(asOfDate, ++retryCount);
}
}
```
J'espère que vous êtes suivi. Par exemple, si vous obtenez une impasse recommencer à tous les millions de requêtes, ou par mois, alors que vous êtes bien. Si vous obtenez 1, toutes les minutes, toutes les autres requêtes, alors que vous êtes en difficulté et doit corriger la cause plutôt que de travailler autour d'elle...
Parfois, vous obtenez une impasse mais vous ne voulez pas que votre demande de mourir à cause d'elle; nouvelle tentative de vous achète le temps dont vous avez besoin pour enquêter sur la cause racine du problème; notez que je ne vous suggérons de lire le premier lien 🙂 Parfois, vous obtenez également un blocage ou un délai d'attente juste parce que le système est occupé.
Je ne dis pas de ne pas le faire, je dis juste que pour le surveiller. Comme je l'ai dit, si c'est peu fréquent, alors vous êtes bon. Mais si c'est régulier, alors vous avez un problème et que vous avez mis de force dans un échec silencieux - pour l'application à ce point dans le temps, mais ensuite, signifie que vous avez besoin d'un moyen de surveiller si il arrive donc fréquemment que vous avez réellement besoin pour traiter la cause sous-jacente et non pas seulement ses effets. Si vous n'avez pas de moniteur puis vous ne savez même pas il n'y a rien à étudier.
Nous avons obtenu, 20 ou 30 fois par heure pendant les pics de charge. Cette approche m'a donné assez de temps pour maintenir le système en cours d'exécution, mais aussi à enquêter sur les causes profondes comme vous le suggérez. Il fixe aussi 🙂 je suis totalement d'accord avec vous!
Peut-être réessayer pour SqlException.Nombre: SqlConnectionBroken = -1, SqlTimeout = -2, SqlOutOfMemory = 701, SqlOutOfLocks = 1204, SqlDeadlockVictim = 1205, SqlLockRequestTimeout = 1222, SqlTimeoutWaitingForMemoryResource = 8645, SqlLowMemoryCondition = 8651, SqlWordbreakerTimeout = 30053

OriginalL'auteur dash
3

Votre requête dans l'impasse avec une autre requête. L'autre requête est probablement un insert, update ou delete requête, depuis select seul n'a pas tendance à l'impasse.

Si vous ne vous inquiétez pas trop à propos de la cohérence, vous pouvez utiliser le with (nolock) astuce:
```
FROM 
[TB_EVENT_LOG] with (nolock)
,[TB_USER] with (nolock)
,[TB_READER] with (nolock)
```
Qui sera la cause de votre requête ne pas placer des verrous. Une requête sans verrous ne sera pas causer des blocages. L'inconvénient est qu'il peut renvoyer des données incohérentes, lorsqu'il s'exécute en même temps qu'une requête de modification.

Notez que si la serrure a dégénéré à un Verrou de Table, cela ne fonctionnera pas; voir msdn.microsoft.com/en-us/library/ms187373.aspx.
Cet article s'applique uniquement aux DDL, comme alter table, qui acquiert un Sch-M (modification du schéma) de verrouillage. Un with (nolock) sera heureux de lire à travers une with (tablockx)
"Un soutien pour l'utilisation de la READUNCOMMITTED et NOLOCK dans la clause from qui s'appliquent à la table cible d'une instruction UPDATE ou DELETE sera supprimée dans une future version de SQL Server. Évitez d'utiliser ces indicateurs dans ce contexte, de nouveaux travaux de développement et le plan de modifier les applications qui utilisent actuellement." est également dans ce. Je ne suis pas sûr à 100% qu'il va lire au moyen d'une opération dans tous les cas; j'ai connu des situations où nolock n'a pas fonctionné, parce qu'un tablelock a été mis en place.
Aussi, à partir de l'en-tête de l'article: s'Applique à: SUPPRIMER INSÉRER, SÉLECTIONNEZ mise à JOUR de FUSION, je ne suis pas vraiment en désaccord avec vous (donc juste un commentaire), c'est juste que j'ai trouvé les comportements de (NOLOCK) pour être peu fiables, et, comme @Dems mentionne, il est préférable de résoudre le problème sous-jacent.

OriginalL'auteur Andomar

Vous devez vous connecter pour publier un commentaire.