Journalisation de SQL Server 7.0, SQL Server 2000 et SQL Server 2005 et les algorithmes de stockage de données étendent la fiabilité des données

Traductions disponibles Traductions disponibles
Numéro d'article: 230785 - Voir les produits auxquels s'applique cet article
Agrandir tout | Réduire tout

Sommaire

Résumé

SQL Server 7.0, SQL Server 2000 et SQL Server 2005 restructurer et redéfinir les algorithmes de journalisation et les données des précédentes versions de Microsoft SQL Server pour améliorer l'intégrité et la fiabilité des données.

Pour en savoir plus sur les concepts sous-jacents des moteurs de SQL Server 7.0 et SQL Server 2000, consultez « ARIES (algorithme pour la récupération et la sémantique d'isolation Exploiting): méthode de récupération des transactions fine prise en charge-granularité verrouillage et les restaurations partielles Utilisation Write-transfert journalisation », de transactions ACM sur les systèmes de base de données. Ce document a été écrit par Chunder Mohan.

Ce document traite les techniques de SQL Server 7.0, SQL Server 2000 et SQL Server 2005 pour étendre la fiabilité des données et l'intégrité liés aux échecs.

Il est recommandé de lire les articles suivants dans la Base de connaissances Microsoft pour les autres précisions sur la mise en cache et autres discussions sur le mode Échec :
86903 Description de la mise en cache les contrôleurs de disque dans SQL Server
46091 À l'aide de disque dur contrôleur mise en cache avec SQL Server
234656 L'aide de la mise en cache disque avec SQL Server

Plus d'informations

Avant de commencer la discussion approfondie, certains des termes tel qu'utilisé tout au long de cet article sont définis dans la section suivante.
Réduire ce tableauAgrandir ce tableau
TermeDéfinition
Sauvegarde de batterie Batterie séparées et localisée sauvegarde fonction directement disponible et contrôlée par le mécanisme de mise en cache pour éviter la perte de données.
note Ce n'est pas un onduleur (UPS). Un ONDULEUR ne garantit pas les activités d'écriture et peut être déconnecté du périphérique 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.
Dirty, page Page contenant des modifications de données Qu'avez encore à être vidées vers le stockage stable. Pour plus d'informations relatives à la page sale tampons, consultez la documentation SQL Server Books Online.
Échec Tout ce qui peut provoquer une défaillance inattendue du processus SQL Server. Exemples : consommation d'énergie de panne, réinitialisation de l'ordinateur erreurs de mémoire, autres problèmes matériels, des secteurs défectueux, pannes de lecteur, Échecs de système d'exploitation et ainsi de suite.
Vider Forcer d'un tampon du cache à stable de stockage.
Accès rapide Objet de synchronisation utilisé pour protéger la cohérence physique d'une ressource.
Stockage non volatile Tout média qui reste disponible entre les défaillances du système.
Page en attente Page reste des données de cache et ne peut pas être vidées vers le stockage stable jusqu'à ce que tous les enregistrements de journaux associés sont sécurisés dans un emplacement de stockage stable.
Stockage stable Identique stockage non volatile.
Stockage volatile N'importe quel moyen que ne pas restent intacts sur les échecs.
SQL Server 2005, SQL Server 2000, SQL Server 7.0, les versions antérieures de SQL Server et plusieurs produits de base de données standard sur le marché aujourd'hui utilisent le protocole Write-transfert WAL (enregistrement).

Protocole de transfert en écriture WAL (enregistrement)

Le protocole terme est un excellent moyen pour décrire WAL. Il est spécifique et ensemble défini de mise en ?uvre les étapes nécessaires pour garantir des données est stockée échangé correctement et peuvent être récupérés vers un état connu en cas de défaillance. Tout comme un réseau contient un protocole défini pour échanger des données d'une manière cohérente et protégée, donc trop le WAL décrit le protocole pour protéger les données.

Le document ARIES définit le WAL en tant que :
Le protocole WAL affirmations que les enregistrements du journal représentant les modifications apportées à certaines données doivent être déjà dans le stockage stable avant que les données modifiées soit autorisées à remplacer la version précédente des données de stockage non volatile. C'est-à-dire que le système ne peut pas écrire une page de mise à jour dans la version de stockage non volatile de la page jusqu'à ce qu'au moins les parties d'annulation des enregistrements du journal qui décrivent les mises à jour de la page ont été écrites pour stable de stockage.
Pour plus d'informations sur l'enregistrement Write-transfert, consultez la documentation SQL Server Books Online.

SQL Server et le WAL

SQL Server 2005, SQL Server 2000, SQL Server 7.0 et les versions de SQL Server antérieures utilisent le protocole WAL. Pour garantir committal correcte d'une transaction, tous les enregistrements de journaux associés à la transaction doivent être sécurisées de stockage stable.

Pour clarifier ce, prenons l'exemple spécifique suivant (pour cet exemple montre comment Supposons que n'existe aucun d'index et la page affectée est page 150).
BEGIN TRANSACTION
   INSERT INTO tblTest VALUES (1)
COMMIT TRANSACTION
				
maintenant décomposer l'activité en enregistrement simpliste étapes :
Réduire ce tableauAgrandir ce tableau
InstructionActions effectuées
DÉBUT DE TRANSACTION Écrit dans la zone de cache de journal mais il est inutile de vider au stockage stable car le serveur SQL n'a pas faite des modifications physiques.
INSERT INTO tblTestDonnées de 1. page 150 sont récupérées dans le cache de données SQL Server, si elle est pas déjà disponible.

2. La page est latched , épinglé et marqué sale et verrous appropriés sont obtenus.

3. Un enregistrement de 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 temps est publié.

6. Les enregistrements de journaux associés à la transaction ou page ne doit pas être vidées à ce stade dû au fait que toutes les modifications restent dans le stockage volatile.
COMMIT TRANSACTION1. Un enregistrement de journal de validation est formé et les enregistrements de journaux associés à la transaction doivent être écrite pour stable de stockage. La transaction n'est pas considéré comme validées jusqu'à ce que les enregistrements du journal sont correctement affectées au stockage stable.

Celles-ci 2. page 150 restent dans le cache de données SQL Server et n'est pas immédiatement vidé au stockage stable. Lorsque les enregistrements du journal sont correctement sécurisée récupération pouvez rétablir l'opération si nécessaire.

Verrous 3. transactionnelles sont publiés.
Ne pas être confondu avec verrouillage et de journalisation. Bien qu'Important, verrouillage et de journalisation sont problèmes distincts lorsque vous traitez du WAL. Dans l'exemple ci-dessus, SQL Server 7.0, SQL Server 2000 et SQL Server 2005 généralement conservent le temps de page 150 pour l'heure nécessaires pour exécuter les modifications Insertion physique sur la page, pas l'heure ensemble de la transaction. Le type de verrouillage appropriée est établi à 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 de plus en détail, vous pouvez vous demander ce qui se produit lorsque les processus LazyWriter ou CheckPoint exécuter. SQL Server 7.0, SQL Server 2000 et SQL Server 2005 émettent tous les vidages appropriés à stable de stockage pour les enregistrements de journal transactionnelle associés à la page sale et affichée. Cela garantit le protocole WAL qu'une page de données peut ne jamais être écrite sur stable stockage jusqu'à ce que les enregistrements du journal transactionnelle associé ont été vidés.

Stockage de SQL Server et de stabilité

SQL Server 7.0, SQL Server 2000 et SQL Server 2005 améliorent les opérations de page journal et de données en incluant les connaissances de tailles de secteur de disque (généralement 512 octets).

Pour conserver les propriétés ACID d'une transaction, le serveur SQL doit représentent les points de défaillance. Pendant une panne de spécifications de lecteur de disque uniquement garantissent une limitée d'opérations d'écriture de secteur. La plupart des spécifications garantissent l'exécution d'une écriture de secteur unique lorsqu'une défaillance se produit.

SQL Server 7.0, SQL Server 2000 et SQL Server 2005 utilisent pages données 8 Ko et le journal (si consommées) en multiples de la taille de secteur. (La plupart des lecteurs de disques utilisez 512 octets comme la taille de secteur par défaut). Dans le cas d'une défaillance, SQL Server peut compte des opérations d'écriture supérieure à un secteur en utilisant la parité de journal et les techniques écriture déchiré.

Détection de page déchiré

Cette section provient d'en la ligne de SQL Server 7.0 documentation décrivant la détection de page déchiré :
Cette option permet à SQL Server détecter les opérations incomplètes d'E / S causées par défaillances de l'alimentation ou d'autres pannes du système. Lorsque cette propriété a la valeur true, elle provoque un peu à être retournée pour chaque secteur de 512 octets dans une page 8 kilo-octets (Ko) de la base de données chaque fois que la page est écrit sur le disque. Si un peu est dans un état incorrect lorsque la page est une version ultérieure lu par SQL Server, puis la page a été écrite incorrectement ; une page déchirée est détectée. Pages déchirés sont généralement détectés lors de la récupération étant une page qui a été mal écrit susceptible d'être lus par récupération.

Bien que les pages de base de données SQL Server soient 8 Ko, disques effectuent des opérations d'E / S à l'aide d'un secteur de 512 octets. Par conséquent, les secteurs 16 sont écrits par page de la base de données. Une page déchirée peut se produire si le système échoue (par exemple, en raison d'échec de l'alimentation) entre l'heure que du système d'exploitation écrit le premier secteur de 512 octets sur le disque et la fin de l'opération de 8 Ko d'E / S. Si le premier secteur d'une page de base de données est correctement écrit avant la défaillance, la page de base de données sur disque apparaîtra en tant que mises à jour, bien qu'il peut ne pas ont réussi.

À l'aide de caches de contrôleur de disque de sauvegarde de batterie peut s'assurer que données sont correctement écrit sur le disque ou non écrite du tout. Dans ce cas, ne faire pas ensemble endommagée Détection de page sur true, pour qu'il n'est pas nécessaire.
note Détection de page déchiré n'est pas activée par défaut dans SQL Server 7.0. Voir la rubrique sp_dboption pour savoir comment activer la détection sur votre système.

Parité de journal

Journal de parité est très similaire à la détection de page déchiré. Chaque secteur de 512 octets contient des bits de parité. Ces bits de parité sont toujours écrites avec l'enregistrement de journal et évaluées lorsque l'enregistrement de journal est extrait. En forçant journal écrit sur une limite de 512 octets, SQL Server 7.0, vous SQL Server 2000 et SQL Server 2005 peuvent assurer que committal opérations sont complètement écrites pour les secteurs de disque physique.

Les modifications fournissent la cohérence des données accrue, même sur les versions antérieures de SQL Server.

Versions de SQL Server antérieure à 7.0

Versions de SQL Server antérieure à 7.0 offrait pas journal parité ou les bits déchiré détection installations. En fait, ces versions peuvent écrire la même page journal plusieurs fois jusqu'à ce que les enregistrements du journal remplissent la page journal 2 Ko. Cela peut exposer les transactions qui ont correctement validées. Si la page journal est en cours réécrite pendant une défaillance, un secteur à la transaction validée peut ne pas obtenir réécrit correctement.

Impact sur les performances

Toutes les versions de SQL Server ouvrez les fichiers journaux et de données utilisant la fonction Win32 CreateFile . Le membre dwFlagsAndAttributes inclut l'option FILE_FLAG_WRITE_THROUGH ouverture par SQL Server.
indicateur FILE_FLAG_WRITE_THROUGH
Force le système pour écrire dans n'importe quel cache intermédiaire et accéder directement au disque. Le système peut mettre toujours en cache les opérations d'écriture, mais ne peut pas vider simplement les.

L'option FILE_FLAG_WRITE_THROUGH garantit que, lorsqu'une écriture opération renvoie réussite que les données sont correctement stockées dans le stockage stable. Il Aligne avec le protocole WAL garantir les données.
Plusieurs lecteurs de disque (SCSI et IDE) contiennent des caches intégrés de 512 Ko, 1 Mo, ou plus. Cependant, les caches disque généralement dépendent un condensateur et pas une solution de sauvegarde de batterie. Ces mécanismes de mise en cache ne peut pas garantir écrit sur une puissance cycle ou Échec similaire sur. Ils ne garantissent que l'exécution d'opérations d'écriture les secteur. Il s'agit plus précisément pourquoi le déchiré écriture et de la détection de parité de journal ont été intégrées dans SQL Server 7.0, SQL Server 2000 et SQL Server 2005. Comme les lecteurs de continuer à augmenter la taille, les caches deviennent plus grandes, et ils peuvent exposer les grandes quantités de données pendant une panne.

Plusieurs fournisseurs de matériel fournissent des solutions de contrôleur de disque de sauvegarde de batterie. Ces caches de contrôleur peuvent gérer les données de la mémoire cache pendant plusieurs jours et même permettre le matériel de mise en cache pour être placé dans un deuxième ordinateur. Lorsque l'alimentation est restaurée correctement, les données unwritten sont vidées complètement avant que l'accès aux données plus est autorisé. Bon nombre d'entre elles permettent un pourcentage de lecture et le cache en écriture être établi pour des performances optimales. Certaines contenir des zones de stockage de mémoire volumineuse. En fait, pour un segment très spécifique du marché, certains fournisseurs de matériel fournir haut de gamme disque sauvegardées de batterie cache systèmes contrôleur avec 6 Go de cache. Ces peuvent améliorer considérablement les performances de base de données.

Avancé des implémentations de mise en cache est handle de l' indicateur FILE_FLAG_WRITE_THROUGH demander en ne pas la désactivation du cache du contrôleur car ils peuvent fournissent la valeur true réécrire fonctionnalités dans le cas d'une réinitialisation du système, panne de courant ou autre point de défaillance.

Transferts d'E / S sans utiliser d'un cache peuvent être beaucoup plus de temps en raison pour le temps mécanique nécessaire pour déplacer les têtes de lecteur, taux de sélection numérique et autres facteurs limitation.

Ordre de secteur

Une technique courante utilisée pour améliorer les performances e / S est le secteur de commande. Pour éviter de mouvement tête mécanique les demandes de lecture/écriture sont triées, autorisant un mouvement plus cohérent de l'en-tête pour récupérer ou de stocker des données.

Le cache peut contenir plusieurs journaux et données écrire des requêtes en même temps. Le protocole WAL et l'implémentation de SQL Server du protocole WAL nécessitent vidage du journal écrit stable stockage avant l'écriture de pages peut être émis. Toutefois, Utilisation du cache peut renvoyer succès à partir d'une demande d'écriture de journal sans les données écrites sur le lecteur réel (qui est, écrite sur stable stockage). Cela peut conduire à SQL Server émettant la demande d'écriture page de données.

Avec l'implication de cache en écriture, les données sont toujours considéré comme de stockage volatile. Toutefois, de l'appel D'API Win32 WriteFile , exactement comment SQL Server voit l'activité, un code de retour réussi a été obtenu. SQL Server ou un processus à l'aide seulement le peuvent appel API WriteFile déduire les données a correctement obtenu stockage stable.

À des fins de discussion, supposons que tous les secteurs de la page de données sont triées à écrire avant les secteurs des enregistrements journal correspondants. Ceci enfreint immédiatement le protocole WAL. Le cache écrit une page de données avant les enregistrements du journal. Si le cache est sauvegardé entièrement batterie, une défaillance peut provoquer résultats catastrophique.

Lors de l'évaluation les facteurs des performances optimales pour un serveur de base de données, il existe nombreux facteurs à prendre en compte. Plus de ces considérations est mon système verte capacités FILE_FLAG_WRITE_THROUGH valides ?

note N'importe quel cache vous utilisez doit entièrement prend en charge une solution de sauvegarde de batterie. Tous les autres mécanismes de mise en cache sont suspect à une altération des données et de perte de données. SQL Server fait chaque efforts pour garantir la WAL en activant l'indicateur FILE_FLAG_WRITE_THROUGH.

Test a montré que plusieurs configurations de lecteur de disque peuvent contenir de cache en écriture sans sauvegarde batterie approprié. Les lecteurs SCSI, IDE et EIDE tirer pleinement parti du cache en écriture.

Dans de nombreuses configurations, la seule correctement désactiver la mise en cache en écriture d'un lecteur IDE ou EIDE consiste à avec un utilitaire fabricant spécifique ou en utilisant les cavaliers situés sur le lecteur lui-même. Pour vous assurer que le cache en écriture est désactivé pour le lecteur lui-même, contactez le fabricant du lecteur.

Lecteurs SCSI ont également cache en écriture mais ces caches peuvent généralement être désactivées par le système d'exploitation. S'il existe toute question, contactez le fabricant de lecteur pour utilitaires appropriés.

Écriture cache Empilage

Écriture que cache Empilage est similaire à la commande de secteur. La définition suivante a été effectuée directement à partir un site Web du fabricant de lecteur début IDE :
Normalement, ce mode est actif. Écrire le mode cache accepte que le ordinateur hôte écrire des données dans le tampon jusqu'à ce que la mémoire tampon soit plein ou le transfert ordinateur hôte est terminée.

Une tâche d'écriture disque commence à stocker les données ordinateur hôte sur le disque. Hôte écriture commandes continuer à être acceptée et données transférées vers la mémoire tampon jusqu'à ce que soit la pile de commande écriture soit complet ou le tampon de données est plein. Le lecteur peut réorganiser les commandes d'écriture pour optimiser le débit du lecteur.

Réaffectation d'écriture automatique (AWR)

Autre technique courante utilisée pour protéger des données est de détecter des secteurs défectueux pendant la manipulation de données. L'explication suivante proviennent même début IDE lecteur fabricant site Web :
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 disque survient pendant le processus d'écriture de disque, les taquets de tâche disque et le secteur suspect est réaffecté à une liste des autres secteurs située à l'extrémité du lecteur. Suivant la réaffectation, la tâche d'écriture disque continue jusqu'à ce qu'elle soit terminée.
Ceci peut être une fonctionnalité très puissante Si sauvegarde de la batterie est fournie pour le cache, permettant la modification appropriée lors de redémarrage. Il est préférable pour détecter les erreurs de disque, mais la sécurité données du protocole WAL nouveau nécessiterait cette option pour faire en temps réel et non dans une manière différée. Dans les paramètres WAL, la technique AWR ne peut pas représentent une situation dans laquelle une écriture de journal échoue en raison d'une erreur de secteur mais que le lecteur est plein. Le moteur de base de données doit connaître immédiatement la défaillance pour la transaction peut être correctement annulée, l'administrateur peut être averti et les étapes appropriés pour sécuriser les données et de corriger la situation d'échec de média.

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 vérifier que votre stratégie de sauvegarde est suffisante pour récupérer à partir d'une défaillance irrémédiable. Stockage hors site et autres précautions sont appropriées.
  • Testez la base de données test sur une base fréquemment ou opération de restauration de base de données dans un secondaire.
  • Assurez-vous que les périphériques de mise en cache peuvent gérer toutes les situations Échec (panne de courant, des secteurs défectueux, lecteurs incorrects, une panne système, lockups, pic de l'alimentation, etc.).
  • Assurez-vous que votre périphérique de mise en cache :
    • Intègre sauvegarde de la batterie.
    • Peut redistribution écrit sur alimentation en haut.
    • Peut être complètement désactivée si nécessaire.
    • Gère le secteur défectueux re-mapping realtime.
  • Activer la détection de page déchiré ; elle a peu d'impact performances.
  • Configurer les lecteurs RAID ce qui permet un échange à chaud d'un lecteur de disque défectueux, si possible.
  • Utilisez des contrôleurs de mise en cache plus récentes qui autorise l'ajout d'espace disque plus sans redémarrer le système d'exploitation. Il peut s'agir d'une solution idéale.

Test de lecteurs

Pour totalement sécuriser vos données, vous devez vous assurer que toutes les données cache est correctement géré. Dans de nombreuses situations, cela signifie que vous devez désactiver la mise en cache en é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é tests sur plusieurs disques SCSI et IDE à l'aide de l'utilitaire SQLIOStress . Cet utilitaire simule activité épais asynchrone lecture/écriture pour un périphérique de simulation de données et une unité journal. Statistiques de performances test affichent les opérations d'écriture moyenne par seconde entre 50 et 70 pour un lecteur avec cache en écriture désactivé et une plage 000 entre 5,200 et 7,200.

Pour plus d'informations et des informations sur l'utilitaire SQLIOStress , consultez l'article suivant dans la Base de connaissances :
231619 Comment utiliser l'utilitaire SQLIOStress pour sous contraintes un sous-système de disque tel que SQL Server
Nombre de fabricants de PC (par exemple, Compaq, Dell, passerelle, HP, etc.) commande les lecteurs dont le cache en écriture désactivé. Toutefois, de test indique que cela peut ne pas toujours être le cas toujours tester complètement.

Périphériques de données

Dans tous les mais non-consignées situations, SQL Server nécessite seulement les enregistrements de journal à être vidées. Lors d'opérations non-consignée, les pages de données doivent également être vidées vers le stockage stable ; il n'existe aucun enregistrement journal individuels à régénérer les actions en cas de défaillance.

Les pages de données peuvent rester dans le cache jusqu'à ce que le processus LazyWriter ou CheckPoint les purges stockage stable. L'aide du protocole WAL pour vous assurer que les enregistrements du journal sont correctement stockés garantit que récupération pouvez 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 serveur SQL vide les pages de données à stable de stockage, les enregistrements du journal peuvent être tronqués du journal des transactions. Si les pages de données sont stockées sur cache volatile, il est possible de tronquer les enregistrements du journal qui serait être utilisés pour récupérer une page dans le cas de défaillance. Vérifiez que vos données et le journal périphériques assurer le stockage stable correctement.

Augmentation des performances

La question initiale qui survient est: « J'ai un lecteur IDE qui a été mise en cache, mais lorsque J'AI désactivé il, mon performances devenu beaucoup moins prévue-pourquoi? »

La plupart des lecteurs IDE testés par Microsoft exécuté à un taux 000 de 5,200, et le SCSI les lecteurs à un 000 de 7,200. Lorsque vous désactivez l'écriture la mise en cache du lecteur IDE les performances mécanique peuvent devenir un facteur.

Il est une zone très claire pour traiter la différence de performances: « adresse le taux de transaction ».

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

Rencontrer beaucoup des modifications de performances avec SQL Server sur un lecteur de mise en cache, le taux de transaction a été augmenté l'utilisation de petites transactions.

Test indique que haute écriture activité de mémoires tampon inférieure à 512 Ko ou dépasse 2 Mo peut dégrader 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')
				
Voici résultats du test exemple pour SQL Server :
Secondes SCSI(7200 RPM) 84
SCSI(7200 RPM) 15 secondes (contrôleur de mise en cache)

14 IDE(5200 RPM) secondes (cache disque activé)
IDE(5200 RPM) 160 secondes
Habillage toute la série d'opérations INSERT dans une transaction unique s'exécute dans environ 4 secondes dans toutes les configurations.

La raison est le nombre de vidages journal requis. Sans la transaction, chaque Insertion est une transaction en cours et de lui-même, et chaque fois que les enregistrements du journal de la transaction doivent être vidées. Chaque vidage est de 512 octets la taille, qui nécessite l'intervention lecteur mécanique significative.

Lorsqu'une transaction unique est utilisée, les enregistrements du journal de la transaction peuvent être fournis 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 n'est pas recommandé d'augmenter l'étendue de transaction. Durables transactions peuvent entraîner des excessive et indésirables blocage ainsi qu'augmenté surcharge. Utiliser les performances de SQL Server 7.0, SQL Server 2000 et SQL Server 2005 compteurs SQL Server : bases de données pour afficher les compteurs en fonction de journal de transaction. Plus précisément, Flushed octets journal/s peut indique plusieurs transactions petites menant à l'activité du disque mécanique élevé.

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 ci-dessus, une seule transaction a été implémentée. Toutefois, dans de nombreux scénarios cela peut entraîner intempestive comportement de verrouillage. Examinez la structure de la transaction. Une peut-être opération telle que les opérations suivantes pour effectuer des lots pour réduire le journal des petit et fréquent vident activité :
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 6. x peuvent ne pas voir l'impact de performances même de fréquents et journal des transactions petit écrit. SQL Server 6. x réécrit la même page de 2 Ko journal que transactions sont validées. Cela peut réduire la taille du journal de manière significative par rapport aux vidages de limite de secteur de 512 octets dans SQL Server 7.0, SQL Server 2000 et SQL Server 2005. Réduire la taille du journal directement est liée à la quantité d'activité du lecteur mécaniques. Toutefois, comme décrite ci-dessus, le SQL Server 6. x algorithme peut exposer les transactions validées.
SQL Server nécessite systèmes afin de prendre en charge ? garantie remise aux médias stable ? comme indiqué dans le programme Microsoft SQL Server Always-On stockage solution analyse. FO Pour plus d'informations sur les exigences entrées 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 Microsoft SQL Server Database Engine entrée/sortie configuration

Propriétés

Numéro d'article: 230785 - Dernière mise à jour: jeudi 9 février 2006 - Version: 5.3
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • 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
Mots-clés : 
kbmt kbhowto kbinfo KB230785 KbMtfr
Traduction automatique
IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d?articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d?avoir accès, dans votre propre langue, à l?ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s?exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s?efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante: 230785
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Envoyer des commentaires

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com