Description des algorithmes de journalisation et de stockage des données qui augmentent la fiabilité des données dans SQL Server

Version de produit d’origine : SQL Server 2014, SQL Server 2012, SQL Server 2008, SQL Server 2005
Numéro de la base de connaissances d’origine : 230785

Résumé

Cet article explique comment les algorithmes de journalisation et de données Microsoft SQL Server étendent la fiabilité et l’intégrité des données.

Pour en savoir plus sur les concepts sous-jacents des moteurs et sur l’algorithme pour la sémantique d’exploitation de récupération et d’isolation (ARIES), consultez le document ACM Transactions suivantes sur les systèmes de base de données (sous volume 17, numéro 1, mars 1992) :

Lien externe : ARIES : méthode de récupération des transactions prenant en charge le verrouillage de précision et les restaurations partielles à l’aide de la journalisation en écriture anticipée

Le document traite des techniques SQL Server pour étendre la fiabilité et l’intégrité des données en fonction des défaillances.

Nous vous recommandons de lire les articles suivants dans la Base de connaissances Microsoft pour plus d’informations sur la mise en cache et d’autres discussions en mode échec :

• Description de la mise en cache des contrôleurs de disque dans SQL Server

• Informations sur l’utilisation des caches de lecteur de disque avec SQL Server que chaque administrateur de base de données doit connaître

Termes utilisés dans cet article

Avant de commencer la discussion approfondie, certains des termes utilisés dans cet article sont définis dans le tableau suivant.

Terme	Définition
Batterie sauvegardée	Installation de sauvegarde de batterie distincte et localisée directement disponible et contrôlée par le mécanisme de mise en cache pour empêcher la perte de données. Il ne s’agit pas d’une alimentation ininterruptible (UPS). Un UPS ne garantit aucune activité d’écriture et peut être déconnecté de l’appareil de mise en cache.
Cache	Mécanisme de stockage intermédiaire utilisé pour optimiser les opérations d’E/S physiques et améliorer les performances.
Page sale	Page contenant des modifications de données qui ne doivent pas encore être vidées dans un stockage stable. Pour plus d’informations sur les mémoires tampons de pages sales, consultez Écriture de pages dans la documentation en ligne de SQL Server. Le contenu s’applique également à Microsoft SQL Server 2012 et versions ultérieures.
Échec	Tout ce qui peut entraîner une panne inattendue du processus SQL Server. Voici quelques exemples : panne de courant, réinitialisation de l’ordinateur, erreurs de mémoire, autres problèmes matériels, secteurs incorrects, pannes de lecteur, défaillances système, etc.
Purge	Forcer une mémoire tampon de cache à un stockage stable.
Verrou	Objet de synchronisation utilisé pour protéger la cohérence physique d’une ressource.
Stockage nonvolatile	Tout support qui reste disponible entre les défaillances du système.
Page épinglée	Page qui reste dans le cache de données et ne peut pas être vidée dans le stockage stable tant que tous les enregistrements de journal associés ne sont pas sécurisés dans un emplacement de stockage stable.
Stockage stable	Identique au stockage nonvolatile.
Stockage volatile	Tout support qui ne restera pas intact entre les défaillances.

Protocole WAL (Write-Ahead Logging)

Le terme protocole est un excellent moyen de décrire le WAL. Il s’agit d’un ensemble spécifique et défini d’étapes d’implémentation nécessaires pour vous assurer que les données sont stockées et échangées correctement et peuvent être récupérées à un état connu en cas de défaillance. Tout comme un réseau contient un protocole défini pour échanger des données de manière cohérente et protégée, le WAL décrit également le protocole pour protéger les données.

Le document ARIES définit le wal comme suit :

Le protocole WAL affirme que les enregistrements de journal représentant des modifications apportées à certaines données doivent déjà être dans un stockage stable avant que les données modifiées ne soient autorisées à remplacer la version précédente des données dans le stockage nonvolatile. Autrement dit, le système n’est pas autorisé à écrire une page mise à jour dans la version de stockage nonvolatile de la page tant qu’au moins les parties d’annulation des enregistrements de journal, qui décrivent les mises à jour de la page ont été écrites dans un stockage stable.

Pour plus d’informations sur la journalisation en écriture anticipée, consultez la rubrique journal des transactions en écriture anticipée dans la documentation en ligne de SQL Server.

SQL Server et wal

SQL Server utilise le protocole WAL. Pour vous assurer qu’une transaction est correctement validée, tous les enregistrements de journal associés à la transaction doivent être sécurisés dans un stockage stable.

Pour clarifier cette situation, tenez compte de l’exemple spécifique suivant.

Note

Pour cet exemple, supposons qu’il n’y a pas d’index et que la page affectée est la page 150.

BEGIN TRANSACTION
 INSERT INTO tblTest VALUES (1)
COMMIT TRANSACTION

Ensuite, décomposez l’activité en étapes de journalisation simplistes, comme décrit dans le tableau suivant.

.	Actions effectuées
BEGINTRANSACTION	Écrit dans la zone de cache du journal. Toutefois, il n’est pas nécessaire de vider le stockage stable, car SQL Server n’a apporté aucune modification physique.
INSERT INTO tblTest	1. La page de données 150 est récupérée dans le cache de données SQL Server, si elle n’est pas déjà disponible. 2. La page est verrouillée, épinglée et marquée comme sale, et les verrous appropriés sont obtenus. 3. Un enregistrement de journal d’insertion est généré et ajouté au cache du journal. 4. Une nouvelle ligne est ajoutée à la page de données. 5. Le verrou est libéré. 6. Les enregistrements de journal associés à la transaction ou à la page ne doivent pas être vidés à ce stade, car toutes les modifications restent dans le stockage volatile.
COMMIT TRANSACTION	1. Un enregistrement de journal de validation est formé et les enregistrements de journal associés à la transaction doivent être écrits dans un stockage stable. La transaction n’est pas considérée comme validée tant que les enregistrements de journal ne sont pas correctement affectés au stockage stable. 2. La page de données 150 reste dans le cache de données SQL Server et n’est pas immédiatement vidée vers un stockage stable. Lorsque les enregistrements de journal sont correctement sécurisés, la récupération peut rétablir l’opération, si nécessaire. 3. Les verrous transactionnels sont libérés.

Ne confondez pas les termes « verrouillage » et « journalisation ». Bien qu’il soit important, le verrouillage et la journalisation sont des problèmes distincts lorsque vous traitez avec le wal. Dans l’exemple précédent, SQL Server conserve généralement le verrou de la page 150 pour le temps nécessaire pour effectuer les modifications d’insertion physique sur la page, et non l’intégralité du temps de la transaction. Le type de verrou approprié est établi pour protéger la ligne, la plage, la page ou la table si nécessaire. Pour plus d’informations sur les types de verrous, reportez-vous aux sections de verrouillage en ligne de SQL Server.

En examinant l’exemple plus en détail, vous pouvez demander ce qui se passe lorsque les processus LazyWriter ou CheckPoint s’exécutent. SQL Server émet tous les vidages appropriés dans un stockage stable pour les enregistrements de journal transactionnels associés à la page sale et épinglée. Cela permet de s’assurer que la page de données du protocole WAL ne peut jamais être écrite dans un stockage stable tant que les enregistrements de journal transactionnels associés n’ont pas été vidés.

Stockage SQL Server et stable

SQL Server améliore les opérations de journal et de page de données en incluant la connaissance des tailles de secteur disque (généralement 4 096 octets ou 512 octets).

Pour conserver les propriétés ACID d’une transaction, SQL Server doit tenir compte des points d’échec. En cas de défaillance, de nombreuses spécifications de lecteur de disque garantissent uniquement un nombre limité d’opérations d’écriture de secteur. La plupart des spécifications garantissent l’achèvement d’un seul secteur d’écriture lorsqu’une défaillance se produit.

SQL Server utilise des pages de données de 8 Ko et le journal (si vidé) sur plusieurs de la taille du secteur. (La plupart des lecteurs de disque utilisent 512 octets comme taille de secteur par défaut.) En cas de défaillance, SQL Server peut tenir compte des opérations d’écriture supérieures à un secteur en utilisant la parité des journaux et les techniques d’écriture déchirées.

Détection de page déchirée

Cette option permet à SQL Server de détecter les opérations d’E/S incomplètes provoquées par des pannes d’alimentation ou d’autres pannes système. Lorsque la valeur est true, un peu est retourné pour chaque secteur de 512 octets dans une page de base de données de 8 kilo-octets (Ko) chaque fois que la page est écrite sur le disque. Si un bit est dans un état incorrect lorsque la page est lue ultérieurement par SQL Server, la page a été écrite de manière incorrecte ; une page déchirée est détectée. Les pages endommagées sont détectées lors de la récupération, car toute page qui a été écrite de manière incorrecte est susceptible d’être lue par récupération.

Bien que les pages de base de données SQL Server soient de 8 Ko, les disques effectuent des opérations d’E/S à l’aide d’un secteur de 512 octets. Par conséquent, 16 secteurs sont écrits par page de base de données. Une page déchirée peut se produire si le système échoue (par exemple, en raison d’une panne d’alimentation) entre le moment où le système d’exploitation écrit le premier secteur de 512 octets sur le disque et l’achèvement de l’opération d’E/S de 8 Ko. Si le premier secteur d’une page de base de données est correctement écrit avant l’échec, la page de base de données sur le disque apparaît comme mise à jour, même si elle n’a peut-être pas réussi.

En utilisant des caches de contrôleur de disque soutenus par batterie, vous pouvez vous assurer que les données sont correctement écrites sur le disque ou qu’elles n’ont pas été écrites du tout. Dans ce cas, ne définissez pas la détection de page déchirée sur « true », car cela n’est pas nécessaire.

Note

La détection de page déchirée n’est pas activée par défaut dans SQL Server. Pour plus d’informations, consultez Options SET d’ALTER DATABASE (Transact-SQL).

Parité des journaux

La vérification de la parité des journaux est similaire à la détection de page déchirée. Chaque secteur de 512 octets contient des bits de parité. Ces bits de parité sont toujours écrits avec l’enregistrement du journal et évalués lorsque l’enregistrement du journal est récupéré. En forçant les écritures de journal sur une limite de 512 octets, SQL Server peut s’assurer que les opérations de validation sont écrites dans les secteurs de disque physique.

Impact sur les performances

Toutes les versions de SQL Server ouvrent les fichiers journaux et de données à l’aide de la fonction CreateFile Win32. Le membre dwFlagsAndAttributes inclut l’option FILE_FLAG_WRITE_THROUGH lorsqu’il est ouvert par SQL Server.

FILE_FLAG_WRITE_THROUGH indique au système d’écrire dans n’importe quel cache intermédiaire et d’accéder directement au disque. Le système peut toujours mettre en cache les opérations d’écriture, mais ne peut pas les vider de manière différée.

L’option FILE_FLAG_WRITE_THROUGH garantit que lorsqu’une opération d’écriture retourne une réussite, les données sont correctement stockées dans un stockage stable. Cela s’aligne sur le protocole WAL qui garantit les données.

De nombreux lecteurs de disque (SCSI et IDE) contiennent des caches intégrés de 512 Ko, 1 Mo ou plus. Toutefois, les caches de lecteur reposent généralement sur un condensateur et non sur une solution à batterie. Ces mécanismes de mise en cache ne peuvent pas garantir les écritures dans un cycle d’alimentation ou un point de défaillance similaire. Ils garantissent uniquement l’achèvement des opérations d’écriture du secteur. C’est précisément la raison pour laquelle la détection de parité d’écriture et de journal a été intégrée à SQL Server 7.0 et versions ultérieures. À mesure que les lecteurs continuent de croître en taille, les caches deviennent plus volumineux et peuvent exposer de plus grandes quantités de données lors d’une défaillance.

De nombreux fournisseurs de matériel fournissent des solutions de contrôleur de disque avec batterie. Ces caches de contrôleur peuvent conserver les données dans le cache pendant plusieurs jours et même autoriser le matériel de mise en cache à être placé sur un deuxième ordinateur. Lorsque l’alimentation est correctement restaurée, les données non écrites sont vidées avant que l’accès aux données supplémentaires ne soit autorisé. La plupart d’entre eux permettent d’établir un pourcentage de cache de lecture et d’écriture pour des performances optimales. Certains contiennent des zones de stockage de mémoire volumineuses. En fait, pour un segment spécifique du marché, certains fournisseurs de matériel fournissent des systèmes de contrôleur de mise en cache de disque à batterie haut de gamme avec 6 Go de cache. Ceux-ci peuvent améliorer de manière significative les performances de la base de données.

Les implémentations de mise en cache avancées gèrent la FILE_FLAG_WRITE_THROUGH requête en ne désactivant pas le cache du contrôleur, car elles peuvent fournir de véritables fonctionnalités de réécriture en cas de réinitialisation du système, de défaillance d’alimentation ou d’un autre point d’échec.

Les transferts d’E/S sans utilisation d’un cache peuvent être plus longs en raison du temps mécanique nécessaire pour déplacer les têtes de lecteur, les taux de rotation et d’autres facteurs de limitation.

Classement du secteur

Une technique courante utilisée pour augmenter les performances des E/S est l’ordre du secteur. Pour éviter le mouvement mécanique de la tête, les demandes de lecture/écriture sont triées, ce qui permet d’obtenir ou de stocker des données plus cohérentes.

Le cache peut contenir plusieurs demandes de journal et d’écriture de données en même temps. Le protocole WAL et l’implémentation SQL Server du protocole WAL nécessitent un vidage des écritures de journal dans un stockage stable avant que l’écriture de page puisse être émise. Toutefois, l’utilisation du cache peut renvoyer la réussite d’une demande d’écriture de journal sans que les données soient écrites dans le lecteur réel (autrement dit, écrites dans un stockage stable). Cela peut entraîner l’émission par SQL Server de la demande d’écriture de page de données.

Avec l’implication du cache d’écriture, les données sont toujours considérées comme étant dans un stockage volatile. Toutefois, à partir de l’appel WriteFile de l’API Win32, exactement la façon dont SQL Server voit l’activité, un code de retour réussi a été obtenu. SQL Server ou tout processus qui utilise l’appel d’API WriteFile peut déterminer uniquement que les données ont obtenu correctement un stockage stable.

À des fins de discussion, supposons que tous les secteurs de la page de données sont triés pour écrire avant les secteurs des enregistrements de journal correspondants. Cela enfreint immédiatement le protocole WAL. Le cache écrit une page de données avant les enregistrements du journal. Sauf si le cache est entièrement soutenu par batterie, une défaillance peut entraîner des résultats catastrophiques.

Lorsque vous évaluez les facteurs de performances optimaux pour un serveur de base de données, il existe de nombreux facteurs à prendre en compte. La plus importante est la suivante : « Mon système autorise-t-il des fonctionnalités valides FILE_FLAG_WRITE_THROUGH ? »

Note

Tout cache que vous utilisez doit prendre entièrement en charge une solution avec batterie. Tous les autres mécanismes de mise en cache sont susceptibles d’endommager les données et de perdre des données. SQL Server effectue tous les efforts nécessaires pour garantir le wal en activant FILE_FLAG_WRITE_THROUGH.

Les tests ont montré que de nombreuses configurations de lecteur de disque peuvent contenir une mise en cache en écriture sans la sauvegarde de batterie appropriée. Les lecteurs SCSI, IDE et EIDE tirent pleinement parti des caches d’écriture. Pour plus d’informations sur le fonctionnement des DISQUES SSD avec SQL Server, consultez l’article de blog CSS SQL Server Engineers suivant :

SQL Server et SSD - Notes d’apprentissage de RDORR - Partie 1

Dans de nombreuses configurations, la seule façon de désactiver correctement la mise en cache d’écriture d’un lecteur IDE ou EIDE consiste à utiliser un utilitaire de fabricant spécifique ou à utiliser des jumpers situés sur le lecteur lui-même. Pour vous assurer que le cache d’écriture est désactivé pour le lecteur lui-même, contactez le fabricant du lecteur.

Les lecteurs SCSI ont également des caches d’écriture. Toutefois, ces caches peuvent généralement être désactivés par le système d’exploitation. S’il existe une question, contactez le fabricant de lecteurs pour obtenir les utilitaires appropriés.

Écrire un empilement de cache

Le stacking de cache d’écriture est similaire à l’ordre du secteur. La définition suivante a été prise directement à partir d’un site web du fabricant de lecteurs IDE de premier plan :

Normalement, ce mode est actif. Le mode de cache d’écriture accepte les données d’écriture de l’hôte dans la mémoire tampon jusqu’à ce que la mémoire tampon soit complète ou que le transfert de l’hôte soit terminé.

Une tâche d’écriture de disque commence à stocker les données de l’hôte sur le disque. Les commandes d’écriture de l’hôte continuent d’être acceptées et les données transférées vers la mémoire tampon jusqu’à ce que la pile de commandes d’écriture soit pleine ou que la mémoire tampon de données soit pleine. Le lecteur peut réorganiser les commandes d’écriture pour optimiser le débit du lecteur.

Réaffectation automatique d’écriture (AWR)

Une autre technique courante utilisée pour protéger les données consiste à détecter les secteurs incorrects lors de la manipulation des données. L’explication suivante provient du site web d’un fabricant de lecteurs IDE de premier plan :

Cette fonctionnalité fait partie du cache d’écriture et réduit le risque de perte de données pendant les opérations d’écriture différées. Si une erreur de disque se produit pendant le processus d’écriture du disque, la tâche de disque s’arrête et le secteur suspect est réaffecté à un pool de secteurs alternatifs situés à la fin du lecteur. Après la réaffectation, la tâche d’écriture de disque se poursuit jusqu’à ce qu’elle soit terminée.

Il peut s’agir d’une fonctionnalité puissante si la sauvegarde de la batterie est fournie pour le cache. Cela fournit une modification appropriée lors du redémarrage. Il est préférable de détecter les erreurs de disque, mais la sécurité des données du protocole WAL exigerait à nouveau qu’elle soit effectuée en temps réel et non de manière différée. Dans les paramètres WAL, la technique AWR ne peut pas tenir compte d’une situation dans laquelle une écriture de journal échoue en raison d’une erreur de secteur, mais le lecteur est plein. Le moteur de base de données doit immédiatement connaître l’échec afin que la transaction puisse être abandonnée correctement, l’administrateur peut être alerté et les mesures appropriées prises pour sécuriser les données et corriger la situation de défaillance du support.

Sécurité des données

Il existe plusieurs précautions qu’un administrateur de base de données doit prendre pour garantir la sécurité des données.

• Il est toujours judicieux de s’assurer que votre stratégie de sauvegarde est suffisante pour récupérer après une défaillance catastrophique. Le stockage hors site et d’autres précautions sont appropriés.
• Testez fréquemment l’opération de restauration de base de données dans une base de données secondaire ou de test.
• Assurez-vous que tous les appareils de mise en cache peuvent gérer toutes les situations d’échec (panne de courant, secteurs incorrects, lecteurs incorrects, pannes système, verrouillages, pics d’alimentation, etc.).
• Assurez-vous que votre appareil de mise en cache :
  • A une sauvegarde de batterie intégrée
  • Peut réémettre des écritures sur l’alimentation
  • Peut être entièrement désactivé s’il est nécessaire
  • Gère le remapping de secteur incorrect en temps réel
• Activer la détection de page déchirée. (Cela a peu d’effet sur les performances.)
• Configurez des lecteurs RAID permettant un échange chaud d’un lecteur de disque incorrect, si c’est possible.
• Utilisez des contrôleurs de mise en cache plus récents qui vous permettent d’ajouter davantage d’espace disque sans redémarrer le système d’exploitation. Il peut s’agir d’une solution idéale.

Tests de lecteurs

Pour sécuriser entièrement vos données, vous devez vous assurer que toutes les mises en cache des données sont correctement gérées. Dans de nombreuses situations, vous devez désactiver la mise en cache d’écriture du lecteur de disque.

Note

Assurez-vous qu’un autre mécanisme de mise en cache peut gérer correctement plusieurs types de défaillance.

Microsoft a effectué des tests sur plusieurs lecteurs SCSI et IDE à l’aide de l’utilitaire SQLIOSim . Cet utilitaire simule une activité de lecture/écriture asynchrone lourde sur un appareil de données simulé et un appareil de journal. Les statistiques de performances de test montrent les opérations d’écriture moyennes par seconde comprises entre 50 et 70 pour un lecteur avec la mise en cache d’écriture désactivée et une plage RPM comprise entre 5 200 et 7 200.

Pour plus d’informations sur l’utilitaire SQLIOSim , consultez l’article suivant dans la Base de connaissances Microsoft :

Comment utiliser l’utilitaire SQLIOSim pour simuler l’activité SQL Server sur un sous-système de disque

De nombreux fabricants d’ordinateurs commandent les lecteurs en désactivant le cache d’écriture. Toutefois, les tests montrent que cela peut ne pas toujours être le cas. Par conséquent, testez toujours complètement.

Appareils de données

Dans toutes les situations mais non journalisées, SQL Server ne nécessite que les enregistrements de journal à vider. Lorsque vous effectuez des opérations non journalisées, les pages de données doivent également être vidées dans un stockage stable ; il n’existe aucun enregistrement de journal individuel pour régénérer les actions en cas de défaillance.

Les pages de données peuvent rester en cache jusqu’à ce que le processus LazyWriter ou CheckPoint les vide dans un stockage stable. L’utilisation du protocole WAL pour vous assurer que les enregistrements de journal sont correctement stockés garantit que la récupération peut récupérer une page de données à un état connu.

Cela ne signifie pas qu’il est recommandé de placer des fichiers de données sur un lecteur mis en cache. Lorsque SQL Server vide les pages de données dans un stockage stable, les enregistrements de journal peuvent être tronqués à partir du journal des transactions. Si les pages de données sont stockées dans un cache volatile, il est possible de tronquer les enregistrements de journal qui seraient utilisés pour récupérer une page en cas de défaillance. Assurez-vous que vos données et appareils de journal prennent correctement en charge le stockage stable.

Augmentation des performances

La première question qui peut vous arriver est : « J’ai un lecteur IDE qui était en cache. Mais quand je l’ai désactivé, mes performances sont devenues moins que prévu. Pourquoi ?

La plupart des lecteurs IDE testés par Microsoft s’exécutent à 5 200 RPM et les lecteurs SCSI à 7 200 RPM. Lorsque vous désactivez la mise en cache d’écriture du lecteur IDE, les performances mécaniques peuvent devenir un facteur.

Pour résoudre la différence de performances, la méthode à suivre est claire : « Adressez le taux de transaction ».

De nombreux systèmes OLTP (Online Transaction Processing) nécessitent un taux de transaction élevé. Pour ces systèmes, envisagez d’utiliser un contrôleur de mise en cache qui peut prendre en charge un cache d’écriture et fournir l’amélioration des performances souhaitée tout en garantissant l’intégrité des données.

Pour observer des modifications significatives des performances qui se produisent dans SQL Server sur un lecteur de mise en cache, le taux de transaction a été augmenté à l’aide de petites transactions.

Les tests montrent que l’activité d’écriture élevée des mémoires tampons inférieures à 512 Ko ou supérieure à 2 Mo peut entraîner des performances lentes.

Prenons l’exemple suivant :

CREATE TABLE tblTest ( iID int IDENTITY(1,1), strData char(10))
GO

SET NOCOUNT ON
GO

INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 10000
INSERT INTO tblTest VALUES ('Test')

Voici des exemples de résultats de test pour SQL Server :

SCSI(7200 RPM) 84 seconds
SCSI(7200 RPM) 15 seconds (Caching controller)

IDE(5200 RPM) 14 seconds (Drive cache enabled)
IDE(5200 RPM) 160 seconds

Le processus d’habillage de la série entière d’opérations INSERT dans une transaction unique s’exécute en environ quatre secondes dans toutes les configurations. Cela est dû au nombre de vidages de journaux requis. Si vous ne créez pas de transaction unique, chaque INSERT transaction est traitée comme une transaction distincte. Par conséquent, tous les enregistrements de journal de la transaction doivent être vidés. Chaque vidage est de 512 octets de taille. Cela nécessite une intervention de conduite mécanique importante.

Lorsqu’une transaction unique est utilisée, les enregistrements de journal de la transaction peuvent être regroupés et un seul écriture plus volumineux peut être utilisé pour vider les enregistrements de journal collectés. Cela réduit considérablement l’intervention mécanique.

Avertissement

Nous vous recommandons de ne pas augmenter votre étendue de transaction. Les transactions de longue durée peuvent entraîner des blocages excessifs et indésirables et une surcharge accrue. Utilisez les compteurs de performances SQL Server :Databases SQL Server pour afficher les compteurs basés sur le journal des transactions. Plus précisément, les octets de journal vidés/s peuvent indiquer de nombreuses petites transactions pouvant entraîner une activité de disque mécanique élevée.

Examinez les instructions associées au vidage du journal pour déterminer si la valeur Vidage des octets de journal/s peut être réduite. Dans l’exemple précédent, une transaction unique a été utilisée. Toutefois, dans de nombreux scénarios, cela peut entraîner un comportement de verrouillage non souhaité. Examinez la conception de la transaction. Vous pouvez utiliser du code similaire au code suivant pour exécuter des lots afin de réduire l’activité de vidage fréquent et petit des journaux :

BEGIN TRAN
GO

INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 50
    BEGIN
        INSERT INTO tblTest VALUES ('Test')
  
        if(0 = cast(@@IDENTITY as int) % 10)
        BEGIN
            PRINT 'Commit tran batch'
            COMMIT TRAN
            BEGIN TRAN
        END
    END
GO

COMMIT TRAN
GO

SQL Server exige que les systèmes prennent en charge la livraison garantie sur un support stable, comme décrit dans le document de téléchargement des exigences de révision du programme d’E/S SQL Server. Pour plus d’informations sur les exigences d’entrée et de sortie pour le moteur de base de données SQL Server, consultez Moteur de base de données Microsoft SQL Server exigences d’entrée/sortie.