Subnetwork Line Feature Geometry LOB growing in Database

[JeffBlake]

We're using an Oracle database with ST_geometry and have noticed that the LOB associated with our subnet line is growing dramatically — it's currently sitting at 83 GB.

We attempted to use the new Prune Branch History tool to remove records older than 6 months and also tried pruning records older than 2 weeks. However, we didn’t observe any reduction in memory usage.

Has anyone encountered similar behavior or have suggestions on how to clean this up? We're particularly interested in:

• Whether LOBs are retained even after pruning
• If there's a recommended way to compact or purge unused LOB data
• Any Oracle-specific settings or cleanup routines that might help

Any insights or experiences would be greatly appreciated!

[RobertKrisher]

@JeffBlake make sure you've read the requirements on this page: Prune branch history—ArcGIS Pro | Documentation. The most likely scenario is you have versions and/or conflicts out there that are preventing the tool from pruning any inactive records.

[JeffBlake]

@RobertKrisher so we are working off a copy of our prod db and deleted our branch versions from the branches table in the db, do i need to spin up a service with a version manager and delete the versions that way? I believe we had to do that before we could get the tool to run at all.

[RobertKrisher]

You can run the tool with versions still in the system, most customers will. If there are many versions that aren't reconcile or contain conflicts, the tool won't prune as many records because of the referenced moments. This is discussed in the page I linked. Check the number of rows in the table before, and after the prune.

Just deleting all the rows from the branches table is going to leave information orphaned in the system tables. You don't need to do it by hand through the service, but you do need to use either a GP tool, script, or SDK to use our APIs to reconcile (or delete) the versions. Any versions with conflicts will need to have their conflicts resolved in order to remove the referenced moments from the default version history.

Finally, there are likely some configuration changes you can make to your subnetwork definitions to reduce the size of your subnetwork lines. Things like making sure you're not including service lines as part of the aggregated geometries for each tier of your network can significantly reduce the size of each line and the speed with which that table grows. Even thought a feature's shape isn't included in the aggregated geometry, it is still included in all the functions and calculations for the subnetwork.

[JeffBlake]

@RobertKrisher So we did another refresh from prod we were seeing a memory usage for the db of 132 GB. I used the delete version gp tool to delete all versions on the DB and unregistered all the feature class replicas in the db. After this we saw memory usage go down to 131 GB. I then used the prune branch history using two different dates and got row counts on our subnet line feature: 

Row Count Before Prune 458197
Row Count After Prune 6/1/2025 108895
Row Count After Prune 8/11/2025 24309

After both prunes we saw no difference in memory usage. Also we are seeing gigs of growth even since I made this post. Here is what i was able to pull today.

Will look into your suggestion about configuration changes for subnetworks, I am just not a data editor so am unfamiliar with how this is being done,

[RobertKrisher]

If we deleted the rows from the table, then we have done our part. Some DBMS have another step you have to go through in order to free up the space associated with the old rows.