Nous disons à notre client de mettre un fichier de base de données SQL Server (MDF) sur un lecteur physique différent de celui du fichier journal de transaction (LDF). La société de technologie (embauchée par notre client) souhaitait mettre le journal de transaction sur un lecteur plus lent (par exemple moins cher) que le lecteur de base de données, car avec des journaux de transaction, vous n'écrivez simplement à une écriture séquenciale dans le fichier journal.
Je leur ai dit que je pensais que le lecteur (en fait une configuration RAID) devait également être sur un lecteur rapide, car chaque appel de modification de données à la base de données doit être enregistré là-bas, ainsi que la base de données elle-même.
Après avoir dit que, j'ai réalisé que je n'étais pas totalement sûr de cela. La vitesse du lecteur de transaction fait-elle une différence significative de la performance ... si le lecteur avec la base de données est rapide?
4 Réponses :
En termes simplistes, si vous parlez d'une base de données OLTP, votre débit est déterminé par la vitesse de vos écritures sur le journal des transactions. Une fois que ce plafond de performance est touché, toutes les autres actions dépendantes doivent attendre sur le contrat de se connecter à compléter.
C'est une prise très simpliste sur les internes du journal des transactions, auxquels des livres entiers sont dédiés, mais le point rudimentaire reste.
MAINTENANT Si le système de stockage que vous utilisez peut fournir aux iops dont vous avez besoin pour prendre en charge les fichiers de votre journal de transaction et de la base de données, un lecteur / LUN partagé fournirait suffisamment vos besoins.
Pour vous fournir une ligne d'action recommandée spécifique, je devrais en savoir plus sur votre charge de travail de base de données et les performances que vous souhaitez que votre serveur de base de données soit livré.
Obtenez vos mains sur le titre Internals SQL Server 2008 Pour obtenir un look approfondi dans les internes du journal des transactions SQL Server, c'est l'un des meilleurs titres SQL Server là-bas et il paiera Pour lui-même en quelques minutes de la valeur que vous gagnez de la lecture.
+1: Le livre (s) de Kalen Delaney est la source pour aller pour tous les détails.
Eh bien, le journal des transactions est la structure principale qui fournit de l'acide, peut être un gros goulot d'étranglement pour la performance, et si vous faites des sauvegardes régulièrement, son espace requis a une limite supérieure, donc je le mettrais dans un lecteur sûr et rapide avec juste assez d'espace + un peu de marge.
Le journal des transactions doit être sur les lecteurs les plus rapides, si cela peut simplement compléter l'écriture sur le journal, il peut effectuer le reste de la transaction en mémoire et laisser tomber le disque plus tard.
La vitesse du lecteur de journal est le facteur le plus critique pour une base de données intensive d'écriture. Aucune mises à jour ne peut se produire plus rapidement que le journal peut être écrit, votre lecteur doit donc prendre en charge votre taux de mise à jour maximum expérimenté lors d'une pointe. Et toutes les mises à jour génèrent un journal. Les mises à jour du fichier de base de données (MDF / NDF) peuvent offrir des taux d'écriture plus lents en raison de deux facteurs
Vous avez donc raison que le débit de journal est critique.
Mais en même temps, les écrivies de journal ont un motif spécifique d'écrivies séquentielles: le journal est toujours ajouté à la fin. Tous les lecteurs mécaniques ont un débit beaucoup plus élevé, pour les lectures et les écrires, pour des opérations séquentielles, car ils impliquent moins de mouvements physiques des têtes de disque. Donc, c'est aussi vrai que votre ops les gars disent qu'un lecteur plus lent peut offrir en fait suffisamment de débit.
Mais tout cela vient avec de grands avertissements:
+1: Un point important sur les composants SQL qui "lisent" le journal de transaction car c'est si souvent surveillé.
Merci, vos informations (avec les autres réponses) éclairent les choses. Nous aurons plus d'un journal sur ce lecteur - bien que vous aurez de loin le trafic le plus transactionnel. Il y aura également des sauvegardes de journal de transaction régulières. Je pense qu'un lecteur rapide est le pari le plus sûr.
Vous pouvez toujours utiliser SQLIOSIM.EXE pour tester diverses configurations avant de déployer: support.microsoft.com/kb/231619 < / a>