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:07:34
duplique une des bases pour faire un test ![[:spamafote]](https://forum-images.hardware.fr/images/perso/spamafote.gif "[:spamafote]")
je ne sais pas comment les fichiers de données sont gérés
![[:valentinorossi]](https://forum-images.hardware.fr/images/perso/valentinorossi.gif "[:valentinorossi]")
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.
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 
).
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...
---------------
Topic .Net - C# @ Prog
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. |
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
Marsh Posté le 03-09-2004 à 12:38:22
| WhyMe a écrit : Log et données ds des fichiers séparés |
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
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 ?
Sujets relatifs:
- Disque dur Lacie externe
- Problème de detection de disque 120 Go sur 6154VA
- problème avec un disque externe
- virus ou crash: récupération des données
- disque dur non reconu
- partitionage et disque dur maxtor 40 go
- [NCQ Technology] Faut-il attendre pour changer de disque ?
- kel carte graphique sans ventilo de base à 100?
- Disque Dur HS...??
- disque dur 160 GIG maxtor
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
Petite précision : les disques sont des SCSI 15000 rpm en raid 5 et formatés en NTFS