OCI: si possible, utiliser l'OCILIB

Dernièrement, j'ai travaillé sur une interface C écrite en OCI natif. Sans rentrer dans les détails, elle était d'une piètre qualité, en particulier les requêtes n'étaient pas bindées ...

Si vous avez le choix, je vous conseille vivement d'utiliser l'OCILIB plutôt que d'attaquer directement la couche native. Dans le cas contraire, inspirez-vous du code source de l'OCILIB disponible à cette adresse. Des exemples sont également fournis dans la doc officielle.

Mais de grâce, ne réinventez pas la roue !

Si vous avez besoin d'un bulk collect en OCI, voici un exemple.

Cassandra

Une présentation de Cassandra ( version 2.0 ), une base nosql hybride.

Cassandra est un moteur in-memory pour l'écriture. Couplé à un produit libre comme Spark pour la lecture, on aboutit à une solution full in-memory, ce qui change la donne en terme de performance.
 

MongoDB

Une présentation de MongoDB ( version 2.4 ) ,  une base nosql orientée document.

Les données à l'heure du big data

Une réflexion sur l'évolution des bases de données au moment où le big data commence sa démocratisation.

db_stress: un prototype pour simuler une montée en charge

Cet outil écrit en Java ( environnement de test: AIX6, JVM 1.6, instance 11.2.0.2 ) permet de créer n threads. Pour chaque thread, il utilise une session créée par un pool de connexion UCP et exécute une transaction ( select ou procédure stockée ) m fois. Entre chaque exécution, un sleep permet de stresser plus au moins l'instance.

Il est disponible ici.

Pour l'utiliser, il suffit de compiler les fichiers source ( javac ) après avoir paramétré votre environnement unix ( voir fichier env_java ). Il se lance de cette manière: java Pilote nb_thread delay_ms nb_execution. Le premier paramètre indique le nombre de threads, le second paramètre la valeur du sleep en ms et le troisième paramètre le nombre d'exécutions de chaque transaction.

Il se configure à l'aide de deux fichiers xml, config.xml et scenario.xml. Le fichier config.xml permet de définir les caractéristiques de l'instance via une url jdbc et de configurer le pool de connexion UCP. Le fichier scenario.xml permet de définir un test de charge; il décrit la transaction de chaque thread. L'outil ne traite que les select et les procédures. L'utilisation des variables bindées est possible.

Histogramme

Une série d'articles intéressants sur les limites des histogrammes : http://allthingsoracle.com/histograms-part-3-when/

ORA-4031: KGLH0

En utilisant l'outil db_shared_pool, j'ai pu observer que le namespace des pipes ne se désalloue pas en 11.2.0.2.  Pour éviter un arrêt/relance de l'instance, une solution consiste à purger les pipes via la procédure dbms_pipe.purge, ce qui force leur désallocation.

Si le problème se pose sur d'autres objets du shared pool et s'il n'existe pas de patch ou si vous ne pouvez pas passer un patch existant, penser à la procédure dbms_shared_pool.purge. Elle vous sera peut-être d'un grand secours !