J'aimerais connaître la différence entre SSDT dans Visual Studio et Integration Services dans SQL Server. Lorsque je développe un paquet SSIS localement en utilisant SSDT dans VS, je peux passer des données à mon serveur SQL local sans que Integration Services soit installé dans l'instance de SQL Server. Je me demande si j'ai besoin de Integration Services pour permettre la communication entre les serveurs. Disons que la base de données du serveur SQL se trouve sur un serveur et le paquet .dtsx sur un autre.
Réponses
Trop de publicités?
J Weezy
Points
1388
C'est là que le département marketing de Microsoft s'est emballé. Il est important de comprendre que Microsoft n'est pas une société qui écrit du code. Microsoft est une société de marketing qui écrit du code.
La réponse simple est que SSDT est un ensemble de modèles de projets pour ce qui est censé être de la Business Intelligence.
SSDT contient trois types de modèles :
- SSIS : Services d'intégration
- SSRS : Reporting Services
- SSAS : Services d'analyse
UPDATE
Je n'ai pas répondu à la question de la gestion des paquets. Fondamentalement, vous pouvez exécuter n'importe quel paquet SSDT contre le serveur SQL dans Visual Studio. Cependant, si vous voulez déployer les paquets SSDT sur le serveur SQL, vous devez avoir installé ces services. Les services peuvent être installés via l'assistant d'installation de l'instance de SQL Server. Vous devrez tenir compte d'un autre concept épineux connu sous le nom de ciblage de la version du serveur SQL : Cliquez ici
Par exemple, si vous voulez déployer et exécuter des paquets SSIS sur le serveur SQL, vous devez installer les services d'intégration (y compris DTExec.exe et ISDeploymentWizard.exe). Vous devrez également installer SSISDB sur le serveur SQL afin de pouvoir déployer des packages SSIS sur le serveur SQL - cette opération s'effectue via SQL Server Management Studio (SSMS). Les paquets sont à la fois déployés et gérés à partir d'un dossier appelé Catalogue des services d'intégration . L'exécution des paquets peut ensuite être automatiquement planifiée via l'agent SQL Server. Il est très peu probable que vous travailliez un jour directement avec la SSIDB, si ce n'est pour lui demander des informations : voir ici .
Voir les instructions de Microsoft : cliquez ici
Les packages SSRS sont gérés par une interface Web distincte et je n'ai pas eu affaire aux packages SSAS. N'est-ce pas amusant ?
Une note sur DTExec.exe
J'ai rencontré des puristes qui dédaignent SSIS, en grande partie parce qu'ils ne le comprennent pas. L'argument général que je reçois est qu'il est plus lent que PowerShell ou les procédures stockées. Cela peut faire exploser la tête de quelqu'un.
Fondamentalement, PowerShell s'exécute par le biais du .NET Framework, qui est en C# et doit passer par quelques couches du système d'exploitation pour s'exécuter. Alors que les composants de SSIS sont écrits en C#, l'application DTExec.exe est écrite en C++, qui peut accéder directement aux ressources du système (C# ne peut pas le faire parce qu'il s'agit d'un code géré). Ainsi, SSIS va détrôner PowerShell et les procédures stockées dans les tâches importantes.
Les procédures stockées sont un animal différent, mais elles sont toujours plus lentes car elles n'ont pas de tampon de pipeline (c'est-à-dire d'onglet de flux de données). Une autre limitation majeure est la manière dont SQL Server exécute les procédures stockées, c'est-à-dire de manière séquentielle. Imaginons donc qu'un travail SSIS comparable soit divisé en plusieurs procédures stockées et que ces procédures soient appelées par une procédure stockée principale - une super procédure stockée pour ainsi dire. Le serveur SQL exécutera les procédures stockées de manière séquentielle, une par une, ce qui constitue un énorme goulot d'étranglement en termes de performances. Le pipeline tampon de SSIS élimine ce problème en traitant par défaut 10 000 lignes (ce chiffre est configurable) dans chaque tâche, puis en les transférant à la tâche suivante. Ainsi, nous pouvons considérer les tâches de flux de données comme leur propre procédure stockée.
Contexte supplémentaire
Il existe une confusion de longue date sur ce qui constitue SSIS en ce qui concerne Visual Studio mais pas nécessairement SQL Server.
- Avant 2005 : Il s'agissait de Data Transformation Services ( DTS )
- 2005 & 2008 : En 2005, DTS a été considérablement remanié et renommé SSIS à la fin du développement. C'est pourquoi tout dans SSIS fait encore référence à DTS (c'est-à-dire aux fichiers *.dtsx). C'est toujours le cas aujourd'hui. Bizarre, seul un masochiste aime les DTS. MAIS ! Le paquet de modèles a été renommé en Business Intelligence Development Studio ( BIDS )
- 2012 & 2013 : Il a été renommé en SSDT-BI . Apparemment, il y avait déjà un autre produit nommé SSDT
- 2015 et au-delà : Il s'appelle désormais SSDT
Voir la tentative de Microsoft d'expliquer la SSDT : cliquez ici
Jusqu'à Visual Studio 2017 (VS 2017), SSDT et ses diverses incarnations ont été largement traités comme le petit enfant idiot de Visual Studio. Je dis cela parce que VS était installé comme un produit autonome pour ces types de projets uniquement. Je ne sais pas pourquoi cela a été fait de cette façon - ma meilleure supposition est parce que SSDT est gratuit. Quoi qu'il en soit, si vous vouliez utiliser Visual Studio pour le développement d'autres applications, vous deviez installer une instance distincte de Visual Studio. Ainsi, nous, les développeurs, avons littéralement deux installations autonomes sur notre boîte de développement et nous devons utiliser l'installation spécifique pour ce que nous faisons (c'est-à-dire le développement SSDT ou non-SSDT).
Aujourd'hui, avec VS 2019, Microsoft se débarrasse de ce modèle et a enfin intégré le paquet SSDT dans le produit. Cependant, le déploiement initial de VS 2019 pour SSDT a été une comédie d'erreurs dès sa sortie de la boîte. Voir mon explication par en cliquant ici . En fait, SSIS n'est pas installé avec le paquetage et doit être ajouté séparément. Cependant, vous disposez toujours d'une instance de VS 2019. En outre, le fournisseur de données SQL11 a été déprécié. Et, cela aussi ne vient apparemment pas avec le paquet d'installation non plus et doit être installé séparément. Ainsi, tous les paquets existants qui l'utilisent devront être mis à niveau et redéployés (voir le problème connu n° 1).
J'attends pour l'instant la mise à niveau vers VS 2019. Le moins que l'on puisse dire, c'est que VS 2017 a été pénible. Personnellement, j'utilise toujours VS 2013 Update 5. Toutes les instances VS ciblent SQL Server 2014.
Hadi
Points
16319
En plus de la bonne réponse détaillée de @JWeezy, j'aimerais ajouter une brève explication :
Outils de données SQL Server pour Visual Studio sont l'environnement de développement de la suite de business intelligence SQL Server (SQL Server Integration Services, Reporting Services, Analysis Services).
Services d'intégration du serveur SQL (installé à partir de l'installation de SQL Server), installez tous les fichiers nécessaires à l'exécution des paquets SSIS sur la machine locale.
Les deux produits peuvent exécuter des paquets .dtsx mais le premier n'est destiné qu'au développement et aux tests tandis que le second est destiné aux serveurs de production.
Références
