Purging Strategies in Oracle SOA Suite 12c - Part II

July 18, 2017

Reading time ~2 minutes

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.

Read the 1st part here

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:


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:


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!!

Arturo Viveros is an outstanding Mexican professional currently based in Oslo, Norway, with 11 years of experience in the development, design, architecture and delivery of IT Projects for a variety of industries. He is also a regular speaker in technology conferences, both in Mexico and abroad. He is an Oracle ACE and works as principal architect in Sysco Middleware. Arturo is also part of the coordinating committee for ORAMEX (Oracle User Group in Mexico) and has recently achieved the Oracle SOA Certified IT Architect certification as well as the Cloud & SOA Certified Architect grades from Arcitura Inc. He is a certified trainer authorized to deliver the SOA School and Cloud School modules both in English and in Spanish.

Arturo is also a regular contributor for several highly specialized technical publishers such as SOA Magazine, Service Technology Magazine and Oracle OTN, and coauthored on the Oracle API Management 12c Implementation book.

Customizing service calls with multiple levels of security in OSB 12c

This will be a part two of my previous post which you can read [here](http://blog.sysco.no/osb/jdeveloper/Service-call-with-multiple-leve...… Continue reading