Et votre pipelined function renvoie 8168 lignes... (quoique)

Un des éléments fondamentaux utilisés par Oracle pour calculer le coût d'une requête est la cardinalité des différentes opérations des plans d'exécution examinés. Cette cardinalité est l'estimation du nombre de lignes retournées pour les étapes des plans. Pour calculer une cardinalité, Oracle s'appuie sur les statistiques collectées mais également sur des modèles de calcul.

Autrement dit, si les statistiques ou les modèles de calcul sont en contradiction avec le nombre de lignes réellement retournées par une opération, il est possible (probable?) que le plan préféré par Oracle soit sous-optimal. C'est sur ce principe que vous vous appuyez pour mettre en oeuvre la méthode de "cardinality feedback" qui consiste à comparer la cardinalité aux nombres de lignes effectivement retournées pour détecter facilement ce type de situation. Vous pouvez réaliser cette analyse "à l'oeil" avec des outils comme trcanlzr, le hint gather_plan_statistics ou SQL Real Time Monitoring. Oracle 11.2 utilise lui-même cette approche "automatiquement" depuis qu'un algorithme a été embarqués dans le moteur en 11.2 (cf cet article précédent qui l'illustre).

Vous connaissez tout ça et vous savez, par exemple,

Oracle Unified Directory en 30 minutes

Oracle Unified Directory est le futur des annuaires d'Enterprise Oracle. A ce titre, il a été annoncé comme le remplaçant, à venir, d'Oracle Internet Directory et d'Oracle Directory Server Enterprise Edition (aka Sun Java Directory Server ou iPlanet). Pourquoi Oracle Unified Directory ? Pourquoi Oracle ne continue-t-il pas simplement sur la voie ODSEE ? Pourquoi prendre le risque de perdre des clients ?

Entre rêves et marketing, le white-paper de la solution présente les objectifs, ambitions et utopies qu'entretient Unified Directory : repousser les limites de volume et de capacité de monter en charge d'ODSEE ; passer l'ordre de grandeur de temps de réponse des requêtes LDAP à la milli-seconde ; tirer parti des standards et des meilleures technologies open-source ; simplifier la configuration des annuaires et leur gestion ; permettre le déploiement d'infrastructures largement distribuées et évolutives ; 99,999% de disponibilité ; capitaliser toutes les expériences des équipes d'Oracle chargées de la gestion des identités depuis 15 ans ; permettre la révolution des Elastic Directory Services [NDLR: se prononce cloud 3.0, sans doute...]. Peut-on y croire ?

Pourtant, il y a plusieurs intérêts réels et immédiats à mettre en place Oracle Unified Directory...

• Le premier, qui laissera les utilisateurs froids, est essentiel pour la future plate-forme : Unified Directory est 100% java, comme Oracle Virtual Directory, ou presque, et comme Weblogic.
• Le second : vous mettrez en oeuvre la solution en 30 minutes avec une simplicité déconcertante, une VM Java SE 6 et une distribution multi-plateforme de 120Mo
• Le troisième : Unified Directory offre plusieurs fonctionnalités très intéressantes ; celle (1) d'un annuaire LDAP mais aussi (2) d'un proxy pour d'autres annuaires et, surtout, (3) de réplicats légers d'ODSEE.

Cet article est une introduction à Oracle Unified Directory. Vous passerez par les étapes d'installation, de configuration et une première utilisation. Mais les minutes filent, avançons ! Si vous décidez de poursuivre, vous avez déjà perdu 5 minutes (5')...

Supprimer un backupset d'un catalogue RMAN sans CROSSCHECK

Sans accès au media manager depuis votre base de données Oracle, impossible d'établir un canal de maintenance et donc de lancer la commande CROSSCHECK. Dans la cas où cette perte est définitive, pour supprimer les références à vos fichiers de sauvegarde de votre catalogue RMAN ou de votre fichier de contrôle, vous pouvez utiliser CHANGE ... UNCATALOG pour supprimer les références à ces fichiers.

Seulement voilà :

RMAN> list backup tag=TAG20120516T101354;

List of Backup Sets
===================

BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
7       6.75M      SBT_TAPE    00:00:56     16-MAY-12
        BP Key: 7   Status: UNAVAILABLE  Compressed: YES  Tag: TAG20120516T101354
        Handle: 08nb4832_1_1   Media: oracle RMAN0000001

  List of Archived Logs in backup set 7
  Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
  ---- ------- ---------- --------- ---------- ---------
  1    51      6997886    16-MAY-12 7009301    16-MAY-12

RMAN> change backup tag=TAG20120516T101354 uncatalog;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of uncatalog command at 11-JUN-12  
RMAN-06122: CHANGE .. UNCATALOG not supported for BACKUPSET 

Oracle Advanced Queing, JMS Publish/Subscribe, Weblogic et Message-Driven Beans

Traditionnellement, les applications qui s'appuient sur des bases de données, exécutent des requêtes pour répondre aux questions de leurs utilisateurs. Toutefois, ces systèmes d'information évoluent :

• les bases de données sont désormais alimentées au fil de l'eau plutôt que par des batchs ou des travaux planifiés
• les utilisateurs s'attendent de plus en plus à ce qu'on leur pousse l'information alors qu'ils allaient la chercher autrefois.

Pour répondre à ces évolutions de manière efficace, les applications de bases de données mutent. Alors qu'elles passaient parfois un temps important à faire du "Polling" de données dans des tables, elles s'appuient désormais sur des mécanismes de publish/subscribe. Il faut dire que ceux-ci sont extrêmement virtueux :

• ils ont fait leur preuve, depuis plusieurs milliers d'années, alors qu'IBM dominait encore le monde de l'informatique
• ils réduisent les temps de latence ; les notifications des clients, même en nombre, deviennent quasi-instantanées
• ils nécessitent bien moins de ressources que de sonder systématiquement toutes les données depuis parfois des dizaines de programmes
• ils sont capables de monter facilement en charge, du fait de leur nature asynchrone

Avec l'arrivée annoncée d'une nouvelle génération d'applications web qui s'appuient sur les websockets, il est probable que tout cela ait encore plus de sens.

Cet article illustre ce type d'approche à l'aide d'une file d'attente Oracle Advanced Queuing (AQ) sur laquelle sont publiés des messages JMS qui déclenchent un EJB de type Message Driven Bean dans Weblogic. Il présente les différents aspects d'implémentation et de paramétrage de ces composants...