Est-ce que le besoin de lecteur de journal des transactions pour être aussi rapide que le lecteur de base de données?

Question

Nous disons à notre client de placer un fichier de base de données SQL Server (mdf), sur un disque physique différent du fichier journal des transactions (.ldf). La société de technologie (embauché par notre client) voulait mettre le journal des transactions sur un disque plus lent (par exemple moins cher) que le lecteur de base de données, car avec les journaux de transactions, vous êtes en train d'écrire sequencially dans le fichier journal.

Je leur ai dit que je pensais que le lecteur (en fait une configuration RAID) nécessaire pour être sur un disque rapide aussi bien, parce que chaque modification de données appel à la base de données, les besoins être sauvé là-bas, ainsi que la base de données elle-même.

Après avoir dit que si, je me suis aperçu que je n'étais pas tout à fait sûr. Est-ce que la vitesse du lecteur du journal des transactions font une différence significative dans la performance ... si le lecteur avec la base de données est rapide?

Answer 1

La vitesse du lecteur de journal est le facteur le plus critique pour une base de données d'écriture intensive. Aucune mise à jour peut se produire plus rapidement que le journal peut être écrit, de sorte que votre disque dur doit supporter votre au maximum taux de mise à jour à un pic connu. Et toutes les mises à jour génèrent journal. fichier de base de données mises à jour (MDF / NDF) peut se permettre d'écrire un rythme plus lent en raison de deux facteurs

• des mises à jour de données sont écrites paresseusement et rincée au point de contrôle. Cela signifie qu'un débit pic de mise à jour peut être amorti sur la voiture moyenne
• plusieurs mises à jour peuvent accumuler sur une seule page et sera donc besoin d'une seule écriture

Vous avez raison que le journal est le débit critique.

Mais en même temps, les écritures de journal ont un motif spécifique de l'écriture séquentielle: journal est toujours ajouté à la fin. Tous les disques mécaniques ont un débit beaucoup plus élevé, pour les lectures et les écritures, pour les opérations successives, car elles impliquent moins de mouvement physique des têtes de disque. Alors, est aussi vrai que vos ops les gars disent qu'un lecteur plus lent peut offrir en fait un débit suffisant.

Mais ceux-ci viennent avec quelques grands avertissements:

• le lecteur plus lent (ou une combinaison RAID) doit vraiment offrir haut débit séquentiel
• le lecteur doit voir les écritures de journal d'une seule et unique base de données, et rien d'autre. Toute autre opération qui pourrait interférer avec la position de la tête du disque actuel endommagera votre débit d'écriture et le résultat de la performance de base de données plus lente
• le journal doit être seulement écrire, et ne pas lire. Gardez à l'esprit que certains composants doivent lire le journal, et ils vont ainsi déplacer la mécanique de disque à d'autres postes afin qu'ils puissent relire le journal écrit précédemment:
  • réplication transactionnelle
  • mirroring de base de données
  • sauvegarde du journal

Answer 2

En termes simples, si vous parlez d'une base de données OLTP, votre débit est déterminé par la vitesse de vos écritures au journal des transactions. Une fois ce plafond de performance est frappé, toutes les autres actions dépendantes doivent attendre sur le commettras de se connecter à compléter.

Ceci est un développement très simpliste sur le fonctionnement interne du journal des transactions, auquel des livres entiers sont consacrés, mais les restes de point rudimentaire.

Maintenant, si le système de stockage que vous travaillez avec peut fournir le IOPS que vous avez besoin pour soutenir à la fois vos fichiers de données de journaux de transactions et la base de données ensemble, puis un lecteur partagé / LUN fournirait suffisamment à vos besoins.

Pour vous fournir un plan d'action spécifique recommandée je besoin de savoir plus au sujet de votre charge de travail de base de données et les performances dont vous avez besoin de votre serveur de base de données pour fournir.

mettre la main sur le titre SQL Server 2008 internes pour obtenir un regard approfondi sur les éléments internes du journal des transactions SQL Server, il est l'un des meilleurs titres SQL Server là et il va payer pour lui-même en quelques minutes de la valeur que vous gagnez de la lecture.

Answer 3

Eh bien, le journal des transactions est la structure principale qui fournit ACID, peut être un goulot d'étranglement pour la performance, et si vous faites des sauvegardes régulièrement son espace nécessaire a une limite supérieure, donc je le mettre dans un coffre-fort, rouler vite avec juste assez d'espace + un peu de marge.

Answer 4

Le journal des transactions devrait être sur les disques les plus rapides, si elle ne peut tout simplement compléter l'écriture dans le journal qu'il peut faire le reste de la transaction dans la mémoire et le laisser frapper le disque plus tard.