SQL Server

Enregistrement de la présentation et de récupération dans SQL Server

Paul S. Randal

 

À une vue d'ensemble :

  • Fonctionnement des enregistrement et de récupération dans SQL Server
  • Comment fonctionne le journal des transactions et que vous devez savoir sur la gestion il
  • Modèles de récupération et leur effet sur la journalisation

Contenu

Ce qui est l'enregistrement ?
Qu'est-ce que la récupération ?
Le journal des transactions
Modèles de récupération
Conclusion

Certains des parties plus mal comprises de SQL Server sont sa journalisation et mécanismes de récupération.Le fait que le journal des transactions existe et peut provoquer des problèmes ne Si pas gérés correctement semble confound plusieurs « involontaire DBAs. » Pourquoi est-il possible pour le journal des transactions pour la croissance illimitée ?Pourquoi parfois faut-il si longue à la mise en ligne après un arrêt fatal du système pour la base de données ?Pourquoi ne peut pas enregistrement être désactivé complètement ?Pourquoi ne peut pas je récupérer ma base de données correctement ?Venez quel est le journal des transactions et Pourquoi voit-on ?

Ce sont toutes les questions que je vois à plusieurs reprises sur forums SQL Server et groupes de discussion, et dans cet article J'AI voulez fournir une présentation des enregistrement et système de récupération et expliquez pourquoi il est partie intégrante de SQL Server Storage Engine.JE vous explique l'architecture du journal des transactions et comment les modèles de récupération trois disponibles pour une base de données peuvent modifier le comportement du journal des transactions et le processus de journalisation.Ainsi que la façon, je vous également proposent certains des liens vers ressources couvrant transaction journal Gestion des meilleures pratiques.

Ce qui est l'enregistrement ?

Journalisation et de récupération ne sont pas concepts qui sont propres à SQL Server, tous les systèmes de gestion professionnelle de base de données relationnelle (SGBDR) doivent demandez-leur pour prendre en charge les diverses propriétés ACID de transactions.ACID signifie Atomicity, Cohérence, Isolation et Durabilité, qui sont les propriétés fondamentales d'un système de traitement des transactions (comme un SGBDR).Vous pouvez obtenir des informations supplémentaires informations dans leACID section de propriétés de la bibliothèque MSDN.

Vidéo

Paul Randal explique l'importance de la gestion de votre journal des transactions correctement dans le modèle de récupération complète, et il vous montre techniques permettant cela dans SQL Server.

Opérations dans un SGBDR sont connectées (ou enregistrées) au niveau physique et logique en termes de ce qui se passe dans la structure de stockage de la base de données.Chaque modification aux structures de stockage possède son propre enregistrement journal, qui décrit la structure en cours de modification et que la modification a été.Pour cela de telle sorte que les modifications peuvent être relues ou contrepassée, le cas échéant.Les enregistrements du journal sont stockés dans un fichier spécial appelé le journal des transactions, je vais décrire ce de manière plus détaillée plus tard, mais pour l'instant vous pouvez considérer en tant que fichier accès séquentiel.

Un ensemble d'une ou plusieurs de telles modifications peut être (et en fait, sont toujours) regroupées dans une transaction, qui fournit l'unité d'apporter des modifications (atomicity) à une base de données en tant que loin que les utilisateurs, les développeurs d'applications, de base et DBAs consistent.Une transaction soit réussit (validation) ou échoue/est annulée (annulation).Dans le premier cas, les opérations qui forment la transaction sont forcément soient reflétées dans la base de données.Dans le second cas, les opérations sont forcément ne pas répercutées dans la base de données.

Transactions dans SQL Server sont soit explicite ou implicite.Une transaction explicite est une dans laquelle l'utilisateur ou une application émet une instruction BEGIN TRANSACTION T-SQL, signalement le début d'un groupe de modifications liées à cette session.Une transaction explicite réussit lorsqu'une instruction COMMIT la TRANSACTION est émise, signalisation la réussite du groupe de modifications.Si une instruction TRANSACTION ROLLBACK est émise à la place, toutes les modifications apportées par cette session depuis l'instruction BEGIN TRANSACTION a été émise sont annulées (annulée) et la transaction est annulée.Une restauration de transactions peut également être forcée par un événement externe, comme la base de données exécutant hors d'espace de disque ou un arrêt de serveur, comme je vous explique plus loin.

Une transaction implicite est une dans laquelle l'utilisateur ou de l'application ne pas explicitement émettez une instruction BEGIN TRANSACTION instruction avant d'émettre une instruction T-SQL.Toutefois, étant donné que toutes les modifications de la base de données doivent être transactionnelles, le moteur de stockage démarre automatiquement une transaction en coulisses.Lorsque l'instruction T-SQL a terminé, le moteur de stockage valide automatiquement la transaction qui démarrait d'entourer l'instruction de l'utilisateur.

Vous pouvez considérer que ce n'est pas nécessaire car une seule instruction T-SQL ne sont pas générer un grand nombre des modifications apportées aux structures de stockage de la base de données, mais envisagez quelque chose comme une instruction ALTER INDEX RECONSTRUIRE.Bien que cette instruction ne peut pas être contenue dans une transaction explicite, il peut générer un numéro énorme de modifications apportées à la base de données.Ainsi, il doit exister un mécanisme pour garantir que si quelque chose se tromper lorsque l'on (l'instruction est annulée, par exemple), toutes les modifications sont correctement annulés.

Par exemple, envisagez ce qui se produit lorsqu'une ligne seule table est mise à jour dans une transaction implicite.Imaginez une table tas simple avec un c1 de la colonne entière et une celui-ci colonne char.La table comporte des lignes 10 000, et un utilisateur soumet une requête Mise à jour comme suit :

UPDATE SimpleTable SET c1 = 10 WHERE c2 LIKE '%Paul%';

Lieu de l'une des opérations suivantes :

  • Les pages de données à partir de SimpleTable sont lues à partir du disque en mémoire (le pool de tampons) afin qu'ils peuvent rechercher les lignes correspondantes. Il s'avère que trois des pages données contenir cinq lignes qui correspond le prédicat de clause WHERE.
  • Le moteur de stockage lance automatiquement une transaction implicite.
  • Les pages de données trois et les lignes de données cinq sont verrouillés pour autoriser les mises à jour de se produire.
  • Les modifications sont apportées aux enregistrements cinq données sur les pages trois données en mémoire.
  • Les modifications sont également enregistrées dans les enregistrements du journal dans le journal des transactions sur le disque.
  • Le moteur de stockage valide automatiquement les transactions implicites.

Notez que je n'a pas répertorie une étape dans lequel les pages de trois données mis à jour sont écrites sortie sur le disque. Il s'agit car ils n'avez encore pas besoin d'être ; tant que les enregistrements du journal décrivent les modifications sont sur le disque dans le journal des transactions, alors les modifications sont protégées. Si les pages doivent être ensuite lire ou modifiées de nouveau, puis la copie plus récente de la page est déjà en mémoire, mais pas sur le disque (encore). Les pages de données sont écrites sur le disque lorsque l'opération point de contrôle suivante se produit ou si la mémoire qu'ils utilisent dans le pool de mémoire tampon est nécessaire pour une autre image de page.

Points de contrôle existent pour deux raisons, au traitement par lots des écriture e / S pour améliorer les performances et réduire le temps requis pour la récupération sur incident. En termes de performances, si une page de données a été forcé insérée les sur le disque chaque fois qu'il a été mis à jour, le nombre d'écriture e / S se produisant sur un système de disponibilité peut facilement submerger le sous-système d'E / S. Il est préférable d'écrire régulièrement pages sale (pages qui ont été modifiés depuis la lecture à partir du disque) que pour écrire des pages immédiatement comme ils sont modifiés. Je vais étudier l'aspect de récupération de points de contrôle dans un instant.

Tort sur les points de contrôle est qu'ils uniquement écrivent des pages avec des modifications des transactions validées. Ce n'est pas cet argument a la valeur true, une point de contrôle écrit toujours tout page sale, quel que soit si la transaction qui a modifié une page a validé ou non.

Enregistrement de transfert en écriture est le mécanisme lesquels les enregistrements du journal décrivant une modification sont écrits sur le disque avant que les modifications elles-mêmes sont écrites. Il fournit la durabilité partie les propriétés ACID. Tant que les enregistrements du journal décrivant les modifications sont sur le disque, en cas d'un incident, les enregistrements du journal (et donc les modifications elles-mêmes) peuvent être récupérés et les effets de la transaction ne sont pas perdues.

Qu'est-ce que la récupération ?

Vous recherchez des conseils SQL Server ?

Pour obtenir des conseils sur SQL Server, visitez le Conseils SQL Server Magazine TechNet page.

Pour plus de conseils sur d'autres produits, visitez le Index TechNet Magazine pourboires.

Enregistrement existe prennent en charge une variété d'opérations dans SQL Server. Elle garantit que si un incident se produit, une transaction validée est correctement répercutée dans la base de données après l'incident. Il êtes sûr une transaction non validée va être correctement restaurée et ne pas reflétée dans la base de données après un incident. Il garantit que qu'il est possible d'annuler une transaction de l'exécution et ont toutes ses opérations annulées. Elle permet une copie de sauvegarde le journal des transactions à prendre afin que d'une base de données peut être restauré et les sauvegardes du journal transaction relus présentant la base de données à un point spécifique dans le temps avec cohérence transactionnelle. Et fonctionnalités qui dépendent de lire le journal des transactions, tel que réplication, la mise en miroir de base de données et capture de données modification prend en charge.

La majorité de ces utilisations de journalisation impliquent un mécanisme appelé récupération. Récupération est le processus de devoir les modifications décrites dans les enregistrements de journal relu ou annulées dans la base de données. Relecture des enregistrements du journal est appelée RÉTABLIR (ou la roulette vers l'avant) phase de récupération. Journal rétablissement enregistrements est appelée Annuler (ou en rouleau) phase de récupération. En d'autres termes, récupération est Assurez-vous qu'une transaction et tous ses enregistrements de journal constitutifs sont soit rétablies ou annulées.

L'écran simple de récupération est lorsqu'une transaction est annulée, auquel cas elle est annulée et il est sans effet net sur la base de données. Le formulaire plus complexe est récupération sur incident, lorsque SQL Server se bloque (pour ce que le motif) et le journal des transactions doit être récupérée pour placer la base de données à un point de façon transactionnelle cohérent. Cela signifie que toutes les transactions qui ont été validées au moment de l'incident doivent être appliquées avant pour garantir que leurs effets sont conservées dans la base de données. Et toutes les transactions l'exécution qui n'a pas validé au moment de l'incident doivent être restaurées afin de que leurs effets ne sont conservées dans la base de données.

Cela est car il n'existe aucune fonction d'une transaction dans SQL Server pour continuer après un incident. Par conséquent, si les effets d'une transaction partiellement complète ont été annulées pas, la base de données serait rester dans un état incohérent (voire même structurellement endommagé, en fonction de la transaction était au milieu d'ainsi).

Donc comment récupération savoir quoi faire ? Tous les processus de récupération dépendent du fait que chaque enregistrement de journal est marqué avec un numéro de séquence journal (enregistrement). Un numéro de séquence de journal est un numéro croissante, trois parties qu'unique définit la position d'un enregistrement journal dans le journal des transactions. Chaque enregistrement de journal dans une transaction est stockée dans un ordre séquentiel dans le journal des transactions et affiche le numéro de transaction et le numéro de l'enregistrement journal précédent de la transaction. Autrement dit, chaque opération est enregistrée comme une partie de la transaction contient un « lien « revenir à l'opération qui immédiatement précédé il.

Pour le cas simple d'une transaction unique est annulée, le mécanisme de récupération peut facilement et rapidement suivre la chaîne des opérations consignées de la dernière opération revenir à la première opération et annuler les effets des opérations dans l'ordre inverse à partir de laquelle ils se sont produits. Les pages de base de données qui ont été affectés par la transaction sont toujours dans le pool de mémoire tampon ou sur le disque. Dans les deux cas, l'image de la page qui est disponible est certain d'être une dans laquelle l'effet de la transaction est reflétée dans la page et doit être annulée.

Lors de la récupération sur incident, le mécanisme est plus complexe. Le fait que les pages de base de données sont écrites pas sur le disque lorsqu'une transaction valide signifie que n'est aucune garantie que le jeu de pages de base de données sur disque reflète avec précision le jeu de modifications décrites dans le journal des transactions, soit pour les transactions validées ou non validées. Toutefois, il existe une information finale le puzzle n'ont pas mentionné encore, toutes les pages de base de données ont un champ dans leur en-tête de page (une partie de 96 octet de la page 8192 octet contenant des métadonnées à propos de la page) qui contient le numéro du dernier enregistrement journal affecté de la page. Cela permet au système récupération d'une décision à faire sur un enregistrement de journal particulier qu'il doit récupérer :

  • Pour un enregistrement de journal à partir d'une transaction validée où la page de base de données possède une égale numéro à ou supérieur à l'enregistrement de l'enregistrement journal, rien ne doit être effectuée. L'effet de l'enregistrement de journal a déjà été conservée sur la page de disque.
  • Pour un enregistrement de journal d'une transaction validée où la page de base de données possède un numéro inférieur à l'enregistrement de l'enregistrement journal, l'enregistrement de journal doit être rétablie afin de que les effets de transaction sont conservées.
  • Pour un enregistrement journal d'une transaction non validée dans laquelle la page de base de données a une égale numéro à ou supérieur à l'enregistrement de l'enregistrement de journal, l'enregistrement de journal doit être annulé pour garantir que les effets de transaction ne sont conservées.
  • Pour un enregistrement du journal d'une transaction non validée dans laquelle la page de base de données a un numéro inférieur à l'enregistrement de l'enregistrement de journal, rien ne doit être effectuée. L'effet de l'enregistrement de journal n'est pas conservée sur la page de disque et en tant que tel n'a pas besoin d'être annulée.

Récupération sur incident lit dans le journal des transactions et garantit que tous les effets de validées toutes les transactions sont conservées dans la base de données, et tous les effets de toutes les transactions non validées ne sont conservées dans la base de données, les RÉTABLIR et Annuler phases, respectivement. Une fois la récupération sur incident terminée, la base de données est façon transactionnelle cohérente et disponible pour utilisation.

Je L'AI expliqué précédemment qu'une du utilise d'une opération point de contrôle consiste à réduire le temps Arrêt prend de récupération. En vidant régulièrement des toutes les pages sale sur le disque, le nombre de pages qui ont changé en raison de transactions validées mais dont les images ne sont pas sur le disque est réduit. Cela, à son tour, réduit le nombre de pages qui doit avoir la récupération de RÉTABLISSEMENT appliquée pendant la récupération sur incident.

Le journal des transactions

Récupération de l'incident est uniquement possible si le journal des transactions est intact. En fait, le journal des transactions est la partie de la base de données la plus importante, il est le seul endroit où toutes les modifications de la base de données sont garanties pour être décrite dans le cas d'un incident.

Si le journal des transactions est manquant ou endommagé après un incident, puis récupération sur incident ne peut pas effectuer, menant à une base de données suspect. Dans ce cas, la base de données doit être restauré à partir de sauvegardes ou récupérées en utilisant moins souhaitable options, telles que la réparation d'urgence mode. (Ces procédures n'entrent pas dans le cadre de cet article mais seront abordés en détail dans les articles plus loin dans l'exercice.)

Le journal des transactions est un fichier spécial qui chaque base de données nécessaires pour fonctionner correctement. Elle contient les enregistrements de journal qui sont générés à partir de l'enregistrement et sont utilisées pour les lire lors de récupération (ou l'un des autres utilisations de journalisation Qu'avons déjà mentionné). Ainsi que l'espace occupé par les enregistrements du journal elles-mêmes, une transaction également réserve espace dans le journal des transactions pour les enregistrements du journal potentiel obligatoire si la transaction doit être annulée et requis pour restaurer. Cette comptes pour le problème vous pouvez observer où, par exemple, une transaction qui met à jour 50MB des données dans la base de données peut en fait besoin 100MB d'espace de journal de transaction.

Lorsqu'une nouvelle base de données est créée, le journal des transactions est essentiellement vide. Lorsque transactions se produisent, les enregistrements de journal sont écrits séquentiel dans le journal des transactions, qui signifie qu'aucun gain de performance de créer des transactions plusieurs fichiers journaux, très tort. Le journal des transactions utilise chaque fichier journal à son tour.

Enregistrements du journal des transactions simultanées peuvent être insérés dans le journal des transactions. N'oubliez pas qu'enregistrements du journal d'une transaction unique sont liées par leurs LSNs, il est donc pas nécessaire pour tous les enregistrements journal pour une transaction être regroupées dans le journal. LSNs peuvent presque être considérés comme un cachet de date.

L'architecture physique du journal des transactions est illustrée dans la figure 1 . Elle est fractionnée en interne en segments plus petits appelés fichiers journaux virtuels (ou VLFs). Il s'agit simplement une aide pour la gestion interne plus facile du journal des transactions. Lorsqu'un fichier journal virtuel complet, enregistrement automatique continue à utiliser le fichier journal virtuel suivant dans le journal des transactions. Vous pourriez considérer que finalement le journal des transactions s'exécute hors de l'espace, mais cela où le journal des transactions est si différents de fichiers de données.

fig01.gif

Figure 1 architecture physique de la transaction de journal

Le journal des transactions s'agit d'un fichier circulaire, tant que les enregistrements du journal au début du journal des transactions ont été tronqués (ou désactivées). Puis lorsque la journalisation atteint la fin du journal des transactions, qu'il habille à nouveau au début et commence à remplacer ce qui s'y trouvait avant.

Comment enregistrements du journal obtenir tronquées afin de l'espace qu'ils occupés peut être réutilisé ? Un enregistrement de journal n'est plus nécessaire dans le journal des transactions si toutes des options suivantes sont réunies :

  • La transaction dont il fait partie est engagé.
  • Les pages de base de données qu'il modifié ont toutes été écrites sur le disque par un point de contrôle.
  • L'enregistrement de journal n'est pas nécessaire d'une sauvegarde (complète, différentielle ou journal).
  • L'enregistrement de journal n'est pas nécessaire pour une fonctionnalité qui lit le journal (tel que la mise en miroir de base de données ou par réplication).

Un enregistrement de journal qui est toujours nécessaire est appelé actif, et un fichier journal virtuel possède au moins un enregistrement de journal actif est également appelée actif. EVERY si souvent, le journal des transactions est activée pour voir si tous les enregistrements journal dans un fichier journal virtuel complet sont actifs ou non ; s'ils sont tous inactifs, le fichier journal virtuel est marqué comme tronqué (c'est-à-dire que le fichier journal virtuel peut être écrasée lorsque le journal des transactions encapsule). Lorsqu'un fichier journal virtuel est tronqué, il n'est pas remplacé ou mis à zéro en aucune manière, il est simplement marqué comme tronqué et puis peut être réutilisé.

Ce processus est appelé troncature des journaux, à ne pas confondre avec réellement réduisant la taille du journal Transactions de. Troncature des journaux ne modifie la taille physique du journal des transactions, uniquement les parties du journal des transactions sont actifs ou non. figure 2 illustre le journal des transactions de 1 figure après que troncation s'est produit.

fig02.gif

La figure 2 de la transaction de se connecter après la troncature des journaux

Actif Vérifiez VLFs de du journal logique, la partie du journal des transactions qui contient tous les enregistrements de journal actif. La base de données elle-même sait où incident récupération doit commencer à lire les enregistrements du journal dans la partie active du journal, le début de la plus ancienne transaction active dans le journal, le MinLSN (cela est stockée dans la page de démarrage de la base de données).

Récupération de l'incident ne sait pas où arrêter la lecture d'enregistrements du journal, donc il continue jusqu'à ce qu'elle atteigne une section zeroed du journal des transactions (si le journal des transactions n'a pas encore enveloppée) ou un enregistrement de journal dont bits de parité n'entrent pas la séquence de l'enregistrement de journal précédent.

Comme VLFs sont tronqués et nouveaux devenue actives, le journal logique se déplace dans le fichier journal de transaction physique et finalement doit habiller au début, comme illustré dans La figure 3 .

fig03.gif

La figure 3, la nature circulaire du journal des transactions

La vérification Si troncature des journaux peut avoir lieu dans une des circonstances suivantes :

  • Lorsqu'un point de contrôle survient dans le modèle de récupération SIMPLE ou dans d'autres modèles de récupération lorsqu'une sauvegarde complète n'a été effectuée. (Cela implique qu'une base de données restent dans un modèle de récupération pseudo-SIMPLE après est passé de SIMPLE jusqu'à ce qu'une sauvegarde complète de la base de données se produit.)
  • Lorsqu'une sauvegarde du journal complète.

N'oubliez pas que troncature des journaux ne peut pas être possible de nombreuses raisons qu'un enregistrement de journal doit rester actif. Lorsque troncature des journaux ne peut pas se produire, les VLFs ne peut pas être tronqués et finalement le journal des transactions doit augmenter (ou ajouter un autre fichier du journal des transactions). Transaction excessive journal croissance peut entraîner des problèmes performances via un phénomène, appelé fragmentation du fichier journal virtuel. Suppression de fragmentation du fichier journal virtuel peut parfois entraîner une amélioration considérablement les performances des activités liées de journal.

Pour plus d'informations sur ce, voir du Kimberly Tripp blog publier » Étapes 8 pour mieux le débit du journal des transactions." Kimberly décrit recommandées relatives à la transaction journal capacité de planification, gestion et performances accrues, il est également important de lecture !

Il existe deux problèmes courants qui peuvent empêcher troncature des journaux :

  • Une transaction de longue active. Le journal des transactions entière étant donné que le premier enregistrement journal de la plus ancienne transaction active peut jamais être tronqué jusqu'à ce que cette transaction valide ou Abandon.
  • Basculer vers le modèle de récupération complète, prise d'une sauvegarde complète et en puis jamais prenant les connecter les sauvegardes. Le journal des transactions entier restera actif, en attente d'être sauvegardés par une sauvegarde du journal.

Pour une liste complète des facteurs et des instructions sur la façon de déterminer ce qui empêche troncature des journaux, voir la rubrique documentation en ligne de SQL Server » Facteurs qui peuvent retarder troncation du journal." J'ai également créé une démonstration de vidéo montre l'effet de croissance de journal de transactions non contrôlé et comment supprimer la fragmentation du fichier journal virtuel, consultez cette vidéo screencast (et screencasts précédente sur des sujets SQL) à technetmagazine.com/Videos.

Si le journal des transactions s'agrandit pour capacité et ne peut pas augmenter les en outre, puis erreur 9002 sera signalée et vous devrez prendre des mesures pour fournir plus d'espace, comme croissance du fichier journal, l'ajout d'un autre fichier journal ou supprimer n'importe quel impediment dans le journal est tronqué.

Aucun circonstances devez vous supprimer le journal des transactions, essayez de recréer en utilisant les commandes non documentées ou simplement tronquer en utilisant les options NO_LOG ou TRUNCATE_ONLY du journal de sauvegarde (qui ont été supprimées dans SQL Server 2008). Ces options soit provoquer incohérence transactionnelle (et plus probablement endommagé) ou supprimer la possibilité de pouvoir récupérer correctement la base de données.

Pour plus d'informations sur la résolution d'un journal des transactions complet, consultez la rubrique documentation en ligne » Dépannage d'un journal des transactions complet (erreur 9002)."

Modèles de récupération

Comme vous le constatez, le comportement du journal des transactions dépend en partie sur la base de données utilise le modèle de récupération. Il existe trois modes de récupération disponible, et elles ont une incidence sur transaction journal comportement comment les opérations sont enregistrées ou les deux.

La récupération complète signifie que chaque partie de chaque opération est connecté, qui est appelée entièrement consignée. Une fois une sauvegarde complète de la base de données a été effectuée au modèle de récupération complète, le journal des transactions est automatiquement tronque pas jusqu'à ce qu'une sauvegarde du journal est prise. Si vous ne souhaitez pas qu'utilisation des sauvegardes du journal et la possibilité de récupérer une base de données à un point spécifique dans le temps, n'utilisez pas le modèle de récupération complète. Toutefois, si vous souhaitez utiliser la mise en miroir de base de données, puis vous n'avez aucun choix, comme il prend uniquement en charge la récupération complète.

Le mode de récupération BULK_LOGGED a la même sémantique troncature des journaux transaction le modèle de récupération complète mais permet à certaines opérations être partiellement connecté, qui est appelée faiblement consignée. Une reconstruction d'index et de certaines opérations de chargement en bloc sont des exemples, dans le modèle de récupération complète l'opération entière est enregistrée.

Mais au BULK_LOGGED modèle de récupération uniquement l'allocation de modifications sont connectées, qui réduit considérablement le nombre d'enregistrements du journal généré et à son tour, réduit le risque pour la croissance de journal des transactions. Pour plus d'informations sur les opérations faiblement connectées, consultez la section documentation en ligne » Les opérations qui peuvent être enregistrées minimum."

Enfin, le modèle de récupération SIMPLE a en fait le même comportement enregistrement en tant que la récupération BULK_LOGGED, mais la sémantique de troncation de journal transaction est assez différent. Sauvegardes de journaux ne sont pas possibles dans le modèle de récupération SIMPLE, qui signifie que le journal peut être tronqué (à condition que rien d'autre est maintenant enregistrements du journal actif) quand une point de contrôle se produit. Il et des inconvénients à chacun de ces modes de récupération en termes des sauvegardes sont possibles (ou nécessaire) et la capacité à récupérer à différents points dans le temps (j'aborderai cela dans un autre article plus tard cette année).

Conclusion

Cet article a été réellement une explication plus universitaire de fonctionne d'une partie essentielle de SQL Server. J'espère que j'ai géré effacer des tout misconceptions que vous avez peut-être dû. Si c'est votre première introduction à la journalisation et de récupération, Voici les principaux points que j'aimerais vous permet de prendre extérieur de cet article :

  • Ne créez pas plusieurs fichiers journaux, comme il va entraîner un gain de performance.
  • Connaître le modèle de récupération utilise votre base de données et l'effet sur le journal des transactions, en particulier autour si il peut automatiquement tronquer ou pas lorsqu'un point de contrôle se.
  • Être conscient de risque de croissance de journal des transactions, les facteurs qui peuvent entraîner et comment l'obtenir sauvegarder sous contrôle.
  • Savoir où rechercher l'aide lors du dépannage d'un journal des transactions complet.

Sur mon blog, j'ai plus beaucoup d'informations sur le journal des transactions et les facteurs qui affectent les il — voir mon category valider blog » Journal des transactions« Pour plus d'informations. Diverses rubriques de documentation en ligne concernant le journal des transactions sont également très bonnes, commençant par Gestion des journaux de transactions.

Comme toujours, si vous avez des commentaires ou des questions, veuillez ignorer m'une ligne à Paul@SQLskills.com.

Grâce à Kimberly l. Tripp pour fournir une révision technique de cet article.

S Paul Randal est le directeur Gestion de SQLskills.comet un MVP de SQL Server. Il a travaillé dans l'équipe SQL Server Storage Engine chez Microsoft de 1999 à 2007. Paul écrit DBCC CHECKDB/réparation pour SQL Server 2005 et était responsable pour le moteur de stockage base pendant le développement de SQL Server 2008. Paul est un expert de la récupération après incident, haute disponibilité et la maintenance de base de données et un présentateur standard à des conférences dans le monde entier. Blogs il à SQLskills.com/blogs/paul.