Discussion :

[Saintelaitlait]

Bonjour,

J'aimerais savoir si une des règle empirique d'oracle s'applique aussi à SQL Server.

Dans le cas d'oracle, lorsqu'on va chercher plus de 20% des données d'une table, il est conseillé de forcer le sgbd à faire un full table scan au lieu d'un index seek. On peut y arriver en ajoutant un +0 au select sur la clef primaire numérique. Dans certains cas, le sgbd gère cela par lui même et ne s'occupe pas

Est-il possible, et nécéssaire de faire cela en SQL-Server? Sachant que je ramène l'intégralité de ma table qui contient +/- 1 million de records.

Merci

[elsuket]

Bonjour,

Dans le cas d'oracle, lorsqu'on va chercher plus de 20% des données d'une table, il est conseillé de forcer le sgbd à faire un full table scan au lieu d'un index seek.

Est-ce vraiment le cas pour toutes les requêtes ? j'en doute, mais je suis profane sur Oracle ...

je ramène l'intégralité de ma table qui contient +/- 1 million de records.

Dans ce cas SQL Server fera un clustered index scan, c'est à dire qu'il lira toute la table.
Dans 99.99999% des cas, SQL Server fonctionne correctement sous réserve que la maintenance des statistiques soit faite proprement.

En effet j'ai l'impression que lorsqu'une tables est volumineuse et qu'elle subit un grand nombre de changements, alors il est nécessaire de forcer la mise à jour des statistiques.

Pour vous donner une idée, lorsque je suis arrivé chez mon employeur actuel, il n'y avait aucune maintenance des statistiques, et le CPU était constamment au dessus de 80%, sur une nombre de serveurs que l'on peut compter sur deux mains.
Depuis le lendemain du forçage du recalcul, l'utilisation du CPU dépasse rarement les 35% sur les serveurs les plus occupés.

Le fait est que je suis loin d'être le premier à l'avoir fait, et que je ce n'est pas le premier employeur chez qui je dois le faire.
Il suffit de regarder les résultats retournés par votre moteur de recherche préféré pour s'en rendre compte

@++

[mikedavem]

En effet j'ai l'impression que lorsqu'une tables est volumineuse et qu'elle subit un grand nombre de changements, alors il est nécessaire de forcer la mise à jour des statistiques.

Normal du fait de l'algorithme de mise à jour auto des statistiques (500 lignes + 20% des données). Tant que ce nombre de changements est inférieure à ce seuil ales statistiques peuvent être obsolètes. De la même manière en mise à jour automatique il se peut également que le taux d'échantillonnage ne soit plus correct. Dans ce cas il faudra désactiver la mise à jour auto et faire des mises à jour en manuel en principe un sample correct.

++

[Rei Ichido]

Bonjour,


Est-ce vraiment le cas pour toutes les requêtes ? j'en doute, mais je suis profane sur Oracle ...

Non, évidemment, en particulier dans le cas où l'index permet d'éviter d'accéder à la table.
De toute façon, c'est le genre de "magouille" qu'il vaut mieux éviter à mon avis. Quitte à vouloir forcer un comportement de l'optimiseur, il vaut mieux utiliser un hint !

[elsuket]

Normal du fait de l'algorithme de mise à jour auto des statistiques (500 lignes + 20% des données). Tant que ce nombre de changements est inférieure à ce seuil ales statistiques peuvent être obsolètes.

Tu sais tout comme moi que ce seuil est parfois largement dépassé.
Je pense que lorsque cela devient trop coûteux, puisque la mise à jour des statistiques est coûteuse en IO et en CPU, SQL Server ne la fait pas, probablement temporairement ...

De toute façon, c'est le genre de "magouille" qu'il vaut mieux éviter à mon avis. Quitte à vouloir forcer un comportement de l'optimiseur, il vaut mieux utiliser un hint !

Je suis d'accord avec vous sur la première phrase.
Pour choisir de forcer le comportement de l'optimiseur, il faut être sûr et certain qu'il n'y a pas d'autre alternative (j'ai toujours un peu de mal à admettre que je dois mettre un indicateur).
Si les statistiques sont à jour, c'est souvent dû à l'expression de la requête ... ou tout simplement au fait qu'un index qui couvre assez bien celle-ci n'est pas là

@++

[mikedavem]

Tu sais tout comme moi que ce seuil est parfois largement dépassé.
Je pense que lorsque cela devient trop coûteux, puisque la mise à jour des statistiques est coûteuse en IO et en CPU, SQL Server ne la fait pas, probablement temporairement ...
@++

Il faut savoir que SQL Server ne met pas à jour de suite les statistiques lorsque ce seuil est atteint. Les statistiques sont simplement invalidées. Elles ne seront mis à jour que lorsque quelqu'un en aurait vraiment besoin. De plus il faute faire le distingo entre l'algorithme de mise à jour de 2000 et les autres versions.

Pour 2000 le seuil de changement correspond à 20% des lignes modifiées alors que pour 2005 et 2008 c'est 20% des données de la colonne. Cela signifie que si tu as une colonne relativement volatile alors l'invalidation de l'ensemble des statistiques de la table seront rapidement invalidés alors que dans le 2ème cas il faut que ce soit 20% des données de la colonne donc beaucoup mois rapide.

++