Discussion :

[dream_rachid]

On travaille depuis deux années sur le datwarehouse dans le métier du Retail , comme vous le saviez , dans ce domaine la performance et la gestion de la volumétrie de données est le plus grand challenge à gagner

Pour atteindre cet objectif nous avons configuré deux gros serveurs en cluster pour contenir la base de données (32 GO de Ram , 1 TO d’espace disque pour le data et 100 GO pour le LOG) et nous avons opter pour la version 2008 de SQLSERVER en 64 B.

Nous souffrons actuellement des problèmes liés à la performance : nos packages dures des longes heures et saturent le système ( par exemple un seule module (appro) durent plus de 4 heures)

J’ai fait un tour sur les forums et les blogs spécialisés dans MS BI et j’ai essayé de faire des tests et ci-après les résultats :

Source : TABLE COMMANDES Seulement l’année 2010 : 36 000 000 de lignes
Destination : TABLES FACT_CMD Depuis 2007 : 120 000 000 de lignes

1ère Tentative :
Détecter les mises à jours en utilisant le Composant LOOKUP  Résultat : Erreur des saturation de mémoire ( enivrent 4 GO de Ram pour 5 Millions de lignes)
2ème Tentative :
Détecter les mises à jours en utilisant le Composant MERGEJION  Résultat : Erreur des saturation de mémoire
3ème Tentative
Instruction MERGE : Saturation du système ( CPU à 100 %) et un fichier log volumineux malgré que la base est en mode BULKINSERT
4ème Tentative :
Jointure de données en utilisant l’instruction Select avec LEFT OUTER JOIN DWH à jour , temps de traitement acceptable
- Mise à jour en insert OK
- Mise à jour en update  très lente en utilisant le composant OLDB COMMAND  Solution utilisée l’instruction UPDATE SET … WHERE SOURCE INNER JOIN DESTINATION WHERE Condition de jointure
- Mise à jour en delete : actuellement j’utilise MERGE (mais j’essaye de voir d’autre solution)


Merci de me communiquer vos commentaires :

- Quel est la méthode la plus optimale pour charger un DHW (volumineux) en mode incrémental ??!
- Comment détecter « que » les mises à jour de J-1 à partir de la PROD sachant que dans les tables sources aucun mouchard n’est configuré ?
- Est-ce que c’est déconseillé d’utiliser les composants SSIS dans une base de données trop volumineuse et les remplacer par des instructions SQL

[asaintraymond]

En attendant les réponses de plus experts que moi , d'après cet article trouvé ici-même :
http://patriceharel.developpez.com/t...sis-composant/
Ca devrait être le Lookup la méthode la plus performante pour détecter les mises à jour (par rapport au MERGE).
Tu as un message de dépassement de 4 gigas de RAM, ton serveur n'en a pas plus ou bien SSIS n'en utilise que 4 ?
Si le serveur n'a que 4 gigas ça me parait assez peu.

Sur les temps de mises à jour update et insert, une méthode pour accélerer les temps de traitement est de supprimer les clés étrangères de la table de faits, mais peut-être l'as-tu déjà fait.

[dream_rachid]

Notre serveur du DWH est de 32 GO de RAM avec 2 CPU en DUAL QUAD XEON,néanmoins, on atteint la saturation du serveur si on utilise le composant de LOOKUP.
j'ai bien spécifié que ce composant utilise presque 4 GO de RAM pour 5 millions de ligne.

[Jinroh77]

Si le composant est en mode Full Cache il va effectivement charger l'intégralité de la requête en mémoire.
Dans votre Lookup avez-vous une requête utilisant uniquement les champs dont vous avez besoin ou directement l'interrogation d'une table ? (vous gagnerez beaucoup d'utilisation mémoire comme cela).

Comment déclenchez-vous les packages ?
Vos process tournent-ils alors bien en x64 ? Vous pouvez alors utiliser bien plus que les 4Go de saturation, ce qui est bizarre...

[dream_rachid]

Merci pour vos réponses :

- oui , le composant est en Full cache , et si je vais modifier cette option ça peut affecter la performance ( d'après MSDN)

- oui , dans le Lookup j'utilise que les champs dont j'ai besoin : je procède toujours à une requête select


- "Comment déclenchez-vous les packages ?" : en Utilisant l'agent SQL

- Non, Malheureusement les process tournent en 32 bit nous avons un problème de driver pour Oracle 64 bit car le MS OLE DB for oracle est dispo que pour la version 32 bit malgré qu'on a essayé avec le Oracle OLE DB mais on n'a pas arrivé à se connecter à la source (BASE ORACLE 11 G sous Unix)

pour l'histoire du 4 GO :d , j'ai mentionné qu'un exemple 4 GO pour 5 millionsde lignes un simple calcul ça fait 24 GO de ram pour 32 Millions de lignes !!!!
( j'ai stoppé l'exécution car j'étais sure qu'il va finir par saturer le système)

[asaintraymond]

En fait pourquoi as-tu besoin de faire un test de modif sur l'ensemble des lignes de ta table de faits ?

En théorie en incrémental on ne devrait faire que de l'insertion.
Alors peut-être qu'il arrive qu'il y ait des modifs, mais ça doit quand même être limité dans le temps (genre 1 mois max).
Tu ne peux pas faire tes contrôles uniquement sur une période d'un mois ?