La base de données sur laquelle s’appuie notre infrastructure SOA est fortement sollicitée, notamment par l’enregistrement des différentes instances de composites. Afin de maintenir de bonnes performances et une bonne réactivité des différentes consoles de supervision, notamment de « l’entreprise manager (EM) », il est important d’adapter son niveau de « log » en fonction de ses besoins et de faire un nettoyage régulier de ses données. Voici donc quelques pistes qui vous permettrons d’aller dans ce sens.
Utiliser le bon niveau de log
Pour limiter la quantité de données de la base, la première chose à faire est d’adapter son niveau de log à ses besoins. Notamment en positionnant le « niveau d’audit » à « production level ».
Un autre levier possible est l’utilisation de la propriété « inMemoryOptimization » au niveau des flux BPEL.
Cette propriété permet selon la valeur qui lui est passée de ne sauvegarder par exemple que les instances en erreur voire aucune instance pour les flux qui ne présentent aucune criticité.
Purge drastique des instances
Pour ce faire, Oracle fournit un script permettant de vider les principales tables utilisées par l’infrastructure SOA.
Celui-ci aura pour effet de supprimer l’ensemble des données liées à vos exécutions de flux et de repartir d’un environnement vierge de toute instance.
Action à réaliser principalement sur des environnements de développements pour lesquels les données n’ont pas besoin d’être conservées et idéale pour repartir sur une base propre lors d’un nouveau sprint de développement.
Ces scripts sont disponibles à l’emplacement suivant de votre Oracle_home :
$Oracle_Home\soa\common\sql\soainfra\sql\oracle\122100\truncate\truncate_soa_oracle.sql
Purge automatique des instances
Depuis la version 12c, Oracle met à disposition une interface de paramétrage pour la purge automatique des instances de flux.
Contrairement à la purge décrite précédemment, celle-ci permet une sélection plus fine des instances à supprimer ainsi que la fréquence de lancement souhaitée.
Celle-ci est accessible et paramétrable depuis l’EM.
Il est également possible de la déclencher par script SQL, celui-ci étant bien entendu fourni par Oracle.
Plusieurs remarques néanmoins concernant la purge :
Bien que les instances soient supprimées, l’espace alloué n’est pas automatiquement libéré.
Il est donc important de réaliser des actions de « shrink » sur les partitions courantes afin de libérer effectivement de l’espace au quotidien.
La seconde remarque concerne la gestion des anciennes partitions dans le cas bien entendu où le modèle de données est partitionné (option).
Lors du passage sur une nouvelle partition, par exemple en début de mois si telle est la granularité du partitionnement, une période de transition s’effectue durant laquelle l’ancienne partition existe toujours.
et où la nouvelle débute sa croissance. Il faut donc veiller à réaliser les actions de « shrink » sur la partition courante mais également sur la précédente.
Par ailleurs, une fois les anciennes partitions vidées de toutes leurs instances, il est recommandé de les supprimer.
Oracle fournit à cet effet des scripts de vérifications qui permettent de valider que ces partitions ne sont plus utilisées et de les supprimer le cas échéant.
Finalement, pour l’avoir expérimenté, il peut arriver que certaines tables ou certaines instances ne soient pas correctement supprimées.
Ce qui a pour effet de conserver des partitions durant de longues périodes et d’occuper de l’espace inutilement.
Si tel est le cas, il faudra envisager de réaliser des actions de maintenance plus drastique comme des suppressions manuelles de partitions par exemple.
Conclusion
La stratégie de purge fait partie intégrante d’un projet de mise en place d’une plateforme SOA. Mal anticipée, la plateforme se retrouve vite inexploitable et une saturation de la base de données peut engendrer une diminution des performances voire dans des cas extrêmes mener à des interruptions de service des environnements.
Plus la volumétrie de votre base sera faible et meilleures les performances seront.
Il convient également de garder à l’esprit que la base de données de la SOA n’a pas vocation à être utilisée dans l’optique de stocker des données sur le long terme ou à servir de support pour faire des analyses business.
Dans le cas où le besoin de conservation des données sur la durée avec un besoin de reporting se ferait sentir, il peut être intéressant de se tourner vers des outils de type ELK, qui permettent de stocker et de traiter une grande quantité de données.
