Discussion :

[fucce]

Bonjour,

J'ai une petite question : nous avons un disque en RAID1 qui est destiné aux logs. Quand je regarde la date de modification de nos 2 fichiers de logs (1 de 10go et 1 de 6go), ils ne bougent pas depuis le redémarrage. C'est normal docteur??? Cela pourrait expliquer éventuellement nos locks lors de transactions (voir discussion http://www.developpez.net/forums/d63...-mssql-2000-a/) En effet, les accès disques sur les logs (via perfmon) sont très bons alors que ceux sur le disque de données sont très mauvais. On est un peu paumés, merci d'avance pour votre aide!

[elsuket]

Bonjour,

Il va falloir que vous nous donniez un peu plus de détails !

C'est normal docteur???

Je ne sais pas exactement ce qui peut expliquer cela ... cette date est probablement mise à jour lorsque le journal de transactions doit grossir.

En effet, les accès disques sur les logs (via perfmon) sont très bons alors que ceux sur le disque de données sont très mauvais

C'est-à-dire ?

A+

[fucce]

Merci de votre attention,
Je surveille les courbes de Disque Physique\Long moy de file d'attente du disque et le Disque Physique\% Temps du disque via le gestionnaire de performances. La courbe concernant le disque de data est toujours au taquet alors que les indicateurs du disque des logs est toujours au plus bas. Utilisant pas mal de transactions, on s'étonne de ne pas voir d'activités sur le disque des logs c'est pourquoi je vous pose la question sur la taille des fichiers ldf.

[ylarvor]

votre base est bien en mode complet?

[fucce]

Bonjour ylarvor!!
Oui, je sais je multiplie les posts mais je n'ai jamais autant pratiqué de BD de ma vie. Pourrais-tu m'expliquer ce que tu entends par mode complet stp?
Une autre petite remarque pour savoir si l'un d'entre vous a déjà été confronté à ça :
quand on démarre SQL Server Entreprise Manager et que l'on se positionne sur notre base, on a un vilain message d'erreur :
Pièce jointe 37458
et quand on valide ce message... ben on a rien :
Pièce jointe 37459

[fucce]

Pour ceux que ça intéresse : j'ai résolu mon dernier problème (l'erreur de script). Il faut modifier l'affichage de la base en Grandes icônes par exemple et revenir sur liste des tâches. Le tabs.html est regénéré et l'affichage ok!

[ylarvor]

votre message est un problème javascript, ca a l'air de fonctionner quand meme, je suis desole que votre manager ne fonctionne pas à la perfection...

Pour le mode de journalisation complet. Pour en savoir plus :
http://blog.developpez.com/ylarvor?t..._de_rcupration

votre fichier de log devrait necessiter une sauvegarde regulière et il devrait croite journalièrement, si ce n'est pas le cas, c'est que vous n'etes pas en mode complet mais en mode simple ce qui fait que vous n'utilisez pas le journal de transaction.

[fucce]

Après avoir récupérer un affichage correct, je constate bien que mon fichier de log augmente régulièrement. C'est donc ok de ce côté mais je n'arrive pas à mettre la main sur la cause du goulet d'étranglement de l'accès aux disques de données.
Une occupation comme celle jointe est choquante?
Pièce jointe 37464

[xpander]

...

[fucce]

???

[SQLpro]

Oui, elle est choquante. Elle montre parfaitement que vous n'avez pas dimensionné vos fichiers de base de données correctement. Cela provoque de multiples problèmes de performances, notamment :

• opération de croissances des fichiers arrivant de manière incongrue
• fragmentation physique irrémédiable des fichiers

Lisez l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro?ti..._fichiers_et_t

Je remarque aussi que vous avez plusieurs fichiers de données. Sont-il sur des DISQUES PHYSIQUES différents ? Si ce n'est pas le cas, c'est stupide. Le seul intérêt de découper une BD en de multiples fichiers est de paralléliser les opérations de lecture et d'écriture. Si vous fichiers dont sur le même disque non seulement cela ne sert à rien, mais comme vous gére une croissance automatique, cela les fragmentent encore plus.

A +

[fucce]

Bonjour,
Je pensais que le découpage en 4 fichiers de données était lié au 4 processeurs... Quant à la répartition sur les disques, oui les fichiers de données sont sur un même disque physique en RAID1+0. Les logs sont sur un autre disque, le système sur un autre et les sauvegardes des logs et des datas sur un dernier! J'ai lu qu'il fallait séparer les logs des datas et du système...

[fucce]

Je suis aussi tombé sur un post très intéressant concernant la contention de tempdb. Ce qui nous mis sur la piste : ce sont les nombreux PAGELATCH_UP dans les informations sur les processus. Là aussi, on nous conseille de mettre les fichiers sur un disque à part et multiplier les fichiers. Pour l'instant, ceux-ci sont sur le même disque que les datas et il n'existe qu'un seul fichier (je vais encore me faire engueuler) fichier à croissance auto de 10% et de taille 1,5Go. Pour ma défense, je tiens à dire que c'est un prestataire extérieur qui a installé notre base... ouf!

[elsuket]

Bonjour,

Dans ce cas, conseillez à votre employeur de changer de prestataire: au mieux il vous a entubé, au pire il s'est assuré de revenir !

Le mieux serait de prendre un serveur vierge, de monter votre BD dessus, de ne faire plus qu'un seul fichier de données si vous ne pouvez pas disposer de disques supplémentaires, et de le dimensionner de telle sorte que celui-ci n'ait plus besoin de croître, de même pour le journal de transactions.

@++

[SQLpro]

Je suis aussi tombé sur un post très intéressant concernant la contention de tempdb.

Il existe deux points de contention dans SQL Server. Dans l'ordre :
1) le journal de transaction
2) la base tempdb.
Si c'est bien votre base tempdb qui est engorgée, il y a fort à parier que c'est plus lié au style de développement, et notamment l'utilisatin massive de tables temporaires explicite, de triggers, de clauses OUTPUT (2005) et de niveau d'isoaltion SNAPSHOT...

Ce qui nous mis sur la piste : ce sont les nombreux PAGELATCH_UP dans les informations sur les processus.

Le page LATCH est un verrou non sur les données, mais sur les pages de navigation des index. Un grand nombre de latch n'est pas toujours synonyme de mauvais fonctionnement et la répartition sur plusieurs disque peut ne rien y changer....

Là aussi, on nous conseille de mettre les fichiers sur un disque à part et multiplier les fichiers.

Ce ne sera certes pas une mauvaise chose, mais à condition que chaque fichier soit sur un disque physique différent, sinon ce sera pire !

Pour l'instant, ceux-ci sont sur le même disque que les datas et il n'existe qu'un seul fichier

Séparer : tempdb / JT / Data production / index production
temdb et JT supportent du RAID 1
data et index production supportent du RAID 5, 0+1 ou 10

A +

[fucce]

OK merci je prends en compte de vos conseille et nous allons réfléchir à un autre agencement de notre serveur!
Pour elsuket : c'est clair que notre prestataire nous a entubé! On les a rappelé (c'est ceux qui nous ont livré notre dernier module) et ils nous fait comprendre que SQL Server n'était pas leur spécialité!

[fucce]

Là aussi, on nous conseille de mettre les fichiers sur un disque à part et multiplier les fichiers.

Ce ne sera certes pas une mauvaise chose, mais à condition que chaque fichier soit sur un disque physique différent, sinon ce sera pire !

J'ai lu ce lien http://searchsqlserver.techtarget.co...276989,00.html .
Dans le point 1 : 1 fichier par processeur
Dans le point 4 : 1 fichier tempdb par disque si possible