le composant Merge join demande un composant de tri ou alors des données déjà triés.
Il est possible de ne pas utiliser le composant tri avec deux methodes:

1. Le composant d'extraction OleDb procède une propriété (voir les propriétés de "OleDb source Output" dans l'éditeur avancé, onglet propriété d'entrée ou de sortie)
   Passez le paramètre IsSorted à True.
2. Il est aussi possible de forcer le flag de sortie de chaque composant de lecture (requete SQL contenant un order by) à 1

Vous le savez sans doute deja, mais chaque outil de SQL Serveur 2005 à son propre mode de deployement, je me suis donc attaché à trouver un mode pour chacun. Dans le cadre ou je souhaite laisser un livrable pret à installer par mon client ou mon service d'exploitation.
Très vite on trouvera le generateur de "deployement manifest" de SSIS ainsi que les fichier de publication de SSAS à utiliser avec l'assitant de deployement.
Pour SSRS ce point est bien plus complexe.
Les choix qui s'offre à nous :
- Deploiement via Visual Studio
- Deplacement des fichiers RDL
...
Après quelques recherche je suis tomber sur le pilotage de l'application RS.exe via un fichier RSS.
il nous faut donc plusieurs elements pour effectuer un livraison avec ce mode
1 Fichier .RSS
1 Fichier .Bat (pour lancer le tout)
x fichiers .Rdl

l'utilisation de l'option "Fast Parse" du composant "Flat File" ou Fichier plat permet de gagner en performance de lecture des fichiers:
Voir les paramètres avancés du composant "Flat File" dans l'onglet proprietes> Parametrès des input/output> passer l'option Fast Parse à True.

Test de performance Par Mladen Prajdić
http://weblogs.sqlteam.com/mladenp/archive/2006/07/17/10634.aspx
Pour aller plus loin l'auteur de ce blog à utilisé les options Tablock pour gagner en performance mais dans ce cadre nous n'utilisons plus les standards de SSIS.

Afin de permettre aux packages SSIS d'être portables sous différents environnements sans avoir à re-parametrer l'ensemble des composants (je vous rappelle qu'un environnement de production ne contient pas visual studio... :) ) il est nécessaire d'utiliser un fichier de configuration.
mon choix est le fichier de configuration XML,
1- Plus flexible, il permet aux administrateurs de paramétrer les variables des différents environnements sans pour autant connaître SSIS,SQL serveur.
2- Lors de l'installation via le "Deployement manifest" il est possible d'éditer directement les configurations
3- Les paramètres gérés par ce fichiers sont sélectionnés manuellement


Tutorial:

• http://vyaskn.tripod.com/sql_server_2005_making_ssis_packages_portable.htm
• http://social.msdn.microsoft.com/Forums/en-US/sqldocumentation/thread/4982759f-29a9-4554-b44e-72b46cd52b83
• http://www.sqlis.com/post/Easy-Package-Configuration.aspx
  

Best practices:

• Sélectionner uniquement les données variables d'un environnement à un autre, nom de serveur,
• Utiliser un fichier par source de données (dans le cas ou vous avez plusieurs packages, ils ne portent pas tous les même sources)
  

Dans ce post nous allons donc parler de versionning:

Definition:

nous n'utiliserons pas SourceSafe puisque nous avons deja un serveur Subversion en place.

Après quelques recherches et un test, 2 produits semblent interressant VisualSVN et AnkhSVN.
VisualSVN est payant (environ 50$ la licence) alors que AnkhSVN est gratuit mais en cours de developpement pour le module Visual Studio 2005 et 2008.

Après quelques jours de test, la version actuelle de AnkhSVN(dev) n'est pas encore assez stable (la version stable n'etant pas compatible avec la derniere version de SUBVERSION) alors que VisualSVN est stable. le site de VisualSVN propose une documentation simple et pragmatique sur les cas d'utilisation de l'application.

Integration de Subversion avec VisualStudio avec l'add-on VisualSVN ou AnkhSVN
Tutoriel: http://www.devx.com/codemag/Article/38974/0/page/1
VisualSVN: http://www.visualsvn.com/visualsvn/download/
AnkhSVN: http://ankhsvn.open.collab.net/

1. Utiliser le bon "Protection Level", Pourquoi utiliser vous ce mode ? J'ai vu beaucoup de développeurs ne pas regarder ce paramètre alors que sa fonction est vitale pour travailler en équipe ou pour déployer sont travail.
2. Utiliser un fichier de configuration pour L'ensemble des données variables des Packages.
   Sources,Destinations, noms des serveurs...(1 par sources afin de les reutiliser dans plusieurs Packages)
3. Utiliser les transactions pour gerer l'arret des chargements en cas d'echec sans pour autant etre obliger de recharger l'ensemble des données
4. Minimiser l'appel à des programmes externes. fichiers Bat,Cmd...
5. Minimiser l'appel à des procedures stockées.(j'ai reussit beaucoup de projets sans!)
6. Découper vos flux en arborecence de packages (1 Flux = 1 Package, 1 Dimension = 1 Package)
7. Auditer les actions de vos ETL (voir methode Kimball)
8. Pourquoi ne pas utiliser les bonnes pratiques du developpement logiciel (XP, SVN...)

Sur SQLCAT:
http://sqlcat.com/top10lists/archive/2008/10/01/top-10-sql-server-integration-services-best-practices.aspx
le blog de Matthew Roche:
http://bi-polar23.blogspot.com/2007/11/ssis-best-practices-part-2.html

Apres deux années passées à gérer une base de KM et des formations autour des technologies Microsoft, l’ouverture de ce blog va me permettre de partager avec vous mes expériences sur les technologies SQL serveur 2005 et 2008. L’objet principal et d’ouvrir des débats sur
- Les meilleures pratiques
- L’architecture des systèmes
- La gestion de projet