Discussion :

[krousty]

Bonjour,
J’ai un problème assez aléatoire avec le rebuild des index sur une BD sur un serveur abonnés . L’étape se plante de temps en temps avec le message suivant

« L'exécution de la requête « ALTER INDEX XXXX ] ON [dbo].[X... » a échoué avec l'erreur suivante : « La transaction (ID de processus 61) a été bloquée sur les ressources verrou par un autre processus et a été choisie comme victime »

J’ai donc essayé, ds mon plan de maintenance de récupérer des infos avec les requêtes suivantes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
SELECT  L.request_session_id AS SPID, DB_NAME(L.resource_database_id) AS DatabaseName,
					O.Name AS LockedObjectName, 
					P.object_id AS LockedObjectId, 
					L.resource_type AS LockedResource, 
					L.request_mode AS LockType,
					ST.text AS SqlStatementText,        
					ES.login_name AS LoginName,
					ES.host_name AS HostName,
					TST.is_user_transaction as IsUserTransaction,
					AT.name as TransactionName,
					CN.auth_scheme as AuthenticationMethod
FROM    sys.dm_tran_locks L
					JOIN sys.partitions P ON P.hobt_id = L.resource_associated_entity_id
					JOIN sys.objects O ON O.object_id = P.object_id
					JOIN sys.dm_exec_sessions ES ON ES.session_id = L.request_session_id
					JOIN sys.dm_tran_session_transactions TST ON ES.session_id = TST.session_id
					JOIN sys.dm_tran_active_transactions AT ON TST.transaction_id = AT.transaction_id
					JOIN sys.dm_exec_connections CN ON CN.session_id = ES.session_id
					CROSS APPLY sys.dm_exec_sql_text(CN.most_recent_sql_handle) AS ST
WHERE   resource_database_id = db_id()
ORDER BY L.request_session_id

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select session_id, blocking_session_id from sys.dm_exec_requests where blocking_session_id != 0

(Après avoir activer les traces)
mais ça ne me revoie rien :/
D’ailleurs cette tâche a-t-elle un réel intérêt si elle s’effectue auparavant sur le distributeur ? il me semble que les index sont aussi répliqué ? Non ?

Cordialement,

[WOLO Laurent]

Vous devez planifier la recreation des index pendant les intervalles de temps ou les donnees ne sont pas repliquees par vers les abonnees !
Ca ne sert a rien de monitorer puis que tu as definis les periodes de battements lors de la configuration de la replication transactionnelle.

[krousty]

Bonjour,
Merci pour la piste.
Il n'y avait pas de plage de prévu pour la maintenance ..
J'en ai donc mis une en place mais sans résultat , c'est toujours aléatoire.
Cordialement,

[WOLO Laurent]

Non, nous ne parlons pas de la meme chose.
Dans la replication, tu as deux synchronisations :
Celle qui raffraichit le distributeur et une autre qui raffraichie l'abonne.

Ton plan de maintenance concerne le distributeur ou l'abonne ?

[dbaffaleuf]

il me semble que les index sont aussi répliqué ? Non ?

Non les reconstructions d'indexes ne sont pas répliquées. Il faut le faire sur le publisher et sur le subscriber. Par exemple, l'index pourrait ne pas exister sur le subscriber et faire tomber le distributeur si ALTER INDEX REBUILD était répliqué. Un autre avantage est que ça permet de remettre à jour les stats sur le subscriber de la même façon que sur le publisher.

[krousty]

Ton plan de maintenance concerne le distributeur ou l'abonne ?

Mon plan de maintenance concerne l'abonné .

Merci pour l'info dbaffaleuf.

je vais revoir ce soir la théorie sur la réplication je pense ce soir...

[dbaffaleuf]

En plus de MSDN, qq bonnes ressources sur le sujet:

- http://www.replicationanswers.com/
- http://blogs.msdn.com/b/repltalk/

[WOLO Laurent]

Vous pouvez verifier le planning des intervals de synchronisation en faisnt un clique droit sur les abonnements (Dossier replication), puis cliquer sur Historique du Job.