SQL Server (2005/2008): la sauvegarde complète tronque-t-elle le journal en mode de récupération complète
Je viens de lire beaucoup de documentation MSDN et je pense comprendre les différents modèles de récupération et le concept d'une chaîne de sauvegarde. J'ai encore une question:
Une sauvegarde complète de la base de données tronque-t-elle le journal des transactions (en utilisant le mode de récupération complète)?
Si oui: où est-ce mentionné dans le MSDN? Tout ce que j'ai pu trouver, c'est que seul BACKUP LOG tronque le journal.
Si non: pourquoi? Étant donné qu'une sauvegarde complète de la base de données démarre une nouvelle chaîne de sauvegarde, quel est l'intérêt de conserver les transactions finalisées avant la sauvegarde complète active dans le journal?
Non - certainement pas. La seule chose qui permet au journal d'effacer/tronquer dans les modèles de récupération FULL ou BULK_LOGGED est une sauvegarde de journal - sans exception. J'ai eu cet argument il y a quelque temps et j'ai posté un long et détaillé blog avec une explication et un script que vous pouvez utiliser pour le prouver à vous-même sur Idées fausses autour du journal et des sauvegardes de journaux: comment vous convaincre .
N'hésitez pas à poursuivre avec plus de questions. Btw - voir également le long article que j'ai écrit pour TechNet Magazine sur Comprendre la journalisation et la récupération dans SQL Server .
Merci
Une sauvegarde complète NE tronque PAS le journal, vous devez effectuer une opération de journal de sauvegarde. Une sauvegarde complète NE RÉINITIALISE PAS la chaîne de journaux - ce serait complètement gâcher la réplication/l'envoi des journaux, etc.
Vous devez regarder de près comment SQL Server effectue les sauvegardes, mais sachez que les transactions en cours/à long terme ne sont pas incluses dans la sauvegarde (sinon la sauvegarde peut ne jamais se terminer), il n'est donc pas tout à fait exact de dire qu'une sauvegarde complète d'un La base de données en ligne est garantie de rendre la prochaine sauvegarde de journal obsolète.
D'après ma compréhension la seule chose qui tronque le journal des transactions est une sauvegarde du journal .
Une sauvegarde complète copie seulement suffisamment le journal pour qu'il soit cohérent sur le plan des transactions, car il faut un certain temps pour que l'opération de sauvegarde se termine et pendant ce temps, les pages copiées peuvent avoir changé.
Vous avez toujours besoin de vos sauvegardes de journal pour une récupération ponctuelle.
Je n'ai pas de MSDN vers lequel me lier, mais je peux vous lier à le blog de Paul Randal , qui était un développeur de l'équipe SQL Server, a écrit DBCC CHECKDB et des parties de Books Online.
Il répond également aux questions sur ce forum, ce serait donc une autorité encore meilleure que les informations de seconde/troisième main de ma part :)
Les gens ont souvent une idée fausse de la sauvegarde complète et des sauvegardes de journaux. Pour que la sauvegarde fonctionne dans FULL modèle de récupération de sauvegarde, les t-logs doivent être utilisés, car pendant les sauvegardes, il peut toujours y avoir des transactions en cours dans la base de données (à moins que vous n'effectuiez ce que l'on appelle COLD sauvegarde lorsque vous fermez 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:
- Démarrer la sauvegarde - suspendre toutes les actions dans de vrais fichiers et écrire dans les t-logs.
- Effectuer la sauvegarde - toutes les transactions se poursuivent, mais ne sont pas écrites dans de vrais fichiers, elles sont écrites dans des t-logs
- Fin de la sauvegarde - reprenez l'écriture des transactions de base de données dans des fichiers réels.
- Si nécessaire, videz le contenu des journaux T dans les vrais fichiers.
C'est la raison pour laquelle les journaux T ne sont pas par défaut tronqués/rétrécis, car ils constituent une partie vitale de la poursuite des transactions pendant la phase de sauvegarde.
Ne confondez pas tronquer le journal et réduire le journal.
TRUNCATE revient à supprimer les transactions du journal qui se trouvent avant le dernier point de contrôle (le point de contrôle étant lorsque les transactions sont transférées vers la base de données elle-même). Cela se fait à l'aide de la commande BACKUP.
Réduire le journal consiste à réduire la taille réelle du fichier journal. Cela se fait à l'aide des commandes DBCC.
Fondamentalement, vous n'avez pas besoin de réduire automatiquement le journal des transactions à chaque fois car les journaux des transactions ont besoin d'espace pour fonctionner et si vous tronquez automatiquement, il restera presque la même taille.