Purging Strategies in Oracle SOA Suite 12c - Part II
In my earlier post about purging the Oracle SOA product database, I mentioned that this is one of the most critical tasks when it comes to ensuring the stability and performance of SOA/BPM Suite production environments.
This means that you should never neglect this or expect it to magically take care of itself.
So let’s take a look at a couple of extra tips to get a better grip on this:
In 12c we have auto-purge, which can be configured and scheduled from the EM console. Unfortunately, EM still lacks a reporting / alerting feature to provide purging statistics or at least make sure the jobs are actually running successfully. So, if you’re blindly trusting this feature, it could very well be that instances are piling up by the millions without you noticing until it becomes a problem.
Luckily, there’s a very simple way to find out and keep track, just by looking into the SOA_PURGE_HISTORY table inside the SOAINFRA schema:
This table is pretty straightforward, as it will tell us the start & end time, if it was the single or the parallel script and the final status: C (Completed) or R (Rollbacked).
The out-of-the-box scripts are quite sensitive and enforce a lot of validations, which means that if anything goes wrong they will rollback everything and no instances will be purged whatsoever. So in case there’s a malfunction it’s good to be able to know and take the necessary steps to correct it before everything blows up.
Another important element regarding auto-purge is understanding and fine tuning the available parameters in line with your particular purging needs and strategy. For this it’s usually very useful to be able to identify the number of purgeable instances in the SOA DB before and after running a job. Take a look at this link from the A-Team:
http://www.ateam-oracle.com/how-to-find-purgeable-instances-in-soabpm-12c/
Analyzing this kind of behavior can be done for example in a QA environment, taking the load produced by stress / volume testing as a meaningful sample before applying any changes to production.
If you’re using Mediator / OSB together with the Resequencer component, then you will probably need to do periodical health checks on the DB in order to make sure instances are on a consistent state, so again you can leverage the A-Team’s advanced product knowledge:
http://www.ateam-oracle.com/resequencer-health-check/
Last but not least, don’t forget to log into MOS every once in a while and look for patches related to purging. There have been several fixes which can prevent or solve specific problems the scripts may stumble upon.
So, if you haven’t done it yet it’s as good a time as any to sit down with your trusted DBA and sort out the purging strategy for your organization’s Oracle SOA 12c platform.
Well, that’s all for this article; I certainly hope you found the post interesting and useful, thanks for reading!!