6 novembre 2008
4
06
/11
/novembre
/2008
20:42
Bonsoir,
J'ai classé cet article dans la partie performance, mais il pourrait également s'agir d'administration. Comme vous le savez tous ORACLE utilise toute une série de statistiques pour déterminer le meilleur (en tout cas pou lui) plan d'execution d'une requête donnée.
C'est magnifique ! Cela signifie qu'en fonction de la volumétrie, de la répartition des données et de divers autres paramètres, ORACLE va pouvoir utiliser un plan d'execution différent.
C'est beau et c'est chiant en même temps. Je m'explique. Je me positionne dans le cas d'un éditeur de logiciel qui fait bien son travail (ca existe).
L'editeur en question à des bases de tests avec une forte volumétrie, et valide son application.
Un client a forte volumétrie également contrairement à l'éditeur à des temps de réponse mauvais.
Je vous épargne les aller-retours très constuctifs du genre "Chez nous ca marche", ou "nos données sont secrètes, hors question de vous les faire parvenir",....
Nous sommes face à un problème (récurent) !
Dans le cas d'applications ou des centaines de requêtes (voir des milliers) sont executées comment s'assurer que les plans d'executions soient identiques chez le client et l'éditeur.
Tout est dans le titre : LES STATS !
Si j'arrive à avoir les mêmes stats que le client, il me suffit de rejouer son scénario et si le problème vient réellement d'un plan d'execution différent, alors je vais pouvoir identifier la ou les requêtes en question.
Etape 1: Demander au client de sauvegarder ses statistiques
Pour cela nous allons créer une table pour heberger ces statistiques.
exec DBMS_STATS.CREATE_STAT_TABLE (ownname=>'USER_CLIENT', stattab=>'NOM_TABLE_STATS');
Ici, USER_CLIENT est le schéma applicatif à soucis, et NOM_TABLE_STATS la table ou l'on va sauvegarder les statistiques.
On peut également passer le paramètre tblspace pour indiquer uin tablespace particulier pour la table.
Etape 2: Exporter les statistiques vers cette table
exec DBMS_STATS.EXPORT_SCHEMA('USER_CLIENT','NOM_TABLE_STATS');
Il suffit au client de faire un export de la table NOM_TABLE_STATS et de l'envoyer à son editeur préféré.
Et donc que nous reste-il à faire....
Etape 3 : importer la table NOM_tABLE_STATS
(je ferai un de ces soir un article sur les import /export)
Etape 4 : Remplacer les stats de ma base de tests par les stats du client.
On va faire ca en deux fois.
exec DBMS_STATS.DELETE_SCHEMA_STATS('USER_EDITEUR',FORCE=>TRUE);
Si on veut être prudent, on peut créer au préalable une table de sauvegarde pour les stats et conserver les stats au moment de la suppression.
exec DBMS_STATS.CREATE_STAT_TABLE('USER_EDITEUR','Stats_backup');
exec DBMS_STATS.EXPORT_SCHEMA('USER_EDITEUR','Stats_backup');
exec DBMS_STATS.DELETE_SCHEMA_STATS('USER_EDITEUR',FORCE=>TRUE);
Import des stats
exec DBMS_STATS.IMPORT_SCHEMA_STATS('USER_EDITEUR','NOM_TABLE_STATS');
Et voila nous avons maintenant les même statistiques que notre client adoré, et donc une plus grande probabilité de trouver l'origine du souci, si celui ci est lié à des plans d'executions différents.
L'interêt de ce genre de manipulations peut également être d'utiliser les statistiques d'une base de production (très forte volumétrie) sur un environnement de developpement à faible volumétrie, et de lister les plans d'executions afin de s'assurer par exemple que nos nouveaux developpements ne vont pas engendrer de "Full scan" sur des grosses tables.
Au final en approchant les stats par cette face, on se rend compte que si la collecte de statistiques est importante en soi, sa mise en place, son administration et les choix qui seront fait concernant les statistiques pouront avoir un impact positif ou négatif (si c'est mal fait, voir pas fait).
REMARQUE (1): Un de mes fidèles lecteurs, m'a fait part du problème la couleur de fond pour les impressions. Alors avant que je commence à changer, est ce quelqu'un d'autre à quelque chose à redire sur la lisibilité (taille de police trop petite, couleur,...).
N'hesites pas.
REMARQUE (2) : Malgré mon appel à la diffusion, je constate que le compteur de ma liste d'inscrits à la news letter est bloqué !
LAO.
J'ai classé cet article dans la partie performance, mais il pourrait également s'agir d'administration. Comme vous le savez tous ORACLE utilise toute une série de statistiques pour déterminer le meilleur (en tout cas pou lui) plan d'execution d'une requête donnée.
C'est magnifique ! Cela signifie qu'en fonction de la volumétrie, de la répartition des données et de divers autres paramètres, ORACLE va pouvoir utiliser un plan d'execution différent.
C'est beau et c'est chiant en même temps. Je m'explique. Je me positionne dans le cas d'un éditeur de logiciel qui fait bien son travail (ca existe).
L'editeur en question à des bases de tests avec une forte volumétrie, et valide son application.
Un client a forte volumétrie également contrairement à l'éditeur à des temps de réponse mauvais.
Je vous épargne les aller-retours très constuctifs du genre "Chez nous ca marche", ou "nos données sont secrètes, hors question de vous les faire parvenir",....
Nous sommes face à un problème (récurent) !
Dans le cas d'applications ou des centaines de requêtes (voir des milliers) sont executées comment s'assurer que les plans d'executions soient identiques chez le client et l'éditeur.
Tout est dans le titre : LES STATS !
Si j'arrive à avoir les mêmes stats que le client, il me suffit de rejouer son scénario et si le problème vient réellement d'un plan d'execution différent, alors je vais pouvoir identifier la ou les requêtes en question.
Etape 1: Demander au client de sauvegarder ses statistiques
Pour cela nous allons créer une table pour heberger ces statistiques.
exec DBMS_STATS.CREATE_STAT_TABLE (ownname=>'USER_CLIENT', stattab=>'NOM_TABLE_STATS');
Ici, USER_CLIENT est le schéma applicatif à soucis, et NOM_TABLE_STATS la table ou l'on va sauvegarder les statistiques.
On peut également passer le paramètre tblspace pour indiquer uin tablespace particulier pour la table.
Etape 2: Exporter les statistiques vers cette table
exec DBMS_STATS.EXPORT_SCHEMA('USER_CLIENT','NOM_TABLE_STATS');
Il suffit au client de faire un export de la table NOM_TABLE_STATS et de l'envoyer à son editeur préféré.
Et donc que nous reste-il à faire....
Etape 3 : importer la table NOM_tABLE_STATS
(je ferai un de ces soir un article sur les import /export)
Etape 4 : Remplacer les stats de ma base de tests par les stats du client.
On va faire ca en deux fois.
- Suppression des statistiques actuelles.
- Import des statistiques du client.
Suppression des statistiques:
exec DBMS_STATS.DELETE_SCHEMA_STATS('USER_EDITEUR',FORCE=>TRUE);
Si on veut être prudent, on peut créer au préalable une table de sauvegarde pour les stats et conserver les stats au moment de la suppression.
exec DBMS_STATS.CREATE_STAT_TABLE('USER_EDITEUR','Stats_backup');
exec DBMS_STATS.EXPORT_SCHEMA('USER_EDITEUR','Stats_backup');
exec DBMS_STATS.DELETE_SCHEMA_STATS('USER_EDITEUR',FORCE=>TRUE);
Import des stats
exec DBMS_STATS.IMPORT_SCHEMA_STATS('USER_EDITEUR','NOM_TABLE_STATS');
Et voila nous avons maintenant les même statistiques que notre client adoré, et donc une plus grande probabilité de trouver l'origine du souci, si celui ci est lié à des plans d'executions différents.
L'interêt de ce genre de manipulations peut également être d'utiliser les statistiques d'une base de production (très forte volumétrie) sur un environnement de developpement à faible volumétrie, et de lister les plans d'executions afin de s'assurer par exemple que nos nouveaux developpements ne vont pas engendrer de "Full scan" sur des grosses tables.
Au final en approchant les stats par cette face, on se rend compte que si la collecte de statistiques est importante en soi, sa mise en place, son administration et les choix qui seront fait concernant les statistiques pouront avoir un impact positif ou négatif (si c'est mal fait, voir pas fait).
REMARQUE (1): Un de mes fidèles lecteurs, m'a fait part du problème la couleur de fond pour les impressions. Alors avant que je commence à changer, est ce quelqu'un d'autre à quelque chose à redire sur la lisibilité (taille de police trop petite, couleur,...).
N'hesites pas.
REMARQUE (2) : Malgré mon appel à la diffusion, je constate que le compteur de ma liste d'inscrits à la news letter est bloqué !
LAO.
Partager cet article
