Sauvegarde et restauration : Interopérabilité et coexistence (SQL Server)

  • Article

S’applique à :SQL Server

Cette rubrique décrit les considérations relatives à la sauvegarde et à la restauration pour plusieurs fonctionnalités dans SQL Server. Ces fonctionnalités concernent : la restauration de fichiers et le démarrage de bases de données, la restauration et la désactivation en ligne d'index, la mise en miroir de bases de données, la restauration fragmentaire et les index de recherche en texte intégral.

Dans cette rubrique :

Restauration de fichiers et démarrage d'une base de données

Cette section s’applique uniquement aux bases de données SQL Server qui ont plusieurs groupes de fichiers.

Note

Lors du démarrage d'une base de données, seuls les groupes de fichiers dont les fichiers étaient en ligne lorsque la base de données était fermée sont récupérés et mis en ligne.

Si un problème se produit lors du démarrage de la base de données, la récupération échoue et la base de données est affectée de l'attribut SUSPECT. Si le problème peut être isolé dans un ou des fichiers, l'administrateur de la base de données peut placer les fichiers hors connexion et tenter de la redémarrer. Pour placer un fichier hors connexion, vous pouvez utiliser l'instruction ALTER DATABASE suivante :

ALTER DATABASE nom_base_de_données MODIFY FILE (NAME ='nom_fichier', OFFLINE)

Si le démarrage aboutit, les groupes de fichiers qui contiennent un fichier hors connexion demeurent hors connexion.

Restauration en ligne et index désactivés

Elle concerne seulement les bases de données avec plusieurs groupes de fichiers et, dans le cas du mode de récupération simple, au moins un groupe de fichiers en lecture seule.

Dans ces cas de figure, lorsqu'une base de données est en ligne, l'index peut être créé, supprimé, activé ou désactivé uniquement si les groupes de fichiers qui contiennent une partie de l'index sont en ligne.

Pour plus d’informations sur la restauration de groupes de fichiers hors connexion, consultez Restauration en ligne (SQL Server).

Sauvegarde et restauration et mise en miroir d'une base de données

Cette section ne concerne que les bases de données en mode de restauration complète et composées de plusieurs groupes de fichiers.

Note

La fonctionnalité de mise en miroir de bases de données sera supprimée dans une prochaine version de Microsoft SQL Server. Évitez d'utiliser cette fonctionnalité dans de nouveaux travaux de développement, et prévoyez de modifier les applications qui utilisent actuellement cette fonctionnalité. Utilisez Groupes de disponibilité Always On à la place.

La mise en miroir de bases de données est une solution permettant d'accroître la disponibilité d'une base de données. La mise en miroir est implémentée individuellement pour chaque base de données et fonctionne uniquement avec les bases de données qui utilisent le mode de restauration complète. Pour plus d’informations, consultez Mise en miroir de bases de données (SQL Server).

Note

Pour distribuer des copies d'un sous-ensemble des groupes de fichiers d'une base de données, utilisez la réplication : ne répliquez que les objets des groupes de fichiers à copier sur d'autres serveurs. Pour plus d’informations sur la réplication, consultez Réplication SQL Server.

Création de la base de données miroir

La base de données miroir est créée par la restauration (WITH NORECOVERY) de sauvegardes de la base de données principale sur le serveur miroir. La base de données restaurée doit conserver le nom initial de la base de données. Pour plus d’informations, consultez Préparer une base de données miroir pour la mise en miroir (SQL Server).

Vous pouvez créer la base de données miroir à l'aide d'une séquence de restauration fragmentaire, si celle-ci est prise en charge. Cependant, vous ne pouvez pas démarrer la mise en miroir avant d'avoir restauré tous les groupes de fichiers et, en règle générale, les sauvegardes des journaux pour synchroniser la base de données miroir avec la base de données principale. Pour plus d’informations, consultez l’article Restaurations fragmentaires (SQL Server).

Restrictions imposées en matière de sauvegarde et de restauration lors de la mise en miroir

Pendant une session de mise en miroir de base de données, les restrictions suivantes s'appliquent :

  • La sauvegarde et la restauration de la base de données ne sont pas autorisées.

  • La sauvegarde de la base de données principale est autorisée, mais pas la sauvegarde du journal des transactions sans récupération (BACKUP LOG WITH NORECOVERY).

  • La restauration de la base de données principale n'est pas autorisée.

Restauration fragmentaire et index de recherche en texte intégral

Cette section ne concerne que les bases de données contenant plusieurs groupes de fichiers et, pour les bases de données en mode simple, que les groupes de fichiers en lecture seule.

Les index de recherche en texte intégral sont stockés dans des groupes de fichiers de base de données et peuvent être affectés par une restauration fragmentaire. Si l'index de recherche en texte intégral réside dans le même groupe de fichiers que des données de table associées, la restauration fragmentaire fonctionne comme prévu.

Note

Pour afficher l’ID du groupe de fichiers qui contient un index de recherche en texte intégral, sélectionnez la colonne data_space_id de sys.fulltext_indexes.

Index de recherche en texte intégral et tables dans des groupes de fichiers distincts

Si un index de recherche en texte intégral réside dans un autre groupe de fichiers que les données de table associées, le comportement d'une restauration fragmentaire dépend du groupe de fichiers restauré et mis en ligne en premier :

  • Si le groupe de fichiers contenant l'index de recherche en texte intégral est restauré et mis en ligne avant les groupes de fichiers contenant les données de table associées, la recherche en texte intégral fonctionne comme prévu dès que l'index de recherche en texte intégral est en ligne.

  • Si le groupe de fichiers contenant les données de table est restauré et mis en ligne avant le groupe de fichiers contenant l'index de recherche en texte intégral, le comportement du texte intégral peut être affecté. Cela est dû au fait que les instructions Transact-SQL qui déclenchent une population, regénèrent le catalogue ou réorganisent le catalogue échouent jusqu’à ce que l’index soit mis en ligne. Ces instructions incluent CREATE FULLTEXT INDEX, ALTER FULLTEXT INDEX, DROP FULLTEXT INDEX et ALTER FULLTEXT CATALOG.

    Dans ce cas, les facteurs suivants sont importants :

    • Si le suivi des modifications est activé pour l'index de recherche en texte intégral, le DML utilisateur échoue tant que le groupe de fichiers de l'index n'est pas mis en ligne. Il en va de même pour une opération de suppression.

    • Quel que soit le suivi des modifications, les requêtes de texte intégral échouent, car l'index n'est pas disponible. Si une requête de texte intégral est tentée alors que le groupe de fichiers contenant l'index de recherche en texte intégral est hors connexion, une erreur est retournée.

    • Les fonctions d'état (telles que FULLTEXTCATALOGPROPERTY) réussissent uniquement dans les cas où elles n'ont pas à accéder à l'index de recherche en texte intégral. Par exemple, l’accès à des métadonnées de texte intégral en ligne réussit, alors que uniquekeycount et itemcount échouent.

    Une fois le groupe de fichiers de l'index de recherche en texte intégral restauré et mis en ligne, les données de l'index et des tables sont cohérentes.

Dès que le groupe de fichiers des tables et celui de l'index de recherche en texte intégral sont en ligne, tout remplissage de texte intégral suspendu reprend.

Sauvegarde et restauration de fichiers et compression

SQL Server prend en charge la compression des données du système de fichiers NTFS des groupes de fichiers en lecture seule et des bases de données en lecture seule.

La restauration des fichiers dans un groupe de fichiers en lecture seule est prise en charge sur les fichiers compressés NTFS. La sauvegarde et la restauration de ces groupes de fichiers fonctionne pour l'essentiel de la même manière que pour n'importe quel groupe de fichiers en lecture seule, à quelques exceptions près :

  • La restauration d'un fichier en lecture-écriture (y compris le fichier primaire et les fichiers journaux d'une base de données en lecture-écriture) vers un volume compressé échoue et génère une erreur.

  • La restauration d'une base de données en lecture seule vers un volume compressé est autorisée.

Note

Les fichiers journaux des bases de données en lecture-écriture ne doivent jamais être placés sur des systèmes de fichiers compressés.

Tâches associées

Voir aussi

Sauvegarder et restaurer des bases de données SQL Server
Sauvegarder et restaurer des bases de données répliquées
Secondaires actifs : sauvegarde sur les réplicas secondaires (groupes de disponibilité Always On)