Questions sur Oracle 12c

bonjour les experts 12c ,
J'aimerais bien comprendre quelques nouveautés dans la 12c :
1/ Calcul des statistiques à la volé en cas de chargement ?
et si des stats existent déjà sur la table à alimenter, elles seront recalculées ? dans quel conditions de chargement ? insertion d'une ligne ? ou plusieurs ? exemple ?
2/ A quoi sert les colonnes invisibles ?
3/ A quoi sert la conversion d’une vue en table dans un expdp avec l'option VIEWS_AS_TABLES ? Je ne vois pas l'utilité pour l'instant ?
4/ Plan d'exécution adaptatif : Si l'optimiseur découvre que le plan initial est KO , il change de plan en cours d'exécution.
Dans ce cas comment fait-il : annuler tout et réexécuter ? continuer ?
Peut-il par exemple passer d'un plan avec full scan à un autre plan avec accès indexé à la place ? ou inversement ?
Ce fonctionnement est-il automatique ? paramètres et restrictions ?

merci pour vos précisions ?
Z.

Bonjour,

1/ http://blog.developpez.com/pachot/12...ticsgathering/
2/ lorsque une appli fait des 'select *' ou des insert sans nommer les colonnes, ce qui n'est pa une bonne pratique, on risque d'avoir des regressions en ajoutant une colonne. Les colonnes invisibles peuvent servir à éviter ces regressions. Ce n'est utile que dans dans cas particuliers doncs.
3/ juste à exporter le résultat d'une vue comme si c'était une table. C'est le but des vues: les interroger comme une table. Alors pourquoi pas les exporter.
4/ le plan prévoit les 2 méthodes de jointures (hash join et nested loop) et calcule le point (nombre de ligne) où l'une devient préférable à l'autre. Lors de la première exécution le choix sera fait en fonction du nombre de lignes mesurée. Ce choix va rester pour les exécutions suivantes.

Difficile à détailler plus dans un forum. C'est des choses qu'on couvre sur 2 jours de formation en général (pour info je donne un cours Nouvelles Fonctionalités 12c le mois prochain à Lausanne). Surtout pour les plans d'exécution adaptifs, il faut manipuler un peu pour bien saisir le fonctionnement.

Cordialement,
Franck.

Bonjour Franck ,

Merci pour tes réponses toujours pertinentes.
Peux-tu stp m'apporter plus de précisions sur le point 4/ Plan d'exécution adaptatif ?

un plan peut-il changer en cours d'exécution ? dans quelles conditions ?
merci.
Z.

Bonjour,
Le plan change (ou plutôt active une autre méthode de jointure) au cours de la première exécution seulement.
Un collègue à moi a présenté ça à l'OpenWorld, voici un résumé avec demo: http://www.dbi-services.com/index.ph...xecution-plans
Cordialement,
Franck.

Citation:

---

Envoyé par pachot

Bonjour,
Le plan change (ou plutôt active une autre méthode de jointure) au cours de la première exécution seulement.

---

Justement pourquoi ce mécanisme uniquement à la première exécution ?
Qu'est ce qui se passe à la 2ème exécution ?
Et si la mémoire est flashée ou l'instance est redémarrée ?
Merci Franck pour tes précisions :)

Vous pouvez lire sur ce sujet sur le blog de l'équipe qui développe l'Optimiseur: adaptive joins. Vous allez trouver là bas des article détaillé sur ce sujet dans la section Optimizer White papers.

C'est justement la premier fois que la requête s'exécute qu'elle est surveillée pour décider de la méthode de jointure. En fait l'optimiseur explore comme d'habitude plusieurs options mais il report la décision finale au moment de l'exécution de la requête (avant la décision été déjà prise au moment de l'exécution de la requête).
Donc il commence avec la meilleur méthode de jointure estimée et bufferise les enregistrement tout en surveillant le nombre de enregistrements ramène, c'est la vielle méthode d'optimisation proposé depuis la création de l'optimiseur basé sur le coût : comparer les estimations avec le nombre des enregistrements réellement ramène à l'exécution.
A la deuxième exécution le mécanisme est désactivé: il ajout forcement un coût supplémentaire et il est normal de considère qu'actuellement le plan choisi c'est le "bon".
Si l'instance est redémarré ou la mémoire vidée, la requête n'existe plus dans Shared Pool donc c'est du hard-parsing, c'est à dire une ré-"première fois".

Adaptive Plan n'est là que pour affiner l'optimization. lors de la première exécution. Un peu comme bind variable peeking. Donc seulement à la première exécution et pas persistent. Il faut le voir comme l'optimisation qui a lieu au hard parse, sauf que certaines décisions sont reportées à la première exécution.
Pour les exécutions suivantes il y a d'autres fonctionnalités, comme les SQL Plan directives, Automatic Reoptimization, qui permettent de chercher un nouveau plan d'exécution lorsque le contexte a changé, et éventuellement de le persister (via directives et extended statistics) au delà du redémarrage de l'instance.

bonjour ,
merci pour vos explications.
Juste une dernière question , quand l'optimiseur décide de changer de plan ( activer une autre jointure) au cours de la première exécution , comment il fait au juste ?
Il revient en arrière et re-exécute la requête entièrement avec la nouvelle jointure OU il continue à traiter le reste des lignes avec la nouvelle jointure( si c'est le cas , comment il fait ??? !!!) ?
merci pour votre aide !
Z.

Bonjour,J'ai mis en ligne sur ce blog un exemple de plan qui change, avec les infos d'exécution qui montrent qu'il ne revient pas en arrière. en fait dans le plan STATISTICS COLLECTOR va bufferiser les lignes jusqu'au point d'inflexion qui a été calculé lors de l'optimisation. A ce moment là la méthode de jointure est choisie et toutes les lignes l'utiliseront (celles qui étaient bufferisées et les suivantes).Cordialement,Franck.

Bonjour Franck,
Peux-tu stp me confirmer que cette nouveauté permet d'éviter qu'une requête qui devrait prendre quelques minutes ne part pour un scénario catastrophique (des heures voir l'infini ...) ?
Ce mécanisme est-il actif par défaut ? Est-il désactivable ?
Merci pour tes précisions d'Expert .

Bonjour,

Oui, ca va éviter ce cas lorsque le mauvais plan vient d'une mauvaise estimation. On peut quand même se retrouver dans cette situation lorsque les cardinalités ont changé.
La fonctionnalité peut être désactivée avec optimizer_adaptive_features ou optimizer_adaptive_reporting_only
(mais ils désactivent d'autre chose aussi, sinon c'est le paramètre non documenté _optimizer_adaptive_plans)

Pour le moment, en 12.1.0.1, il n'y a pas de hint ADAPTIVE_PLAN/NO_ADAPTIVE_PLAN pour contrôler ça. Mais on peut espérer avoir ça pour le prochain patchset ;)

Cordialement,
Franck.