Dégradation de la performance SQL pour les tables contenant plusieurs colonnes

**hackeddb** · 27/03/2013, 16h56

* Bonjour, *

j'ai un soucie avec un traitement de chargement de données dans SQL Server 2008.
Le problème est le suivant: j'ai une table qui contient 118 colonnes (type nvarchar + numeric ...)
au niveau de la sélection il n'y a aucun problème de perf
par contre quand je lance une opération de mise à jour j'ai un vrai problème de performance
en gros pour updater la table avec 1 millions d'enregistrements il me faut 7 heurs ce qui est trop

j'ai pensé à splitter la table mais cela impacte plusieurs process déjà développer. et ça n'a pas de sens en modélisation.

avez vous des suggestions svp?

Merci d'avance pour votre aide.

**aieeeuuuuu** · 27/03/2013, 17h03

Envoyé par hackeddb

j'ai une table qui contient 118 colonnes (type nvarchar + numeric ...)

C'est beaucoup !
L'on peut penser que vous avez effectivement un problème de modélisation, mais sans la structure des tables, difficile à dire.

Dites en plus sur cette table, ce qu'elle contient,...Les types sont-t-ils adaptés ? (pas besoin de NVARCHAR là ou du VARCHAR suffit, pas besoin de NUMERIC là où du INT suffit,...)
et postez la DDL de la table en question

Envoyé par hackeddb

en gros pour updater la table avec 1 millions d'enregistrements il me faut 7 heurs

Vous pourriez désactiver les index avant cette mise à jour, et les reconstruire ensuite, mais là encore, sans connaitre le contexte, on ne peut pas trop détailler

Envoyé par hackeddb

mais cela impacte plusieurs process déjà développer

Vous pouvez réduire l'impact de votre changement de modèle en créant des vues...

**hackeddb** · 27/03/2013, 17h17

Merci pour le feedback aieeeuuuuu!

en faite c'est une table qui stocke les informations relatives à des individus.
A part les infos classiques (Nom,Prenom ,email ,adresse et tel...) il y a 50 colonnes en plus pour stocker des scores et des colonnes réservées pour des segmentations et de la géolocalisation ...

Il y a plusieurs colonnes qui peuvent être déclarées en VRACHAR alors qu'elles sont actuellement déclarées en NVARCHAR.

Déjà cela permettra de réduire la taille de chaque ligne dans les pages SQL mais bon ce n'est pas grande chose au final...

**hackeddb** · 27/03/2013, 17h26

Concernant la désactivation des index c'est déjà fait.
Je garde que l'indexe par défaut celui de la clé primaire. ==> toujours 7 heurs de MAJ
La taille de cette table est de 30 millions d'enregistrements.
sachant que la base est hébergée sur un serveur dédié Dell PowerEdge T610 de 8 cores et 16 Go de RAM ...

Merci encore.

**Donpi** · 27/03/2013, 17h30

Envoyé par hackeddb

j'ai pensé à splitter la table mais cela impacte plusieurs process déjà développer. et ça n'a pas de sens en modélisation.

(juste une parenthèse)

Je pense au contraire qu'il y a un nœud dans la modélisation. Difficile d'imaginer 118 colonnes pour définir un seul "Sujet". A cette taille ça ressemble plus a une de ces tables obèses qui évoluent sur plusieurs années et ou les développeur ajoutent des colonnes sans se soucier de la performance a long terme...

**fsmrel** · 27/03/2013, 17h38

Envoyé par hackeddb

ça n'a pas de sens en modélisation

Si la table en cause ne respecte pas la 3e forme normale, alors du point de vue de la modélisation elle est peccamineuse.

**hackeddb** · 27/03/2013, 17h48

en fait c'est une table qui vient d'un datawarhouse fait avec l'approche data-vault.
Cette table se trouve dans un datamart qui est l'agrégation des hub-satellites liés à aux individus.

en gros cette table va être exploiter par des analystes qui n'ont pas forcément des connaissances en SQL...

Cordialement,
hackeddb.

**Jean.Cri1** · 27/03/2013, 17h59

et en quoi consiste l'update ?
à defaut de spliter la table on peut peut etre splitter l'update ...

**aieeeuuuuu** · 27/03/2013, 18h17

Envoyé par hackeddb

Concernant la désactivation des index c'est déjà fait.
Je garde que l'indexe par défaut celui de la clé primaire. ==> toujours 7 heurs de MAJ

Il faut malgré tout s'assurer que certains index ne sont pas utiles à l'update.
Contrairement à une idée répandue, les index peuvent accélérer certaines opérations de mise à jour. Mais là encore, tout dépend des index et de la requête update...

**Babyneedle** · 27/03/2013, 18h21

Premièrement, il faut utiliser les bon outils.

Pour ma part, dès que j'ai un problème de performance, j'inspecte le plan d'exécution. Tu n'as pas à connaitre toutes les parties mais au moins les éléments de base. En bonus, le système va même te suggérer des index s'il en manque.

Autre chose à vérifier sont:

- Le niveau de FILLFACTOR (pour un environnement BI, il devrait être à 100).
- La fragmentation des index
- La mise à jour des statistiques de la table
- La présence ou non de partitions.

Un autre outil intéressant, les statistiques d'éxécution.

Code :

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

1
2
SET STATISTICS IO ON
SET STATISTICS TIME ON

Tu vas peut-être te rendre compte que le bottleneck est au niveau de la mémoire ou bien du disque.

Pour ce qui est de la structure, j'ajouterais aux précédentes interventions qu'il serait bien de vérifier le pourcentage de valeurs nulles ou par défaut dans les colonnes 'secondaires'. Cela peut grandement influencer la capacité du moteur à composer un plan d'exécution efficace...