Discussion :

[devkais]

Bonjour,

Je me permets de vous contacter pour un avis d'Experts en bases de données Oracle.

Je travaille sur une migration oracle 10g vers 11g sur une base de 10 To !
Pour des raisons de gain de temps et de stabilité des plans d’exécution les statistiques sont FIGEES depuis la 8i en 2004 (même lors de la migration précédente 9i/10g).

Les temps de réponses 11g (base de test à volumètrie réelle) présentent une régression par rapport à la 10g !

Il faut remédier à cela sans recalculer les stats en 11g(une vraie contrainte).
Le code de l'application est bourré de hints pour forcer l'optimiseur ...

Faut-il forcer le calcul des stats en 11g après avoir inhibé tous les hints dans le code de l’application ? 3000 hints environ !
Sinon quel est le risque si on garde les anciens stats et on analyse traitement par traitement ?

Merci par avance pour votre aide.

Kais

[Pomalaix]

Pour des raisons de gain de temps et de stabilité des plans d’exécution les statistiques sont FIGEES depuis la 8i en 2004 (même lors de la migration précédente 9i/10g).
...
Il faut remédier à cela sans recalculer les stats en 11g(une vraie contrainte).
...
Faut-il forcer le calcul des stats en 11g après avoir inhibé tous les hints dans le code de l’application ? 3000 hints environ !

Il y a en 11g différents outils, nouveaux ou non, qui faciliteront vos tests pour sortir de ce que je considère comme une fuite en avant (en plutôt en arrière).

1) désactivation globale des directives d'optimisation (les hints), à titre de test :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

alter session set "_optimizer_ignore_hints" =true;

2) statistiques "privées"
- vous calculez les stats avec l'option PUBLISH=FALSE

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
exec dbms_stats.set_database_prefs('PUBLISH', 'FALSE');
exec dbms_stats.gather...

- vous activez ces statistiques uniquement dans la session de test

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

alter session set optimizer_use_pending_statistics=true;

- si elles s'avèrent bénéfiques, vous les publiez pour tout le monde

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

EXEC DBMS_STATS.PUBLISH_PENDING_STATS(NULL, NULL);

3) émulation d'un optimiseur de version inférieure, par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

alter session set optimizer_features_enable='8.1.7';

4) fonctionnalité "sql performance analyzer" appartenant à l'option payante Real Application Testing, qui permet de comparer les performances individuelles d'un jeu de requêtes avant et après modification (ici le changement de version)

5) "sql plan management", qui fournit une sorte d'assurance anti régression, grâce à des plans de référence qu'on peut transférer depuis la V10 par exemple


De plus, il se pourrait, d'après ce que vous décrivez, que vous traîniez dans votre INIT.ORA V11 des vieux paramètres qui sont désormais complètement inadaptés.

[Mohamed.Houri]

Bonjour,

Je me permets de vous contacter pour un avis d'Experts en bases de données Oracle.

Je travaille sur une migration oracle 10g vers 11g sur une base de 10 To !
Pour des raisons de gain de temps et de stabilité des plans d’exécution les statistiques sont FIGEES depuis la 8i en 2004 (même lors de la migration précédente 9i/10g).

Les temps de réponses 11g (base de test à volumètrie réelle) présentent une régression par rapport à la 10g !

Il faut remédier à cela sans recalculer les stats en 11g(une vraie contrainte).
Le code de l'application est bourré de hints pour forcer l'optimiseur ...

Faut-il forcer le calcul des stats en 11g après avoir inhibé tous les hints dans le code de l’application ? 3000 hints environ !
Sinon quel est le risque si on garde les anciens stats et on analyse traitement par traitement ?

Merci par avance pour votre aide.

Kais

Ce qui semble le plus simple et le moins risqué pour vous dans le cas que vous présentez ici est de faire, comme l'a déjà conseillé pomalaix, ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
11g> ALTER session SET optimizer_features_enable='10.2.0.4.0'; -- votre version 10g

Si, avec ceci vous arrivez à retrouver une performance acceptable, alors vous avez un répis. Je dis répis car je ne pense pas que vous puissiez naviguer d'une migration à une autre en maitenant toujours l'optimisateur(CBO) de la dernière version. A chaque migration des améliorations sont apportées au CBO (des bugs aussi) et vous devriez déployer des efforts afin d'utiliser la dernière version du CBO.

Utilisez donc ce répis afin de tester abondamment la nouvelle version en environnement de test. A chaque fois que vous être confronté à un problème de performance dans la nouvelle version, appliquer le code ci-dessous, générez les deux plans d'execution (celui avec le nouveau CBO et celui avec l'ancien) et comparez.

[pachot]

Bonjour,

Le code de l'application est bourré de hints pour forcer l'optimiseur ...

Quels types de hints ? Beaucoup changent de comportement d'une version à l'autre. D'autres non.

Sinon quel est le risque si on garde les anciens stats et on analyse traitement par traitement ?

Le problème, c'est que vous allez vous retrouver à tuner des requête en sachant très bien que les stats sont fausses...

Pour des raisons de gain de temps et de stabilité des plans d’exécution les statistiques sont FIGEES depuis la 8i en 2004 (même lors de la migration précédente 9i/10g).

Ce n'est pas la bonne solution pour figer les plans d'exécution...

Je pense que la bonne approche serait d'utiliser les SQL baselines (SQL Plan Management) - nécessite Tuning Pack - pour assurer la stabilité des plans:
1. creer des baselines fixes avec les plans de la 10g: soit avec SQL Tuning Sets à partir de la 10g, soit avec capture en ayant mis optimizer_features_enable à la 10g.
-> là normalement pas de regression car les anciens plans sont utilisés
2. calculer les stats
3. vérifier l'évolution des plans d'exécution. Accepter les plans meilleurs. Et lorsque les nouveaux plans (avec bonnes stats) sont moins bons, réfléchir individuellement à chaque requête.

Biens sûr, c'est tout un projet...

Cordialement,
Franck.

[devkais]

Bonjour ,
La plus part des hints sont :
ORDERED
USE_HASH
USE_NL
NO_MERGE
INDEX
NO_QUERY_TRANSFORMATION
...

Pensez-vous que recalculer les stats 11g est un grand risque dans mon cas ?

Quelles sont les conséquences si on garde la même technique de stats figées 8i sur une base 11g !

Merci.

[pachot]

Non, je ne pense pas que recalculer les stats présente un grand risque. surtout s'il y a des hints pour forcer les plans de toute façon.
De toute façon, en 11g c'est facile de tester les stats avant. voir le post de Pomalaix.

[Mohamed.Houri]

Pensez-vous que recalculer les stats 11g est un grand risque dans mon cas ?

Quelles sont les conséquences si on garde la même technique de stats figées 8i sur une base 11g !

Dans la version 8i les statistiques ont certainement été calculées en utilisant la commande "ANALYZE". Si vous optez (et je répète que tôt ou tard vous devriez le faire) pour un recalcul des statistiques en 11g vous devez alors utiliser le package DBMS_STATS. Et c'est là où commencent les problèmes. Ces deux méthodes ne fonctionnent tout simplement pas de la même manière et ne produisent pas les mêmes statistiques. j'ai résumé brièvement quelques différences ici dans cette intervention. Ce qui veut dire clairement que vous allez avoir du pain sur la planche. Afin que vous puissiez espérer avoir la même performance en 11g, il va falloir au moins retomber sur les mêmes statistiques en 11g qu'en 8i et en utilisant DBMS_STATS.

A votre place moi j'opterai pour la statégie suivante:

1. Dans le cas où j'ai encore du temps avant le passage en PRODCUTION, j'oublie les statistiques en 8i, je recalcule les statistiques en 11g en utilisant DBMS_STATS et je laisse mon application vivre tout en la surveillant. Il va falloir également tout tester. A chaque problème de performance, j'altererai l'optimisateur (CBO) à la version qui m'a déjà donné statisfaction et j'analyserai les raisons qui m'empêchent de produire en 11g la performance de la version 10g. J'utiliserai aussi les conseils donnés par Pomalaix si j'ai un problème lié aux hints par exemple en les ignorant au niveau global. Il va sans dire que c'est un projet. Une migration c'est un projet qu'il faut prendre au sérieux.

2. Si je n'ai vraiment pas de temps avant le passage en PRODUCTION, je ne risquerai pas de passer en PRODUCTION sans avoir tester la stratégie que j'aurai adoptée pour cela. Il faut dire qu'à part utiliser le CBO de la version antérieure comme solution temporaire, je ne vois pas quoi faire de mieux.

D'une manière générale, j'ai toujours opté pour "Ne pas recalculer les statistiques si la performance est bonne". Mais là, vous n'avez pas de chance, la performance n'est pas bonne en 11g et une solution fiable serait d'avoir des statistiques qui reflettent la réalité. Le CBO fonctionne comme cela "Garbage in Garbage out". S'il arrive à faire de bonnes estimations sur la base des statistiques dont il dispose il arrivera à produire un plan d'exécution le plus performant possible; sinon c'est aléatoire soit le dynamic sampling fait office d'un bon remplaçant (pas vrai à tous les coups) soit la cardinality feedback entre en scène (et là j'ai un vrai doute que cela fonctionne bien)

[devkais]

Bonjour à tous les Experts,

Ci-joint le paramétrage de la base de test 11g.

Il s’agit d’une base 11g est construite par clonage base 10g + upgrade 10g/11g.

Elle est configurée pour une gestion automatique de la mémoire.

Pensez-vous que tout est OK au niveau paramétrage 11g ?

Sinon j'ai des questions diverses :
- Si contrainte de temps pour calculer les stats , est-il possible de les calculer uniquement sur certaines tables + indexes avec un % d'estimation = 5% par exemple ? Ce % sera-t-il suffisant ?

- Si après recalcul des stats en 11g il arrive une régression quasi-totale des traitements (rien ne marche), faut-il investiguer pendant quelques jours pour analyser requête par requête les 5000 requêtes de l’appli. (Travail de fourmis) ou revenir en arrière sur les anciennes stats et trouver une autre solution ?

- Quelle méthode simple permet de réorganiser efficacement tous les objets de la base (move de tables , rebuild d'index ...) afin de gagner en performances ?

- Faut-il vérifier les lignes chaînées et migrées en 11g ?
- Dois-je modifier un ou plusieurs paramètres cachés de la base dans mon cas de figure ?

- SQL Developer (l’outil gratuit d’Oracle) permet-il d’auditer un peu la base et avoir des informations utiles ?

- Au cours des tests 11g , le DBA serait éventuellement amené à modifier un paramètre de la base 11g , faut-il dans ce cas refaire tous les tests déjà effectués ?

Merci pour votre aide.

Cordialement.

[Pomalaix]

Attention, ne partez pas sans méthode dans des bricolages anarchiques et sans cohérence.

Comme l'ont souligné les copains, une telle migration est un véritable projet (potentiellement plusieurs semaines), ce qui n'a rien à voir avec l'application de 2 ou 3 formules prétendues magiques.
Pour moi, il faut que votre hiérarchie prenne conscience de l'ampleur de ce projet et des compétences requises, et renforce votre équipe en conséquence.

Par exemple, personne ne peut répondre à la question du paramétrage de votre base (sans compter qu'il manque le nom des paramètres dans votre fichier Excel), car on paramètre une base en fonction des données qu'on y met et de l'usage qu'on en fait.
Il n'existe pas de paramétrage tout terrain qui serait valable pour n'importe quelle base 11g.