Performance

Bonjour

il ne suffit pas de séparer les groupes de fichiers, il faut aussi les
placer sur des disques physiques differents.



Le 03/02/2006, Michel PRIORI a supposé :

Bonjour à tous,

J'ai fait une série de tests sur des serveurs (pas en production) sur des
disques IDE simples.
Quelqu'un peut'il me donner des valeurs "terrain" sur l'amélioration des
performances après avoir créé, sur le(s) même(s) disques, plusieurs groupes
de fichiers afin de séparer les index des tables.
Pour ma part les améliorations constatées sont minimes (moins de 1%).

Quels sont vos retours ?

Ok pour les mettre sur des disques différents.

Ce que je recherche : obtenir la compaison effective entre une base de
données une fois avec 1 Groupe de Fichier (1GF) de 2 Fichiers (2F) chacun sur
1 disque chacun (2D) par rapport à 2 GF de 1 F sur 2 D en tout.
Pour être encore plus générique j'espère des retours avec plus de fichiers
et de GF.

Cordialement

"Nicolas Gouyette" wrote:

Bonjour

il ne suffit pas de séparer les groupes de fichiers, il faut aussi les
placer sur des disques physiques differents.



Le 03/02/2006, Michel PRIORI a supposé :
> Bonjour à tous,
>
> J'ai fait une série de tests sur des serveurs (pas en production) sur des
> disques IDE simples.
> Quelqu'un peut'il me donner des valeurs "terrain" sur l'amélioration des
> performances après avoir créé, sur le(s) même(s) disques, plusieurs groupes
> de fichiers afin de séparer les index des tables.
> Pour ma part les améliorations constatées sont minimes (moins de 1%).
>
> Quels sont vos retours ?

Bonjour,

Pour améliorer les performances, il faut au moins :

- Séparer les fichiers DATA et LOG sur des disques différents (si possible
avec des cartes contrôleurs différents)
- Spliter la base TempDB en autant de fichier que de processeurs disponibles
(a vérifier)

Pour le reste, le mieux est de disposer d'un maximum d'axe permettant de
paraléliser les accès. Le split d'un fichier en plusieurs sur un même disque
ne va pas améliorer les performances mais permettre d'améliorer la
maintenance de la base (fichiers plus petit et donc plus facilement
manipulable).

----------------------------------------------------------------------
Philippe TROTIN - Microsoft Service France

"Michel PRIORI" <MichelPRIORI@discussions.microsoft.com> wrote in message
news:4E3B204A-DF23-44CA-B09F-D6782F33C4D6@microsoft.com...

Ok pour les mettre sur des disques différents.

Ce que je recherche : obtenir la compaison effective entre une base de
données une fois avec 1 Groupe de Fichier (1GF) de 2 Fichiers (2F) chacun
sur
1 disque chacun (2D) par rapport à 2 GF de 1 F sur 2 D en tout.
Pour être encore plus générique j'espère des retours avec plus de fichiers
et de GF.

Cordialement

"Nicolas Gouyette" wrote:

Bonjour

il ne suffit pas de séparer les groupes de fichiers, il faut aussi les
placer sur des disques physiques differents.



Le 03/02/2006, Michel PRIORI a supposé :
> Bonjour à tous,
>
> J'ai fait une série de tests sur des serveurs (pas en production) sur
> des
> disques IDE simples.
> Quelqu'un peut'il me donner des valeurs "terrain" sur l'amélioration
> des
> performances après avoir créé, sur le(s) même(s) disques, plusieurs
> groupes
> de fichiers afin de séparer les index des tables.
> Pour ma part les améliorations constatées sont minimes (moins de 1%).
>
> Quels sont vos retours ?

Bonjour,
et merci pour ces précisions

Ma question reste néanmoins sans réponse : Est-ce que à configuration
identique (même nombre de disque, même nombre de fichier) le fait de créer
un groupe de fichier spécifique pour les index améliore les performances en
vrai.

Je dis ça car c'est une recommendation que j'ai lu à plusieurs reprises et
je n'en vois pas la justification technique. Par contre je vois très bien les
problèmes de maintenance et de restaure.

Donc est-ce quelqu'un à des chiffres et des tests à nous proposer pour
montrer cela ou est-ce du vent ?


"Philippe T [MS]" wrote:

Bonjour,

Pour améliorer les performances, il faut au moins :

- Séparer les fichiers DATA et LOG sur des disques différents (si possible
avec des cartes contrôleurs différents)
- Spliter la base TempDB en autant de fichier que de processeurs disponibles
(a vérifier)

Pour le reste, le mieux est de disposer d'un maximum d'axe permettant de
paraléliser les accès. Le split d'un fichier en plusieurs sur un même disque
ne va pas améliorer les performances mais permettre d'améliorer la
maintenance de la base (fichiers plus petit et donc plus facilement
manipulable).

----------------------------------------------------------------------
Philippe TROTIN - Microsoft Service France

"Michel PRIORI" <MichelPRIORI@discussions.microsoft.com> wrote in message
news:4E3B204A-DF23-44CA-B09F-D6782F33C4D6@microsoft.com...
> Ok pour les mettre sur des disques différents.
>
> Ce que je recherche : obtenir la compaison effective entre une base de
> données une fois avec 1 Groupe de Fichier (1GF) de 2 Fichiers (2F) chacun
> sur
> 1 disque chacun (2D) par rapport à 2 GF de 1 F sur 2 D en tout.
> Pour être encore plus générique j'espère des retours avec plus de fichiers
> et de GF.
>
> Cordialement
>
> "Nicolas Gouyette" wrote:
>
>> Bonjour
>>
>> il ne suffit pas de séparer les groupes de fichiers, il faut aussi les
>> placer sur des disques physiques differents.
>>
>>
>>
>> Le 03/02/2006, Michel PRIORI a supposé :
>> > Bonjour à tous,
>> >
>> > J'ai fait une série de tests sur des serveurs (pas en production) sur
>> > des
>> > disques IDE simples.
>> > Quelqu'un peut'il me donner des valeurs "terrain" sur l'amélioration
>> > des
>> > performances après avoir créé, sur le(s) même(s) disques, plusieurs
>> > groupes
>> > de fichiers afin de séparer les index des tables.
>> > Pour ma part les améliorations constatées sont minimes (moins de 1%).
>> >
>> > Quels sont vos retours ?
>>
>>
>>

Non et Oui !!!
Non car un groupe de fichiers, par lui-même, n'a pas vocation d'amélioration
des performances mais plutot une fonction de maintenance comme tu le
signales.
Par contre, il est plus que bénéfique de mettre un index sur un autre disque
dans un autre fichier
Cela permettra à SQL Server de paralléliser les I/O. Il ouvrira un thread
pour chaque fichier.
Pour bénéficier de ce parallélisme, il te faut mettre cet index sur un autre
fichier et le seul moyen d'y arriver passe par la création d'un groupe de
fichiers sur lequel sera placé cet index

--
Bien cordialement
Med Bouchenafa

"Michel PRIORI" <MichelPRIORI@discussions.microsoft.com> a écrit dans le
message de news: 242A5CCE-E810-4641-8619-E13A24CFF121@microsoft.com...

Bonjour,
et merci pour ces précisions

Ma question reste néanmoins sans réponse : Est-ce que à configuration
identique (même nombre de disque, même nombre de fichier) le fait de
créer
un groupe de fichier spécifique pour les index améliore les performances
en
vrai.

Je dis ça car c'est une recommendation que j'ai lu à plusieurs reprises et
je n'en vois pas la justification technique. Par contre je vois très bien
les
problèmes de maintenance et de restaure.

Donc est-ce quelqu'un à des chiffres et des tests à nous proposer pour
montrer cela ou est-ce du vent ?


"Philippe T [MS]" wrote:

Bonjour,

Pour améliorer les performances, il faut au moins :

- Séparer les fichiers DATA et LOG sur des disques différents (si
possible
avec des cartes contrôleurs différents)
- Spliter la base TempDB en autant de fichier que de processeurs
disponibles
(a vérifier)

Pour le reste, le mieux est de disposer d'un maximum d'axe permettant de
paraléliser les accès. Le split d'un fichier en plusieurs sur un même
disque
ne va pas améliorer les performances mais permettre d'améliorer la
maintenance de la base (fichiers plus petit et donc plus facilement
manipulable).

----------------------------------------------------------------------
Philippe TROTIN - Microsoft Service France

"Michel PRIORI" <MichelPRIORI@discussions.microsoft.com> wrote in message
news:4E3B204A-DF23-44CA-B09F-D6782F33C4D6@microsoft.com...
> Ok pour les mettre sur des disques différents.
>
> Ce que je recherche : obtenir la compaison effective entre une base de
> données une fois avec 1 Groupe de Fichier (1GF) de 2 Fichiers (2F)
> chacun
> sur
> 1 disque chacun (2D) par rapport à 2 GF de 1 F sur 2 D en tout.
> Pour être encore plus générique j'espère des retours avec plus de
> fichiers
> et de GF.
>
> Cordialement
>
> "Nicolas Gouyette" wrote:
>
>> Bonjour
>>
>> il ne suffit pas de séparer les groupes de fichiers, il faut aussi les
>> placer sur des disques physiques differents.
>>
>>
>>
>> Le 03/02/2006, Michel PRIORI a supposé :
>> > Bonjour à tous,
>> >
>> > J'ai fait une série de tests sur des serveurs (pas en production)
>> > sur
>> > des
>> > disques IDE simples.
>> > Quelqu'un peut'il me donner des valeurs "terrain" sur l'amélioration
>> > des
>> > performances après avoir créé, sur le(s) même(s) disques, plusieurs
>> > groupes
>> > de fichiers afin de séparer les index des tables.
>> > Pour ma part les améliorations constatées sont minimes (moins de
>> > 1%).
>> >
>> > Quels sont vos retours ?
>>
>>
>>

Merci Med,

Peux tu me dire, sur ton vécu, quelle est l'incidence d'une telle opération.

Au passage les livres blancs de Bill nous indiquent que si l'on créer un
groupe de fichier avec autant de fichiers que de disques physiques, on
obtient aussi la parallélisation dont tu parles.

Je reste avec mon interrogation :
Est-ce que ça vaut le coût de séparer les index des tables en restant sur la
même configuration matérielle et le même nombre de fichier (considérant qu'il
en existe plusieurs de base).
Pour ma part je n'ai pas un gain de performance pertinent.
Est-ce que quelqu'un à déjà eu une amélioration des perf avec type de
structuration ?

"Med Bouchenafa" wrote:

Non et Oui !!!
Non car un groupe de fichiers, par lui-même, n'a pas vocation d'amélioration
des performances mais plutot une fonction de maintenance comme tu le
signales.
Par contre, il est plus que bénéfique de mettre un index sur un autre disque
dans un autre fichier
Cela permettra à SQL Server de paralléliser les I/O. Il ouvrira un thread
pour chaque fichier.
Pour bénéficier de ce parallélisme, il te faut mettre cet index sur un autre
fichier et le seul moyen d'y arriver passe par la création d'un groupe de
fichiers sur lequel sera placé cet index

--
Bien cordialement
Med Bouchenafa

"Michel PRIORI" <MichelPRIORI@discussions.microsoft.com> a écrit dans le
message de news: 242A5CCE-E810-4641-8619-E13A24CFF121@microsoft.com...
> Bonjour,
> et merci pour ces précisions
>
> Ma question reste néanmoins sans réponse : Est-ce que à configuration
> identique (même nombre de disque, même nombre de fichier) le fait de
> créer
> un groupe de fichier spécifique pour les index améliore les performances
> en
> vrai.
>
> Je dis ça car c'est une recommendation que j'ai lu à plusieurs reprises et
> je n'en vois pas la justification technique. Par contre je vois très bien
> les
> problèmes de maintenance et de restaure.
>
> Donc est-ce quelqu'un à des chiffres et des tests à nous proposer pour
> montrer cela ou est-ce du vent ?
>
>
> "Philippe T [MS]" wrote:
>
>> Bonjour,
>>
>> Pour améliorer les performances, il faut au moins :
>>
>> - Séparer les fichiers DATA et LOG sur des disques différents (si
>> possible
>> avec des cartes contrôleurs différents)
>> - Spliter la base TempDB en autant de fichier que de processeurs
>> disponibles
>> (a vérifier)
>>
>> Pour le reste, le mieux est de disposer d'un maximum d'axe permettant de
>> paraléliser les accès. Le split d'un fichier en plusieurs sur un même
>> disque
>> ne va pas améliorer les performances mais permettre d'améliorer la
>> maintenance de la base (fichiers plus petit et donc plus facilement
>> manipulable).
>>
>> ----------------------------------------------------------------------
>> Philippe TROTIN - Microsoft Service France
>>
>> "Michel PRIORI" <MichelPRIORI@discussions.microsoft.com> wrote in message
>> news:4E3B204A-DF23-44CA-B09F-D6782F33C4D6@microsoft.com...
>> > Ok pour les mettre sur des disques différents.
>> >
>> > Ce que je recherche : obtenir la compaison effective entre une base de
>> > données une fois avec 1 Groupe de Fichier (1GF) de 2 Fichiers (2F)
>> > chacun
>> > sur
>> > 1 disque chacun (2D) par rapport à 2 GF de 1 F sur 2 D en tout.
>> > Pour être encore plus générique j'espère des retours avec plus de
>> > fichiers
>> > et de GF.
>> >
>> > Cordialement
>> >
>> > "Nicolas Gouyette" wrote:
>> >
>> >> Bonjour
>> >>
>> >> il ne suffit pas de séparer les groupes de fichiers, il faut aussi les
>> >> placer sur des disques physiques differents.
>> >>
>> >>
>> >>
>> >> Le 03/02/2006, Michel PRIORI a supposé :
>> >> > Bonjour à tous,
>> >> >
>> >> > J'ai fait une série de tests sur des serveurs (pas en production)
>> >> > sur
>> >> > des
>> >> > disques IDE simples.
>> >> > Quelqu'un peut'il me donner des valeurs "terrain" sur l'amélioration
>> >> > des
>> >> > performances après avoir créé, sur le(s) même(s) disques, plusieurs
>> >> > groupes
>> >> > de fichiers afin de séparer les index des tables.
>> >> > Pour ma part les améliorations constatées sont minimes (moins de
>> >> > 1%).
>> >> >
>> >> > Quels sont vos retours ?
>> >>
>> >>
>> >>
>>
>>
>>

D'où vient cette sorte de mythe concernant des fichiers multiples pour
tempdb ?
Je n'ai jamais vu de document sérieux là dessus, et d'expérience, les
fichiers de tempdb sont remplis en incrémental (1er puis quand plein, 2ème,
etc ...), bref, pas de quoi améliorer les perfs !

Quelqu'un peut éclairer ma lanterne si j'ai loupé quelque chose ?

Guillaume.
========================== "Philippe T [MS]" a écrit :

Bonjour,

Pour améliorer les performances, il faut au moins :

- Séparer les fichiers DATA et LOG sur des disques différents (si possible
avec des cartes contrôleurs différents)
- Spliter la base TempDB en autant de fichier que de processeurs disponibles
(a vérifier)

Salut,

Ces questions de résultat chiffrés sont illusoires car elles dépendent d'un
tas de paramètres !
Tout dépend du rapport lectures/écritures, de la quantité de cache de ton
controleur RAID, de ton nombre d'axes, de ta quantité d'indexes, du type
d'accès que tu effectues.

Bref, il est bien difficile de pouvoir te donner un avis dans l'absolu.
Il est vrai cependant que si tu as une grosse base bien indexée avec des
requêtes qui, grâce aux indexes sont très ciblées, tu gagneras probablement
sensiblement en séparant en deux volumes un pour les données, l'autres pour
les indexes.

Il faut cependant mettre avant celà les tlogs sur un autre volume car sur
une activité transactionnelle forte, le type d'I/O sur les tlogs et leur
occurence sont parasités par les accès aux données. Les tlogs méritent donc
en premier lieu d'être isolés car en plus ce sont des écritures synchrones,
donc avec un impact directement perceptible par l'utilisateur lors de modifs
(insert/delete/update).

Mettre en tempdb sur des disques séparés peut aussi être intéressant en cas
de nombreuses sous-requêtes, tables tempo ou requêtes avec tri.

Enfin, parfois dans certains cas, quelques tables très modifiées peuvent
avoir intérêt à avoir leurs indexes séparés sur un autre volume pour
permettre de paralléliser de manière efficace.

Bref, rien ne vaut un test en vrai quoi qu'il en soit !

Guillaume.
============================= "Michel PRIORI" a écrit :

Merci Med,

Peux tu me dire, sur ton vécu, quelle est l'incidence d'une telle opération.

Au passage les livres blancs de Bill nous indiquent que si l'on créer un
groupe de fichier avec autant de fichiers que de disques physiques, on
obtient aussi la parallélisation dont tu parles.

Je reste avec mon interrogation :
Est-ce que ça vaut le coût de séparer les index des tables en restant sur la
même configuration matérielle et le même nombre de fichier (considérant qu'il
en existe plusieurs de base).
Pour ma part je n'ai pas un gain de performance pertinent.
Est-ce que quelqu'un à déjà eu une amélioration des perf avec type de
structuration ?

Sur mon vécu il m'est difficile de te donner des chiffres
Soit j'interviens en audit et c'est quelque chose que je recommende
systématiquement
Comme cette recommendation s'accompagne généralement d'un tas d'autres, je
n'ai jamais réellement mesuré séparement son impact.

Soit j'interviens en conception, c'est aussi que je fais systématiquement
sans vraiment me poser de question

Maintenant Michel, il est vrai que ta question est légitime et je ne vois
qu'un seul moyen d'y répondre
Faire un essai et mesurer le temps d'attente moyen des IO
SELECT * FROM :: fn_virtualfilestats(dbid, fileid)
Il y a une colonne interessante IoStallMS qui te donne le temps d'attente
(en millisecondes) des I/O sur le fichier fileID


--
Bien cordialement
Med Bouchenafa


"Michel PRIORI" <MichelPRIORI@discussions.microsoft.com> a écrit dans le
message de news: 97D04B5B-5496-4685-82E7-125C8AE5802B@microsoft.com...

Merci Med,

Peux tu me dire, sur ton vécu, quelle est l'incidence d'une telle
opération.

Au passage les livres blancs de Bill nous indiquent que si l'on créer un
groupe de fichier avec autant de fichiers que de disques physiques, on
obtient aussi la parallélisation dont tu parles.

Je reste avec mon interrogation :
Est-ce que ça vaut le coût de séparer les index des tables en restant sur
la
même configuration matérielle et le même nombre de fichier (considérant
qu'il
en existe plusieurs de base).
Pour ma part je n'ai pas un gain de performance pertinent.
Est-ce que quelqu'un à déjà eu une amélioration des perf avec type de
structuration ?

"Med Bouchenafa" wrote:

Non et Oui !!!
Non car un groupe de fichiers, par lui-même, n'a pas vocation
d'amélioration
des performances mais plutot une fonction de maintenance comme tu le
signales.
Par contre, il est plus que bénéfique de mettre un index sur un autre
disque
dans un autre fichier
Cela permettra à SQL Server de paralléliser les I/O. Il ouvrira un
thread
pour chaque fichier.
Pour bénéficier de ce parallélisme, il te faut mettre cet index sur un
autre
fichier et le seul moyen d'y arriver passe par la création d'un groupe de
fichiers sur lequel sera placé cet index

--
Bien cordialement
Med Bouchenafa

"Michel PRIORI" <MichelPRIORI@discussions.microsoft.com> a écrit dans le
message de news: 242A5CCE-E810-4641-8619-E13A24CFF121@microsoft.com...
> Bonjour,
> et merci pour ces précisions
>
> Ma question reste néanmoins sans réponse : Est-ce que à configuration
> identique (même nombre de disque, même nombre de fichier) le fait de
> créer
> un groupe de fichier spécifique pour les index améliore les
> performances
> en
> vrai.
>
> Je dis ça car c'est une recommendation que j'ai lu à plusieurs reprises
> et
> je n'en vois pas la justification technique. Par contre je vois très
> bien
> les
> problèmes de maintenance et de restaure.
>
> Donc est-ce quelqu'un à des chiffres et des tests à nous proposer pour
> montrer cela ou est-ce du vent ?
>
>
> "Philippe T [MS]" wrote:
>
>> Bonjour,
>>
>> Pour améliorer les performances, il faut au moins :
>>
>> - Séparer les fichiers DATA et LOG sur des disques différents (si
>> possible
>> avec des cartes contrôleurs différents)
>> - Spliter la base TempDB en autant de fichier que de processeurs
>> disponibles
>> (a vérifier)
>>
>> Pour le reste, le mieux est de disposer d'un maximum d'axe permettant
>> de
>> paraléliser les accès. Le split d'un fichier en plusieurs sur un même
>> disque
>> ne va pas améliorer les performances mais permettre d'améliorer la
>> maintenance de la base (fichiers plus petit et donc plus facilement
>> manipulable).
>>
>> ----------------------------------------------------------------------
>> Philippe TROTIN - Microsoft Service France
>>
>> "Michel PRIORI" <MichelPRIORI@discussions.microsoft.com> wrote in
>> message
>> news:4E3B204A-DF23-44CA-B09F-D6782F33C4D6@microsoft.com...
>> > Ok pour les mettre sur des disques différents.
>> >
>> > Ce que je recherche : obtenir la compaison effective entre une base
>> > de
>> > données une fois avec 1 Groupe de Fichier (1GF) de 2 Fichiers (2F)
>> > chacun
>> > sur
>> > 1 disque chacun (2D) par rapport à 2 GF de 1 F sur 2 D en tout.
>> > Pour être encore plus générique j'espère des retours avec plus de
>> > fichiers
>> > et de GF.
>> >
>> > Cordialement
>> >
>> > "Nicolas Gouyette" wrote:
>> >
>> >> Bonjour
>> >>
>> >> il ne suffit pas de séparer les groupes de fichiers, il faut aussi
>> >> les
>> >> placer sur des disques physiques differents.
>> >>
>> >>
>> >>
>> >> Le 03/02/2006, Michel PRIORI a supposé :
>> >> > Bonjour à tous,
>> >> >
>> >> > J'ai fait une série de tests sur des serveurs (pas en production)
>> >> > sur
>> >> > des
>> >> > disques IDE simples.
>> >> > Quelqu'un peut'il me donner des valeurs "terrain" sur
>> >> > l'amélioration
>> >> > des
>> >> > performances après avoir créé, sur le(s) même(s) disques,
>> >> > plusieurs
>> >> > groupes
>> >> > de fichiers afin de séparer les index des tables.
>> >> > Pour ma part les améliorations constatées sont minimes (moins de
>> >> > 1%).
>> >> >
>> >> > Quels sont vos retours ?
>> >>
>> >>
>> >>
>>
>>
>>

Vos interrogation m'en amene une à moi du coup !
je n'ai jamais vraiment eu le besoin de séparer mes index dans des fichiers
séparés toutefois etant curieux de nature et soif d'apprendre !
comment faite vous pour créer un fichier et lui preciser explicitement de
mettre les index sur celui ci ????


je sais créer des groupes de fichier mais la c'est la colle ?


Merci


"GNocent" <GNocent@discussions.microsoft.com> a écrit dans le message de
news: 60BE83F4-BCA7-4E9C-B17D-95A312943E82@microsoft.com...

D'où vient cette sorte de mythe concernant des fichiers multiples pour
tempdb ?
Je n'ai jamais vu de document sérieux là dessus, et d'expérience, les
fichiers de tempdb sont remplis en incrémental (1er puis quand plein,
2ème,
etc ...), bref, pas de quoi améliorer les perfs !

Quelqu'un peut éclairer ma lanterne si j'ai loupé quelque chose ?

Guillaume.
========================== > "Philippe T [MS]" a écrit :

Bonjour,

Pour améliorer les performances, il faut au moins :

- Séparer les fichiers DATA et LOG sur des disques différents (si
possible
avec des cartes contrôleurs différents)
- Spliter la base TempDB en autant de fichier que de processeurs
disponibles
(a vérifier)