Cet article vous concerne si vous avez exécuté par inadvertance sur une base de données une requête DELETE, TRUNCATE ou DROP et que vous avez perdus des enregistrements. Ce qui suit vous explique comment récupérer ces données.

Si vous demandiez à un administrateur de base de données (DBA) quelle est la fonctionnalité qu’il aimerait le plus voir apparaître dans la fonctionnalité de récupération de SQL Server, il répondrait sans aucun doute: “La possibilité de restaurer une seule table depuis une sauvegarde de la base de données”.

Il est bien sûr possible de récupérer les données d’une table donnée à partir de la sauvegarde de la base de données dans laquelle elle se trouve, mais vous ne pouvez réaliser cette opération sans restaurer l’entière de la sauvegarde.

Les administrateurs de base de données veulent cela pour plusieurs raisons:

Introduction

Il y a certaines circonstances dans lesquelles vous pouvez avoir besoin de restaurer votre base de données à un point précis dans le temps (point in time recovery). Ces raisons sont généralement liées à l’exécution d’instructions DML ou DDL accidentelles. Par exemple:

Une table accidentellement supprimée peut être recupérée de plusieurs façons. Le choix de la technique dépend des ressources disponibles pour la récupération. Le premier choix est habituellement une sauvegarde de base de données. Mais, même si vous n’en avez pas, la table supprimée peut toujours être récupérée (dans certains cas encore plus rapidement que si vous aviez une sauvegarde).

Le pire cauchemar d’un DBA SQL est la perte de données en raison d’une erreur de leur part. Il n’est pas rare d’exécuter ou d’oublier une clause WHERE lors de l’exécution d’un DELETE ou d’un UPDATE, ce qui compromet potentiellement des millions de lignes de données.

Alors, quelles sont les options disponibles dans SQL Server pour récupérer les données?

Le journal de transactions SQL Server contient des enregistrements décrivant les modifications apportées à une base de données. Ils stockent suffisamment d’informations pour récupérer la base de données à un point précis dans le temps, de rejouer ou annuler une modification. Mais, comment voir son contenu, trouver une transaction spécifique, voir ce qui s’est passé et annuler les changements comme par exemple la récupération de lignes supprimées accidentellement

Oups! Dites-vous lorsque vous avez exécuté une requête UPDATE sans condition WHERE sur une base de données et écrasé un tas de lignes avec des données incorrectes. Comment pouvez-vous ramener les bonnes valeurs?

Si vous avez accidentellement exécuté une instruction DROP et que vous disposez d’une sauvegarde complète, étant donné qu’aucun changement n’est survenu après que la table a été supprimée, vous pouvez tout simplement récupérer les données en écrasant la base de données originale avec la sauvegarde. Toutefois, si ce n’est pas le cas, soit parce que les objets de base de données et les données ont été modifiés après que l’instruction SQL DROP a été exécutée, soit parce que vous n’avez pas une sauvegarde de la base de données valide, il existe encore un moyen de récupérer toutes vos données perdues.

Chaque base de données SQL Server contient un ensemble de fichiers stockés dans le système d’exploitation. Ces fichiers stockent les données et les informations de journalisation. Les fichiers sont utilisés individuellement par une seule base de données et les informations de journalisation et les données ne sont jamais mélangées dans le même fichier. Alors que les données sont stockées dans un fichier MDF, toutes les transactions, les modifications de la base de données SQL Server effectuées par chaque transaction sont stockées dans un fichier LDF – le fichier de journalisation des transactions qui est une composante essentielle de la base de données. D’un point de vue conceptuel, le fichier de journalisation est une série d’enregistrements du journal. Physiquement, les enregistrements de journalisation sont stockés dans un ou plusieurs fichiers LDF physiques qui constituent le journal des transactions.