[ASE]update stats

plochert · 08/03/2006, 12h07

Hello
Des différents possibilité pour mettre à jour les statistiques, est-ce qu'il y a un intérêt à ne pas utiliser systématiquement la plus complète : update all statistics ?

fadace · 08/03/2006, 13h52

Oui, des raisons de perf. Le update all statistiques va faire un histogramme pour toutes les colonnes, ce qui est fort coûteux en terme de ressouces.

plochert · 08/03/2006, 14h03

Oui je suis d'accord mais si on a les ressources est-ce que l'update all ne garantit pas de meilleurs choix de la part de l'optimiseur ?

fadace · 08/03/2006, 15h24

Oui, il garantit les statistics les plus fournies.

plochert · 16/03/2006, 13h22

ok mais
dans le cas où j'ai une appli qui utilise beaucoup de requêtes dynamiques (pas de proc), le update all va avoir tendance à générer plus de combinaisons de plans et donc ralentir l'exécution globale des requêtes.

mpeppler · 16/03/2006, 13h59

C'est en effet possible. Comme souvent dans notre métier il est difficile de donner une réponse catégorique - il y a trop souvent des élements spécifiques au site qui détermine la meilleurs solution.

Personellement je standardise sur "update index statistics", et (en 12.5.x en tout cas), je positionne les paramètres 'histogram tuning factor' à 10, et 'number of histogram steps' à 50. Ces paramètres permettent à Sybase de génèrer un nombre variables de "step" pour les histogrammes (entre 50 et 500 steps, en fonction de la structure des données.)

Michael

fadace · 17/03/2006, 17h41

Personnellement, je suis ~ mpeppler.

Jamais de update all car excessif...

plochert · 20/03/2006, 13h24

OK pour ne pas mettre un update all par défaut.
Dans un cas, l'optimiseur n'arrive pas à choisir le bon plan, dbcc tracecon(3604,302,310) pour s'en assurer.
Plutôt que de faire un update all (sur 1 table de 15millions de ligne), je vais voir en utilisant les plans abstraits pour résoudre ce problème.

Et puis l'update all, en générant plus de statistiques, va offrir à l'optimiseur beaucoup plus de choix pour sélectionner le meilleur plan d'exécution. Comme l'application utilise beaucoup de requêtes dynamiques, au final, cela ne m'apporterait plus d'inconvénient que d'avantage.

mpeppler · 20/03/2006, 14h23

Il faut aussi s'assurer que les stats sont bien à jour, et peut-être changer le nombre de step pour l'histogramme.

08/03/2006, 12h07	#1
plochert Invité de passage Inscription : décembre 2004 Messages : 21 Détails du profil Informations personnelles : Localisation : France, Paris (Île de France) Informations forums : Inscription : décembre 2004 Messages : 21 Points : 1 Points : 1	[ASE]update stats Hello Des différents possibilité pour mettre à jour les statistiques, est-ce qu'il y a un intérêt à ne pas utiliser systématiquement la plus complète : update all statistics ?
	00

08/03/2006, 13h52	#2
fadace Rédacteur/Modérateur Fabien Celaia Administrateur de base de données Inscription : octobre 2002 Messages : 3 779 Détails du profil Informations personnelles : Nom : Fabien Celaia Âge : 41 Localisation : Suisse Informations professionnelles : Activité : Administrateur de base de données Secteur : Service public Informations forums : Inscription : octobre 2002 Messages : 3 779 Points : 8 124 Points : 8 124	Oui, des raisons de perf. Le update all statistiques va faire un histogramme pour toutes les colonnes, ce qui est fort coûteux en terme de ressouces. __________________ Sr DBA Oracle / Sybase / MS-SQL / DB2 / Informix / Postgresql Administrateur SAP Mes articles Attention : pas de réponse technique par MP : pensez aux autres, passez par les forums !
	00

08/03/2006, 15h24	#4
fadace Rédacteur/Modérateur Fabien Celaia Administrateur de base de données Inscription : octobre 2002 Messages : 3 779 Détails du profil Informations personnelles : Nom : Fabien Celaia Âge : 41 Localisation : Suisse Informations professionnelles : Activité : Administrateur de base de données Secteur : Service public Informations forums : Inscription : octobre 2002 Messages : 3 779 Points : 8 124 Points : 8 124	Oui, il garantit les statistics les plus fournies. __________________ Sr DBA Oracle / Sybase / MS-SQL / DB2 / Informix / Postgresql Administrateur SAP Mes articles Attention : pas de réponse technique par MP : pensez aux autres, passez par les forums !
	00

16/03/2006, 13h22	#5
plochert Invité de passage Inscription : décembre 2004 Messages : 21 Détails du profil Informations personnelles : Localisation : France, Paris (Île de France) Informations forums : Inscription : décembre 2004 Messages : 21 Points : 1 Points : 1	Profondeur de stats ok mais dans le cas où j'ai une appli qui utilise beaucoup de requêtes dynamiques (pas de proc), le update all va avoir tendance à générer plus de combinaisons de plans et donc ralentir l'exécution globale des requêtes.
	00

17/03/2006, 17h41	#7
fadace Rédacteur/Modérateur Fabien Celaia Administrateur de base de données Inscription : octobre 2002 Messages : 3 779 Détails du profil Informations personnelles : Nom : Fabien Celaia Âge : 41 Localisation : Suisse Informations professionnelles : Activité : Administrateur de base de données Secteur : Service public Informations forums : Inscription : octobre 2002 Messages : 3 779 Points : 8 124 Points : 8 124	Personnellement, je suis ~ mpeppler. Jamais de update all car excessif... __________________ Sr DBA Oracle / Sybase / MS-SQL / DB2 / Informix / Postgresql Administrateur SAP Mes articles Attention : pas de réponse technique par MP : pensez aux autres, passez par les forums !
	00

08/03/2006, 14h03	#3
plochert Invité de passage Inscription : décembre 2004 Messages : 21 Détails du profil Informations personnelles : Localisation : France, Paris (Île de France) Informations forums : Inscription : décembre 2004 Messages : 21 Points : 1 Points : 1	Oui je suis d'accord mais si on a les ressources est-ce que l'update all ne garantit pas de meilleurs choix de la part de l'optimiseur ?
	00

16/03/2006, 13h59	#6
mpeppler Rédacteur/Modérateur Inscription : janvier 2006 Messages : 1 300 Détails du profil Informations personnelles : Âge : 52 Informations forums : Inscription : janvier 2006 Messages : 1 300 Points : 1 504 Points : 1 504	C'est en effet possible. Comme souvent dans notre métier il est difficile de donner une réponse catégorique - il y a trop souvent des élements spécifiques au site qui détermine la meilleurs solution. Personellement je standardise sur "update index statistics", et (en 12.5.x en tout cas), je positionne les paramètres 'histogram tuning factor' à 10, et 'number of histogram steps' à 50. Ces paramètres permettent à Sybase de génèrer un nombre variables de "step" pour les histogrammes (entre 50 et 500 steps, en fonction de la structure des données.) Michael
	00

20/03/2006, 13h24	#8
plochert Invité de passage Inscription : décembre 2004 Messages : 21 Détails du profil Informations personnelles : Localisation : France, Paris (Île de France) Informations forums : Inscription : décembre 2004 Messages : 21 Points : 1 Points : 1	OK pour ne pas mettre un update all par défaut. Dans un cas, l'optimiseur n'arrive pas à choisir le bon plan, dbcc tracecon(3604,302,310) pour s'en assurer. Plutôt que de faire un update all (sur 1 table de 15millions de ligne), je vais voir en utilisant les plans abstraits pour résoudre ce problème. Et puis l'update all, en générant plus de statistiques, va offrir à l'optimiseur beaucoup plus de choix pour sélectionner le meilleur plan d'exécution. Comme l'application utilise beaucoup de requêtes dynamiques, au final, cela ne m'apporterait plus d'inconvénient que d'avantage.
	00

20/03/2006, 14h23	#9
mpeppler Rédacteur/Modérateur Inscription : janvier 2006 Messages : 1 300 Détails du profil Informations personnelles : Âge : 52 Informations forums : Inscription : janvier 2006 Messages : 1 300 Points : 1 504 Points : 1 504	Il faut aussi s'assurer que les stats sont bien à jour, et peut-être changer le nombre de step pour l'histogramme.
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email