web-dev-qa-db-fra.com

Comment attacher une base de données dans SQL Server?

Quelques questions courantes concernant la connexion de bases de données dans SQL Server:

  • Que signifie attacher ou détacher une base de données?
  • Comment détacher une base de données?
  • Comment joindre une base de données?
    • Que signifie attacher et reconstruire le journal?
  • Comment le faire dans SQL Server Express?
  • Quand pourrais-je envisager de détacher et d'attacher?
  • Y a-t-il des risques ou des avertissements?
  • Qu'en est-il de la liaison entre les versions et les éditions de SQL Server? (Standard à Enterprise? 2000 à 2008? 2012 à 2008?)
32
Mike Walsh

Qu'est-ce que détacher ou attacher et comment fonctionnent-ils?

Nous allons commencer par détacher. Lorsque vous détachez une base de données dans SQL Server, vous mettez la base de données hors ligne et la supprimez de l'instance SQL Server à partir de laquelle vous le détachez. Les données et les fichiers journaux des bases de données restent intacts et sont conservés dans un état cohérent afin que vous puissiez ensuite attacher la base de données ultérieurement ou à une autre instance SQL Server. Attach connecte les données et les fichiers journaux d'une base de données qui a été correctement détachée (ou qui ont été copiés à partir d'une instance correctement arrêtée de SQL Server) à un instance de SQL Server et met la base de données en ligne.

Comment détacher une base de données?

Vous pouvez le faire dans T-SQL ou à partir de l'interface graphique de SQL Server Management Studio.

Dans l'interface graphique, faites un clic droit sur la base de données que vous souhaitez détacher, sélectionnez All Tasks et cliquez sur Detach. De là, vous obtiendrez la boîte de dialogue de détachement. Vous pouvez choisir de supprimer les connexions en premier pour déconnecter de force toutes les connexions actives et restaurer le travail qu'elles étaient en cours d'exécution. Vous pouvez également choisir de mettre à jour les statistiques avant le détachement. Detaching through - Choose Detach...

Dans T-SQL:

-- You don't want to be in the database you are trying to detach
USE Master
GO

-- Optional step to drop all active connections and roll back their work
ALTER DATABASE DatabaseName
SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO

-- Perform the detach
EXEC sp_detach_db 'DatabaseName'
GO

Pour la procédure stockée système sp_detach_db, vous pouvez éventuellement transmettre deux paramètres:

  • @skipchecks - une entrée acceptable est 'True' ou 'False' si 'True', SQL Server mettra à jour les statistiques avant de se détacher. Si 'False', ce ne sera pas le cas. Si vous ne spécifiez rien ici, les statistiques seront mises à jour dans SQL Server 2005 ou version ultérieure.
    • @keepfulltextindexfile - La valeur par défaut ici est 'True' - si ce paramètre est défini sur true, les métadonnées d'index de texte intégral ne seront pas supprimées pendant le détachement.

Pour en savoir plus sur le détachement et plus de détails sur les risques que je souligne ci-dessous, le article de Books Online for sp_detach_db est un bon point de départ.

Comment joindre une base de données?

Vous pouvez également le faire dans T-SQL ou à partir de l'interface graphique de SQL Server Management Studio.

( REMARQUE: si vous disposez des données et des fichiers journaux d'une base de données qui n'a pas été correctement détachée, votre pièce jointe peut ne pas fonctionner. Lorsque le détachement se produit, la base de données est mise hors ligne et les fichiers journaux et données sont mis dans un état cohérent. Cela se produit également lorsqu'un service est correctement arrêté. )

Dans l'interface graphique, faites un clic droit sur le dossier de niveau supérieur Databases pour votre instance et sélectionnez Attach. Dans la boîte de dialogue suivante, vous devez ensuite sélectionner le fichier de données principal (.MDF) de la base de données que vous souhaitez attacher et vous assurer que les autres fichiers sont sélectionnés et leurs emplacements appropriés spécifiés, puis cliquez sur OK, attachant votre base de données.

Dans T-SQL, la meilleure façon de procéder dans SQL Server 2005 et avant consiste à utiliser le CREATE DATABASE commande. Il s'agit de la méthode prise en charge au-delà de SQL Server 2012. Si vous souhaitez voir comment utiliser sp_attach_db, vous pouvez voir que dans les livres des articles en ligne pour [sp_attach_db][3] ou [sp_attach_single_file_db][4]

Lorsque vous avez votre fichier journal et vos fichiers de données disponibles et qu'ils sont cohérents, voici l'approche T-SQL:

- Utilisation de Create Database et de la clause FOR ATTACH pour attacher

CREATE DATABASE DatabaseName 
    ON (FILENAME = 'FilePath\FileName.mdf'), -- Main Data File .mdf
    (FILENAME = 'FilePath\LogFileName.ldf'), -- Log file .ldf
     (FILENAME = 'FilePath\SecondaryDataFile.ndf)  -- Optional - any secondary data files
    FOR ATTACH 
GO 

Vous pouvez également en savoir plus sur l'instruction Créer une base de données dans les livres en ligne.

Comment détacher/attacher dans SQL Server Express?

C'est en fait la même chose. Si vous utilisez SQL Server Management Studio Express, vous pouvez également utiliser la boîte de dialogue détacher/attacher dans l'interface graphique décrite ci-dessus ou les étapes T-SQL via SSMS Express décrites ci-dessus. Aucune différence avec Express là-bas.

Si vous n'avez pas SSMS Express, vous pouvez le télécharger ( ici est la version SQL Server 2012 Express).

Vous pouvez entrer dans une session SQLCMD et utiliser les mêmes constructions T-SQL décrites ci-dessus.

Quand devrais-je envisager de détacher ou d'attacher?

D'abord, un mot sur ce que détacher et attacher n'est pas destiné à être utilisé pour: Sauvegarde et récupération Détacher et attacher n'est pas un moyen de sauvegarder votre base de données pour la routine fins de récupération. Il n'y a pas de sauvegarde du journal des transactions de cette façon, cela place votre base de données dans un état où les fichiers de base de données peuvent être supprimés accidentellement et n'est pas du tout un bon moyen à cet effet.

Cela dit, détacher et attacher sont bons pour quelques cas d'utilisation (non exhaustifs, n'hésitez pas à modifier pour ajouter ou créer une nouvelle réponse avec plus):

  • Parfois pour les migrations (bien que je préfère la sauvegarde/restauration pour celles décrites dans ma réponse ici )
  • Lorsque vous souhaitez supprimer une base de données qui n'est plus utilisée activement mais qui a la possibilité de se joindre plus tard si nécessaire.
  • Dans certaines situations de dépannage, cela peut être demandé
  • Je n'ai pas l'espace pour sauvegarder ou restaurer à la fois des données et des fichiers journaux dans un autre environnement (vous ne devriez jamais être ici, mais je l'ai utilisé pour déplacer des bases de données de développement dans des environnements à certains moments. Je ne voulais pas ou je n'avais pas besoin le journal a fait ainsi une attacher/reconstruire le fichier journal)

Risques et avertissements

Encore une fois, les livres en ligne sont une bonne ressource ici , mais je vais appeler quelques considérations spécifiques à avoir en tête pour détacher ou attacher une base de données -

Détacher

  • Vous mettez votre base de données hors ligne. Il ne sera plus accessible. Cela devrait être évident, mais mérite d'être rappelé. C'est pourquoi ce n'est pas une excellente option de sauvegarde.
  • Lorsque votre base de données est en ligne, SQL Server verrouille les fichiers. Je ne recommanderais pas d'essayer cela pour me prouver le contraire, car il pourrait y avoir une autre situation en jeu, mais vous ne pouvez généralement pas supprimer un fichier de base de données (données, données secondaires ou fichier journal) lorsque SQL Server est en ligne. C'est une bonne chose. Lorsque vous vous détachez, vous n'avez pas une telle protection - cela peut être une mauvaise chose.
  • Si vous avez affaire à une corruption de base de données et que vous trouvez un article quelque part qui a une première étape de Détachement - c'est faux - si vous détachez une base de données corrompue, cela peut-être ça. Vous ne pourrez peut-être pas joindre à nouveau cette base de données.
  • Couper et coller vos fichiers de base de données de production sur votre réseau est un moyen d'introduire potentiellement une corruption au niveau des fichiers.
  • Cela peut entraîner l'échec d'un plan de maintenance. La situation est que vous avez, comme je l'ai fait, mis en place un plan de maintenance pour effectuer des sauvegardes régulières de toutes les bases de données sans vérifier les meilleures pratiques. Cela fonctionne bien, donc vous cessez d'y penser. Quelqu'un d'autre décide alors de mettre une base de données qu'il n'utilise pas hors ligne. Le plan de maintenance échouera à partir de ce point jusqu'à ce que vous modifiiez le plan de maintenance en cochant l'option "ignorer les bases de données dont l'état n'est pas en ligne" dans la boîte de dialogue "Base (s) de données". Notez qu'il n'échouera pas seulement pour la base de données hors ligne - le plan de maintenance échouera avec une erreur au moment où il essaiera de sauvegarder la base de données hors ligne afin que certaines bases de données en ligne ne soient pas sauvegardées. (auteur différent pour ce point alors traitez avec suspicion)

Attacher - Tout comme vous ne devriez pas exécuter de scripts à partir d'Internet ou accepter des paquets d'étrangers à l'aéroport, vous ne devez pas attacher une base de données que vous avez obtenue de quelqu'un d'autre sans quelques étapes pour le vérifier. Cette base de données peut contenir du code dans des déclencheurs, des procédures stockées, etc. qui pourraient compromettre votre environnement. Vous devez examiner une base de données que vous souhaitez attacher dans un environnement sûr et protégé par un pare-feu, pas votre système de production.

Qu'en est-il des différentes versions ou éditions de SQL Server?

Ce ne sont pas différentes des règles de restauration des bases de données entre les versions. Vous pouvez généralement restaurer jusqu'à la prochaine version pour 3 versions (SQL Server 2008 à SQL Server 2012, par exemple, fonctionnera. SQL Server 2000 à SQL Server 2012 ne fonctionnera pas). Vous ne pouvez pas du tout revenir en arrière via la sauvegarde/restauration ou détacher/attacher - vous devez créer des scripts pour les objets et les scripts pour les insérer manuellement et avec un outil qui le fait. Pour les éditions, vous pouvez généralement vous déplacer entre les principales références SKU de SQL Server - par exemple, vous pouvez déplacer une base de données de Standard vers Enterprise sans travail supplémentaire. Si vous utilisez des fonctionnalités d'entreprise (Say, compression ou partitionnement), vous devrez cependant désactiver ces fonctionnalités avant de procéder au déplacement. Vous pouvez vous faire une idée des fonctionnalités que vous devez envisager de désactiver en regardant ici .

33
Mike Walsh