Discussion :

[Baquardie]

Bonjour,

Juste une petite question-discussion. J'ai des bases de données qui sont très grosse et dans l'optique d'aider la performance j'aimerais les scinder en plusieurs fichiers.

Quelle est la taille recommandée?

Par exemple, j'ai une BD de 25 gig et une autre de 200 gig. Est-ce que faire des fichiers de 10 gig est un best practice ?

Merci !

[SQLpro]

Non !!!!!!

Le découpage en fichier doit être opéré par rapport à la capacité de vos disques physiques.

Il faut donc créer des disques physiques et non des disques logiques, même dans des SAN !

Multiplier inconsidérément le nombre de fichiers grève les performances. En revanche si cela permet de paralléliser les IO alors c'est bon !

Lisez ce que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p8...t-le-stocakge/

A +

[Baquardie]

Merci vos articles sont très intéressant.

Nous sommes en effet sur des SAN et c'est le service technique qui me demande de fractionner mes fichiers de base de données pour leur permettre d'améliorer la performance lors des défragmentation... Je savais que ça pouvait aider à performance à un certain niveau de fragmenter les fichiers de base de données mais de ce que je lis... vu que nous sommes sur un SAN... je ne suis plus du tout certaine que ça vaille la peine malheureusement !

J'ai trouvé cet article qui est très intéressant...

http://www.symantec.com/connect/arti...tiris-products

Je pense que je vais avoir une petite conversation avec le service technique parce que la dernière fois que je leur ai parlé, on m'a dit qu'on avait beau me donner plein de lecteurs différents pour les LOG, TempDB et les fichiers de base de données, au niveau du SAN c'était à la même place physiquement ! ....

[Baquardie]

Joie ! Je viens d'apprendre que nous avons des disques RAID 5 !

[SQLpro]

En règle générales les gens du systèmes sont naturellement incompétent en terme de DBA et font systématiquement tout ce qui ne faut pas faire avec les SGBDR ce qui a pour conséquence de tirer les performances vers le bas !

DBA c'est un vrai métier et mieux payé que celui d'ingénieur système vu la responsabilité !

Lisez ce que j'ai écrit sur Wikipédia à ce sujet : http://fr.wikipedia.org/wiki/Adminis...e_donn%C3%A9es

A +

[Invité]

DBA c'est un vrai métier et mieux payé que celui d'ingénieur système vu la responsabilité !

Je trouve ça un peu fort, tout de même, limite méprisant.
Si le réseau marche pas, tu as beau avoir un serveur de bd très performant, il ne servira pas à grand chose.

[Baquardie]

Bon je viens de parler avec le service technique.

Pour notre serveur de production, le disque pour les LOG est un RAID 10 (8 disques) tandis que le disque pour le data est un RAID 5 (9 disques). Semblerait-il que c'est une question de cout $$.

[mikedavem]

Bonjour,

Pourquoi ne pas faire une grappe RAID 10 pour vos données également ? (Vu que vous avez 9 disques)

++

[kagemaru]

Quelle est la taille des disques physiques utilisée dans chaque unité logique ?

[Ptit_Dje]

En parlant de file systeme et de best practices, j'en profite pour rebondir sur la securite de vos disques...
Laissez l'access full aux administrateurs du server, au systeme et au service account de SQL Server en ce qui concerne vos disques de donnees et de log.
Les autres n'ont pas besoin d'avoir acces a ces fichiers a priori.
Pensez aussi a desactiver l'indexation des disques.

[SQLpro]

Je trouve ça un peu fort, tout de même, limite méprisant.
Si le réseau marche pas, tu as beau avoir un serveur de bd très performant, il ne servira pas à grand chose.

Oui, mais si les données sont perdues l'entreprise meure ! Alors entre nous une panne réseau, c'est vraiment pas bien grave !

L'expérience de Mike Hotek qui avait 12 client dans le World Trade Center avec des bases SQL Server 2000, et ce avant le crash est édifiante : http://www.sqlmag.com/article/data-a...possible-.aspx

A +

[kagemaru]

Alors entre nous une panne réseau, c'est vraiment pas bien grave !

Si l'entreprise est un site de commerce en ligne, il faut espérer qu'elle a un site de secours hautement dispo. Une petite heure de cessation d'activité peut avoir de mauvaises conséquences également.

DBA c'est un vrai métier et mieux payé que celui d'ingénieur système vu la responsabilité !

Justement, le problème est que la plupart du temps, les responsabilités ne sont pas clairement définies : qui est responsable pour la sécurité des donnèes ?

Tel que je le vois souvent, les DBA se contentent de programmer des sauvegardes. Ces sauvegardes sont mis sur cassette ou externalisés sur un stockage externe (distant ou pas). Je vois une grande majorité de DBA se contenter du fait que les backups ont bien été fait dans le système de fichier. Ensuite, le fait qu'ils soient correctement externalisés, mis en lieu sûr relève souvent de l'admin système.

Faut-il que le DBA s'assure que "ses" données sont en lieu sûr ou bien l'admin système qui est très souvent chargés de l'externalisation des sauvegardes ?

Pour revenir à l'attribution du stockage pour les bases, cela dépend très souvent de l'entreprise et du lien entre sa survie et ses donnèes. Si une boîte est dépendante de ses infos et à besoin de haute dispo, parce que sa survie est en jeu, le DBA est généralement mieux écouté que dans d'autres boîtes ou les donnès des bases ne sont que des données parmi tant d'autres.

Désolé pour ce troll du vendredi ;-) faudrait déplacer ça dans un autre fil.

[mikedavem]

Si l'entreprise est un site de commerce en ligne, il faut espérer qu'elle a un site de secours hautement dispo. Une petite heure de cessation d'activité peut avoir de mauvaises conséquences également.

Je te rejoins sur ce point, une heure de cessation d'activité peut également avoir des conséquences dramatiques sur le business d'une entreprise. Dans une gestion des risques, il est vrai qu'on dédouble souvent les organes à risques. Je pense que dans ce cas l'on pourrait simplement avoir une ligne de secours. Bien entendu, la perte des données stratégiques et vitales au SI, comme le souligne SQLPro, serait encore plus catastrophique. La plupart des entreprises n'y survivent pas à l'heure actuelle.

++

[Ptit_Dje]

Pour obtenir une solution HA, il faut effectivement tout doubler que se soit de ligne internet, de switch, de routeur ou de serveur db... Ou autre composants.
En gros, 0 single point of failure des disques durs au front end utilisateur.

[Invité]

Tel que je le vois souvent, les DBA se contentent de programmer des sauvegardes. Ces sauvegardes sont mis sur cassette ou externalisés sur un stockage externe (distant ou pas). Je vois une grande majorité de DBA se contenter du fait que les backups ont bien été fait dans le système de fichier. Ensuite, le fait qu'ils soient correctement externalisés, mis en lieu sûr relève souvent de l'admin système.

Je te rejoins complètement là-dessus, c'est pour ça que j'ai réagis.
Personnellement, je prône plus une approche constructive et complémentaire avec les ingénieurs systèmes que celle méprisante.
On travaille en commun pour une société et il est courant que l'on est besoin de l'un et de l'autre pour résoudre des problèmes.
Après on peut se considérer bien supérieur sur bien des points, il reste qu'une bonne secrétaire n'est peut-être pas bardée de haut diplômes et de certifications, c'est tout de même névralgique pour le bon fonctionnement d'une société.
Voilà pour le troll du vendredi.

[SQLpro]

Pour compléter ce troll de vendredi.... Je n'ai jamais été méprisant pour qui que ce soit et pour quelque fonction que ce soit, mais il faut placer les choses à leur juste valeur. C'est bien là le problème. Et la synergies DBA / admin système est importante, mais doit toujours être considéré sous l'angle prioritaire du service des données..., et c'est donc bien le DBA qui doit piloter l'admin système.
Or dans les entreprises on trouve souvent l'inverse !

A +