Share via

  • Article

Détachement d'une base de données partagée évolutive

À terme, les données de rapports sont trop anciennes pour être utiles, et la base de données de rapports est dite obsolète. La mise à jour d'une base de données partagée évolutive implique un cycle de mise à jour en trois phases dont la première est la phase de détachement. La phase de détachement implique essentiellement le détachement d'une base de données de rapports obsolète et du démontage des volumes de rapports des serveurs correspondants. Une fois détachée d'une instance de serveur donnée, la base de données de rapports obsolète cesse d'être une base de données partagée évolutive sur cette instance de serveur.

Étapes de la phase de détachement

Au cours de cette phase, vous êtes amené à effectuer les tâches suivantes sur chacun des serveurs de rapports :

  1. Désactiver éventuellement les nouvelles requêtes sur la base de données et permettre aux requêtes en cours de se terminer tranquillement. Pour plus d'informations, consultez « Stratégies de préparation au détachement d'une base de données de rapports obsolète », plus loin dans cette rubrique.

  2. Détachez la base de données de chacune des instances de serveur.

    Vous pouvez accomplir cette opération à l'aide de l'instruction Transact-SQL suivante.

    sp_detach_db @dbname='<database_name>'

    Où <database_name> est le nom de la base de données.

  3. Démontez le jeu des volumes de rapports sur chacun des serveurs de rapports.

    Pour démonter un volume à l'aide de l'utilitaire DiskPart, entrez les commandes suivantes à l'invite de commandes :

    DiskPart

    DISKPART> select volume=<drive-number>

    DISKPART> remove

    DISKPART> exit

    Où <drive-letter> est la lettre affectée au volume de rapports. Si la base de données utilise plusieurs volumes de rapports, effectuez cette étape pour chacun des volumes.

  4. Masquez le numéro d'unité logique (LUN) correspondant au volume de rapports pour masquer celui-ci des serveurs de rapports. Pour cela, utilisez les utilitaires de votre fournisseur de matériel. Si la base de données utilise plusieurs volumes de rapports, effectuez cette étape pour chacun des volumes.

[!REMARQUE]

La phase de détachement correspond à la première phase d'un cycle de mise à jour pour un jeu donné de volumes de rapports. Cependant, vous pouvez utiliser deux jeux différents de volumes de rapports pour les versions actualisée et obsolète d'une base de données de rapports. Cette opération vous permet le chevauchement des phases de détachement et de mise à jour des deux jeux de volumes. Pour plus d'informations, consultez Optimisation de la disponibilité d'une base de données partagée évolutive.

Stratégies de préparation au détachement d'une base de données de rapports obsolète

Lors du remplacement de la version obsolète d'une base de données, il est important de prendre en compte les besoins professionnels de votre environnement de création de rapports. Vous devez évaluer lequel des besoins professionnels suivants est le plus important : permettre aux requêtes en cours de se terminer ou terminer la mise à jour le plus rapidement possible.

En fonction du besoin le plus important, vous pouvez décider du mode de gestion de la phase de détachement sur chacun des serveurs de rapports.

  • Permettre aux requêtes de se terminer

    Pour préserver toutes les requêtes en cours, commencez la phase de détachement en arrêtant le flux des transactions vers la base de données, en stoppant par exemple l'activité d'E/S. Puis, sur chaque instance de serveur, attendez que toutes les requêtes en cours se terminent. Lorsque la base de données a été détachée de toutes les instances de serveur, vous pouvez démonter le volume de rapports.

  • Mettre à jour la base de données le plus rapidement possible

    Pour terminer la mise à jour rapidement, accédez de manière exclusive à la base de données sur chacune des instances de serveur en arrêtant les requêtes immédiatement ou après un nombre spécifié de secondes. Les requêtes terminées peuvent redémarrer après l'attachement d'une version actualisée de la base de données.

    Par exemple, pour permettre aux requêtes en cours de se terminer en 60 secondes avant de terminer les requêtes restantes, utilisez l'instruction Transact-SQL suivante :

    USE master;
ALTER DATABASE AdventureWorks
SET SINGLE_USER
WITH ROLLBACK AFTER 60;
GO

    Vous pouvez désormais détacher la base de données de chacune des instances de serveur et démonter le ou les volumes de rapports de chaque serveur correspondant.

Pour plus d'informations, consultez ALTER DATABASE (Transact-SQL).

À ce stade, le jeu démonté des volumes de rapports est prêt pour la phase d'actualisation ou de construction de son cycle de mise à jour suivant.

Une autre solution consiste à actualiser la base de données sur un autre jeu de volume de rapports avant de commencer la phase de détachement sur le jeu actuellement monté des volumes de rapports. Pour plus d'informations, consultez Optimisation de la disponibilité d'une base de données partagée évolutive.