Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Windows Windows Serveur SQL Serveur Un seul fichier de données ou plusieurs

Un seul fichier de données ou plusieurs

8 réponses
Avatar
olivier
j'ai une base de 600 Mo qui a été installée au départ dans un seul fichier de
données. A terme elle devrait atteindre les 2 Go. ma question est quelle est
la configuration idéale et la plus optimiser : un seul fichier ou plusieurs
fichiers pour les datas ? Et si c'est plusieurs fichiers, que dois-je prendre
en parametres pour déterminer la taille de chaque fichier ? Puis-je répartir
le contenu du fichier actuel vers plusieurs par exemple en ne laissant dans
le premier fichier que les tables systeme, puis en répartissant les tables
dans les autres fichiers ?
Merci de votre assistance (serveur SQL 2000 SP3 - 2Go ram)
Signaler un problème avec ce contenu

8 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Fred BROUARD
Bonjour,

olivier a écrit:
j'ai une base de 600 Mo qui a été installée au départ dans un seul fichier de
données. A terme elle devrait atteindre les 2 Go. ma question est quelle est
la configuration idéale et la plus optimiser : un seul fichier ou plusieurs
fichiers pour les datas ? Et si c'est plusieurs fichiers, que dois-je prendre
en parametres pour déterminer la taille de chaque fichier ? Puis-je répartir
le contenu du fichier actuel vers plusieurs par exemple en ne laissant dans
le premier fichier que les tables systeme, puis en répartissant les tables
dans les autres fichiers ?
Merci de votre assistance (serveur SQL 2000 SP3 - 2Go ram)




tout dépend si vous voulez de l'optimisation en performances ou en admin.

En perf le découpage en groupe de fichier implique le placement de ces fichiers
sur des grappes RAID différentes afin d'assurer un accès parallèle.

En admin le décoyupage peut être intéressant pour les problématiques de
sauvegardes partielles.

A +

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Avatar
olivier
je souhaites gagner en performances.
il me faut donc un seul fichier ou plusieurs fichiers pour les datas ?
Et si c'est plusieurs fichiers, que dois-je prendre en parametres pour
déterminer la taille de chaque fichier ?
Puis-je répartir le contenu du fichier actuel vers plusieurs par exemple en
ne laissant dans le premier fichier que les tables systeme, puis en
répartissant les tables dans les autres fichiers ?


"Fred BROUARD" a écrit :

Bonjour,

olivier a écrit:
> j'ai une base de 600 Mo qui a été installée au départ dans un seul fichier de
> données. A terme elle devrait atteindre les 2 Go. ma question est quelle est
> la configuration idéale et la plus optimiser : un seul fichier ou plusieurs
> fichiers pour les datas ? Et si c'est plusieurs fichiers, que dois-je prendre
> en parametres pour déterminer la taille de chaque fichier ? Puis-je répartir
> le contenu du fichier actuel vers plusieurs par exemple en ne laissant dans
> le premier fichier que les tables systeme, puis en répartissant les tables
> dans les autres fichiers ?
> Merci de votre assistance (serveur SQL 2000 SP3 - 2Go ram)


tout dépend si vous voulez de l'optimisation en performances ou en admin.

En perf le découpage en groupe de fichier implique le placement de ces fichiers
sur des grappes RAID différentes afin d'assurer un accès parallèle.

En admin le décoyupage peut être intéressant pour les problématiques de
sauvegardes partielles.

A +

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************




Avatar
Fred BROUARD
Attention cela n'a d'intérêt que dans le cas de disques SCSI. ATA et cie n'ont
pas d'intérêt car les bus ne fonctionnent pas en parallèle.

olivier a écrit:
je souhaites gagner en performances.
il me faut donc un seul fichier ou plusieurs fichiers pour les datas ?



le top serait d'avoir un fichier de data pour chaque table et un fichier d'index
pour chaque index de chaque table, chaque fichier étant sur une grappe SCSI
différente.

Exemple : base comprenant 2 tables : CLIENT et COMMANDE.
Client à un index sur nom.
Commande à deux index : un sur la clef étrangère de lisaison avec client,
l'autre sur la colonne DATE_COMMANDE.
=> 5 groupe de fichier, donc 5 grappes de disque, sonc si RAID 5 => 15 disques !!!

A cela si l'on veut être encore plus pointu et peformant, il faudrait :
mettre l'OS sur une grappe disque à part
mettre le fichier pagefile.sys sur une grappe disque à part
mettre la base tempdb sur une grappe disque à part
mettre les journaux des bases de production sur une grappe disque à part

on rajoute donc en RAID 5, 20 disques soit un serveur avec 35 disques.


Et si c'est plusieurs fichiers, que dois-je prendre en parametres pour
déterminer la taille de chaque fichier ?



Un outil pour étudier la volumétrie estimée à terme. Power Designer (ex AMC
Designor) de PowerSoft/Sybase, fait cela très bien lors de la modélisation en
calculant le volume des tables ET des index de chaque table.
Prévoir des fichiers de taille fixe sur des disque jamais utilisé (formaté).

Puis-je répartir le contenu du fichier actuel vers plusieurs par exemple en
ne laissant dans le premier fichier que les tables systeme, puis en
répartissant les tables dans les autres fichiers ?



C'est possible, mais c'est une opération lourde





Vous aurez sans doute compris que cela s'étudie en amont de la production et non
après avoir réalisé son application.
Bien entendu la répartition donnée ci dessus est un exemple extrême. Il faut
étudier le chose en tenant compte de la volumétrie et de l'usage des données
(requêtes, fréquences...).


A +


--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************



"Fred BROUARD" a écrit :


Bonjour,

olivier a écrit:

j'ai une base de 600 Mo qui a été installée au départ dans un seul fichier de
données. A terme elle devrait atteindre les 2 Go. ma question est quelle est
la configuration idéale et la plus optimiser : un seul fichier ou plusieurs
fichiers pour les datas ? Et si c'est plusieurs fichiers, que dois-je prendre
en parametres pour déterminer la taille de chaque fichier ? Puis-je répartir
le contenu du fichier actuel vers plusieurs par exemple en ne laissant dans
le premier fichier que les tables systeme, puis en répartissant les tables
dans les autres fichiers ?
Merci de votre assistance (serveur SQL 2000 SP3 - 2Go ram)




tout dépend si vous voulez de l'optimisation en performances ou en admin.

En perf le découpage en groupe de fichier implique le placement de ces fichiers
sur des grappes RAID différentes afin d'assurer un accès parallèle.

En admin le décoyupage peut être intéressant pour les problématiques de
sauvegardes partielles.

A +

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************






Avatar
Philippe T [MS]
Bonjour,

J'abonde dans le sens de Med et j'ajoute les éléments suivants :

Il faut de préférence disposer d'axes disques et de cartes contrôleur
différentes pour :
- le fichier des DATAs
- le fichier des LOGs
- la base TempDB

Pour optimiser encore, il est possible d'isoler les indexes et d'étudier
parmis les tables celles qui pourraient nécessiter d'être sur un autre axe
disque (tables très volumineuses avec accès fréquent, ...)

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

"Med Bouchenafa" wrote in message
news:%
Dans SQL Server, l'unité de stockage n'est pas le fichier mais le groupe de
fichiers ou groupeFile
On ne peut stocker des objets que sur des groupeFiles, et il est impossible
de stocker un objet sur un fichier particulier à moins de créer des
groupFiles mono-fichiers.

Maintenant pour reformuler la question, faudrait-il mieux un groupeFile
contenant un seul fichier ou un groupeFile contenant plusieurs fichiers?
Si l'on crée un groupFile avec plusieurs fichiers et que l'on stocke un
objet sur ce groupFile, SQL Server repartit le stockage de cet objet sur
tous les fichiers du groupFile
La répartition se fait proportionnellement à la taille de chacun des
fichiers.
Dans un système comportant plusieurs axes I/O indépendants, cela permet de
placer chacun des fichiers sur un axe et de faire travailler l'ensemble en
parallèle.
C'est effectivement génial en terme de performance sauf que de nos jours
personne n'utilise un tel système de disques indépendants pour des raisons
de tolérance aux pannes
Tout le monde utilise un système RAID qui non seulement répartit les
fichiers sur plusieurs axes mais assure aussi la tolérance aux pannes .

Alors pourquoi continuer des groupFiles multi-fichiers alors qu'un système
RAID le fait en mieux?
J'en vois deux raisons
- Pour des raisons de maintenance
SQL Server est capable de sauvegarder un fichier et cela peut avoir son
importance sur les très grosses bases de données ou la fenêtre de sauvegarde
peut-être très importante

- Pour des raisons de performance (assez discutables...)
Pour accèder à un objet se trouvant sur plusieurs fichiers, SQL Server est
capable de lancer autant de threads que de fichiers.
Cela permet de paralléliser l'accès à l'objet.
Habituellement, je mets dans chaque fileGroup un nombre de fichiers
proportionnel au nombre de CPU du système
En toute honneté, je n'ai pas vu de perfomances spectaculaires et je n'ai
jamais eu le temps de faire des tests réels sur le sujet.
Si quelqu'un a un lien sur le sujet, je reste très interessé.

Maintenant la deuxième question serait faudrait-il avoir un ou plusieurs
fileGroup?
Seules des considérations d'administration peuvent dicter le choix car SQL
Server est capable de faire une sauvagarde au niveau du grouFile.
Habituellement, j'utilise toujours
-un fileGroup que je nomme SYSTEM et sur lequel je mets les objets
système de la base
-un ou plusieurs fileGroup DATA sur lequel je mets les données (index
cluster compris)
-un ou plusieurs fileGroup INDEX sur lequel le mets les index


--
Bien cordialement
Med Bouchenafa

"olivier" a écrit dans le message de
news:
je souhaites gagner en performances.
il me faut donc un seul fichier ou plusieurs fichiers pour les datas ?
Et si c'est plusieurs fichiers, que dois-je prendre en parametres pour
déterminer la taille de chaque fichier ?
Puis-je répartir le contenu du fichier actuel vers plusieurs par exemple
en
ne laissant dans le premier fichier que les tables systeme, puis en
répartissant les tables dans les autres fichiers ?


"Fred BROUARD" a écrit :

Bonjour,

olivier a écrit:
> j'ai une base de 600 Mo qui a été installée au départ dans un seul
> fichier de
> données. A terme elle devrait atteindre les 2 Go. ma question est
> quelle est
> la configuration idéale et la plus optimiser : un seul fichier ou
> plusieurs
> fichiers pour les datas ? Et si c'est plusieurs fichiers, que dois-je
> prendre
> en parametres pour déterminer la taille de chaque fichier ? Puis-je
> répartir
> le contenu du fichier actuel vers plusieurs par exemple en ne laissant
> dans
> le premier fichier que les tables systeme, puis en répartissant les
> tables
> dans les autres fichiers ?
> Merci de votre assistance (serveur SQL 2000 SP3 - 2Go ram)


tout dépend si vous voulez de l'optimisation en performances ou en admin.

En perf le découpage en groupe de fichier implique le placement de ces
fichiers
sur des grappes RAID différentes afin d'assurer un accès parallèle.

En admin le décoyupage peut être intéressant pour les problématiques de
sauvegardes partielles.

A +

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************






Avatar
Fred BROUARD
Tu a raison j'en étais resté au DMA !!!

mais le P ATA c'était pas génial comme parallélisation. En revanche le S-ATA est
déjà plus intéressant, notamment pour les SAN.

A +

Med Bouchenafa a écrit:
>>Attention cela n'a d'intérêt que dans le cas de disques SCSI. ATA et
cie n'ont
>>pas d'intérêt car les bus ne fonctionnent pas en parallèle.

*C'est assez intriguant comme affirmation!!*
De quel bus s'agit-il?
Un bus IDE/ATA a toujours été parallèle tout comme le bus SCSI d'ailleurs.

Et tout le monde se dérige d'ailleurs aujourd'hui vers un bus série
ATA vers du SATA
SCSI vers du SAS
--
Bien cordialement
Med Bouchenafa

"Fred BROUARD"
<mailto: a écrit dans le message de news:

<mailto:...
> Attention cela n'a d'intérêt que dans le cas de disques SCSI. ATA et
cie n'ont
> pas d'intérêt car les bus ne fonctionnent pas en parallèle.
>
> olivier a écrit:
>> je souhaites gagner en performances.
>> il me faut donc un seul fichier ou plusieurs fichiers pour les datas ?
>
> le top serait d'avoir un fichier de data pour chaque table et un
fichier d'index
> pour chaque index de chaque table, chaque fichier étant sur une
grappe SCSI
> différente.
>
> Exemple : base comprenant 2 tables : CLIENT et COMMANDE.
> Client à un index sur nom.
> Commande à deux index : un sur la clef étrangère de lisaison avec
client,
> l'autre sur la colonne DATE_COMMANDE.
> => 5 groupe de fichier, donc 5 grappes de disque, sonc si RAID 5 =>
15 disques !!!
>
> A cela si l'on veut être encore plus pointu et peformant, il faudrait :
> mettre l'OS sur une grappe disque à part
> mettre le fichier pagefile.sys sur une grappe disque à part
> mettre la base tempdb sur une grappe disque à part
> mettre les journaux des bases de production sur une grappe disque à part
>
> on rajoute donc en RAID 5, 20 disques soit un serveur avec 35 disques.
>
>
>> Et si c'est plusieurs fichiers, que dois-je prendre en parametres pour
>> déterminer la taille de chaque fichier ?
>
> Un outil pour étudier la volumétrie estimée à terme. Power Designer
(ex AMC
> Designor) de PowerSoft/Sybase, fait cela très bien lors de la
modélisation en
> calculant le volume des tables ET des index de chaque table.
> Prévoir des fichiers de taille fixe sur des disque jamais utilisé
(formaté).
>
>> Puis-je répartir le contenu du fichier actuel vers plusieurs par
exemple en
>> ne laissant dans le premier fichier que les tables systeme, puis en
>> répartissant les tables dans les autres fichiers ?
>
> C'est possible, mais c'est une opération lourde
>
>>
>
> Vous aurez sans doute compris que cela s'étudie en amont de la
production et non
> après avoir réalisé son application.
> Bien entendu la répartition donnée ci dessus est un exemple extrême.
Il faut
> étudier le chose en tenant compte de la volumétrie et de l'usage des
données
> (requêtes, fréquences...).
>
>
> A +
>
>
> --
> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
> ********************* http://www.datasapiens.com ***********************
>
>
>>
>> "Fred BROUARD" a écrit :
>>
>>
>>>Bonjour,
>>>
>>>olivier a écrit:
>>>
>>>>j'ai une base de 600 Mo qui a été installée au départ dans un seul
fichier de
>>>>données. A terme elle devrait atteindre les 2 Go. ma question est
quelle est
>>>>la configuration idéale et la plus optimiser : un seul fichier ou
plusieurs
>>>>fichiers pour les datas ? Et si c'est plusieurs fichiers, que
dois-je prendre
>>>>en parametres pour déterminer la taille de chaque fichier ? Puis-je
répartir
>>>>le contenu du fichier actuel vers plusieurs par exemple en ne
laissant dans
>>>>le premier fichier que les tables systeme, puis en répartissant les
tables
>>>>dans les autres fichiers ?
>>>>Merci de votre assistance (serveur SQL 2000 SP3 - 2Go ram)
>>>
>>>
>>>tout dépend si vous voulez de l'optimisation en performances ou en
admin.
>>>
>>>En perf le découpage en groupe de fichier implique le placement de
ces fichiers
>>>sur des grappes RAID différentes afin d'assurer un accès parallèle.
>>>
>>>En admin le décoyupage peut être intéressant pour les problématiques de
>>>sauvegardes partielles.
>>>
>>>A +
>>>
>>>--
>>>Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>>>Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>>>Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>>>********************* http://www.datasapiens.com ***********************
>>>
>>>
>
>



--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Avatar
Pascal
"Philippe T [MS]" wrote in message
news:
Bonjour,

J'abonde dans le sens de Med et j'ajoute les éléments suivants :

Il faut de préférence disposer d'axes disques et de cartes contrôleur
différentes pour :
- le fichier des DATAs
- le fichier des LOGs
- la base TempDB

Pour optimiser encore, il est possible d'isoler les indexes et d'étudier
parmis les tables celles qui pourraient nécessiter d'être sur un autre axe
disque (tables très volumineuses avec accès fréquent, ...)



Je me demande avant d'arriver à de telles solutions si ce n'est pas plus
efficace, simple et moins cher d'acheter des disques plus gros et plus
rapide et peut-êrtre revoir les reqûtes SQL et le modèle afin de les
optimiser...

Evidement c'est plus facile si c'est sur un SAN bien que c'est pas toujours
evident de demander de répartir les fichiers sur des disques séparés afin de
s'assurer d'un balancing maximum.

Pascal
Avatar
Philippe T [MS]
Bonjour,

Chez l'un de mes clients actuellement nous avons obtenu un gain de
performance de plus de 25% simplement en passant d'une configuartion RAID 5
mono axe à une configuration RAID 1 Log + RAID 5 Data.

Après, je suis entièrement d'accord avec vous sur le travail d'optimisation
au niveau de la base. Une étude du plan d'exécution des procédures stockées
les plus consomatrices de la base ainsi que la mise en place d'indexes
pertinent va également vous faire gagner en performance. Par contre la
séparation data / log est un minimum si vous souhaitez obtenir de bonnes
performances.

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

"Pascal" wrote in message
news:aQWUe.12398$

"Philippe T [MS]" wrote in message
news:
Bonjour,

J'abonde dans le sens de Med et j'ajoute les éléments suivants :

Il faut de préférence disposer d'axes disques et de cartes contrôleur
différentes pour :
- le fichier des DATAs
- le fichier des LOGs
- la base TempDB

Pour optimiser encore, il est possible d'isoler les indexes et d'étudier
parmis les tables celles qui pourraient nécessiter d'être sur un autre
axe disque (tables très volumineuses avec accès fréquent, ...)



Je me demande avant d'arriver à de telles solutions si ce n'est pas plus
efficace, simple et moins cher d'acheter des disques plus gros et plus
rapide et peut-êrtre revoir les reqûtes SQL et le modèle afin de les
optimiser...

Evidement c'est plus facile si c'est sur un SAN bien que c'est pas
toujours evident de demander de répartir les fichiers sur des disques
séparés afin de s'assurer d'un balancing maximum.

Pascal



Avatar
Pascal
"Philippe T [MS]" wrote in message
news:
Bonjour,

Chez l'un de mes clients actuellement nous avons obtenu un gain de
performance de plus de 25% simplement en passant d'une configuartion RAID
5 mono axe à une configuration RAID 1 Log + RAID 5 Data.

Après, je suis entièrement d'accord avec vous sur le travail
d'optimisation au niveau de la base. Une étude du plan d'exécution des
procédures stockées les plus consomatrices de la base ainsi que la mise en
place d'indexes pertinent va également vous faire gagner en performance.
Par contre la séparation data / log est un minimum si vous souhaitez
obtenir de bonnes performances.



Oui je suis bien d'accord, mais dans le cadre d'un vieux projet (2001) chez
un gros client (fusion de banques belge-française) , j'ai eu vraiment du mal
à convaincre qu'on fasse ce travail sur le san, c'est-à-dire avoir sur des
disques physique séparé le log, temp (j'ai du insister pour que le temp
reste sur les disques locaux en raid 1), data et index...en plus de
s'assurer que c'était réparti sur les deux contrôleurs pour avoir du
balancing et un max d'I/O...
Ca me semblait la moindre des choses sur un san vu qu'on doit cohabiter avec
d'autres et qu'on a que très peu de garantie sur la vitesse quand les autres
pompent.
Evidement sur un san on n'est pas seul et ou doit parfois passer par des
intermédiaires qui ne comprennent pas toujours l'utilité de ce genre de
chose.
Heureusement la DB était bien foutue et j'avais déjà optimisé un maximum les
procédures, vues indexées etc et les performances ont quand même été
acceptable malgré qu'on n'a pas respecté mes exigeances (pas grand chose,
quelques centaines d'utilisateurs concurent sur quelques milllions de record
par tables sur une db contenant aussi des documents en upload/download)
Parfois le plus dur est de convaincre...on perd un temps fou en energie.

Pourtant tout est bien expliqué sur le site micrososft et aussi dans les
help.


Pascal