Vous êtes actuellement hors ligne, en attente de reconnexion à Internet.

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

IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d’une traduction incorrecte du contenu ou de son utilisation par les clients.

La version anglaise de cet article est la suivante: 230785
Résumé
Cet article explique comment les algorithmes d'enregistrement et les données de Microsoft SQL Server étendent l'intégrité et la fiabilité des données.

Pour en savoir plus sur les concepts sous-jacents des moteurs et ARIES (algorithme pour exploiter une sémantique d'Isolation et de récupération), voir les Transactions ACM suivantes sur le document de systèmes de base de données (sous « Volume 17, numéro 1, mars 1992) :

Le rédacteur en chef de ce document est C. Mohan. Le document aborde les techniques de SQL Server pour étendre la fiabilité des données et l'intégrité par rapport aux échecs.

Nous vous conseillons de lire les articles suivants dans la Base de connaissances Microsoft pour plus d'informations sur la mise en cache et autres modes de défaillance :
86903 Description de la mise en cache des contrôleurs de disque de SQL Server
234656 Informations sur l'utilisation de caches disque avec SQL Server que chaque administrateur de base de données devrait connaître
Plus d'informations
Avant de commencer l'étude approfondie, certains des termes utilisés dans cet article sont définis dans le tableau suivant.
TermeDéfinition
Batterie de secoursBatterie séparée et localisée installation de secours directement disponible et contrôlée par le mécanisme de mise en cache pour éviter la perte de données.
Remarque Ce n'est pas un onduleur (UPS). Un onduleur ne garantit pas des activités d'écriture et peut être déconnecté de l'équipement de mise en cache.
Mémoire cacheMécanisme de stockage intermédiaire utilisé pour optimiser les opérations d'e/s physiques et d'améliorer les performances.
Page incorrectePage contenant des modifications de données qui n'ont pas encore être vidées vers le stockage stable. Pour plus d'informations sur les mémoires tampons des pages incorrectes, voir la "Écriture de Pages« rubrique dans la documentation en ligne de SQL Server.
Remarque Le contenu s'applique également à Microsoft SQL Server 2012 et les versions ultérieures.
ÉchecTout ce qui peut provoquer un arrêt imprévu du processus SQL Server. Les exemples incluent : l'alimentation panne, réinitialisation de l'ordinateur, des erreurs de mémoire, autres problèmes liés au matériel, des secteurs défectueux, des pannes de disque, défaillances du système et ainsi de suite.
FlushForçage d'un tampon de cache pour stockage stable.
LoquetObjet de synchronisation utilisé pour protéger la cohérence physique d'une ressource.
Stockage non volatileTout support qui reste disponible pour tous les échecs du système.
Page épingléPage qui reste dans les données du cache et ne peut pas être vidée au stockage stable jusqu'à ce que tous les enregistrements de journal associés sont sécurisés dans un emplacement de stockage stable.
Stockage stableIdentique au stockage non volatile.
Stockage volatileTout support pas reste intacte sur les échecs.

Protocole Write-Ahead Logging (WAL)

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

Le document ARIES définit WAL comme suit :
Le protocole WAL affirme que les enregistrements du journal représentant des modifications à certaines données doivent déjà être dans un emplacement stable que les données modifiées sont autorisées à remplacer la version précédente des données dans le stockage non volatile. Autrement dit, le système n'est pas autorisé à écrire une page mise à jour vers la version de stockage non volatile de la page tant qu'au moins les parties annuler les enregistrements de journal qui décrivent les mises à jour à la page ont été écrites au support de stockage stable.
Pour plus d'informations sur l'enregistrement à écriture anticipée, consultez le Journal des transactions à écriture anticipée rubrique à la documentation en ligne de SQL Server.

SQL Server et WAL

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

Pour clarifier cette situation, prenons l'exemple spécifique suivant.

Remarque Pour cet exemple, supposons qu'il n'y a pas d'index et que la page concernée est page 150.
BEGIN TRANSACTION   INSERT INTO tblTest VALUES (1)COMMIT TRANSACTION				
Ensuite, décomposer l'activité de journalisation simpliste étapes, comme décrit dans le tableau suivant.
InstructionActions effectuées
DÉBUT DE LA TRANSACTIONÉcrit dans la zone de cache de journal. Toutefois, il n'est pas nécessaire de vider sur le stockage stable parce que le SQL Server n'a pas apporté de modification physique.
Table INSERT INTO tblTest
  1. Données page 150 sont récupérées dans le cache de données SQL Server, si n'est pas déjà disponible.
  2. La page est accrochage, épinglé, et marqué comme modifié, et verrous appropriées sont obtenues.
  3. Un enregistrement du journal insérer est créé et ajouté au cache de journal.
  4. Une nouvelle ligne est ajoutée à la page de données.
  5. Le verrou est libéré.
  6. Les enregistrements du journal associé à la transaction ou la page n'a pas à être vidées à ce stade parce que toutes les modifications restent en mémoire volatile.
VALIDATION DE TRANSACTION
  1. Un enregistrement de journal Commit est formé et les enregistrements du journal associés à la transaction doivent être écrites au support de stockage stable. La transaction n'est pas considérée engagée jusqu'à ce que les enregistrements du journal sont correctement affectées au stockage stable.
  2. Données page 150 restent dans le cache de données SQL Server et ne sont pas vidées immédiatement vers un stockage stable. Lorsque les enregistrements du journal sont correctement sécurisées, récupération peut répéter l'opération, s'il est nécessaire.
  3. Transactionnelles verrous sont libérés.
Ne pas confondre par les termes « verrouillage » et « enregistrement ». Bien qu'importants, de verrouillage et de consignation sont des problèmes distincts lorsque vous avez affaire à WAL. Dans l'exemple précédent, SQL Server généralement contient le loquet sur page 150 pour le temps nécessaire pour effectuer les modifications physiques insérer sur la page, pas toute la durée de la transaction. Le type de verrouillage appropriée est établi pour protéger la ligne, plage, page ou si nécessaire. Reportez-vous aux sections verrouillage documentation en ligne de SQL Server pour plus de détails sur les types de verrou.

En examinant l'exemple plus en détail, vous vous demandez peut-être ce qui se passe lorsque les processus d'écriture différée ou point de contrôle sont exécutés. SQL Server 7 problèmes tous les vidages appropriés pour le stockage des enregistrements de journal des transactions qui sont associés à la page sale et épinglée stable. Cela permet de s'assurer que la page de données du protocole WAL ne peut jamais être écrits au support de stockage stable jusqu'à ce que les enregistrements de journal des transactions associées ont été vidées.

Stockage de SQL Server et stable

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

Pour mettre à jour les propriétés d'une transaction ACID, le SQL Server doit tenir compte de points de défaillance. Lors d'un échec de nombreuses spécifications de lecteur de disque garantissent seulement une quantité limitée d'opérations d'écriture de secteur. La plupart des spécifications garantissent la fin de l'écriture de secteur unique lorsqu'une défaillance se produit.

SQL Server utilise les pages de données de 8 Ko et le journal (s'il est vidé) multiples de la taille de secteur. (La plupart des lecteurs de disque Utilisez 512 octets la taille de secteur par défaut). En cas d'échec, SQL Server peut de compte pour les opérations d'écriture supérieur à un secteur de parité de journal et de techniques d'écriture déchirée.

Détection de page endommagée

Cette option permet à SQL Server détecter les opérations d'e/s incomplètes provoquées par des coupures de courant ou de tout autre panne du système. Lorsque la valeur est true, cela entraîne un bit est positionné pour chaque secteur de 512 octets d'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 une version ultérieure en lecture par SQL Server, la page a été écrite incorrectement ; une page déchirée est détectée. Pages déchirées sont généralement détectées pendant la récupération, car toute page qui a été écrite incorrectement est susceptible d'être lu par la récupération.

Bien que les pages de base de données SQL Server sont de 8 Ko, les disques réalisent les opérations d'e/s à l'aide d'un secteur de 512 octets. Par conséquent, d'écrire 16 secteurs par page de base de données. Une déchirure de page peut se produire si le système tombe en panne (par exemple, en raison d'une panne de courant) entre l'heure à laquelle 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 écrit correctement avant la panne, la page de base de données sur le disque s'affiche comme mise à jour, bien qu'il risque de ne pas avoir réussi.

À l'aide de caches de contrôleur de disque avec batterie de secours, vous pouvez vous assurer que les données sont correctement écrites sur le disque ou pas écrit du tout. Dans ce cas, ne définissez pas de détection de page endommagée à « true », car ce n'est pas nécessaire.

Remarque Détection de page endommagée n'est pas activée par défaut dans SQL Server. Pour plus d'informations, consultez le site Web MSDN suivant :

Parité de journal

Contrôle de parité de journal est très similaire à la détection de page endommagée. Chaque secteur de 512 octets contient des bits de parité. Ces bits de parité sont toujours écrites avec l'enregistrement du journal et évaluées lors de la récupération de l'enregistrement du journal. En forçant les écritures de journal sur une limite de 512 octets, SQL Server peut Assurez-vous qu'opérations du moment de la validation sont totalement écrits dans les secteurs du disque physique.

Versions de SQL Server antérieures à 7.0

Versions de SQL Server antérieures à 7.0 ne fournissait pas parité de journal ou des installations de détection de bits endommagée. En fait, ces versions peuvent écrire la même page de journal plusieurs fois jusqu'à ce que les enregistrements du journal remplissent la page du journal de 2 Ko. Cela peut exposer les transactions qui ont été validés avec succès. Si la page de journal est réécrite lors d'un échec, un secteur avec la transaction validée ne peut pas réécrite correctement.

Impact sur les performances

Toutes les versions de SQL Server à l'aide de la fonction Win32CreateFile d'ouvrir les fichiers journaux et de données. Le membre dwFlagsAndAttributes inclut l'option FILE_FLAG_WRITE_THROUGHlorsqu'ils sont ouverts par SQL Server.
FILE_FLAG_WRITE_THROUGH
Indique au système d'écrire dans n'importe quel cache intermédiaire et aller directement sur le disque. Le système peut toujours mettre en cache les opérations d'écriture, mais il ne peut pas les vider.

L'option FILE_FLAG_WRITE_THROUGH garantit que lorsqu'une opération d'écriture renvoie un état de réussite, les données sont correctement stockées dans un emplacement stable. Cette option s'aligne avec le protocole WAL qui garantit que 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 dépendent généralement d'un condensateur et non une solution de batterie. Ces mécanismes de mise en cache ne peut pas garantir les écritures sur une puissance de cycle ou point de défaillance identique. Ils garantissent seulement l'exécution des opérations d'écriture de secteur. Il s'agit plus précisément pourquoi l'écriture endommagée et la détection de parité de journal ont été créés dans SQL Server 7.0 et les versions ultérieures. Comme les lecteurs de continuent de croître, les caches plus grandes, et ils peuvent exposer de grandes quantités de données pendant une panne.

De nombreux fabricants de matériel fournissent des solutions de contrôleur de disque avec batterie de secours. Ces caches de contrôleur peuvent mettre à jour les données dans le cache pendant plusieurs jours et même permettre le matériel de mise en cache être placé sur un autre ordinateur. Lorsque l'alimentation est restaurée correctement, les données non écrites sont complètement vidées avant d'autoriser l'accès aux données supplémentaires. Bon nombre d'entre elles permettent un pourcentage de lecture par rapport au cache d'écriture à établir pour des performances optimales. Certaines contiennent des zones de stockage de grande capacité de mémoire. En fait, pour un segment spécifique du marché, certains vendeurs de matériel fournissent les systèmes contrôleur de 6 Go de mémoire cache de la mise en cache de disque haut de gamme avec batterie de secours. Il peuvent améliorer considérablement les performances de la base de données.

Avancée des implémentations de mise en cache poignée le FILE_FLAG_WRITE_THROUGH demande en ne désactivant ne pas le cache de contrôleur, car elles peuvent fournir true réécrira possibilités en cas de réinitialisation du système, de panne de courant ou de tout autre point de défaillance.

Transferts d'e/s sans l'utilisation d'un cache peuvent être beaucoup plus de temps car le temps mécanique nécessaire au déplacement des têtes de lecteur, de vitesse de rotation et d'autres facteurs limitatifs.

Classement du secteur

Une technique courante utilisée pour améliorer les performances d'e/s est secteur de classement. Pour éviter le déplacement des têtes mécanique les demandes de lecture/écriture sont triés, permettant un mouvement plus uniforme de la tête pour extraire ou stocker des données.

Le cache peut contenir plusieurs journaux et demandes d'écriture de données en même temps. Le protocole WAL et la mise en oeuvre de SQL Server du protocole WAL nécessitent de vidage du journal écrit dans stockage stable avant l'écriture de la page peut être émise. Toutefois, utilisation du cache peut-être retourner un succès à partir d'une demande d'écriture de journal sans que les données sont écrites dans la lettre du lecteur (autrement dit, écrite pour stockage stable). Cela peut conduire à SQL Server émettant la demande d'écriture de page données.

Avec la participation de cache d'écriture, les données sont considérées en mémoire volatile. Toutefois, à partir de l'appel API Win32 WriteFile, exactement comment SQL Server considère l'activité, un code de retour de réussite a été obtenu. SQL Server ou n'importe quel processus qui utilise l'appel deWriteFileAPI peut déterminer les données onlythat a obtenu correctement de stockage stable.

Discussion, supposons que tous les secteurs de la page de données sont triés pour écrire avant les secteurs des correspondance des enregistrements du journal. Ceci s'oppose immédiatement le protocole WAL. Le cache consiste à écrire une page de données avant des enregistrements du journal. À moins que le cache est entièrement avec batterie de secours, 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 sont à prendre en compte. Est la plus importante d'entre elles, « Mon système autorise des capacités FILE_FLAG_WRITE_THROUGH valides? »

Remarque N'importe quel cache que vous êtes totalement usingmust prend en charge une solution de batterie. Tous les autres mécanismes de mise en cache sont suspects à une corruption des données et de perte de données. SQL Server s'efforce de garantir WAL en activant FILE_FLAG_WRITE_THROUGH.

Les tests ont démontré que de nombreuses configurations de lecteur de disque peuvent contenir la mise en cache d'écriture sans la sauvegarde par batterie appropriée. Les disques SCSI, IDE et EIDE tirer pleinement parti des caches d'écriture. Pour plus d'informations sur la façon dont SSDs fonctionnent avec SQL Server, reportez-vous à la suite de l'article de Blog d'ingénieurs CSS SQL Server :


Dans de nombreuses configurations, le seul moyen pour désactiver correctement le cache d'écriture d'un lecteur IDE ou EIDE est à l'aide d'un utilitaire de fabricant spécifique ou à l'aide des cavaliers que qui se trouve sur le lecteur proprement dit. Pour vous assurer que le cache d'écriture est désactivé pour le lecteur, contactez le fabricant du lecteur.

Disques 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 toute question, contactez le fabricant du lecteur pour les utilitaires appropriés.

Écriture du Cache d'empilement

L'écriture que cache d'empilement est similaire à la commande du secteur. La définition suivante provient directement du site Web un leader IDE du fabricant du lecteur :
Normalement, ce mode est activé. Écrire le mode cache accepte que l'hôte écrire des données dans la mémoire tampon jusqu'à ce que le tampon est plein ou le transfert d'hôte est terminé.

Une tâche d'écriture de disque commence à stocker les données de l'hôte sur le disque. Commandes d'écriture hôte continuent à être acceptée et les données transférées dans la mémoire tampon tant que la pile de commande d'écriture est pleine ou que le tampon de données est plein. Le lecteur peut réorganiser les commandes d'écriture afin d'optimiser le débit du lecteur.

Réaffectation d'écriture automatique (anticipé)

Une autre technique courante qui est utilisée pour protéger les données consiste à détecter les secteurs défectueux au cours de la manipulation des données. L'explication suivante provient d'un leader IDE lecteur site Web du fabricant :
Cette fonctionnalité fait partie de la mémoire 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 de disque, la tâche de disque s'arrête et le secteur suspect est réaffecté à un pool d'autres secteurs qui se trouvent à 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.
Cela peut être une fonctionnalité très puissante si la batterie de secours est fourni 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 à nouveau l'exige pour être effectuée en temps réel et non de manière différée. Dans les cadre des paramètres WAL, la technique anticipé ne peut pas en compte 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 à propos de la défaillance afin que la transaction peut être abandonnée correctement, l'administrateur peut être prévenu et corriger les mesures prises pour sécuriser les données et de remédier à la situation de défaillance du support.

Sécurité des données

Il existe plusieurs précautions à un administrateur de base de données doit prendre afin de garantir la sécurité des données.
  • Il est toujours une bonne idée pour vous assurer que votre stratégie de sauvegarde est suffisant pour récupérer d'une défaillance catastrophique. Stockage hors site et autres précautions sont appropriées.
  • Testez l'opération de restauration de base de données dans un secondaire ou de la base de données de test de manière fréquente.
  • Assurez-vous que les périphériques de mise en cache peuvent gérer toutes les situations de défaillance (coupure de courant, des secteurs défectueux, disques défectueux, panne du système, des blocages, pic d'alimentation, etc.).
  • Assurez-vous que votre périphérique de mise en cache :
    • Batterie de secours intégrée
    • Pouvez Rééditer écrit sous tension
    • Peut être complètement désactivé si nécessaire
    • Gère le remappage de secteur défectueux en temps réel
  • Activer la détection de page endommagée. (Cela a peu d'effet sur les performances).
  • Configurer les lecteurs RAID permettant une permutation à chaud d'un disque dur défectueux, si cela est possible.
  • Utilisez des contrôleurs de cache plus récentes qui vous permettent d'ajouter plus d'espace disque sans avoir à redémarrer le système d'exploitation. Cela peut être une solution idéale.

Test des disques

Pour pleinement sécuriser vos données, veillez à ce que toute la mémoire cache de données est correctement gérée. Dans de nombreux cas, vous devez désactiver le cache d'écriture du lecteur de disque.

Remarque Assurez-vous qu'un autre mécanisme de mise en cache peut gérer correctement les divers types de défaillances.

Microsoft a effectué des tests sur plusieurs lecteurs SCSI et IDE à l'aide de l'utilitaire SQLIOSim . Cet utilitaire simule l'activité de lecture/écriture asynchrones vers un périphérique de données simulées et du journal. Affichent les statistiques de performance de test les opérations d'écriture moyenne par seconde compris entre 50 et 70 sur un lecteur dont la mise en cache d'écriture est désactivé et rotations par minute varie entre 5 200 et 7 200.

Pour plus d'informations sur l'utilitaire SQLIOSim , consultez l'article suivant dans la Base de connaissances Microsoft :
231619 Comment faire pour utiliser l'utilitaire SQLIOSim pour simuler l'activité de SQL Server sur un sous-système de disque
De nombreux fabricants d'ordinateurs commandent les lecteurs en ayant le cache d'écriture désactivé. Toutefois, les tests montrent que cela peut être pas toujours le cas. Par conséquent, testez toujours complètement.

Périphériques de données

Dans les situations de tout mais non consignée, SQL Server nécessite uniquement les enregistrements de journal à vider. Lorsque vous effectuez des opérations non journalisées, les pages de données doivent également être vidés au stockage stable ; Il n'y a aucun enregistrement de journal individuelles à régénérer les actions en cas d'échec.

Les pages de données peuvent rester dans le cache jusqu'à ce que le processus d'écriture différée ou point de contrôle les vidages de stockage stable. À l'aide du protocole WAL afin de vous assurer que les enregistrements du journal sont stockées correctement permet de s'assurer de récupération peut récupérer une page de données à un état connu.

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

Augmentation des performances

La première question que se produit est: « j'ai un lecteur IDE qui a été mise en cache. Mais lorsque j'ai désactivé, mes performances ont été nettement moins que prévu. « Pourquoi? »

La plupart des lecteurs IDE testés par Microsoft s'exécutent à une vitesse tr/min de 5 200 et SCSI des lecteurs dans un fichier RPM de 7 200. Lorsque vous désactivez l'écriture de la mise en cache du lecteur IDE les performances mécaniques peuvent avoir des répercussions.

Il existe une zone très claire pour résoudre la différence de performances: « Adresse le taux de transaction ».

Il existe des transactions en ligne de nombreux systèmes (OLTP) qui nécessitent un taux de transaction élevé de traitement. Pour ces systèmes, envisagez d'utiliser un contrôleur de mise en cache peut correctement prend en charge un cache d'écriture et le gain de performances tout en garantissant l'intégrité des données.

Si vous rencontrez beaucoup des modifications de performances avec SQL Server sur un disque de mise en cache, le taux de transaction a été augmenté à l'aide de petites transactions.

Test montre que l'activité de mémoires tampons qui est inférieure à 512 Ko ou supérieure à 2 Mo d'écriture élevée peut affecter les performances.
Prenons l'exemple suivant :
CREATE TABLE tblTest ( iID int IDENTITY(1,1), strData char(10))GOSET NOCOUNT ONGOINSERT INTO tblTest VALUES ('Test')WHILE @@IDENTITY < 10000   INSERT INTO tblTest VALUES ('Test')				
Résultats de test pour SQL Server sont les suivantes :
Secondes SCSI(7200 RPM) 84
SCSI(7200 RPM) 15 secondes (contrôleur de mise en cache)

IDE(5200 RPM) 14 secondes (lecteur cache activé)
IDE(5200 RPM) 160 secondes

Retour à la ligne toute la série d'opérations d'insertion dans une seule transaction s'exécute environ quatre secondes dans toutes les configurations.

La raison est le nombre de vidages du journal requis. Sans la transaction, chaque insertion est une transaction dans et de lui-même, et chaque fois que les enregistrements du journal de la transaction doivent être vidés. Chaque vidage est de 512 octets de taille, ce qui nécessite une intervention importante lecteur mécanique.

Lorsqu'une transaction unique est utilisée, les enregistrements du journal pour la transaction peuvent être regroupés et une écriture unique et plus grande peut être utilisée pour vider les enregistrements du journal collectées. L'intervention mécanique est considérablement réduite.

Avertissement Il est recommandé que vous n'augmentez pas votre portée de transaction. Les transactions longues peuvent entraîner le blocage excessif et indésirables mais aussient augmente le surplus. Utilisez les compteurs de performances de SQL Server : bases de données SQL Server pour afficher les compteurs basé sur le journal de transactions. Plus précisément, Ecrasé octets de journal par seconde peut indiquer de nombreuses petites transactions conduisant à activité élevée du disque mécanique.

Examinez les instructions associées le vidage du journal et déterminer si le nombre de vidages du journal peut être réduit. Dans l'exemple précédent, une transaction unique a été implémentée. Toutefois, dans de nombreux scénarios, cela peut entraîner un comportement de verrouillage. Examiner la conception de la transaction. Vous pouvez utiliser le code semblable au suivant pour exécuter des lots pour réduire l'activité de vidage de journal fréquentes et petit :
BEGIN TRANGOINSERT INTO tblTest VALUES ('Test')WHILE @@IDENTITY < 50BEGIN   INSERT INTO tblTest VALUES ('Test')   if(0 = cast(@@IDENTITY as int) % 10)   BEGIN      PRINT 'Commit tran batch'      COMMIT TRAN      BEGIN TRAN   ENDENDGOCOMMIT TRANGO				
SQL Server requiert que prend en charge les systèmes de « la remise garantie sur un support stable, » comme décrit dans le Conditions de révision du programme de fiabilité SQL Server d'e/s Télécharger le document. Pour plus d'informations sur la configuration d'entrée et de sortie pour le moteur de base de données SQL Server, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
967576 Configuration requise de Microsoft SQL Server de base de données moteur d'entrée/sortie

Avertissement : Cet article a été traduit automatiquement.

Propriétés

ID d'article : 230785 - Dernière mise à jour : 05/17/2015 07:07:00 - Révision : 1.0

Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2000 Standard, Microsoft SQL Server 7.0 Standard, Microsoft SQL Server 2008 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2008 Express, Microsoft SQL Server 2008 Standard

  • kbhowto kbinfo kbmt KB230785 KbMtfr
Commentaires