Optimiser les accès disque d'une base de données SqlServer

Optimiser les accès disque d'une base de données SqlServer - Disque dur - Hardware

Marsh Posté le 02-09-2004 à 15:03:53    

Je sais, le topic peut paraître bizarre ou mal placé, mais c'est plutôt une question d'ordre générale qui se cache derrière ce topic ;)
 
J'utilise plusieurs base de données sous SqlServer, chacune faisant plusieurs gigas ; par défaut SqlServer ne crée qu'un seul fichier de données par base, je me retrouve donc avec des fichiers monstrueux !
 
Ma question est simple : quel méthode est la + performante entre
. stocker les données ds un seul gros fichier et le parcourir sans arrêt
. stocker les données ds plusieurs fichiers - volumineux
 
???
 
Moi je penche pour la 2ème option, mais je voudrais avoir qq avis avant de me taper toutes les modifs sur les serveurs :D
 
Petite précision : les disques sont des SCSI 15000 rpm en raid 5 et formatés en NTFS :jap:

Reply

Marsh Posté le 02-09-2004 à 15:03:53   

Reply

Marsh Posté le 02-09-2004 à 15:07:34    

duplique une des bases pour faire un test [:spamafote]
 
je ne sais pas comment les fichiers de données sont gérés

Reply

Marsh Posté le 03-09-2004 à 11:09:48    

[:valentinorossi]

Reply

Marsh Posté le 03-09-2004 à 11:50:51    

1 - Je pencherais pour la solution 2.
 
2 - Tu aurais surement plus de réponses sur software & réseaux.

Reply

Marsh Posté le 03-09-2004 à 11:55:05    

point de vue disque dur, dispatcher le contenu dans plusieurs fichiers n'accélérera pas la lecture.
Point de vue parcours du fichier lui même, je sais pas comment se fait la lecture d'une BDD, mais j'imagins qu'il y a des mécanismes pour optimiser celle ci, en s'affranchissant au maximum de la taille globale du fichier, celà dit ça ne peut pas non plus faire de mal d'appliquer ta solution (enfin sauf si tu avais en tête de faire 3000 fichiers différents bien sûr :p).
tu devrais poser la question sur prog plutôt...
petite remarque : le fait de faire plusieurs gros fichiers distincts sur une même partoche va accroitre la fragmentation...


---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
Reply

Marsh Posté le 03-09-2004 à 11:57:21    

TotalRecall a écrit :

point de vue disque dur, dispatcher le contenu dans plusieurs fichiers n'accélérera pas la lecture.
Point de vue parcours du fichier lui même, je sais pas comment se fait la lecture d'une BDD, mais j'imagins qu'il y a des mécanismes pour optimiser celle ci, en s'affranchissant au maximum de la taille globale du fichier, celà dit ça ne peut pas non plus faire de mal d'appliquer ta solution (enfin sauf si tu avais en tête de faire 3000 fichiers différents bien sûr :p).
tu devrais poser la question sur prog plutôt...
petite remarque : le fait de faire plusieurs gros fichiers distincts sur une même partoche va accroitre la fragmentation...


 
apres tout dépends de la config des moteurs sql.
 
la, on ne sait pas si les log et les data sont dans le ^m fichier ou separé.


---------------
| Un malentendu du cul | boum boum ! | La roulette
Reply

Marsh Posté le 03-09-2004 à 12:30:16    

Log et données ds des fichiers séparés :jap:

Reply

Marsh Posté le 03-09-2004 à 12:38:22    

WhyMe a écrit :

Log et données ds des fichiers séparés :jap:


 
alors oui, pourquoi pas.
 
perso, j'ai eu l'occaz de bosser pas mal de temps sur des trucs similaire, les fichiers data et log séparé, mais on évitait justement d'étendre les base sur des fichiers differents.
 
le plus simple pour toi est de tester la chose sur un srv de préprod par exemple.
 


---------------
| Un malentendu du cul | boum boum ! | La roulette
Reply

Marsh Posté le 03-09-2004 à 13:52:14    

Ce qui me gêne ds le fait d'avoir un seul gros fichier pour une base, c'est que c'est vachement dur pour faire la maintenance dessus !
La moindre opération de compression de fichier ou de réindexation bloque + ou - toute la base.
Le fait de travailler sur des fichiers séparés me laisse penser que ces opérations seraient - bloquantes, non ?

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed