Base de données: MSSQL Server 2012;
Niveau d'isolement: read_committed_snapshot p>
J'ai une table "Cov_holes_perioddate". Il a une clé primaire composite qui est également un indice en cluster. Aucun autre index sur cette table. P>
Il existe de nombreux threads (via Java) fonctionnant simultanément. Chaque thread va d'abord faire une "sélection de mise à jour" sur une touche principale différente via le conseil de verrouillage (updock, Rowlock), puis faites du travail, puis mettez à jour la table de cette ligne. Il est garanti du côté Java que chaque thread fonctionne sur une ligne différente de cette table. P>
Cependant, il y a une impasse rare et insaisissable que je ne pouvais pas reproduire systématiquement. Cette impasse se produit une fois dans un grand temps. J'imagine qu'il ne devrait jamais y avoir de conflit de verrouillage car chaque transaction ne devrait que verrouiller une ligne différente. Le graphe deadlock montre "collision" sur "verrouillage de la clé". "ID HOBT" dans le graphique de l'impasse, comme je l'ai demandé, est l'index "dans ce tableau. P>
Qu'est-ce que j'ai manqué? Merci! P>
Liste de code pour chaque trans: Remarque Chaque transport fonctionne sur une clé primaire différente. P>
<deadlock-list>
<deadlock victim="process2fb02d498">
<process-list>
<process id="process2fb02d498" taskpriority="0" logused="0" waitresource="KEY: 6:72057594048413696 (425c06b927a8)" waittime="4321" ownerId="181788" transactionname="implicit_transaction" lasttranstarted="2014-02-18T14:29:08.930" XDES="0x2f0d6a3a8" lockMode="U" schedulerid="4" kpid="8704" status="suspended" spid="60" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2014-02-18T14:29:09.010" lastbatchcompleted="2014-02-18T14:29:09.010" lastattention="1900-01-01T00:00:00.010" clientapp="Microsoft JDBC Driver for SQL Server" hostname="ACNU34794GD" hostpid="0" loginname="cpq_jfu_v380_speedTest_WEBAPP" isolationlevel="read committed (2)" xactid="181788" currentdb="6" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128058">
<executionStack>
<frame procname="adhoc" line="1" stmtstart="148" sqlhandle="0x02000000f9bd1c3532128f75b67ae477b2447ba2a64528db0000000000000000000000000000000000000000">
update cpq_jfu_v380_speedTest.cpqjfuv380speedTest.COV_HOLES_PERIODDATE set LAST_UPDATED_DTZ=@P0 where DIVISION_ID=@P1 and UNIT_ID=@P2 and SKILL=@P3 and PERIOD_START_DATE=@P4 </frame>
<frame procname="unknown" line="1" sqlhandle="0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000">
unknown </frame>
</executionStack>
<inputbuf>
(@P0 nvarchar(4000),@P1 smallint,@P2 smallint,@P3 nvarchar(4000),@P4 date)update cpq_jfu_v380_speedTest.cpqjfuv380speedTest.COV_HOLES_PERIODDATE set LAST_UPDATED_DTZ=@P0 where DIVISION_ID=@P1 and UNIT_ID=@P2 and SKILL=@P3 and PERIOD_START_DATE=@P4 </inputbuf>
</process>
<process id="process2f0110cf8" taskpriority="0" logused="0" waitresource="KEY: 6:72057594048413696 (3d51ccbaf870)" waittime="4303" ownerId="181789" transactionname="implicit_transaction" lasttranstarted="2014-02-18T14:29:08.933" XDES="0x2f651e6c8" lockMode="U" schedulerid="3" kpid="904" status="suspended" spid="56" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2014-02-18T14:29:09.030" lastbatchcompleted="2014-02-18T14:29:09.030" lastattention="1900-01-01T00:00:00.030" clientapp="Microsoft JDBC Driver for SQL Server" hostname="ACNU34794GD" hostpid="0" loginname="cpq_jfu_v380_speedTest_WEBAPP" isolationlevel="read committed (2)" xactid="181789" currentdb="6" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128058">
<executionStack>
<frame procname="adhoc" line="1" stmtstart="148" sqlhandle="0x02000000f9bd1c3532128f75b67ae477b2447ba2a64528db0000000000000000000000000000000000000000">
update cpq_jfu_v380_speedTest.cpqjfuv380speedTest.COV_HOLES_PERIODDATE set LAST_UPDATED_DTZ=@P0 where DIVISION_ID=@P1 and UNIT_ID=@P2 and SKILL=@P3 and PERIOD_START_DATE=@P4 </frame>
<frame procname="unknown" line="1" sqlhandle="0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000">
unknown </frame>
</executionStack>
<inputbuf>
(@P0 nvarchar(4000),@P1 smallint,@P2 smallint,@P3 nvarchar(4000),@P4 date)update cpq_jfu_v380_speedTest.cpqjfuv380speedTest.COV_HOLES_PERIODDATE set LAST_UPDATED_DTZ=@P0 where DIVISION_ID=@P1 and UNIT_ID=@P2 and SKILL=@P3 and PERIOD_START_DATE=@P4 </inputbuf>
</process>
<process id="process2f05d0188" taskpriority="0" logused="0" waitresource="KEY: 6:72057594048413696 (f40d3be1c4a7)" waittime="4381" ownerId="181790" transactionname="implicit_transaction" lasttranstarted="2014-02-18T14:29:08.937" XDES="0x2f0290d08" lockMode="U" schedulerid="4" kpid="5248" status="suspended" spid="59" sbid="0" ecid="0" priority="0" trancount="1" lastbatchstarted="2014-02-18T14:29:08.950" lastbatchcompleted="2014-02-18T14:29:08.950" lastattention="1900-01-01T00:00:00.950" clientapp="Microsoft JDBC Driver for SQL Server" hostname="ACNU34794GD" hostpid="0" loginname="cpq_jfu_v380_speedTest_WEBAPP" isolationlevel="read committed (2)" xactid="181790" currentdb="6" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128058">
<executionStack>
<frame procname="adhoc" line="1" stmtstart="110" sqlhandle="0x02000000e59aa71c628d78d0574a5f60f697c8ffd8228e4b0000000000000000000000000000000000000000">
select DIVISION_ID from cpq_jfu_v380_speedTest.cpqjfuv380speedTest.COV_HOLES_PERIODDATE with (updlock, rowlock) where DIVISION_ID =@P0 and UNIT_ID =@P1 and SKILL =@P2 and PERIOD_START_DATE =@P3 </frame>
<frame procname="unknown" line="1" sqlhandle="0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000">
unknown </frame>
</executionStack>
<inputbuf>
(@P0 smallint,@P1 smallint,@P2 nvarchar(4000),@P3 date)select DIVISION_ID from cpq_jfu_v380_speedTest.cpqjfuv380speedTest.COV_HOLES_PERIODDATE with (updlock, rowlock) where DIVISION_ID =@P0 and UNIT_ID =@P1 and SKILL =@P2 and PERIOD_START_DATE =@P3 </inputbuf>
</process>
<process id="process2f2a9f868" taskpriority="0" logused="0" waitresource="KEY: 6:72057594048413696 (8b00f1e21b7f)" waittime="4380" ownerId="181792" transactionname="implicit_transaction" lasttranstarted="2014-02-18T14:29:08.950" XDES="0x2f651f1d8" lockMode="U" schedulerid="2" kpid="7652" status="suspended" spid="63" sbid="0" ecid="0" priority="0" trancount="1" lastbatchstarted="2014-02-18T14:29:08.950" lastbatchcompleted="2014-02-18T14:29:08.950" lastattention="1900-01-01T00:00:00.950" clientapp="Microsoft JDBC Driver for SQL Server" hostname="ACNU34794GD" hostpid="0" loginname="cpq_jfu_v380_speedTest_WEBAPP" isolationlevel="read committed (2)" xactid="181792" currentdb="6" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128058">
<executionStack>
<frame procname="adhoc" line="1" stmtstart="110" sqlhandle="0x02000000e59aa71c628d78d0574a5f60f697c8ffd8228e4b0000000000000000000000000000000000000000">
select DIVISION_ID from cpq_jfu_v380_speedTest.cpqjfuv380speedTest.COV_HOLES_PERIODDATE with (updlock, rowlock) where DIVISION_ID =@P0 and UNIT_ID =@P1 and SKILL =@P2 and PERIOD_START_DATE =@P3 </frame>
<frame procname="unknown" line="1" sqlhandle="0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000">
unknown </frame>
</executionStack>
<inputbuf>
(@P0 smallint,@P1 smallint,@P2 nvarchar(4000),@P3 date)select DIVISION_ID from cpq_jfu_v380_speedTest.cpqjfuv380speedTest.COV_HOLES_PERIODDATE with (updlock, rowlock) where DIVISION_ID =@P0 and UNIT_ID =@P1 and SKILL =@P2 and PERIOD_START_DATE =@P3 </inputbuf>
</process>
</process-list>
<resource-list>
<keylock hobtid="72057594048413696" dbid="6" objectname="cpq_jfu_v380_speedTest.cpqjfuv380speedTest.COV_HOLES_PERIODDATE" indexname="1" id="lock2c70ba180" mode="U" associatedObjectId="72057594048413696">
<owner-list>
<owner id="process2f2a9f868" mode="U"/>
</owner-list>
<waiter-list>
<waiter id="process2fb02d498" mode="U" requestType="wait"/>
</waiter-list>
</keylock>
<keylock hobtid="72057594048413696" dbid="6" objectname="cpq_jfu_v380_speedTest.cpqjfuv380speedTest.COV_HOLES_PERIODDATE" indexname="1" id="lock2cc3d9980" mode="U" associatedObjectId="72057594048413696">
<owner-list>
<owner id="process2f05d0188" mode="U"/>
</owner-list>
<waiter-list>
<waiter id="process2f0110cf8" mode="U" requestType="wait"/>
</waiter-list>
</keylock>
<keylock hobtid="72057594048413696" dbid="6" objectname="cpq_jfu_v380_speedTest.cpqjfuv380speedTest.COV_HOLES_PERIODDATE" indexname="1" id="lock2cf4fa480" mode="U" associatedObjectId="72057594048413696">
<owner-list>
<owner id="process2f0110cf8" mode="U"/>
</owner-list>
<waiter-list>
<waiter id="process2f05d0188" mode="U" requestType="wait"/>
</waiter-list>
</keylock>
<keylock hobtid="72057594048413696" dbid="6" objectname="cpq_jfu_v380_speedTest.cpqjfuv380speedTest.COV_HOLES_PERIODDATE" indexname="1" id="lock2cf4f9e80" mode="U" associatedObjectId="72057594048413696">
<owner-list>
<owner id="process2fb02d498" mode="U"/>
</owner-list>
<waiter-list>
<waiter id="process2f2a9f868" mode="U" requestType="wait"/>
</waiter-list>
</keylock>
</resource-list>
</deadlock>
<deadlock victim="process2f0110cf8">
<process-list>
<process id="process2fb02d498" taskpriority="0" logused="0" waitresource="KEY: 6:72057594048413696 (425c06b927a8)" waittime="4321" ownerId="181788" transactionname="implicit_transaction" lasttranstarted="2014-02-18T14:29:08.930" XDES="0x2f0d6a3a8" lockMode="U" schedulerid="4" kpid="8704" status="suspended" spid="60" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2014-02-18T14:29:09.010" lastbatchcompleted="2014-02-18T14:29:09.010" lastattention="1900-01-01T00:00:00.010" clientapp="Microsoft JDBC Driver for SQL Server" hostname="ACNU34794GD" hostpid="0" loginname="cpq_jfu_v380_speedTest_WEBAPP" isolationlevel="read committed (2)" xactid="181788" currentdb="6" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128058">
<executionStack>
<frame procname="adhoc" line="1" stmtstart="148" sqlhandle="0x02000000f9bd1c3532128f75b67ae477b2447ba2a64528db0000000000000000000000000000000000000000">
update cpq_jfu_v380_speedTest.cpqjfuv380speedTest.COV_HOLES_PERIODDATE set LAST_UPDATED_DTZ=@P0 where DIVISION_ID=@P1 and UNIT_ID=@P2 and SKILL=@P3 and PERIOD_START_DATE=@P4 </frame>
<frame procname="unknown" line="1" sqlhandle="0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000">
unknown </frame>
</executionStack>
<inputbuf>
(@P0 nvarchar(4000),@P1 smallint,@P2 smallint,@P3 nvarchar(4000),@P4 date)update cpq_jfu_v380_speedTest.cpqjfuv380speedTest.COV_HOLES_PERIODDATE set LAST_UPDATED_DTZ=@P0 where DIVISION_ID=@P1 and UNIT_ID=@P2 and SKILL=@P3 and PERIOD_START_DATE=@P4 </inputbuf>
</process>
<process id="process2f0110cf8" taskpriority="0" logused="0" waitresource="KEY: 6:72057594048413696 (3d51ccbaf870)" waittime="4303" ownerId="181789" transactionname="implicit_transaction" lasttranstarted="2014-02-18T14:29:08.933" XDES="0x2f651e6c8" lockMode="U" schedulerid="3" kpid="904" status="suspended" spid="56" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2014-02-18T14:29:09.030" lastbatchcompleted="2014-02-18T14:29:09.030" lastattention="1900-01-01T00:00:00.030" clientapp="Microsoft JDBC Driver for SQL Server" hostname="ACNU34794GD" hostpid="0" loginname="cpq_jfu_v380_speedTest_WEBAPP" isolationlevel="read committed (2)" xactid="181789" currentdb="6" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128058">
<executionStack>
<frame procname="adhoc" line="1" stmtstart="148" sqlhandle="0x02000000f9bd1c3532128f75b67ae477b2447ba2a64528db0000000000000000000000000000000000000000">
update cpq_jfu_v380_speedTest.cpqjfuv380speedTest.COV_HOLES_PERIODDATE set LAST_UPDATED_DTZ=@P0 where DIVISION_ID=@P1 and UNIT_ID=@P2 and SKILL=@P3 and PERIOD_START_DATE=@P4 </frame>
<frame procname="unknown" line="1" sqlhandle="0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000">
unknown </frame>
</executionStack>
<inputbuf>
(@P0 nvarchar(4000),@P1 smallint,@P2 smallint,@P3 nvarchar(4000),@P4 date)update cpq_jfu_v380_speedTest.cpqjfuv380speedTest.COV_HOLES_PERIODDATE set LAST_UPDATED_DTZ=@P0 where DIVISION_ID=@P1 and UNIT_ID=@P2 and SKILL=@P3 and PERIOD_START_DATE=@P4 </inputbuf>
</process>
<process id="process2f05d0188" taskpriority="0" logused="0" waitresource="KEY: 6:72057594048413696 (f40d3be1c4a7)" waittime="4381" ownerId="181790" transactionname="implicit_transaction" lasttranstarted="2014-02-18T14:29:08.937" XDES="0x2f0290d08" lockMode="U" schedulerid="4" kpid="5248" status="suspended" spid="59" sbid="0" ecid="0" priority="0" trancount="1" lastbatchstarted="2014-02-18T14:29:08.950" lastbatchcompleted="2014-02-18T14:29:08.950" lastattention="1900-01-01T00:00:00.950" clientapp="Microsoft JDBC Driver for SQL Server" hostname="ACNU34794GD" hostpid="0" loginname="cpq_jfu_v380_speedTest_WEBAPP" isolationlevel="read committed (2)" xactid="181790" currentdb="6" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128058">
<executionStack>
<frame procname="adhoc" line="1" stmtstart="110" sqlhandle="0x02000000e59aa71c628d78d0574a5f60f697c8ffd8228e4b0000000000000000000000000000000000000000">
select DIVISION_ID from cpq_jfu_v380_speedTest.cpqjfuv380speedTest.COV_HOLES_PERIODDATE with (updlock, rowlock) where DIVISION_ID =@P0 and UNIT_ID =@P1 and SKILL =@P2 and PERIOD_START_DATE =@P3 </frame>
<frame procname="unknown" line="1" sqlhandle="0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000">
unknown </frame>
</executionStack>
<inputbuf>
(@P0 smallint,@P1 smallint,@P2 nvarchar(4000),@P3 date)select DIVISION_ID from cpq_jfu_v380_speedTest.cpqjfuv380speedTest.COV_HOLES_PERIODDATE with (updlock, rowlock) where DIVISION_ID =@P0 and UNIT_ID =@P1 and SKILL =@P2 and PERIOD_START_DATE =@P3 </inputbuf>
</process>
<process id="process2f2a9f868" taskpriority="0" logused="0" waitresource="KEY: 6:72057594048413696 (8b00f1e21b7f)" waittime="4381" ownerId="181792" transactionname="implicit_transaction" lasttranstarted="2014-02-18T14:29:08.950" XDES="0x2f651f1d8" lockMode="U" schedulerid="2" kpid="7652" status="suspended" spid="63" sbid="0" ecid="0" priority="0" trancount="1" lastbatchstarted="2014-02-18T14:29:08.950" lastbatchcompleted="2014-02-18T14:29:08.950" lastattention="1900-01-01T00:00:00.950" clientapp="Microsoft JDBC Driver for SQL Server" hostname="ACNU34794GD" hostpid="0" loginname="cpq_jfu_v380_speedTest_WEBAPP" isolationlevel="read committed (2)" xactid="181792" currentdb="6" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128058">
<executionStack>
<frame procname="adhoc" line="1" stmtstart="110" sqlhandle="0x02000000e59aa71c628d78d0574a5f60f697c8ffd8228e4b0000000000000000000000000000000000000000">
select DIVISION_ID from cpq_jfu_v380_speedTest.cpqjfuv380speedTest.COV_HOLES_PERIODDATE with (updlock, rowlock) where DIVISION_ID =@P0 and UNIT_ID =@P1 and SKILL =@P2 and PERIOD_START_DATE =@P3 </frame>
<frame procname="unknown" line="1" sqlhandle="0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000">
unknown </frame>
</executionStack>
<inputbuf>
(@P0 smallint,@P1 smallint,@P2 nvarchar(4000),@P3 date)select DIVISION_ID from cpq_jfu_v380_speedTest.cpqjfuv380speedTest.COV_HOLES_PERIODDATE with (updlock, rowlock) where DIVISION_ID =@P0 and UNIT_ID =@P1 and SKILL =@P2 and PERIOD_START_DATE =@P3 </inputbuf>
</process>
</process-list>
<resource-list>
<keylock hobtid="72057594048413696" dbid="6" objectname="cpq_jfu_v380_speedTest.cpqjfuv380speedTest.COV_HOLES_PERIODDATE" indexname="1" id="lock2c70ba180" mode="U" associatedObjectId="72057594048413696">
<owner-list>
<owner id="process2f2a9f868" mode="U"/>
</owner-list>
<waiter-list>
<waiter id="process2fb02d498" mode="U" requestType="wait"/>
</waiter-list>
</keylock>
<keylock hobtid="72057594048413696" dbid="6" objectname="cpq_jfu_v380_speedTest.cpqjfuv380speedTest.COV_HOLES_PERIODDATE" indexname="1" id="lock2cc3d9980" mode="U" associatedObjectId="72057594048413696">
<owner-list>
<owner id="process2f05d0188" mode="U"/>
</owner-list>
<waiter-list>
<waiter id="process2f0110cf8" mode="U" requestType="wait"/>
</waiter-list>
</keylock>
<keylock hobtid="72057594048413696" dbid="6" objectname="cpq_jfu_v380_speedTest.cpqjfuv380speedTest.COV_HOLES_PERIODDATE" indexname="1" id="lock2cf4fa480" mode="U" associatedObjectId="72057594048413696">
<owner-list>
<owner id="process2f0110cf8" mode="U"/>
</owner-list>
<waiter-list>
<waiter id="process2f05d0188" mode="U" requestType="wait"/>
</waiter-list>
</keylock>
<keylock hobtid="72057594048413696" dbid="6" objectname="cpq_jfu_v380_speedTest.cpqjfuv380speedTest.COV_HOLES_PERIODDATE" indexname="1" id="lock2cf4f9e80" mode="U" associatedObjectId="72057594048413696">
<owner-list>
<owner id="process2fb02d498" mode="U"/>
</owner-list>
<waiter-list>
<waiter id="process2f2a9f868" mode="U" requestType="wait"/>
</waiter-list>
</keylock>
</resource-list>
</deadlock>
</deadlock-list>
3 Réponses :
Lock Inc. Illock, iFlock et Xock qui acquièrent des verrous à niveau de ligne peuvent placer des verrous sur des touches d'index plutôt que les lignes de données réelles.
Comme vous ne pouvez pas compter à 100%, une rare impasse peut arriver. Dans votre cas, vous pouvez voir qu'une impasse est sur une clé qui pointerait cette situation. rowlock ne vous donne jamais une garantie absolue de ne verrouiller que cette (s) rangée (s) que vous utilisez. Ceci est même indiqué sur MSDN :
Il n'y a qu'un seul index - le CI. Exactement un robinet par voie transpiration doit être pris là-bas. Je ne suis au courant d'aucun cas où une page serrure ou même plus élevée serait prise par le Tran donné. L'OP devrait examiner le graphique de l'impasse pour s'assurer que ce n'est pas le cas.
Wairsource = "Clé: 6: 72057594048413696 (8B00F1E21B7F)" On dirait que cela verrouille une plage de clés dans ce cas. Les serrures pointent sur le même hobt_id .
Je viens d'ajouter la conception de l'image et de la table de cadavlock comme "Edit 2". En tant que développeur Java et ayant une compréhension limitée sur le côté DB, je suis perplexe par la clé de clé. Quand je sélectionne hobt_id, objet_name (p. [Objet_id]), index_id de sys.partitions p Où hobt_id = 72057594048413696, il renvoie Index 1 sur cette table
L'enquête documentée dans les commentaires conduisent à la réponse suivante:
Vous êtes de passage dans les paramètres qui ne correspondent pas aux colonnes correspondantes en caractères. Cela conduit à des conversions implicites et une gamme cherchent à l'index ordonné en clusters. « Cherchez » signifie qu'un sous-ensemble de l'indice sera numérisé. Cela ne signifie pas nécessairement un singleton chercher.
La gamme Rechercher sur la 3ème colonne des moyens d'index que la requête complètement le filtre non pris en compte la 4ème colonne dans une perspective de verrouillage. Cela peut conduire à plusieurs lignes étant verrouillée. Pas nécessairement aller serrures, car ceux-ci ne sont pas pris en D'autres choses qui ont été jugés:
Est-ce toute la transaction? Déclencheurs? Des vues indexées (ne devrait pas
Peu importe le graphique de blocage donné, mais qui sait)? Pouvez-vous poster la
GRAPH quelque part XML? Et il n'y a pas d'index NC, non? Peut tu
afficher le plan de requête pour les deux déclarations?
.
Pourquoi certaines transactions ont trancount = "2". Peut-être toi
transactions misnested afin qu'elles soient étendues? Cela expliquerait
pourquoi plusieurs verrous peuvent être prises par tran. OIEau un bug d'application. Ajouter ce SI
@@ TRANCOUNT <> 1 ROLLBACK Affirmer cela lors de l'exécution. Réexécutez charge
test avec cette assertion.
.
Y at-il des conversions implicites? Je sais qu'il ya parce que vous êtes
en passant dans un nvarchar (4000), mais les colonnes PK ne peuvent pas avoir un tel
colonne. Cela peut conduire à des serrures de gamme prises. Changer la mise à jour
de @ P2 à convert (CORRECT_COLUMN_TYPE_HERE, @ P2) pour vous assurer.
Examiner le plan d'exécution pour vous assurer que le CI Seek utilise uniquement
prédicats d'égalité. Non Ranges.
J'ajoute cela à la réponse afin que les futurs visiteurs de cette question peuvent apprendre à enquêter sur un problème comme celui-ci. LIRE ENGAGE . Aviez-vous également définir l'indice de verrouillage HOLDLOCK (ou SERIALIZABLE ) serrures de gamme auraient été prises.
Merci à un million pour votre explication détaillée. Cela explique vraiment ce mystère. De plus, merci d'éduquer "l'indice de recherche" n'implique pas nécessairement singleton. Merci beaucoup!
Si cela peut aider quiconque rencontrant un problème similaire.
La cause première est que, par défaut, le pilote MSSQL JDBC envoie un paramètre de chaîne au serveur de base de données comme Unicode. Il existe un paramètre SendStringParameMeterasunicode [true | Faux] qui peut être transmis comme une propriété de connexion. Mais par défaut, cette propriété est définie sur true ( http://technet.microsoft.com /en-us/library/ms378988.aspx ).
Si SendstringParameterasunicode Paramètre n'est pas transmis dans la chaîne de connexion (qui est défini par défaut sur true), le pilote JDBC envoie un paramètre défini comme NCHAR, Varcharne comme NvarchaRar et Longvarchar comme Ntext.
Pour la correction de la correction et des performances optimales avec les types de données Char, Varchar et Longvarchar JDBC, une application doit définir la propriété SendstringParameTersasunicode sur "False"
Est-ce toute la transaction? Déclenche? Vues indexées (ne devrait-il pas avoir d'importance avec le grapheadlock donné, mais qui sait)? Pouvez-vous poster le graphique comme xml quelque part? Et il y a non nc index, non? Pouvez-vous poster le plan de requête pour les deux déclarations? C'est un joli défi.
"Chaque secteur fonctionne sur une autre clé primaire", même si ce n'est pas le cas, et même si la serrure se heurte à la collision de l'impasse.
Merci. Il n'y a pas d'index NC. Pas de déclenchement ni vue indexée. Je n'ai pas encore de réputation de poster une image (pour le plan de requête). Mais le premier (sélectionnez ... pour la mise à jour) est une "recherche d'index en cluster". Ce dernier (mise à jour où) est une "mise à jour de l'index en cluster". J'ai exclu "Lock Hash collier" en interrogeant "%% Lockres %%" et "ayant le nombre (%% Lockres %%)> 1".
Pourquoi certaines des transactions ont-elles
Trancount = "2" . Peut-être que vous avez mal estimé les transactions afin qu'elles soient étendues? Cela expliquerait pourquoi plusieurs serrures peuvent être prises par voie trans. Iow un bug d'applications. Ajoutez cecisi @@ Trancount <> 1 Rollback pour affirmer cela au moment de l'exécution. Remercier votre test de charge avec cet affirmation.Y a-t-il des conversions implicites? Je sais qu'il y en a parce que vous passez dans un
nvarchars (4000) mais les colonnes PK ne peuvent pas avoir une telle colonne. Cela peut entraîner des serrures de gamme. Modifiez la mise à jour de@ p2 àconvert (correction_column_type_here, @ p2) pour vous assurer. Examinez le plan d'exécution pour vous assurer que la recherche de CI n'utilise que des prédicats d'égalité. Pas gammes. Nous voulons une recherche de singleton.Depuis les images, je peux voir que je peux voir des incompatibles de conversion pour la date et le col de cordes. Je vous suggère d'essayer de les réparer et de faire rapport. Ajoutez également la transaction imbriquée affirmée.
Ce n'est pas vraiment une question de programmation. Je sens que cela va mieux sur dba.stackexchange.com Ils ont également beaucoup de personnes intelligentes qui peuvent aider exactement ce type de choses . Meta: Meta. stackexchange.com/questions/172516/... meta.stackexchange.com/questions/201695/...
Merci. Je pense que la "inadéquation de conversion" est vraiment sur quelque chose. Il explique la serrure de la plage. J'utiliserai le profileur SQL pour capturer le plan d'exécution capturé à partir de mon programme de test de chargement Java. A propos de l'affirmation du "Tranacount", ce n'est peut-être pas aussi facile, car tous les SQLS crachent de Java et de Hibernate. Mais j'ai besoin d'inspecter plus loin.
Hibernate vous permet d'exécuter également des énoncés manuels SQL (séparément). Cela devrait fonctionner.; Si vous obtenez vraiment une gamme Scan sur la colonne String, cela signifierait que la requête ignore complètement le filtre à la colonne Date à partir d'une perspective de verrouillage.
J'ai ajouté "Edit 3", ce qui télécharge le plan d'exécution. Une colonne est modifiée en une plage de «Rechercher des prédicats» en raison de la conversion implicite. Cela indique-t-il une analyse de gamme? Cependant, il montre toujours "la recherche d'index en cluster"?