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

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 :
Description de 86903 de mise en cache des contrôleurs de disque dans SQL Server
234656 des informations sur l’utilisation de caches de lecteur de 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 Il ne s’agit pas d’un onduleur (UPS). Un onduleur ne garantit pas des activités d’écriture et peut être déconnecté de l’appareil de mise en cache.
Mémoire cacheMécanisme de stockage intermédiaire permettant d’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 de pages incorrectes, consultez la rubrique «Écriture de Pages» 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’une mémoire tampon de cache pour stockage stable.
LoquetObjet de synchronisation permettant de protéger la cohérence physique d’une ressource.
Stockage non volatileTout support qui reste disponible pour tous les échecs du système.
Attente de pagePage 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 de 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 de 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 de mise à jour vers la version de stockage non volatile de la page, jusqu’au moins les parties de l’annulation des enregistrements du 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 la rubrique de Journal des transactions à écriture anticipée à 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és dans un emplacement stable.

Pour clarifier cette situation, prenons le spécifique.

Remarque Pour cet exemple, supposons qu’il n’y a pas d’index et que la page affecté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 été apportée 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 verrouillé, épingléset marqué comme modifié, et verrous appropriées sont obtenues.
  3. Un enregistrement du journal d’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 ne doit pas être vidé à ce stade, car toutes les modifications restent en mémoire volatile.
VALIDATION DE TRANSACTION
  1. Un enregistrement du journal de validation est formé et les enregistrements de journal associés à la transaction doivent être écrit sur le 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 différents problèmes lorsque vous utilisez des 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 d’insertion 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 d’informations 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 est exécuté. SQL Server émet toutes 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 pour 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 des 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 utiliser 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érieure à 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 incomplètes d’e/s a provoqué par des coupures de courant ou de tout autre panne du système. La valeur True, elle provoque 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 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 écrit correctement avant la panne, la page de base de données sur le disque s’affiche tel qu’il est mis à jour, bien qu’il ne peut pas avoir réussi.

À l’aide de caches de contrôleur de disque secourus par batterie, 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 sur « true » car il 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 Win32 CreateFile d’ouvrir les fichiers journaux et de données. 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 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 de point de défaillance identique. Ils garantissent seulement l’achèvement des opérations d’écriture de secteur. Il s’agit plus précisément pourquoi l’écriture déchiré et 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 fournisseurs de matériel fournissent des solutions de contrôleur de disque secourus par batterie. 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 pour ê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 de 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 de mise en cache des implémentations handle le FILE_FLAG_WRITE_THROUGH demande en ne désactivant ne pas le cache de contrôleur, car ils peuvent fournir true réécrit 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 le 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 le vidage du journal écrit pour stockage stable avant l’écriture de la page peut être émise. Toutefois, utilisation du cache peut retourner le succès d’une demande d’écriture de journal sans les données écrites à la lettre du lecteur (autrement dit, écrite pour le support de stockage stable). Cela peut conduire à SQL Server l’émission de 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 de Win32 API 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 de WriteFile API peut déterminer uniquement que les données 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 d’enregistrements de journal correspondant. 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. La plus importante d'entre elles est « Mon système autorise des capacités FILE_FLAG_WRITE_THROUGH valides ? »

Remarque N’importe quel cache que vous utilisez doit prend totalement 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 fait en sorte d’assurer 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 le fonctionnement de SSDs avec SQL Server, consultez l’article de Blog d’ingénieurs CSS SQL Server suivant :


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ées par le système d’exploitation. S’il existe toute question, contactez le fabricant du lecteur pour les utilitaires appropriés.

Écrire l’empilage de Cache

Écrire que l’empilement de Cache est similaire à la commande du secteur. La définition suivante a été prise directement à partir d’un premier IDE lecteur site Web du fabricant :
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 jusqu'à ce que la pile de commande d’écriture est pleine ou 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 des secteurs défectueux au cours de la manipulation de 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'à son terme.
Cela peut être une fonctionnalité très puissante si la batterie de secours est fourni pour le cache. Ainsi, une modification appropriée au 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 pas de manière différée. Dans les 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 savoir sur 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 pour assurer la sécurité des données.
  • Il est toujours judicieux de vous assurer que votre stratégie de sauvegarde est suffisante 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, blocages, pic de puissance, 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.)
  • Configurez les disques RAID permettant une permutation à chaud d’un disque dur défectueux, s’il est possible.
  • Utilisez des contrôleurs de cache plus récentes qui vous permettent d’ajouter de l’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, il se peut que vous devez vous assurer que tous les caches de données sont 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 en écriture est désactivé et les 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 l’utilisation de 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 désactivé le cache d’écriture. Toutefois, le test indique 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 requiert uniquement les enregistrements de journal vidage. Lorsque vous effectuez des opérations non journalisées, les pages de données doivent également être transférées sur stockage stable ; Il n’y a aucun enregistrement de journal pour 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 qui peut se produire pour vous 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 qui sont testées par Microsoft exécutent à 5 200 RPM et les lecteurs SCSI à 7 200 TPM. Lorsque vous désactivez le cache d’écriture du lecteur IDE, les performances mécaniques peuvent devenir un facteur.

Pour répondre à la différence de performances, la méthode à suivre est très claire : « Le taux de transaction d’adresses ».

De nombreux systèmes de traitement des transactions en ligne nécessitent un taux de transaction élevé. Pour ces systèmes, envisagez d’utiliser un contrôleur de mise en cache qui peut approprié de prise en charge de cache d’écriture et fournir le gain de performances souhaité tout en garantissant l’intégrité des données.

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

Test montre qu’écrire de haute activité de tampons qui est inférieure à 512 Ko ou supérieure à 2 Mo peut affecter les 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')

Résultats de test pour SQL Server sont les suivantes :

SCSI(7200 RPM) 84 secondes
SCSI(7200 RPM) 15 secondes (contrôleur de mise en cache)


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

Le processus de 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. Est le nombre de vidages du journal qui sont nécessaires. Si vous ne créez pas une transaction unique, chaque INSERTION 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 taille de 512 octets. Cela nécessite une intervention importante de 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é pour vider les enregistrements du journal collectées. Cela réduit considérablement l’intervention mécanique.

Avertissement Il est recommandé que vous n’augmentez pas votre portée de transaction. Les transactions longues peuvent provoquer le blocage excessif et indésirables et augmente le surplus. Utilisez les compteurs de performances de SQL Server : bases de données SQL Server pour afficher les compteurs de basé sur le journal de transactions. Plus précisément, Ecrasé octets de journal par seconde peut indiquer beaucoup de petites transactions pouvant provoquer l’activité de disque mécanique.

Examinez les instructions qui sont associées dans le journal vidage pour déterminer si la valeur octets de journal Ecrasé/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 non désiré 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 TRANGO

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 requiert que prend en charge les systèmes « la remise garantie sur un support stable, » comme décrit dans le document téléchargement de Conditions de révision du programme SQL Server la fiabilité d’e/s . 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 :

Configuration requise de base de données moteur d’entrée/sortie 967576 de Microsoft SQL Server

Propriétés

ID d'article : 230785 - Dernière mise à jour : 8 janv. 2017 - Révision : 1

Commentaires