SQL de mise à Jour est vraiment très lent (environ 20-50sec), Sélectionnez prend moins de 1 seconde

J'ai un SQL Tabe "Document" qui contient beaucoup de lignes (jusqu'à quelques millions de dollars).

Quand je suis à l'exécution d'un Select-Déclaration, il faut environ 0,5 seconde.
Mais quand je suis à l'exécution d'une mise à Jour avec la même clause where, il faut environ 20 à 50 secondes, en fonction de la quantité de lignes affectées.

Voici mes Relevés.

//Select

SELECT * FROM Document 
WHERE (State=20 OR State=23) AND 
LetterClosed IS NOT NULL AND 
TYPE=0 AND
SendLetter=1

//Mise à jour

UPDATE Document set State=32 
WHERE (State=20 OR State=23) AND 
LetterClosed IS NOT NULL AND 
TYPE=0 AND
SendLetter=1

L'OU-Mappeur en interne envoyer cette mise à jour-déclaration suivie de la base de données:

exec sp_executesql N'Update
Document
SET
    State=@p4
WHERE
(
  (
    (
      (Document.State = @p0 OR Document.State = @p1) 
      AND Document.LetterClosed IS NOT NULL
    ) 
    AND Document.Type = @p2
  ) 
  AND Document.SendLetter = @p3
)'
,N'@p0 int,@p1 int,@p2 int,@p3 bit,@p4 int',@p0=20,@p1=23,@p2=0,@p3=1,@p4=32

Le problème, c'est que je reçois un Délai d'Exception au bout de 30 secondes de mon LightSpeed(OU de Base de données-Mappeur en c#).

Quelqu'un pourrait-il m'aider?

Edit:

Et ce sont nos indices créés automatiquement par SQL-Server:

CREATE NONCLUSTERED INDEX [_dta_index_Document_9_133575514__K42_1_2_3_4_5_6_7_8_9_11_12_13_14_15_16_17_18_19_20_21_22_23_24_25_26_27_28_29_30_31_32_33_34_] ON [Document] 
(
[State] ASC
)
INCLUDE ( 
[Id],[DocumentId],[SendLetter],[SendFax],[Archive],[Crm],[Validation],[CreationDate],[PageCount],
[InformationLetter],[TermsOfDelivery],[DeliveryTypeNo],[SeparateDelivery],[FormName],[FormDescription],[TemplateFileName],[RecipientType],
[HealthInsuranceNo],[FamilyHealthInsuranceNo],[PensionInsuranceNo],[EmployerCompanyNo],[RecipientName1],[RecipientName2],[RecipientName3],
[RecipientStreet],[RecipientCountryCode],[RecipientZipCode],[RecipientCity],[RecipientFaxNo],[AuthorId],
[AuthorName],[AuthorEmailAddress],[CostcenterDepartment],[CostcenterDescription],[MandatorNo],[MandatorName],[ControllerId],
[ControllerName],[EditorId],[EditorName],[StateFax],[Editable],[LetterClosedDate],[JobId],[DeliveryId],[DocumentIdExternal],[JobGroupIdExternal],
[GcosyInformed]) WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]
go
CREATE NONCLUSTERED INDEX [_dta_index_Document_9_133575514__K2_1_46] ON [Document] 
(
[DocumentId] ASC
)
INCLUDE ( [Id],
[JobId]) WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]
go
CREATE NONCLUSTERED INDEX [_dta_index_Document_9_133575514__K46_K2] ON [Document] 
(
[JobId] ASC,
[DocumentId] ASC
)WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]
go
CREATE NONCLUSTERED INDEX [Document_State_Id] ON [Document] 
(
[State] ASC,
[Id] ASC
)WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]
go
CREATE NONCLUSTERED INDEX [Document_State_CreationDate] ON [Document] 
(
[State] ASC,
[CreationDate] ASC
)WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]
go

Edit 2:
Maintenant, j'ai une exécution graphique-plan :
L'exécution du plan: https://skydrive.live.com/redir?resid=597F6CF1AB696567!444&authkey=!ABq72SAWXOoAXfI

L'exécution du plan de l'Indice de détails mise à Jour: https://skydrive.live.com/?cid=597f6cf1ab696567&id=597F6CF1AB696567%21445&sff=1&authkey=!ADDPWvxB2JLLvWo

Ce SQL-mise à Jour a été d'environ 35 secondes à s'exécuter. Habituellement, cette mise à Jour ne prend que de 0,3 secondes. Il semble qu'un autre processus bloqué. J'ai vu quelques autres sélectionne qui a commencé au milieu de cette mise à jour et j'ai attendu jusqu'à la mise à jour a été achevée qu'ils ont fini de là, sélectionnez-exécution.

Il semble donc que l'indice lui-même est correct (généralement de 0,3 sec exécution).
Tous les sélectionne (à partir de java/jtds, php, .net) sont le niveau d'isolation read committed (par défaut). Serait-il m'aider à changer tous les sélectionne read uncommitted pour éviter ce blocage lors de l'indice de mise à jour?

Merci
Tobi

OriginalL'auteur Tobias Koller | 2013-01-11