Il s’agit du deuxième article de la série d’objets SQL Server migrant à l’aide de SSDT 2017. Dans cet article, nous allons apprendre à copier les procédures stockées par l’utilisateur créées dans la base de données maître SQL Server.
Configuration de la démo
Pour la démonstration, j’ai exécuté le script de maintenance de la base de données Ola-hallengren sur une base de données principale de Nisarg-PC\SQL01. Vous pouvez télécharger la dernière version des scripts de maintenance à partir d’ici. Ces scripts créent des procédures et des tables stockées. Une fois les scripts exécutés avec succès, vous pouvez les afficher en exécutant la requête suivante.
|
1
|
Sélectionnez nom à partir du maître.sys.procédures
|
Nous allons migrer les procédures stockées ci-dessus vers la base de données principale du serveur Nisarg-PC\SQL02.
Créer un package de service d’intégration
Maintenant, tout d’abord, créons un package de service d’intégration. Ouvrez SSDT 2017 Click Cliquez sur Crete Nouveau projet Select Sélectionnez projet de services d’intégration. Le nom du projet sera Procédures stockées dans la base de données principale Migrate.
Faites glisser la tâche de procédure stockée principale de transfert et déposez-la sur la surface de flux de contrôle, renommez-la pour Migrer la procédure stockée de maintenance.
Double-cliquez sur la tâche Procédures stockées Maître de transfert pour la configurer.
Pour transférer la procédure stockée entre les instances, il faut configurer les connexions source et destination. Pour ce faire, cliquez sur SourceConnection et sélectionnez Nouvelle connexion. Tout d’abord, voyons comment nous pouvons configurer la connexion Source.
Configure SourceConnection
Pour configurer la connexion au serveur Source, cliquez sur SourceConnection et sélectionnez Nouvelle connexion.
Dans la boîte de dialogue Éditeur du gestionnaire de connexions SMO, spécifiez le nom du serveur de la source et spécifiez la méthode d’authentification utilisée pour se connecter au serveur SQL. Dans notre démo, le nom du serveur est Nisarg-PC\SQL01 et la méthode d’authentification est l’authentification Windows.
Cliquez sur OK pour enregistrer les propriétés de connexion et fermer la boîte de dialogue.
Configurer DestinationConnection
Pour configurer la connexion pour le serveur de destination, cliquez sur DestinationConnection et sélectionnez Nouvelle connexion.
Dans la boîte de dialogue Éditeur de gestionnaire de connexions SMO, spécifiez le nom du serveur de la source et spécifiez la méthode d’authentification utilisée pour se connecter au serveur SQL. Dans notre démo, le nom du serveur est Nisarg-PC\SQL02 et la méthode d’authentification est l’authentification Windows.
Cliquez sur OK pour enregistrer les propriétés de connexion et fermer la boîte de dialogue. La section connexions ressemble à ce qui suit:
Dans la section Procédure stockée, vous obtenez les options suivantes:
- IfObjectExiste: Lorsque l’objet que nous transférons existe déjà, vous pouvez choisir l’une des actions suivantes effectuées par la tâche de procédure stockée Maître de transfert
- Tâche d’échec : Si la procédure stockée existe sur l’instance de destination, la tâche échouera
- Écraser : Si la procédure stockée existe sur le serveur de destination, la tâche écrasera la procédure stockée existante
- Ignorer : Si la procédure stockée existe sur le serveur de destination, la tâche ignorera le transfert de cette procédure stockée spécifique
- Procédures de transfert: Si vous souhaitez transférer toutes les procédures de magasin définies par l’utilisateur, sélectionnez True. Si vous souhaitez transférer des procédures stockées spécifiques, sélectionnez False
- StoredProcedureList : Si vous souhaitez transférer une procédure stockée spécifique, vous pouvez choisir le SPs que vous souhaitez transférer. Cette option s’active lorsque vous sélectionnez la valeur False pour le paramètre TransferAllStoredProcedures
Nous voulons ignorer le transfert de la procédure stockée existante dans notre démo, alors sélectionnez Ignorer. Nous voulons transférer toutes les procédures stockées, alors sélectionnez True dans l’option TransferAllStoredProcedures.
L’éditeur de tâches Procédures stockées Maître de transfert ressemble à l’image suivante:
Maintenant, nous devrions être avertis lorsque les procédures stockées sont transférées. Pour ce faire, nous allons configurer la tâche de l’opérateur Notifier.
Configure Notify Operator Task
Tout d’abord, faites glisser la tâche Notify operator, déposez-la dans la surface du flux de contrôle, renommez-la pour envoyer un e-mail et double-cliquez dessus.
Tout d’abord, nous devons configurer la connexion entre le serveur sur lequel l’opérateur a été créé. Pour ce faire, cliquez sur la boîte de dialogue Nouveau dans Notifier la tâche de l’opérateur. Une autre boîte de dialogue, Propriétés de connexion, s’ouvre. Spécifiez les valeurs appropriées des paramètres suivants.
- Nom de connexion : Spécifiez le nom de connexion souhaité. Dans notre démo, je l’ai nommé SqlConnection
- Nom du serveur: Spécifiez le nom du serveur sur lequel l’opérateur SQL Server a été créé. J’ai déjà créé un opérateur nommé DBASupport dans Nisarg-PC\SQL01
- Méthode d’authentification : Spécifiez la méthode d’authentification. Dans notre démo, j’ai utilisé l’authentification Windows
Cliquez sur OK pour fermer la boîte de dialogue.
Spécifiez l’objet de l’e-mail dans la zone de texte Objet du message de notification. Dans notre démo, la ligne d’objet est l’État de la Migration de la procédure stockée de la base de données principale.
Spécifiez le corps de l’e-mail dans le corps du message de notification. Dans notre démo, le corps de l’e-mail est le suivant:
Bonjour DBASupport,
La procédure stockée de la base de données principale a été transférée avec succès.
Enfin, la tâche de l’opérateur Notifier ressemble à l’image suivante:
L’e-mail doit être envoyé une fois que toutes les tâches ont été migrées avec succès. Pour ce faire, nous devons connecter les deux tâches à l’aide d’un connecteur. Le paquet ressemble à ce qui suit:
La tâche Procédures stockées du Maître de transfert a été configurée avec succès.
Résumé
Dans le deuxième article de cette série, nous avons pris connaissance de la tâche des procédures stockées du Maître de transfert. J’ai expliqué comment nous pouvons le configurer pour transférer la procédure stockée par l’utilisateur créée dans la base de données principale entre deux instances de SQL Server à l’aide des outils de données SQL Server (SSDT 2017). Dans le prochain article, nous allons en apprendre davantage sur la tâche Transférer les messages d’erreur et créer un package dans SSDT 2017 pour migrer les journaux d’erreurs entre les deux instances de SQL Server.
Table des matières
Transférer des tâches SQL entre des instances SQL Server à l’aide de SSDT 2017
Transférer des procédures stockées entre des bases de données principales sur des instances SQL Server à l’aide de SSDT 2017
Transférer des connexions SQL entre des instances SQL Server à l’aide de SSDT 2017
Transférer des messages d’erreur entre des instances SQL Server à l’aide de SSDT 2017
- Auteur
- Messages récents
Il possède une expertise dans la conception de bases de données, le réglage des performances, la sauvegarde et la récupération, la configuration HA et DR, les migrations et les mises à niveau de bases de données. Il a obtenu un baccalauréat en technologie de l’Université Ganpat. Il peut être joint sur nisargupadhyay87 @ outlook.com
- Comment déplacer des tables vers un autre groupe de fichiers d’une base de données SQL – 14 décembre 2021
- Configurer les pilotes ODBC pour Oracle 19c – 9 décembre 2021
- Configurer un serveur lié entre SQL Server et PostgreSQL à l’aide des pilotes ODBC – Décembre 6, 2021