SQL Server (2005/2008): La sauvegarde complète vide-t-elle le journal en mode de récupération complet

Une sauvegarde complète ne tronque PAS le journal, vous devez effectuer une opération de sauvegarde du journal. Une sauvegarde complète ne réinitialise PAS la chaîne de journal -- cela perturberait complètement la réplication/le transfert de journal, etc.

Vous devez regarder attentivement comment SQL Server fait des sauvegardes mais sachez que les transactions en cours / longues ne sont pas incluses dans la sauvegarde (sinon la sauvegarde peut ne jamais se terminer) donc ce n'est pas tout à fait exact de dire qu'une sauvegarde complète d'une base de données en ligne garantit que la prochaine sauvegarde du journal sera obsolète.

http://msdn.microsoft.com/en-us/library/ms175477.aspx

Selon ma compréhension la seule chose qui tronque le journal des transactions est une sauvegarde du journal.

Une sauvegarde complète ne copie que suffisamment du journal pour qu'elle soit transactionnellement cohérente, car l'opération de sauvegarde prend du temps pour s'achever et que, pendant ce temps, les pages copiées peuvent avoir changé.

Vous avez toujours besoin de vos sauvegardes de journal pour la récupération à un instant donné.

Je n'ai pas MSDN à lier, mais je peux vous diriger vers le blog de Paul Randal, qui était un développeur au sein de l'équipe SQL Server, a écrit DBCC CHECKDB et des parties de Books Online.

Il répond également aux questions sur ce forum, donc ce serait une autorité encore meilleure que des informations de seconde main provenant de moi :)

Les gens ont souvent une idée fausse sur la sauvegarde complète et les sauvegardes de journaux. Pour que la sauvegarde fonctionne dans le modèle de récupération de sauvegarde COMPLÈTE, les t-logs doivent être utilisés, car pendant les sauvegardes, il peut encore y avoir des transactions en cours dans la base de données (sauf si vous effectuez une sauvegarde dite à froid à froid lorsque vous arrêtez la base de données). Oracle utilise le même concept lorsque vous avez une base de données en mode ARCHIVELOG. La séquence d'une sauvegarde se résume à ceci :

1. Démarrer la sauvegarde - suspendre toutes les actions dans les fichiers réels et écrire dans les t-logs.
2. Effectuer la sauvegarde - toutes les transactions se poursuivent, mais ne sont pas écrites dans les fichiers réels, elles sont écrites dans les t-logs
3. Terminer la sauvegarde - reprendre l'écriture des transactions de la base de données dans les fichiers réels.
4. Si nécessaire, vider ce qui se trouve dans les t-logs dans les fichiers réels.

C'est la raison pour laquelle les t-logs ne sont pas tronqués/rétrécis par défaut, car ils sont une partie vitale de la continuation des transactions pendant la phase de sauvegarde.

Ne confondez pas la troncature du journal avec le rétrécissement du journal.

• La TRONCATURE consiste à supprimer les transactions du journal qui sont antérieures au dernier point de contrôle (le point de contrôle étant lorsque les transactions sont écrites dans la base de données elle-même). Cela se fait en utilisant la commande BACKUP.

• Réduire le journal signifie réduire la taille réelle du fichier journal. Cela se fait en utilisant les commandes DBCC.