Discussion :

[plutonium719]

Bonjour,

Toujours à la recherche de petites options qui puissent m'aider pour optimiser des longs et lourds traitements, je viens de voir les propriétés d'une base de données : http://technet.microsoft.com/en-us/l.../ms188124.aspx

Quelqu'un peut-il me dire [SQLPro par exemple] quelles sont les options à mettre à true ou false pour que ça soit plus performant ?
J'ai déjà le "Auto Shrink" à true.
j'aimerais savoir pour le "Auto Create Statistics", "Auto Update Statistics", "Auto Update Statistics Asynchronously"

Est-ce que ça prend des ressources CPU ? Est-ce que ça optimise vraiment ?

Ah oui et dans les procédures stockés, j'utilise des curseurs.
Donc A quoi peuvent me servir les options :
"Close Cursor on Commit Enabled" et "Default Cursor"
j'ai laissé les options par défaut

Merci

[elsuket]

Bonsoir,

Pour les options "Auto Create Statistics" et "Auto Update Statistics", je vous conseille vivement de les laisser telles qu'elles, elle permettent de maintenir des statistiques sur les données que contiennent vos colonnes, et permettent donc à l'optimiseur de requêtes de SQL Server de fonctionner au mieux.
Mettre "Auto Update Statistics Asynchronously", c'est faire exactement l'inverse.

Est-ce que ça prend des ressources CPU ?

Non

Est-ce que ça optimise vraiment ?

Oui

Ah oui et dans les procédures stockés, j'utilise des curseurs.

Là est votre problème : l'utilisation de curseurs est à proscrire, ils sont 10 à 10 000 fois plus lent que le même traitement écrit avec une requête ensembliste, ce pour quoi est parfaitement conçu SQL Server, et ce que ne font pas les curseurs

Avant de toucher à ces options, commencez par changer tous vos traitements faits en curseurs par des traitements ensemblistes, vous y gagnerez considérablement en performance (n'oubliez pas de créer les bons indexes )

[SQLpro]

Toujours à la recherche de petites options qui puissent m'aider pour optimiser des longs et lourds traitements,

Ne révez pas, l'optimisation d'une base de données est quelque chose de complexe et qui s'apprend... Le petites mesurettes que vous prenez seront une goutte d'eau comparer à ce qu'il faut faire en général.

etant l'auteur du cours d'optimisation SQL Server chez orsys, permettez moi de vous inviter à le suivre... Sachez d'ailleurs qu'il va passer à 4 jours en juillet :
http://www.orsys.fr/pdfCours/SQO.pdf

J'ai déjà le "Auto Shrink" à true.

Vous cherchez des performances lamentable !!! Vous en aurez en laissant cette commande à ON !!!

Avez vous pensez à dimensionner vos fichier correctement ?
En principe lorsque l'on créé une base de données on estime la taille de la base à terme (pour 3 à 5 années d'exploitation). Ainsi, si la base va faire 30 Go en 3 ans, il faut dimensionner les fichiers de données à 30 Go et le fichier du JT à 10 Go

pensez aussi à séparer sur des agrégat RAID phyisquement différents, vos fichiers de données et vos fichiers du JT. Le JT se place en général sur l'agrégat RAID le plus rapide en écriture.
De la même manière, placez les index sur un groupe de fichiers annexe de celui contenant les données et placez le sur un 3e agrégat raid.
Enfin si la tempdb est fortement sollicitée, alors la placer sur un 4eme agrégat RAID.

Bien entendu tout cela doit avoir été pensé et dimensionné préalablement !

j'aimerais savoir pour le "Auto Create Statistics", "Auto Update Statistics", "Auto Update Statistics Asynchronously"

Cela est intéressant, mais tout depend de votre stratégie de gestion des index.

***

conseils compémentaires :

Oui les curseur sont la pire des choses. Depuis la version 2005 et l'introduction des CTE tous les curseurs peuvent être remplacés par des resuêtes. Commencez donc par appendre à faire des requêtes, mêmes très complexes (mon site web et les exercices associés peuvent vous y aider).

Lisez les articles que j'ai écrit sur l'optimisations de SQL Server :
http://sqlpro.developpez.com/optimisation/

Avez vous modéliser votre base en respectant au moins les 3 premières formes normales ?
C'est là aussi une grande perte de performance

Avez vous indexée suffisamment votre base ?

etc...

A +

[plutonium719]

Merci elsuket pour les infos.

SQLPro (Monsieur Frédéric Brouard ) > En fait, j'ai pas trop le choix, je suis dans un contexte particulier de projet et pour la DB, à part développer des Procédures stockées pour préparer une base je n'ai accès à rien. C'est le client qui a mis la machine en place, lui-même en passant par des sous-traitants informatique ... Mon champ d'action est donc limité.

Je peux juste agir sur ces quelques paramètres qui des fois font la différence.
Et je peux vous le prouver, avec des Index, et des paramètres sur les propriétés de la base, on peut gagner quelques heures en traitement :]

Voilà voilà

Merci pour vos réponses.