Attachement et détachement des bases de données

Article
12/15/2008

Mis à jour : 12 décembre 2006

Les données et les journaux de transactions d'une base de données peuvent être détachés, puis rattachés à la même instance ou à une autre instance de SQL Server. Le détachement et l'attachement d'une base de données sont utiles pour transférer la base de données dans une instance différente de SQL Server sur le même ordinateur ou pour la déplacer.

Remarque :
Le format de stockage sur disque de SQL Server est le même dans les environnements 64 bits et 32 bits. Par conséquent, l'attachement fonctionne sur les environnements 32 bits et 64 bits. Une base de données détachée d'une instance serveur s'exécutant dans un environnement peut être attachée à une instance serveur qui s'exécute dans un autre environnement.

Remarque :
Pour plus d'informations sur les autorisations de fichier définies lors du détachement et de l'attachement d'une base de données, consultez Sécurisation des fichiers de données et des fichiers journaux.

Détachement d'une base de données

Détacher une base de données consiste à la supprimer de l'instance SQL Server sans toucher à ses fichiers de données et à ses journaux de transactions. Ces fichiers peuvent ensuite servir à rattacher la base de données à n'importe quelle instance de SQL Server, y compris le serveur d'où la base de données a été détachée.

Une base de données ne peut pas être détachée si l'une des conditions suivantes est vraie :

La base de données est répliquée et publiée. Si elle est répliquée, la base de données ne doit pas être publiée. Avant de pouvoir la détacher, vous devez désactiver la publication en exécutant sp_replicationdboption.

Remarque :

Si vous ne pouvez pas utiliser sp_replicationdboption, vous pouvez supprimer la réplication en exécutant sp_removedbreplication.
Une capture instantanée existe sur la base de données.
Avant de pouvoir détacher la base de données, vous devez supprimer toutes ses captures instantanées. Pour plus d'informations, consultez Procédure : supprimer une capture instantanée de base de données (Transact-SQL).

Remarque :

Une capture instantanée de base de données ne peut pas être détachée ou attachée.
La base de données est en cours de mise en miroir dans une session de mise en miroir de bases de données.
La base de données ne peut pas être détachée tant que la session n'est pas interrompue. Pour plus d'informations, consultez Suppression d'une mise en miroir des bases de données.
La base de données est suspecte. Dans SQL Server 2005, une base de données suspecte ne peut pas être détachée ; avant de pouvoir le faire, vous devez la mettre en mode urgence. Pour plus d'informations sur la mise en mode urgence d'une base de données, consultez ALTER DATABASE (Transact-SQL).
La base de données est une base de données système.

Remarque :
Si vous ne pouvez pas utiliser sp_replicationdboption, vous pouvez supprimer la réplication en exécutant sp_removedbreplication.

Remarque :
Une capture instantanée de base de données ne peut pas être détachée ou attachée.

L'attachement d'une base de données efface le cache de plan pour l'instance de SQL Server. Cette opération entraîne la recompilation de tous les plans d'exécution ultérieurs et peut entraîner une baisse temporaire et brutale des performances des requêtes. Dans SQL Server 2005 Service Pack 2, pour chaque mémoire cache effacée du cache du plan, le journal des erreurs de SQL Server contient le message d'information suivant : "SQL Server a rencontré %d occurrence(s) de vidages de mémoire cache pour la mémoire cache '%s' (partie du cache du plan) en raison d'opérations de maintenance ou de reconfiguration de base de données. Ce message est enregistré toutes les cinq minutes si le cache est vidé au cours de cet intervalle.

Pour détacher une base de données

Sauvegarde et restauration et détachement

Le détachement d'une base de données en lecture seule provoque la perte des informations relatives aux bases différentielles des sauvegardes différentielles. Pour plus d'informations, consultez Sauvegarde des bases de données en lecture seule.

Réponse aux erreurs de détachement

Les erreurs générées à l'occasion du détachement d'une base de données peuvent empêcher la fermeture correcte de la base de données et la reconstruction du journal des transactions. Si vous obtenez un message d'erreur, procédez comme suit pour corriger le problème :

Rattachez tous les fichiers associés à la base de données, en plus du fichier primaire.
Résolvez le problème à l'origine de l'affichage du message d'erreur.
Détachez la base de données de nouveau.

Attachement d'une base de données

Vous pouvez attacher une base de données SQL Server copiée ou détachée. Dans SQL Server 2005, les fichiers de texte intégral qui font partie d'une base de données sont attachés à celle-ci. Pour plus d'informations, consultez Attacher et détacher des catalogues de texte intégral.

Remarque relative à la sécurité :
Nous vous recommandons de ne pas attacher ou de restaurer des bases de données provenant de sources inconnues ou non approuvées. Ces bases de données peuvent contenir du code malveillant qui peut exécuter du code Transact-SQL imprévisible ou causer des erreurs en modifiant le schéma ou la structure physique de la base de données. Avant d'utiliser une base de données issue d'une source inconnue ou non approuvée, exécutez DBCC CHECKDB sur la base de données sur un serveur non productif et examinez également le code, notamment les procédures stockées ou le code défini par l'utilisateur, de la base de données.

Nous vous recommandons de ne pas attacher ou de restaurer des bases de données provenant de sources inconnues ou non approuvées. Ces bases de données peuvent contenir du code malveillant qui peut exécuter du code Transact-SQL imprévisible ou causer des erreurs en modifiant le schéma ou la structure physique de la base de données. Avant d'utiliser une base de données issue d'une source inconnue ou non approuvée, exécutez DBCC CHECKDB sur la base de données sur un serveur non productif et examinez également le code, notamment les procédures stockées ou le code défini par l'utilisateur, de la base de données.

À l'attachement, la base de données démarre. En général, l'attachement d'une base de données la place dans le même état où elle se trouvait au moment de son détachement ou de sa copie. Toutefois, dans SQL Server 2005, les opérations d'attachement et de détachement désactivent le chaînage des propriétés des bases de données croisées de la base de données. Pour plus d'informations sur la manière d'activer le chaînage, consultez Option cross db ownership chaining. En outre, TRUSTWORTHY prend la valeur OFF à chaque fois que la base de données est attachée. Pour plus d'informations sur l'affectation de la valeur ON à TRUSTWORTHY, consultez ALTER DATABASE (Transact-SQL).

Lorsque vous attachez une base de données, tous les fichiers de données (fichiers MDF et NDF) doivent être disponibles. Si un fichier de données possède un chemin différent de celui qui existait lorsque la base de données a été créée pour la première fois ou attachée pour la dernière fois, vous devez spécifier le chemin actuel du fichier.

Remarque :
Si le fichier de données primaires attaché est en lecture seule, le moteur de base de données suppose que la base de données est en lecture seule.

La première fois qu'une base de données chiffrée est attachée à une instance de SQL Server, le propriétaire de cette base de données doit ouvrir la clé principale de la base de données en exécutant l'instruction suivante : OPEN MASTER KEY DECRYPTION BY PASSWORD = 'password'. Nous vous recommandons d'activer le déchiffrement automatique de la clé principale en exécutant l'instruction suivante : ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY. Pour plus d'informations, consultez CREATE MASTER KEY (Transact-SQL) et ALTER MASTER KEY (Transact-SQL).

Les conditions requises pour attacher des fichiers journaux dépendent en partie des autorisations de lecture-écriture ou de lecture seule de la base de données. Elles sont exposées ci-dessous.

Pour une base de données en lecture-écriture, vous pouvez généralement attacher un fichier journal dans un nouvel emplacement. Toutefois, dans certains cas, le rattachement d'une base de données nécessite ses fichiers journaux existants. Par conséquent, il est important de toujours conserver tous les fichiers journaux détachés tant que la base de données n'a pas été attachée sans eux.
Si une base de données en lecture-écriture possède un seul fichier journal dont vous ne précisez pas le nouvel emplacement, l'opération d'attachement le recherche dans son emplacement précédent. S'il est trouvé, l'ancien fichier journal est utilisé, que la base de données ait été fermée correctement ou non. Toutefois, si l'ancien fichier journal n'est pas trouvé et si la base de données a été fermée correctement sans séquence de journaux de transactions active, l'opération d'attachement tente de créer un nouveau fichier journal pour la base de données. Pour plus d'informations, consultez Présentation de l'architecture du journal des transactions.

Si le fichier de données primaires attaché est en lecture seule, le moteur de base de données suppose que la base de données est en lecture seule. Pour une base de données en lecture seule, les fichiers journaux doivent être disponibles à l'emplacement spécifié dans le fichier primaire de la base de données. La création d'un nouveau fichier journal est impossible car SQL Server ne peut pas mettre à jour son emplacement stocké dans le fichier primaire.

Important :
Lorsqu'une base de données en lecture seule est détachée puis rattachée, les informations de base différentielle sont perdues. La base de données master se désynchronise alors de la base de données en lecture seule. Les sauvegardes différentielles effectuées après cette opération peuvent produire des résultats inattendus. Par conséquent, si vous utilisez des sauvegardes différentielles avec une base de données en lecture seule, vous devez établir, une fois la base de données rattachée, une base différentielle actuelle en effectuant une sauvegarde complète.

Lorsqu'une base de données en lecture seule est détachée puis rattachée, les informations de base différentielle sont perdues. La base de données master se désynchronise alors de la base de données en lecture seule. Les sauvegardes différentielles effectuées après cette opération peuvent produire des résultats inattendus. Par conséquent, si vous utilisez des sauvegardes différentielles avec une base de données en lecture seule, vous devez établir, une fois la base de données rattachée, une base différentielle actuelle en effectuant une sauvegarde complète.

Sauvegarde et restauration et attachement

Comme toutes les bases de données complètement ou partiellement hors connexion, une base de données contenant des fichiers de restauration ne peut pas être attachée. Pour attacher la base de données, arrêtez la séquence de restauration. Puis, vous pouvez redémarrer la séquence de restauration.

Attachement d'une base de données à une autre instance de serveur

Lorsque vous attachez une base de données à une autre instance de serveur et si vous souhaitez offrir une expérience cohérente aux utilisateurs et aux applications, il est possible que vous deviez recréer une partie ou l'ensemble des métadonnées de la base de données, telles que les connexions et les travaux, sur cette autre instance de serveur. Pour plus d'informations, consultez Gestion des métadonnées lors de la mise à disposition d'une base de données sur une autre instance de serveur.

Remarque :
Une base de données créée par une version plus récente de SQL Server ne peut pas être attachée dans les versions antérieures.

Remarque :
L'attachement de journaux fonctionne correctement avec le format de stockage vardecimal. Mais chaque Moteur de base de données doit au moins être mis à niveau vers SQL Server 2005, SP2, et toutes les bases de données associées doivent être activées pour le format de stockage vardecimal. Par exemple, vous ne pouvez pas attacher une base de données SP2 dont le format de stockage vardecimal est activé pour une version antérieure de SQL Server. Pour plus d'informations sur le format de stockage vardecimal, consultez Stockage des données décimales sous forme de colonne de longueur variable.

L'attachement de journaux fonctionne correctement avec le format de stockage vardecimal. Mais chaque Moteur de base de données doit au moins être mis à niveau vers SQL Server 2005, SP2, et toutes les bases de données associées doivent être activées pour le format de stockage vardecimal. Par exemple, vous ne pouvez pas attacher une base de données SP2 dont le format de stockage vardecimal est activé pour une version antérieure de SQL Server. Pour plus d'informations sur le format de stockage vardecimal, consultez Stockage des données décimales sous forme de colonne de longueur variable.

Pour attacher une base de données

Pour mettre à niveau une base de données à partir d'une version antérieure de SQL Server

Dans SQL Server 2005, vous pouvez utiliser les opérations de détachement (detach) et d'attachement (attach) pour mettre à niveau une base de données utilisateur de SQL Server version 7.0 ou SQL Server 2000. Cependant, les restrictions suivantes s'appliquent :

Les copies de la base de données master, model ou msdb créées à l'aide de SQL Server 7.0 ou SQL Server 2000 ne peuvent pas être attachées dans SQL Server 2005.
Les fichiers journaux de SQL Server 7.0 contenant des opérations de création d'index ne peuvent pas être attachés dans SQL Server 2000 ou SQL Server 2005.
Si vous attachez une base de données répliquée qui a été copiée et non pas détachée :
- Si vous attachez la base de données à une version mise à niveau de la même instance de serveur, vous devez exécuter sp_vupgrade_replication pour mettre à niveau la réplication, une fois l'opération d'attachement terminée. Pour plus d'informations, consultez sp_vupgrade_replication (Transact-SQL).
- Si vous l'attachez à une autre instance de serveur, quelle que soit la version, vous devez exécuter sp_removedbreplication pour supprimer la réplication, une fois l'opération d'attachement terminée. Pour plus d'informations, consultez sp_removedbreplication (Transact-SQL).

Pour mettre à niveau une base de données à l'aide des opérations de détachement et d'attachement

Procédure : mise à niveau d'une base de données avec Detach et Attach (Transact-SQL)

Déplacement d'une base de données ou d'un fichier de base de données

Important :
Nous vous recommandons de déplacer les bases de données à l'aide de la procédure de déplacement planifié ALTER DATABASE, plutôt qu'à l'aide des opérations de détachement et d'attachement. Pour plus d'informations, consultez Déplacement des fichiers de bases de données.

En général, vous pouvez utiliser les opérations de détachement et d'attachement pour déplacer une base de données. Les scénarios standard sont notamment le déplacement d'une base de données vers un des emplacements suivants :

un disque physique différent sur le même ordinateur ; par exemple lorsque le disque contenant un fichier de données est plein et que vous préférez étendre le fichier existant plutôt qu'étendre la base de données par l'ajout d'un nouveau fichier sur un autre disque ;
un autre ordinateur, sans avoir à recréer la base de données pour y restaurer la sauvegarde.

Le déplacement d'une base de données à l'aide d'opérations de détachement et d'attachement suppose les étapes suivantes :

détachement de la base de données ;
déplacement des fichiers de base de données vers l'autre serveur ou disque ;
attachement de la base de données en précisant le nouvel emplacement des fichiers déplacés.

Pour déplacer une base de données à l'aide des opérations de détachement et d'attachement

Procédure : déplacer une base de données à l'aide de la méthode de détachement et d'attachement (Transact-SQL)

Voir aussi

Historique des modifications

Version	Historique
12 décembre 2006	Nouveau contenu : Ajout d'une remarque sur le format de stockage sur disque de SQL Server identique dans les environnements 64 bits et 32 bits. Ajout d'une remarque sur la section « Attachement d'une base de données à une autre instance de serveur ». Ajout d'une remarque sur le format de stockage vardecimal.
17 juillet 2006	Nouveau contenu : Ajout d'informations sur l'effacement du cache de plan dans la section « Détachement d'une base de données ».
17 juillet 2006	Nouveau contenu : Ajout des restrictions contre le détachement des bases de données système. Ajout de la section « Sauvegarde et restauration et détachement ». Ajout de la section « Sauvegarde et restauration et attachement ».
5 décembre 2005	Nouveau contenu : Ajout de la note sur la sécurité.

Partager via