Bonjour à tous,
J'ai mes fichiers LOG sur un disque dédié et ceux de DATA sur un autre.
Pour les fichiers de mes bases TEMPDB à mettre avec les data ? log ? ou sur un autre disque ?
Merci.
@+
Version imprimable
Bonjour à tous,
J'ai mes fichiers LOG sur un disque dédié et ceux de DATA sur un autre.
Pour les fichiers de mes bases TEMPDB à mettre avec les data ? log ? ou sur un autre disque ?
Merci.
@+
Dans l'idéal, sur un autre disque. Mais ca c'est dans le meilleur des mondes
Si 2 disques : inversez par croisement le type de fichier sur les disques.
De plus formez plusieurs fichiers d'égale longueur pour tempdb en fonction du parallélisme que vous avez paramétré.
A +
Merci.Citation:
Envoyé par SQLpro
Càd => DB1-file-data sur Disque1 et DB1-log sur Disque2 puis DB2-file-data sur Disque2 et DB2-log sur Disque1 ....
@+
Yes !
A +
Merci bien.
Encore une question et j'arrête .... pour aujourd'hui :ccool:
RAID10 ou RAID5 pour SQLServer ?
@+
L'idée (selon moi) derrière le fait de distinguer le stockage des données et des journaux transactionnels, c'est de pouvoir s'offrir du stockage permettant de mieux répondre (en terme de performances) aux entrées/sorties bien différentes.
Les Fichiers de données sont majoritairement utilisés pour des lectures d'un ensemble de blocs (balayage d'une table ou d'un indexe cluster), et (en proportion) très peu utilisés en écriture (lors du checkpoint).
Les fichiers de journaux sont majoritairement utilisés en petites écritures séquentielles (Log Buffer flush et Commit), assez peu en lectures (rollback et sauvegardes).
Donc positionner les données sur un disque qui répond bien en terme de lectures, et qui accessoirement permet d'héberger une bonne volumétrie à moindre coût semble correspondre au besoin (RAID 5,6,DP,bons en lecture mais mauvais sur les écritures), de même que positionner les journaux transactionnels sur un disque qui répond bien en terme d'écritures, pas nécessairement en capacité d'héberger une grosse volumétrie (RAID 1 et/ou disques SSD par exemple, bons en écriture mais coût élevé).
La préconisation de SQLPro correspond bien (toujours selon moi) à deux bases avec une forte activité transactionnelle (pas ou peu d'accès sur les fichiers de données, donc l'essentiel de l'activité disque correspond à des écritures séquentielles) sur deux disques de même technologie.
Pour ce qui concerne TempDB, les journaux transactionnels ne seront que très peu utilisés (en tout cas pas lors de tris ni de création de tables de hachage, ce qui est censé composer l'essentiel de l'utilisation de cette base), c'est donc le placement du ou des fichiers de données qui prend toute son importance.
Donc idéalement sur un disque distinct.
Mais tout cela dépend complètement de l'activité en base(s). Très concrètement, si vous n'observez (ou ne prévoyez) pas d'attente sur les accès disque (PAGE_IO_LATCH, IO_COMPLETION,ASYNC_IO_COMPLETION, WRITELOG principalement), il n'est absolument pas nécessaire de s'embêter à gérer N disques...
EDIT: correction d'une erreur typo.
Je crois que tu voulais dire fichiers journaux là :aie:Citation:
Les fichiers de données sont majoritairement utilisés en petites écritures séquentielles (Log Buffer flush et Commit), assez peu en lectures (rollback et sauvegardes).
++
Bonsoir,
C'est bien Les Journaux de Transactions.
Merci.
@+
Tout dépend de la carte contrôleur. Si vous en avez une bonne,; préférez le RAID 10... Il sera 4 fois plus efficace dans certains cas de lecture... et 2 fois dans certains cas d'écritures....Citation:
Envoyé par agdid04
A +
(merci David pour l'erreur remontée).
Pour le choix du type de RAID, cela dépend aussi clairement de la volumétrie des données à héberger, du budget et du nombre maximum de disques dans la machine/baie de stockage. On arrive quand même facilement à un équivalent de 7 disques utiles pour pour 9 disques au total sur un RAID 6, alors que par définition RAID 1 et RAID 10 offrent un équivalent de 1 disque utile pour 2 disques au total.
Mais hélas pas du tout pour la même efficacité... Or vu le prix actuel des disques (faible au Go) comparé a ce que coute une migration dans l'urgence, je conseille d'abandonner définitivement les RAID de niveau 5 et 6 et leurs combinaisons (50, 60) dont le RAID DB de NetApp !
Surtout pour ce qui concerne les fichiers du JT...
Regardez les benchmarks du TPC, vous verrez que jamais le stockage est fait avec ce niveau de RAID.....
En sus, les RAID 5 et Cie. sont peu fiable, car la vérification de la parité n'est généralement pas systématique (elle serait trop couteuse en terme de temps de traitement). Ce qui fait qu'il est possible d'obtenir un disque corrompu qu'il est impossible de réparer...
A +