Aller au contenu
  • Société
    • Qui sommes-nous
    • Nos valeurs
    • Nos partenaires
    • Entreprise citoyenne
    • Régions
  • Services
    • Expertise
    • Formation
    • Développement
    • Migration
    • Infogérance
  • Join the Team
  • Actualités
  • Blog
    • Blog easyteam.fr
    • Blog Cloud Natives
  • Formations
  • Rugb’Easyteam
  • Contact
Menu
  • Société
    • Qui sommes-nous
    • Nos valeurs
    • Nos partenaires
    • Entreprise citoyenne
    • Régions
  • Services
    • Expertise
    • Formation
    • Développement
    • Migration
    • Infogérance
  • Join the Team
  • Actualités
  • Blog
    • Blog easyteam.fr
    • Blog Cloud Natives
  • Formations
  • Rugb’Easyteam
  • Contact
Inscrivez-vous à la newsletter

Inscrivez-vous à la newsletter

Abonnez-vous maintenant et nous vous tiendrons au courant.
Nous respectons votre vie privée. Vous pouvez vous désabonner à tout moment.

Bienvenue sur le Blog d'EASYTEAM (ex ArKZoYd)

  • Accueil
  • Actualités
  • Cloud
  • Infrastructure
  • Données / Sécurité
  • Intégration
  • Dev / DevOps
  • SAM / FinOps
Menu
  • Accueil
  • Actualités
  • Cloud
  • Infrastructure
  • Données / Sécurité
  • Intégration
  • Dev / DevOps
  • SAM / FinOps
  • le 25/04/2018
  • Guillaume
  • SOA & Urbanisation, SOA Suite @fr

SOA 12C : une base propre pour des performances au top !

Partager sur linkedin
LinkedIn
Partager sur twitter
Twitter
Partager sur facebook
Facebook
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.

 

Guillaume
Guillaume
Voir tous ses articles
Partager sur linkedin
LinkedIn
Partager sur twitter
Twitter
Partager sur facebook
Facebook

Laisser un commentaire Annuler la réponse

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Les derniers articles

  • La fin d’OVM – L’essor d’OLVM 18/01/2021
  • Azure Netapp Files 11/01/2021
  • AWS – Choisir entre les services de messagerie pour les applications Serverless AWS 04/01/2021
  • RMAN : Dupliquer une base avec Restore database en 12c 28/12/2020
  • Run kafkaConnect with docker image 21/12/2020

Les derniers commentaires

  • Laurent GALLET dans Chiffrement du flux SQL*NET
  • SylvainF dans Oracle et VMware : risques, enjeux et solutions
  • Développer avec Oracle Functions - EASYTEAM dans Oracle Cloud Infrastructure Container Engine for Kubernetes
  • Younes dans Les bonnes raisons d’utiliser un CDN (réseau de diffusion de contenus / Content Delivery Network)
  • Bruno BOTTREAU dans Oracle et VMware : risques, enjeux et solutions
Espace Membres
Mot de passe perdu ?
EASYTEAM

Tour Nova, 71 Boulevard National,
92250 La Garenne-Colombes
Tél. 0800 40 60 40
contact@easyteam.fr

Facebook
Linkedin
Twitter
Navigation
  • Accueil
  • Qui sommes-nous
  • Entreprise citoyenne
  • Nos valeurs
  • Régions
  • Partenaires
  • Contact
  • Support
Menu
  • Accueil
  • Qui sommes-nous
  • Entreprise citoyenne
  • Nos valeurs
  • Régions
  • Partenaires
  • Contact
  • Support
Services
  • Développement
  • Migration
  • Infogérance
  • Expertise
  • Formation
Menu
  • Développement
  • Migration
  • Infogérance
  • Expertise
  • Formation
Blog
  • Cloud
  • Infrastructures
  • Data
  • Intégration
  • Dev / DevOps
  • SAM / FinOps
  • Applications
Menu
  • Cloud
  • Infrastructures
  • Data
  • Intégration
  • Dev / DevOps
  • SAM / FinOps
  • Applications
Copyright 2018 - EASYTEAM, Tous droits réservés
Mentions légales
Politique de confidentialité​