Sauvegarde du journal de queue lors d'une restauration?

Généralement, lors de la restauration d'une base de données d'un serveur de production vers un serveur hors production, j'utilise l'option WITH REPLACE car lorsque j'oublie, j'obtiens une erreur indiquant que le journal de fin n'est pas sauvegardé.

Selon MSDN, je devrais en effet sauvegarder mon journal de queue avant de restaurer:

Si la base de données est en ligne et que vous prévoyez d'effectuer une opération de restauration sur la base de données, commencez par sauvegarder la fin du journal. Pour éviter une erreur pour une base de données en ligne, vous devez utiliser l'option… WITH NORECOVERY de l'instruction BACKUP Transact-SQL.

Quels sont les dangers ou les inconvénients de la façon dont je le fais? Pourquoi la sauvegarde du journal de queue est-elle avant tout un avantage pour moi?

J'utilise SQL Server 2008R2, mais je suppose que cette requête sera pertinente pour la plupart des versions plus récentes de SQL Server, donc ne l'avez pas marquée comme telle au départ.

sql-server restore transaction-log

— Paul
source

Je pense que cela signifie que si vous allez restaurer au même endroit (et éventuellement appliquer des journaux de transactions supplémentaires). Si vous souhaitez restaurer une simple copie de la base de données ailleurs et n'avez pas besoin de maintenir la chaîne de journaux, j'utiliserais la méthode que vous utilisez. Je pourrais même utiliser WITH COPY_ONLYsur la sauvegarde.

— Aaron Bertrand

Si vous ne sauvegardez pas la fin du journal, vous perdez toutes les transactions qui se sont produites depuis la dernière sauvegarde de la base de données.

— JoseTeixeira
source

Oui j'ai compris ça. Mais même ainsi, je pense que votre réponse m'a fait combler le fossé dans ma pensée. Voir la base de données non produite n'est jamais sauvegardée, donc je perds la totalité de la base de données en restaurant de toute façon, alors pourquoi me soucier du journal de queue. Mais la pensée MSDN est que je sauvegarde toujours ma base de données, le seul bit non sauvegardé en ce moment est le journal de queue, donc ils veulent que je le sauvegarde. Pour mon scénario spécifique d'une base de données de production non transitoire dont personne ne se soucie, il n'y a donc aucun avantage à sauvegarder le journal de queue.

— Paul

Complètement raison. Si vous voulez simplement apporter des données à un environnement de non-production et ne vous souciez pas vraiment de ce qui s'y trouvait, il n'y a vraiment aucun problème.

— JoseTeixeira