Trim Archive History Tool for Branch Versioned Data

[ScottNoldy]

To add another use case:

Feature class is versioned/archived/branch versioned simply to allow offline use in Collector.

Feature class is updated nightly from another database so every night, another row is added for each record to the dataset.  The dataset eventually grows extremely large killing performance.

Something similar to the Trim Archived feature class would be ideal.

[ScottNoldy]

The below comments were moved from a separate Idea, to more accurately reflect the work under consideration by the development team.

[dj]

+1 from another developer concerned about database bloat.

[WillBooth2]

The Utility Network implementation I help look after has only been live for about six months and the rows in the branch tables for the subnetline feature classes are already over 100 times the number you see in DEFAULT.  This matters a lot as the doing spatial intersects on these are very inefficient due to the subnetwork line extents (a SQL optimiser issue), which makes their map display and using the Find Subnetworks tool incredibly slow.
Also DIRTYAREAS already has over 400,000 rows compared to the ones needing attention in DEFAULT will be well less than 100.
I can't see a useful business case for keeping history for these feature classes in particular for the life of this implementation.
Being able to periodically trim this these will be a necessity sooner rather than later.

[Kevin_MacLeod]

Hi folks, anyone know if this is implemented yet?

I am at a cross-roads and want to get a handle on a lot of field data coming in. We are at SDE/Enterprise 10.9.1 and updating imminently.  Branched is the "future" but without simple ability to clean up I am hesitant. I see the workarounds above but I do not have time to experiment or use unsupported things that may or may not continue to work.  

Esri team- any updates? Will this be officially implemented at 11.3.x or 11.4?

[SSWoodward]

@Kevin_MacLeod This idea is still under consideration and has not been implemented.  I'll be sure to update this idea when more information is available. 

[BogdanHristozov]

Hello,

I don't see any benefits of having the archive records stored in the base table. Over time, the amount of  archive records would significantly increase. This can cause troubles in backup management decisions and performance. There was a comment about copying the archiving records into a separate table, which sounds more relevant - the archive records should be separated from the current state of edits and to be used only in designated workflows.

[JeffBoykin]

Upvote!  We have now surpassed 42 million feature rows across 3 UN feature classes with branch versioning (PIPELINELINE, PIPELINEDEVICE, PIPLINEJUNCTION) due to data updates and we are seeing 10-30 minute reconcile times and falling behind on rec and post.  We are looking at taking a backup and nuking the old records ourselves and seeing what happens.  We only have about 20 million actual features.

[CarlVon_Stetten1]

Upvote!  Our SEWERSUBNETLINE feature class is now 1.5 GB for approximately 70 defined subnetworks.

While I understand the value of archive records (if you want to be able to do time-lapse comparisons of the data), our organization has never really needed this functionality with our utility data.

[Zagorki]

We'd like to see this feature/tool implemented as well. We use branch versioned data on a number of feature classes and tables unrelated to UN, Parcel Fabric, etc. Daily loads from our ETLs over the past year have turned what should be a few thousand records in one table to several million. This ETL run time went from an hour to 24 hours over this period.

The un-version and re-version option is not desirable as it removes existing views in the database and services are not happy.

We decided to run a stored procedure weekly to truncate the archival history directly in Postgres by looking at the gdb_branch_id, gdb_is_delete, last_edited_user, and gdb_from_date columns. This works for us for now but is also not preferable.

With the introduction of the Advanced Editing license being required for branch versioned data, this is enough to reconsider our use of branch versioning and return to traditional. If you only use Professional seats, this won't matter to you, but if you have 100s+ editors your costs have now more than tripled per user starting at Enterprise 11.2.

[EstherSmith_Dev]

This is long overdue. There should be an option/tool to purge the history older than X days/months/years.

[PayneTodd]

Can't believe there is no standard way to remove unnecessary records for our Utility Network.  Please Help us out.