La version 12 est donc dans les nuages, le marchand de sable est passé on peut s’endormir tranquillement : Oracle va régler tous nos petits problèmes quotidiens et nous apporter de nouvelles fonctionnalités grâce à sa nouvelle architecture : NEW-FEATURE-12C

Pour découvrir quelles sont les idées d’améliorations de performances mises en œuvre dans cette nouvelle release, tous les DBA ont scruté les « new features » pour trouver les arguments qu’ils apporteront à leurs décideurs pour pousser la migration vers la 12c même si les DSI ne sont pas encore prêts à mettre leurs data dans le cloud.
On trouve avec nos moteurs de recherche préférés : « ADO » (Automatic Data Optimization) associé à « Heat Map » une techno provenant des concepts « ILM » (Information Lifecycle Management) qui permet de détecter le rythme auquel les segments sont accédés et de les placer sur des axes appropriés et/ou de les compresser pour gagner de l’espace et du temps. Plus une donnée est fréquemment accédée (chaude) plus elle doit être accessible (disque rapide). Moins elle est accédée (froide) plus on peut la compresser et la placer sur les axes les moins performants.
On peut ainsi passer des ordres pour modifier la façon dont des données de tables sont stockées, exemple :
ALTER TABLE ILM ADD POLICY
ROW STORE COMPRESS ADVANCED SEGMENT
AFTER 30 DAYS OF NO MODIFICATION;
Nous savons tous que les I/O c’est primordial pour les perfs, mais quand une requête part en vrille, on passe toujours beaucoup de temps à OPTIMISER. On veut donc savoir si la 12c apporte des améliorations côté optimiseur…
On reprend alors les basics de la bonne méthode : lecture du guide Oracle Database 12 1 c Release 1 (12.1) New Features
Et on plonge sur le chapitre « Performance » qui se décline en 4 petites notes sur 3 pages :
1. Database Performance Enhancements
Advanced Network Compression
Very Large Network Buffers
2. General
Asynchronous I/O Control for Direct NFS Client
Tracking I/O Outliers
3. Hardware Optimizations
Multi-Process Multi-Threaded Oracle
4. Improve Ease of Performance Out-of-the-Box
Ability to Specify NFS Version in Direct NFS Client
Peu de nouveauté sur les perfs de nos applications donc …Est-ce que toute la réécriture de la version 12c a oublié l’optimiseur ? … Au moins nous n’aurons pas les problèmes du passage de la 9 à la 10 😉
En prolongeant la lecture sur les autres chapitres dans les derniers paragraphes de la « B.I » (celle qui nous pose le plus de soucis de performances puisque constituée de deux termes incompatibles 😀 !) on tombe sur une page fort intéressante : « Adaptive Query Optimization ».
Et là, on découvre enfin une vraie nouvelle fonctionnalité de l’optimiseur !
Constat partagé par l’ensemble des DBA qui reconnaissent à BO et Cognos de leur générer du taff quotidiennement : L’optimiseur peut se tromper lors de la génération de plan d’exécution de requêtes lourdes.
Contournement : Oracle nous proposait de mettre des « Hint », mais nous ne pouvions pas toujours modifier le code SQL surtout lorsqu’il est généré par ces fameux requêteurs. Autre astuce, exporter un plan « qui marche » et l’importer dans l’environnement qui pose problème.
Maintenant, avec la 12c, une nouvelle solution : Adaptive Query Optimization doit permettre de corriger ces erreurs presque automatiquement !
Voici le schéma de principe de cet « Adaptive Query Optimization » :

L’optimisation des requêtes « adaptatives » est un ensemble de fonctionnalités qui permettent à l’optimiseur de faire de l’ajustement « on line » ou asynchrone de plans d’exécution et de découvrir des informations supplémentaires qui peuvent conduire à de meilleures statistiques pour réorienter les directives d’exécution d’une requête.
Tout d’abord, il vous faut vérifier ces paramètres d’initialisation :
OPTIMIZER_FEATURES_ENABLE à 12.1.0.1 ou supérieure
OPTIMIZER_ADAPTIVE_REPORTING_ONLY à false
OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES à true
Avec cette « optimisation adaptable », un plan peut être suspendu pendant l’exécution et ré-optimisé sur la base d’informations collectées au cours de la première phase de l’exécution. Par exemple, si le choix du plan initial était de faire un NESTED LOOP avec un coût estimé sur une cardinalité de 1, ce plan sera arrêté après 1000 boucle pour être remplacé par une HASH JOIN.
L’exécution d’une requête (son plan d’exécution programmé) est donc surveillée. Si les statistiques diffèrent considérablement des estimations du plan d’origine, les statistiques d’exécution sont enregistrées et utilisées si un nouveau plan plus performant peut être appliqué pour une exécution ultérieure.
Nous avons maintenant de nouvelles informations pour vérifier cela :
La vue V$SQL avec sa nouvelle colonne IS_RESOLVED_ADAPTIVE_PLAN ainsi que la vue DBA_SQL_PLAN_BASELINES :

La tâche SYS_AUTO_SPM_EVOLVE_TASK se charge de trier les bons et mauvais plans, elle met ses informations dans la vue DBA_ADVISOR_TASK et le package DBMS_SPM.REPORT_AUTO_EVOLVE_TASK nous permet de suivre le travail de cette tâche automatique.
Attention comme tout « Advisor » chez Oracle, il nous faut une licence « Tuning Pack ».