Discussion :

[gaultier]

Bonjour

Je me permet de vous solliciter pour essayer de régler de gros problème de performance sur une application éditeur utilisant la replication native sql server.

L'éditeur n'arrive pas à nous aider car nous sommes monter en charge plus vite que lui. Les problèmes que nous rencontrons sont inconnus chez eux.

Petit topo : A été mis en place une fusion Filtré, nous avons environ 180 abonnés tous en windows 2008 R2.

Nous rencontrons beaucoup de lenteur en général.

Mais l'un des problèmes qui embête le plus notre équipe qui suit cette application est que nous n'arrivons plus à voir le pending global du parc d'abonnés.
Ce calcul prend des heures et des heures !!

En faisant un analyse du plan d'execution de la procédure sp_showpendingchange d'un poste, Sqlserver me conseille de créé l'index suivant :

Code :

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

1
2
3
4
5
6
 
GO
CREATE NONCLUSTERED INDEX [<Name of Missing Index, sysname,>]
ON [dbo].[MSmerge_current_partition_mappings] ([partition_id])
INCLUDE ([rowguid])
GO

Puis je le créer en risque ?

Cet index ressort aussi dans la requête suivante sur les index manquants :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
SELECT CONVERT (decimal( 18, 2), user_seeks * avg_total_user_cost * (avg_user_impact * 0.01 )) AS [index_advantage], 
migs.last_user_seek , mid.[statement] AS [Database.Schema.Table] ,
mid.equality_columns , mid.inequality_columns , mid.included_columns ,
migs.unique_compiles , migs.user_seeks , migs.avg_total_user_cost , migs.avg_user_impact
FROM sys .dm_db_missing_index_group_stats AS migs WITH (NOLOCK)
INNER JOIN sys .dm_db_missing_index_groups AS mig WITH (NOLOCK)
ON migs .group_handle = mig.index_group_handle
INNER JOIN sys .dm_db_missing_index_details AS mid WITH (NOLOCK)
ON mig .index_handle = mid.index_handle
ORDER BY user_seeks DESC OPTION (RECOMPILE);

Merci d'avance pour votre aide.

[SQLpro]

De toute façons, oui, créer un index va améliorer les choses....
CONSEIL : nommez le de façon particulière (par exeple avec le nom de l'auteur dedans) et avec la date dans le nom. Vous pourrez ensuite savoir s'il a été réellement utilisé.
Aidez vous aussi de la DMV sys.dm_db_missing_index_details (mais mutualisez leur création).

MAIS...

je ne comprends pas pourquoi vous avez 180 réplications ! Pour moi c'est de la folie furieuse et je pense que vous êtes partit sur une mauvaise architecture. Il existe d'autres solutions.

Décrivez le cahier des charges qui vous a conduit à utiliser 180 bases et donc, je le suppose sur 180 serveurs différents.

Décrivez votre architecture actuelle.

Nous pourrons alors vous aider !

A +

[gaultier]

Bonjour

Merci pour ce retour.

Voici un bref topo de l'architecture :

1 Serveur BDD qui fait à la fois Distribution et Publication.
1 Serveur IIS qui fait frontal Web.
Plus de 180 postes nomade abonnés (portable de commerciaux sur le terrain) qui se répliquent par le biais du IIS en https

La réplication mise en place est une réplication de fusion filtrée.

Pour aggraver encore les choses, le métier nous a imposé une rétention de 24 jours !!!!

Bonne journée

[SQLpro]

Je voit deux écueils à votre système :
1) pourquoi une réplication de fusion ? Vous allez immanquablement avoir des conflits de réplication. Dans un cadre de postes nomades on identifie des flux simplex, rarement full duplex !
2) pourquoi via IIS ? c'est plus rapide, plus simple et plus sécurisé de le faire directement de base à base...

Plus vous allez avoir de postes nomades, plus votre système va se bloquer, jusqu'à devenir inexploitable !

A +