Puis-je exporter un plan de maintenance sans utiliser Integration Services?


12

J'essaie d'exporter un plan de maintenance simple à partir d'une instance SQL Server.

Je souhaite vérifier l'exportation dans le contrôle de code source et appliquer le plan de maintenance exporté à des instances fonctionnellement identiques.

StackOverflow et SQL Server Newbie recommandent d'utiliser Integration Services pour exporter le plan de maintenance.

Lorsque j'essaie de me connecter à Integration Services sur la cible d'exportation, je reçois l'erreur suivante:

La connexion au service Integration Services sur l'ordinateur "WEBSERVER" a échoué avec l'erreur suivante: Le service spécifié n'existe pas en tant que service installé.

Nous avons choisi de désactiver Integration Services sur WEBSERVER car nous n'utilisons cette case que pour servir des données aux applications grand public. Toutes les données sur WEBSERVER sont répliquées à partir d'une instance d'arrière-plan. Integration Services est largement utilisé pour le traitement des données sur l'instance d'arrière-plan.

Existe-t-il un moyen documenté d'exporter un plan de maintenance sans utiliser Integration Services? Microsoft le prend-il en charge?

Réponses:


10

Les plans de maintenance sont stockés dans msdb.dbo.sysssispackages comme tout autre package SSIS stocké sur SQL Server. J'ai un article pratique sur l' extrait de package SSIS de MSDB qui devrait guérir ce qui vous fait mal.


Cela ne fonctionne que si vous avez SSIS entièrement installé, car dtutil- ce qui est construit autour - est fondamentalement désactivé sinon, même s'il est présent. Certaines versions de SQL Server (telles que Web Edition) n'autorisent pas l'installation complète de SSIS, même si les plans de maintenance utilisent essentiellement la quasi-totalité des fonctionnalités de SSIS. (Cependant, il existe un hack pour contourner cela, en supposant que vous avez deux versions de SQL Server, dont l'une n'est pas entravée - voir ma réponse ci-dessous.)
MikeBeaton

3

Il existe un moyen de le faire.

Supposons que, comme l'OP, vous disposez de deux instances SQL Server, dont une avec SSIS installée et l'autre non (probablement pas, par exemple s'il s'agit de SQL Server Web Edition).

Écrivez une procédure stockée qui copie les lignes du plan de maintenance utilisateur du serveur entravé sur le serveur non entravé. Les lignes pertinentes sont:

SELECT name 
FROM msdb.dbo.sysssispackages 
WHERE packagetype = 6

Vous devrez écrire ce SP pour qu'il supprime d'abord toutes les lignes avec des correspondances id, puis insère les dernières versions (ou approche similaire, par exemple, UPDATEcorrespondant à ids, puis INSERTmanquant à ids). Et vous devrez configurer un serveur lié d'un côté ou de l'autre, afin de pouvoir écrire du SQL qui s'adresse aux deux serveurs.

Voilà, vraiment, vous pouvez ensuite l'appeler régulièrement ... à partir d'un plan de maintenance, par exemple ... et sauvegarder tous les plans de maintenance du côté non entravé.

C'est un énorme hack, bien sûr, mais cela fonctionne réellement. (J'imagine qu'il est assez important que le numéro de version de SQL Server soit le même des deux côtés, pour que les données msdb.dbo.sysssispackagessoient aussi compatibles entre les différentes instances de serveur qu'elles semblent l'être.)

Bien sûr, vous pouvez toujours sauvegarder directement les lignes pertinentes de la table de base de données SSIS. Cela fonctionnerait de toute façon - comme une réponse complète à la question d'origine. Comme indiqué, cela n'a rien à voir avec la présupposition de SSIS - cela présuppose simplement des plans de maintenance!

Il s'agit donc d'une méthode légère prise en charge, qui fonctionne sans SSIS n'importe où sur le système. L'avantage de la méthode plus complexe et plus hacky ci-dessus est qu'elle donne des plans exportés dans un format standard, pas seulement en tant que lignes de données nues; donc je pense que c'est beaucoup plus susceptible d'être importable dans une version différente de SQL Server, plus tard.


1

J'ai eu du mal avec le même problème EXACT. Voici les principaux plats à emporter:

Aucun service d'intégration requis sur votre WEBSERVER. Une méthode documentée consiste à utiliser DTUTIL. Utilisez simplement N'IMPORTE QUEL SQL Server (même l'édition gratuite pour les développeurs avec toutes les fonctionnalités Enterprise) sur laquelle Integration Services est installé pour copier les packages de maintenance SQL Server d'une source vers une cible - même s'il ne s'agit pas de la source ou de la cible du package, comme indiqué dans Exemple A.

Exemple A: exécutez DTUTIL sur SQL Server MySSISServerA pour copier un package de maintenance SQL de MySourceServerB vers MyDestServerC .

DTUTIL /SQL "Maintenance Plans\Nightly Maintenance" /copy  sql;"Maintenance Plans\Nightly Maintenance" /sourceserver MySourceServerB /destserver MyDestServerC /Q

Avec la mise en garde qui ANY= même version, sinon, DTUTIL mettra à niveau le plan vers vCurrent
billinkc

Bon point! Mais les mises à niveau peuvent être utiles - pour ce que nous faisons de toute façon. Ce que j'aime faire, c'est créer des plans dans SQL 2008 et copier / mettre à niveau ces plans vers SQL 2008, 2008 R2, 2012,2014, 2016.
Sting

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.