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

* 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.

Citation:

---

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

Citation:

---

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

Citation:

---

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...

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...

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.

Citation:

---

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...

Citation:

---

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.

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.

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

Citation:

---

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...

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:

---

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...

Citation:

---

Je garde que l'indexe par défaut celui de la clé primaire

---

Quelle est justement c'est PK? sur quelle colonne pointe t'elle?

ESt-elle définit comme cluster de la table?

Il nous manque beaucoup d'infos:

• Est-ce une base en production (sollicité pendant l'update)
• DDL de la table
• Texte de la requète de mise à jour
• Statistics (IO et time)
• Plan d'execution
• Wait stats pendant l'execution...