Importance de l'emplacement d'installation de Microsoft SQL Server

J'ai un serveur avec un disque lent bon marché et un disque rapide cher.

Je veux utiliser le disque coûteux pour toutes les choses où il est important qu'il soit rapide, comme mes bases de données.

Pour économiser de l'argent, je veux utiliser le disque lent pour tout ce qui ne fait pas beaucoup de différence, qu'il soit rapide ou lent, comme les sauvegardes.

Maintenant, ma question est, dois-je installer mon Microsoft SQL Server sur le disque lent ou rapide?

(Pour être clair, je placerai mes bases de données sur le disque rapide quoi qu'il arrive, donc ma question ne concerne que l'emplacement de l'installation elle-même)

sql-server database-administration database-performance

— Niels Brinch
source

Pourquoi envisageriez-vous même cela étant donné qu'un ssd à faible écriture de 120 Go est (a) PAS CHER et (b) super rapide et (c) assez bon pour tout ce qui concerne les programmes OS +? J'ai déplacé tous les systèmes d'exploitation à 120 Go ssd il y a 2 ans et le coût n'avait vraiment pas d'importance - à l'époque. Maintenant, c'est encore moins pertinent.

— TomTom

Vous souhaitez confier une base de données critique à un disque SSD? Rappelez-moi de ne jamais faire affaire avec vous ...

— Shadur

@Shadur quel appât de flamme. Oui, je vais le placer sur un disque configuré RAID 10 basé sur SSD qui est répliqué sur 2 autres disques localement et sauvegardé la nuit sur un emplacement distant. Bienvenue dans la décennie!

— Niels Brinch du

@TomTom vous avez raison bien sûr, mais je suis dans une situation plutôt sensible aux coûts dans ce cas, c'est pourquoi je m'embête même avec ce type d'hyperoptimisation. Ma question deviendra de plus en plus hors de propos au fil des ans, comme c'est le cas pour la plupart des questions ici, je suppose.

— Niels Brinch

@NielsBrinch Cent Smart and Pound Foolish. Sérieusement.

— TomTom

Réponses:

C'est une sorte d'opinion, mais je mettrais les binaires SQL Server sur le disque lent. Il est assez courant de placer les fichiers binaires sur le disque du système d'exploitation (bien que certaines personnes détestent cela), ou sur un disque plus lent.

Cependant, vous devez absolument vous rappeler de placer vos bases de données système, en particulier tempdb, sur le disque le plus rapide. En fait, il est également courant de mettre tempdb seul.

Ceci est en ligne avec un couple de d' articles que j'ai trouvé qui pourrait vous être utile.

Il faut également penser aux sauvegardes du journal des transactions, et je suis déchiré parce que vous voulez les LDF sur le disque le plus rapide et que vous voulez également des sauvegardes sur un disque différent de celui où les bases de données vivent, mais il serait préférable qu'elles se trouvent sur un disque plus rapide. Vous devrez faire un jugement, mais je reviendrais probablement sur le disque plus lent et je m'en plaindrais. ;)

— Katherine Villyard
source

Merci. Voulez-vous dire que cela n'affecte pas les performances, notamment si l'installation du serveur SQL (binaires, etc.) est sur le disque lent ou rapide?

— Niels Brinch

Pas que je l'ai remarqué. Et c'est une configuration assez courante.

— Katherine Villyard

Katherine a raison, car les binaires eux-mêmes ne sont pas particulièrement liés aux IO. En général, le fait de placer des fichiers binaires sur un disque rapide améliore les temps de chargement mais affecte rarement la vitesse de fonctionnement générale car le code s'exécute depuis la mémoire. Sauf si vous redémarrez le serveur fréquemment, cela n'aura pas de mal à avoir les binaires sur un stockage plus lent.

— Corey

@Corey remercie beaucoup pour cette explication très précise. C'est ce que je cherchais.

— Niels Brinch du

J'aimerais poursuivre sur la très bonne réponse déjà donnée par Katherine Villyard .

Cela dépend quelque peu de l'utilisation prévue de votre base de données.
Si vous attendez beaucoup d'opérations d'écriture, allez-y et placez vos fichiers .mdfet .ndfsur le disque le plus rapide.

Si toutefois votre base de données est soit une base généralement assez statique (servant du contenu Web par exemple). Et les requêtes ne varient pas beaucoup, il y a de fortes chances que vous ayez une grande quantité de requêtes dans votre mémoire, ou même mises en cache côté application. À quel point vous feriez mieux d'utiliser le disque plus rapide pour votre .ldf, tempdbet les sauvegardes.

De même, si vous vous attendez à de nombreuses requêtes volumineuses, comme pour une OLAPbase de données, vous feriez mieux de stocker votre .mdf, tempdbsur le disque le plus rapide. Et .ldfmettez vos disques plus lents car cela ne fera pas souvent partie du goulot d'étranglement.

Dans tous les cas, ne vous embêtez pas à mettre les binaires sur le disque rapide, nous les mettons généralement sur un disque lent (pas le système si cela peut être évité).
En outre, ne vous laissez pas bloquer pour essayer d'obtenir à la fois les fichiers .ldfet .mdfsur le disque rapide, ils sont généralement séparés chaque fois que possible.

Donc, en résumé, examinez votre charge pour voir quel sera votre goulot d'étranglement le plus probable.

— Reaces
source

Vous avez des choses en arrière. Je sais que c'est contre-intuitif, mais vous voulez les sauvegardes (notamment les sauvegardes du journal des transactions) sur le disque rapide, et les fichiers mdf / ldf (à l'exception notable de tempdb) sur le disque lent.

Vous pouvez y penser comme si Sql Server conserve deux représentations de vos données. Les fichiers MDF + LDF représentent l'état actuel de la base de données, tandis que la sauvegarde (y compris les sauvegardes du journal des transactions depuis la dernière sauvegarde complète) représente ce dont vous avez besoin pour restaurer l'état actuel de la base de données en cas d'échec. Vous voulez garder ces deux représentations séparées l'une de l'autre, donc un événement qui détruit une représentation n'endommagera pas également l'autre représentation.

Il s'avère que les performances du serveur SQL ont tendance à dépendre BEAUCOUP plus de la vitesse à laquelle vous pouvez écrire des fichiers journaux des transactions et de leurs sauvegardes sur la vitesse à laquelle vous pouvez accéder aux fichiers mdf. Cela signifie que vous devez sérieusement envisager de placer des sauvegardes sur le disque rapide (idéalement, vous ajouteriez un petit SSD au serveur que vous pouvez utiliser pour les fichiers ldf, pour leur donner de la vitesse tout en préservant la séparation de vos sauvegardes). Malheureusement, cela laisse le disque lent pour vos fichiers MDF, mais encore une fois: cela n'aura pas autant d'importance que vous le pensez.

Il convient de noter que ce qui précède suppose que vous disposez de suffisamment de RAM, que vous suivez les charges de travail typiques et que vous prévoyez d'utiliser le mode de récupération complète plutôt que simple. De plus, le fonctionnement du système et le programme Sql Server lui-même peuvent être placés sur le lecteur lent, bien que vous souhaitiez probablement autant que vous avez de l'espace pour vivre sur le lecteur rapide.

— Joel Coel
source

Par sauvegardes, j'entends des fichiers qui ne sont pas utilisés, mais simplement stockés. Je mettrais les fichiers mdf et ldf sur le disque rapide. C'est une nouvelle pour moi que mdf est OK pour mettre sur le disque lent, c'était une information intéressante et inattendue.

— Niels Brinch

Vous ne voulez pas le mdf sur le même disque que les sauvegardes / journaux. MDF représente l'état actuel de la base de données. Backup + LDF représente ce dont vous avez besoin pour restaurer la base de données dans son état actuel. Vous voulez que les deux représentations soient séparées l'une de l'autre, donc un événement qui détruit l'une n'endommagera pas également l'autre. Et puisque les journaux et les sauvegardes doivent être sur le disque rapide (les performances dépendent beaucoup plus de la vitesse à laquelle vous pouvez écrire dans le fichier ldf que de la vitesse à laquelle vous pouvez écrire dans le fichier mdf), cela signifie que le mdf doit aller sur le disque lent.

— Joel Coel

Je vais modifier la plupart des commentaires ci-dessus dans la réponse.

— Joel Coel

Je ne sais pas pourquoi vous dites que sur le .ldfet avoir .mdfbesoin d'être séparés en cas de catastrophe ... Il est généralement pas supposé que vous utiliserez l'un pour la reprise après incident, c'est ce que les sauvegardes sont pour. Si vous ne voulez pas autant de perte de données que possible, vous obtenez des sauvegardes de journaux extrêmement fréquentes, vous ne comptez pas sur le fichier journal lui-même.

— Réagit

@Reaces Vous avez raison. J'ai eu un pet de cerveau et écrivais des fichiers LDF avec mes doigts tout en pensant aux sauvegardes TRN dans ma tête. Les pensées générales tiennent, mais je devrai réviser de manière significative pour clarifier cela (y travailler maintenant).

— Joel Coel