SOA 11g Composites Causing MDS Growth
Last updated on NOVEMBER 03, 2016
Applies to:Oracle SOA Platform - Version 188.8.131.52.0 to 184.108.40.206.0 [Release 11gR1]
Information in this document applies to any platform.
Currently with the way MDS-SOA deployment is set up a particular label could pin other undeployed composites even a if label has been logically deleted.
This can cause a lot of rows in the MDS DB since the auto purge cannot purge the logically deleted labels since they are pinned by another label.
Here is the scenario:
1) Deploy CompositeA -> Creates LabelA that pins all the documents in the partition as of now
2) Deploy CompositeB -> Creates LabelB that pins all the documents in the partition as of now
3) Undeploy CompositeA -> Marks all the documents in composite A as logically deleted, deletes LabelA. LabelB still pins CompositeA data
4) Deploy CompositeC -> Creates LabelC that pins all tip versions as of now (i.e, CompositeB and CompositeC)
5) Undeploy CompositeB -> Marks all the documents in composite B as logically deleted, deletes LabelB. LabelC still pins CompositeB data hence compsiteB can not be purged. Since labelB has been removed, CompositeA can be purged now.
5) Undeploy CompositeC -> Marks all the documents in composite C as logically deleted, deletes LabelC. All composites can now be purged.
To summarize, every composite deployment label pins all other other tip composites as of that point. So, if there are interleaved deployment, undeployment, the undeployed composites can not be purged till all the prior deployed composites are undeployed.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms