Description des algorithmes de journalisation et de stockage des données qui étendent la fiabilité des données dans SQL Server
Version du 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 Microsoft SQL Server les algorithmes de journalisation et de données é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 ARIES (Algorithm for Recovery and Isolation Exploiting Semantics), consultez le document transactions ACM sur les systèmes de base de données suivant (sous Volume 17, Numéro 1, mars 1992) :
Le document traite des techniques SQL Server pour étendre la fiabilité et l’intégrité des données en lien avec les 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 les discussions en mode d’échec alternatif :
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 avec batterie | Installation de sauvegarde de batterie distincte et localisée directement disponible et contrôlée par le mécanisme de mise en cache pour éviter la perte de données. Il ne s’agit pas d’un ondule ininterruptible. Un OND 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 incorrecte | Page contenant des modifications de données qui ne doivent pas encore être vidées dans un stockage stable. Pour plus d’informations sur sale mémoires tampons de page, consultez Écriture de pages dans SQL Server documentation en ligne. Le contenu s’applique également à Microsoft SQL Server 2012 et versions ultérieures. |
| Échec | Tout ce qui peut provoquer une panne inattendue du processus de SQL Server. Exemples : panne de courant, réinitialisation de l’ordinateur, erreurs de mémoire, autres problèmes matériels, secteurs défectueux, pannes de lecteurs, défaillances système, etc. |
| Rincer | Forçage d’une mémoire tampon de cache vers un stockage stable. |
| Loquet | Objet de synchronisation utilisé pour protéger la cohérence physique d’une ressource. |
| Stockage non volatile | Tout support qui reste disponible sur 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 un 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 non volatile. |
| Stockage volatile | Tout support qui ne restera pas intact lors des défaillances. |
Write-Ahead Journalisation (WAL)
Le terme protocole est un excellent moyen de décrire WAL. Il s’agit d’un ensemble spécifique et défini d’étapes d’implémentation nécessaires pour s’assurer que les données sont stockées et échangées correctement et qu’elles 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 les modifications apportées à certaines données doivent déjà se trouver 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 un stockage non volatile. Autrement dit, le système n’est pas autorisé à écrire une page mise à jour dans la version de stockage non volatile de la page tant qu’au moins les parties d’annulation des enregistrements de journal, qui décrivent les mises à jour de la page, n’ont pas été écrites dans un stockage stable.
Pour plus d’informations sur la journalisation de l’écriture anticipée, consultez la rubrique Journal des transactions d’écriture anticipée dans SQL Server documentation en ligne.
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, considérez l’exemple spécifique suivant.
Remarque
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.
| Statement | Actions effectuées |
|---|---|
| BEGIN TRANSACTION | Écrit dans la zone du cache du journal. Toutefois, il n’est pas nécessaire de vider vers un stockage stable, car le SQL Server n’a apporté aucune modification physique. |
| INSERT INTO tblTest | 1. La page de données 150 est récupérée dans SQL Server cache de données, si elle n’est pas déjà disponible. 2. La page est verrouillée, épinglée et marquée sale, et les verrous appropriés sont obtenus. 3. Un enregistrement insérer un journal 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 relâché. 6. Les enregistrements de journal associés à la transaction ou à la page n’ont pas besoin d’être vidés à ce stade, car toutes les modifications restent dans un 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 du journal n’ont pas été correctement affectés au stockage stable. 2. La page de données 150 reste dans SQL Server cache de données et n’est pas immédiatement vidée dans un stockage stable. Lorsque les enregistrements du 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 vous confondez pas avec les termes « verrouillage » et « journalisation ». Bien qu’importants, 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 sur la page 150 pendant le temps nécessaire pour effectuer les modifications d’insertion physique sur la page, et non la durée entière 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 la documentation en ligne SQL Server.
En examinant l’exemple plus en détail, vous pouvez vous demander ce qui se passe lors de l’exécution des processus LazyWriter ou CheckPoint. SQL Server émet tous les vidages appropriés dans le stockage stable pour les enregistrements de journal transactionnels associés à la page sale et épinglée. Cela garantit que la page de données du protocole WAL ne peut jamais être écrite dans un stockage stable tant que les enregistrements du journal transactionnel associés n’ont pas été vidés.
SQL Server et stockage stable
SQL Server améliore les opérations de journalisation et de page de données en incluant la connaissance des tailles de secteur de disque (généralement 4 096 octets ou 512 octets).
Pour conserver les propriétés ACID d’une transaction, le SQL Server doit tenir compte des points de défaillance. 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’une écriture de secteur unique en cas de défaillance.
SQL Server utilise des pages de données de 8 Ko et le journal (s’il est vidé) sur les multiples de la taille du secteur. (La plupart des lecteurs de disque utilisent 512 octets comme taille de secteur par défaut.) En cas d’échec, SQL Server peut tenir compte des opérations d’écriture plus grandes qu’un secteur en utilisant la parité des journaux et des techniques d’écriture déchirées.
Détection de page déchirée
Cette option permet aux SQL Server de détecter les opérations d’E/S incomplètes provoquées par des pannes d’alimentation ou d’autres pannes du système. Quand la valeur est true, un bit 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 pendant 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 SQL Server pages de base de données 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 en cas de défaillance du système (par exemple, en raison d’une panne de courant) entre le moment où le système d’exploitation écrit le premier secteur de 512 octets sur le disque et la fin 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 étant mise à jour, même si elle n’a peut-être pas réussi.
En utilisant des caches de contrôleur de disque avec batterie, vous pouvez vous assurer que les données sont correctement écrites sur le disque ou pas du tout écrites. Dans ce cas, ne définissez pas la détection de page déchirée sur « true », car cela n’est pas nécessaire.
Remarque
La détection des pages déchirées n’est pas activée par défaut dans SQL Server. Pour plus d’informations, consultez Options ALTER DATABASE SET (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 lors de la récupération de l’enregistrement de journal. En forçant les écritures de journaux sur une limite de 512 octets, SQL Server pouvez 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 ouvrir les fichiers journaux et les fichiers de données à l’aide de la fonction Win32 CreateFile. Le membre dwFlagsAndAttributes inclut l’option FILE_FLAG_WRITE_THROUGH lorsqu’ils sont ouverts 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 paresseusement.
L’option FILE_FLAG_WRITE_THROUGH permet de s’assurer que lorsqu’une opération d’écriture retourne une exécution réussie, 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 s’appuient généralement sur un condensateur et non sur une solution reposant sur batterie. Ces mécanismes de mise en cache ne peuvent pas garantir les écritures sur 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 d’écriture et de parité des journaux a été intégrée à SQL Server 7.0 et versions ultérieures. À mesure que la taille des lecteurs augmente, les caches deviennent plus volumineux et peuvent exposer de plus grandes quantités de données en cas de 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 permettre au matériel de mise en cache d’ê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 supplémentaire aux données 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 de grandes zones de stockage de mémoire. En fait, pour un segment spécifique du marché, certains fournisseurs de matériel fournissent des systèmes haut de gamme de contrôleurs de mise en cache de disque avec batterie avec 6 Go de cache. Ceux-ci peuvent améliorer considérablement les performances de la base de données.
Les implémentations de mise en cache avancées gèrent la FILE_FLAG_WRITE_THROUGH demande 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 panne de courant ou d’un autre point de défaillance.
Les transferts d’E/S sans l’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 des secteurs
Une technique courante utilisée pour augmenter les performances d’E/S est l’ordre de secteur. Pour éviter les mouvements mécaniques de la tête, les demandes de lecture/écriture sont triées, ce qui permet un mouvement plus cohérent de la tête pour récupérer ou stocker les données.
Le cache peut contenir simultanément plusieurs demandes d’écriture de journaux et de données. Le protocole WAL et l’implémentation SQL Server du protocole WAL nécessitent le 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 sur le lecteur réel (autrement dit, écrites dans un stockage stable). Cela peut entraîner SQL Server’émission 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 comment 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 uniquement déterminer que les données ont correctement obtenu un stockage stable.
À des fins de discussion, supposons que tous les secteurs de la page de données sont triés pour être écrits avant les secteurs des enregistrements de journal correspondants. Cela viole immédiatement le protocole WAL. Le cache écrit une page de données avant les enregistrements du journal. À moins que le cache ne soit entièrement alimenté par batterie, une défaillance peut entraîner des résultats catastrophiques.
Lorsque vous évaluez les facteurs de performances optimales pour un serveur de base de données, de nombreux facteurs doivent être considérés. La plus importante d’entre elles est « Mon système autorise-t-il des fonctionnalités valides FILE_FLAG_WRITE_THROUGH ? »
Remarque
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 sujets à l’altération et à la perte de données. SQL Server met tout en œuvre 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 la façon dont les disques SSD fonctionnent 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 fabricant spécifique ou à utiliser des cavaliers 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. En cas de question, contactez le fabricant du lecteur pour connaître les utilitaires appropriés.
Empilement du cache d’écriture
L’empilement du cache en écriture est similaire à l’ordre de secteur. La définition suivante a été extraite directement du site web d’un fabricant de lecteurs IDE de premier plan :
Normalement, ce mode est actif. Le mode 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 pleine ou que le transfert de l’hôte soit terminé.
Une tâche d’écriture sur 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 d’écriture automatique (AWR)
Une autre technique courante utilisée pour protéger les données consiste à détecter les secteurs défectueux pendant 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ée. Si une erreur de disque se produit pendant le processus d’écriture sur 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éallocation, la tâche d’écriture sur disque continue jusqu’à ce qu’elle soit terminée.
Il peut s’agir d’une fonctionnalité puissante si la sauvegarde de batterie est fournie pour le cache. Cela permet 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 que cette opération 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 correctement abandonnée, que l’administrateur puisse être alerté et que les mesures appropriées soient prises pour sécuriser les données et corriger la situation de défaillance du média.
Sécurité des données
Un administrateur de base de données doit prendre plusieurs précautions 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. L’entreposage 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 de défaillance (panne de courant, secteurs défectueux, disques défectueux, panne du système, verrouillages, pic d’alimentation, etc.).
- Assurez-vous que votre appareil de mise en cache :
- Dispose d’une sauvegarde de batterie intégrée
- Peut réémettre des écritures sous tension
- Peut être entièrement désactivé si nécessaire
- Gère le remappage de secteur incorrect en temps réel
- Activer la détection des pages déchirées. (Cela a peu d’effet sur les performances.)
- Configurez les lecteurs RAID pour permettre l’échange à chaud d’un lecteur de disque défectueux, si possible.
- Utilisez des contrôleurs de mise en cache plus récents qui vous permettent d’ajouter de l’espace disque sans redémarrer le système d’exploitation. Il peut s’agir d’une solution idéale.
Test des 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.
Remarque
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 intensive sur un appareil de données simulé et un périphérique de journal. Les statistiques de performances de test montrent la moyenne des opérations d’écriture par seconde comprises entre 50 et 70 pour un lecteur avec mise en cache d’écriture désactivée et une plage de 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 :
De nombreux fabricants d’ordinateurs commandent les lecteurs en ayant le cache d’écriture désactivé. Toutefois, les tests montrent que ce n’est pas toujours le cas. Par conséquent, toujours tester complètement.
Appareils de données
Dans toutes les situations sauf les situations non journalisées, SQL Server nécessite uniquement le vidage des enregistrements de journal. 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 s’assurer que les enregistrements de journal sont correctement stockés permet de s’assurer 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 le 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 sur 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 appareils de données et de journalisation prennent correctement en charge un stockage stable.
Amélioration des performances
La première question qui peut vous être posée est la suivante : « J’ai un lecteur IDE en cours de mise en cache. Mais quand je l’ai désactivé, mes performances sont devenues moins élevées que prévu. Pourquoi ? »
La plupart des lecteurs IDE testés par Microsoft s’exécutent à 5 200 tr/min et les lecteurs SCSI à 7 200 tr/min. 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 : « Traiter le taux de transaction ».
De nombreux systèmes de traitement transactionnel en ligne (OLTP) 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 approprié et fournir l’amélioration des performances souhaitée tout en garantissant l’intégrité des données.
Pour observer les modifications significatives des performances qui se produisent dans SQL Server sur un lecteur de mise en cache, le taux de transaction a été augmenté en utilisant de petites transactions.
Les tests montrent que l’activité d’écriture élevée des mémoires tampons inférieure à 512 Ko ou supérieure à 2 Mo peut entraîner un ralentissement des performances.
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’encapsulation de l’ensemble de la série d’opérations INSERT dans une seule transaction s’exécute en environ quatre secondes dans toutes les configurations. Cela est dû au nombre de vidages de journal requis. Si vous ne créez pas une seule transaction, 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 a une taille de 512 octets. Cela nécessite une intervention importante de l’entraînement mécanique.
Lorsqu’une transaction unique est utilisée, les enregistrements de journal de la transaction peuvent être regroupés et une seule écriture plus importante peut être utilisée 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 l’étendue de votre transaction. Les transactions de longue durée peuvent entraîner un blocage excessif et indésirable, ainsi qu’une surcharge accrue. Utilisez les SQL Server:D atabases SQL Server compteurs de performances 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 qui peuvent 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 d’octets du journal vidés/s peut être réduite. Dans l’exemple précédent, une seule transaction a été utilisée. Toutefois, dans de nombreux scénarios, cela peut entraîner un comportement de verrouillage indésirable. 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 de journal fréquente et petite :
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 nécessite que les systèmes prennent en charge la livraison garantie sur des supports stables, comme décrit dans le document de téléchargement exigences de révision du programme de fiabilité 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.
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour