Discussion :

[Tuxoon]

Bonjour tout le monde ,

Je viens de préparer un serveur sur lequel je dois installer une instance Microsoft SQL Server:

1. (C:\) Disque SYSTEM (2 disques SAS en RAID 1)
2. (D:\) Disque DATA (Carte SSD-Solid-State Drive) pour la/les Database(s)
3. (E:\) Disque non attribué (2 disques SAS en RAID 1)

Je suis mitigé concernant l'endroit où placer TEMPDB:

1. Mettre TEMPDB sur la carte SSD avec les Databases
2. Mettre TEMPDB sur le deuxième disque (SAS) (E:\)

Dans les deux cas, je crois passer outre les recommandations de Microsoft:

http://msdn.microsoft.com/fr-fr/library/ms175527.aspx

1. Placez la base de données tempdb sur un sous-système d'E/S rapide. Si plusieurs disques sont directement attachés, utilisez l'agrégation de disques.
2. Placez la base de données tempdb sur des disques différents de ceux employés par les bases de données utilisateur.

De plus, il est dit dans le livre "Professional SQL Server 2008 Internals and Troubleshooting" de Christian Bolton - aux éditions "Wrox Press © 2010 Citation":

"Compounding the cost problem is the fact that solid-state drives have a limited life span of writes. A given area of flash memory can only be written to so many times before it fails. Even though this number can be in the tens of thousands, that type of load occurs frequently in databases. SQL Server's temdb or log files are written to constantly, and may not make a good fit for solid-state drives."

Ce qui m'a conduit à rajouter les deux disques SAS en RAID 1 au serveur, spécialement pour TEMPDB.

Mes questions sont les suivantes:

1. Au vue des différences de performances entre le lecteur disque (D:\) SSD et (E:\) SAS-RAID1, est-il contre performant de placer TEMPDB sur le lecteur (E:\)?
2. Quelle est la meilleure solution à appliquer concernant ma config?
3. Quelles autres solutions pourriez-vous me proposer?

Merci beaucoup pour votre aide et vos lumières

[SQLpro]

D'un autre côté si tu n'as pas peur que ton SSD soit mort d'ici 2 ans, tu peut mettre la SSD.... Mais le problème est que la lecture est rapide, mais l'écriture lente (en tout cas pas franchement mieux qu'avec une config de bons disques).
la raison est que le disque doit vérifier qu'il a bien écrit et si ce n'est pas le cas, refaire son écriture sur un autre bloc.

J'ai pas noté de grande différences entre un très bonne config disque et un serveur bien dimensionné (notamment en RAM) et l'utilisation des disques SSD pour une même application. (utilisation de cartes Fusion IO).

A +

[mikedavem]

Carte SSD ? ou disques SSDS ? ou carte IO Fusion ?

Si vous parlez des nouvelles cartes IO Fusion celles-ci offrent des IOPS intéressants pour tempdb. J'ai eu l'occasion de mettre ce type de carte pour une base de données extrêmement consommatrice en IO sur tempdb et la plupart des requêtes ont vu leur performance augmenter de 60% environ (parce que celles-ci utilisaient beaucoup tempdb j'insiste)

Cf ce billet

Cependant je suis du même avis que SQLPro et je trouve que ces technos ne sont pas encore vraiment matures et ont une durée de vie plutôt limitée. En écriture les performances sont quand même bien moins impressionnantes qu'en lecture. Il faut cependant noter qu'une config SSD sera quand même un peu plus rapide qu'une config SAS pour les opérations aléatoires. Avec les SSD on évite les temps de recherche dû à la mécanique des disques. Le coût reste cependant un facteur important de décision.

(D:\) Disque DATA (Carte SSD-Solid-State Drive) pour la/les Database(s)

Est ce qu'il existe un mécanisme de redondance ici ? (RAID 1 par exemple)
++

[Tuxoon]

Bonsoir,

Merci à vous pour vos réponses , ca me rassure dans les choix avenirs .

Est ce qu'il existe un mécanisme de redondance ici ? (RAID 1 par exemple)
++

Il s'agit de carte PCIexpress en RAID-0 dont voici les caracteristiques:

http://www.ocztechnology.com/ocz-rev...press-ssd.html

Je note donc que l'utilisation d'un disque SSD est:

1. une bonne solution concernant les bases de données destinées à la consultation
2. mais un mauvais choix concernant celles sur lequelles s'effectuent un certains nombres d'ecriture limitant ainsi la durée de vie de ces disques
3. une bonne solution en terme de performance concernant TEMPDB, tout en prenant compte que cette utilisation d'écriture constante limite sa durée de vie

Concernant ce serveur là, il s'agit d'un serveur temporaire qui sera utilisé pendant un peu plus d'un mois pour un grand traitement de données (extraction, import, export). Je n'en sais pas plus, le projet vient de m'être donner aujourd'hui . J'en serai plus demain.

Je vais donc tout mettre sur le disque SSD.

Merci encore pour vos lumières .

Je vous souhaite une bonne soirée ou journée