Discussion :

[juvamine]

Bonjour à tous,

Sur une base de données client, nous effectuons des traitements de nuit qui peuvent être assez long (plusieurs heures). C'est en faite 8 procédures SQL que l'on exécute les unes après les autres...
Le problème est que le temps de traitement est très très inconstant. Une procédure va mettre 0h23 un jour, et le lendemain 8h00. Alors que le volume de données à traiter est sensiblement équivalent.
De quelles solutions je dispose pour analyser les raisons de cette inconstance ? Puis-je récupérer d'éventuels verrous après coup ?

D'autre part, nous faisons une sauvegarde du fichier de transaction toutes les heures. Ceci peut-il gêner l'exécution des procédures.

Merci de votre aide
juva

[zinzineti]

Ce billet peut t'aider à identifier la source du lenteur

A+

[Ptit_Dje]

Hello,

Avez vous une certaine recurrence dans les jours ou la lenteur est constatee ?
Quels sont les autres jobs tournants au meme moment que vos batchs de nuit ? Y a t'il une activite speciale les jours de lenteur sur vos serveurs ?
Quelle difference entre ces jobs (l'ensemble) constatez vous entre les jours ou c'est "normal" et les jours ou c'est lent ? Y a t'il des overlaps ? Des differences de perfs generales ?

Peut etre un re-scheduling peut convenir a votre probleme...

[SQLpro]

Si le volume et la nature des données est similaire, il y a fort à parier que c'est un problème général d'indexation et de recalcul des stats.

A quelle fréquence défragmentez vous (ou reconstruisez vous) les index ?
A quelle fréquence recalculez vous les statistiques ?

En principe cela devrait être fait une fois par jour !

Il peut néanmoins y avoir d'autres causes comme des verrous voire des deadlocks. Mais dans ce cas, soit le traitement ne s'effectuerais pas, soit vous auriez des message d'erreur !

A +

[juvamine]

Actuellement ce n'est pas fait par job, mais par un exe indépendant.

Rien ne tourne sur le serveur pendant la nuit (hormis un job de backup du journal de transaction)

Les index sont reconstruit, environ 20 minutes avant ce traitement
avec la requete suivante:

Code SQL :

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

1
2
3
4
5
6
7
8
SELECT @SCRIPT = @SCRIPT + 'ALTER INDEX [' + IDX.NAME + '] ON [' + SCH.NAME + '].[' + OBJ.NAME + '] REBUILD PARTITION = ALL WITH ' + 
							' ( PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, ALLOW_ROW_LOCKS = ON, ' + 
							' ALLOW_PAGE_LOCKS = ON, ONLINE = OFF, SORT_IN_TEMPDB = OFF );' + CHAR(13)
	FROM SYS.INDEX_COLUMNS IDXC 
	INNER JOIN SYS.OBJECTS OBJ ON IDXC.OBJECT_ID = OBJ.OBJECT_ID 
	INNER JOIN SYS.SCHEMAS SCH ON SCH.SCHEMA_ID = OBJ.SCHEMA_ID 
	INNER JOIN SYS.INDEXES IDX ON (IDXC.OBJECT_ID = IDX.OBJECT_ID AND IDXC.INDEX_ID = IDX.INDEX_ID)
	WHERE OBJ.TYPE IN ('U', 'V') AND IS_MS_SHIPPED <> 1

et on execute ensuite ce qu'il y a dans @SCRIPT

Que le traitement mette du temps, ça ne me dérange pas + que ça...Mais qu'il passe de 4h à 8h puis revienne à 4h est plus surprenant...

Merci à zinzineti je vais tenter d'étudier ton billet.

[mikedavem]

Humm cela ne m'étonne pas si vous reconstruisez l'ensemble de vos index de cette façon. (Quelle est la volumétrie de vos index, le nombre, gérez vous des index partitionnés etc ... ?)

La reconstruction hors ligne pose des verrous sur les tables concernées qui peuvent empêcher toute opération sur les tables le temps de la reconstruction.

D'autre part si j'ai bien compris vous lancez un traitement de nuit en parallèle (8 procédure stockées) qui peuvent également générer leurs propres verrous ..

Il faudrait revoir votre stratégie de maintenance des index à mon avis ...

++

[SQLpro]

Le script est déjà pas bon pour 2 raisons :
1) les tables systèmes sont en minuscule. Si la base est en collation CS alors cele va générer une erreur et rien faire
2) comme vous intégré la table sys.index_columns, cela va générer autant de rebuild identiques qu'il y a de colonne dans la clef d'index

En sus, comme vous défragmentez tous les index sans penser à regarder s'ils sont fragmentés, alors vous faites du travail pour rien, mais qui prend du temps.

D'ailleurs ce pourrait être cela qui gène : la fait que cette réindexation ne soit pas terminée lorsque vous lancer le job de recalcul.

Au lieu de réinventer la roue, utilisez les procédures déjà mis au point, telle que celle-ci :
http://sqlpro.developpez.com/optimis...ntenanceIndex/
http://blog.developpez.com/sqlpro/p8...es-index-et-s/
http://blog.developpez.com/sqlpro/p8...-des-statisti/

A +