Hello @RiccardoKlinger
Please, bear with me. I can see 2 scenarios about "branch versioning vs. mass updates" that you have already described.
A. if the branch versioned featureclass is small with just some million rows and the actual featureclass table size in the Enterprise Geodatabase RDBMS Storage is around let's say 20GB or so.
- then you can open Pro
- connect to Portal
- add the Feature Service to the map
- and perform the mass attribute update using the Pro editing tools directly in the branch version sde.default
- can even use model builder to automate the process for example.
- hence there is no need in this scenario to unregister as branch versioned the featureclass(es)
B. on the other hand if the branch versioned featureclass is quite large with 500 milllions rows for example and the featureclass table size in the Enterprise Geodatabase RDBMS storage is around let's say 1 TB.
- then open Pro
- reconcile and post all branch versions child of sde.default
- close Pro
- take a full database backup
- stop the ArcGIS Server Feature Service(s)
- need to do this because of locks that might prevent from unregister as branch versioned
- open pro and unregister as branch version the featureclass(es) then close Pro
- perform the mass attribute update using SQL statement
- sure thing the mass field update will be faster via SQL
- here consider to ask your database administrator to place the database in nologging (oracle), simple recovery mode (sql server) before you do the mass update via SQL, this will speed up the mass update via SQL
- after the update is done the database administrator can change the database back to logging (oracle), full recovery mode (sqlserver)
- open pro and register as branch version the featureclass(es) again and close Pro
- start the ArcGIS Server Feature Service(s)
- test the feature service and make sure you can make edits in a new branch version child of sde.default
- if everything is fine then take another full database backup
@RiccardoKlinger this is pretty much the same process that you have already described in your original question, but I just wanted to create a step by step to clarify for anyone reading this discussion.
I do not see any major problems with Scenario B and you have also mentioned that this is working fine for you, hence although this might not be officially sanctioned by Esri yet. I do not see any other way of doing the branch version mass update for very large featureclasses, Scenario B is the more appropriate way that avoids any data corruption.
Thanks,
| Marcelo Marques | Esri Principal Product Engineer | Cloud & Database Administrator | OCP - Oracle Certified Professional | "In 1992, I embarked on my journey with Esri Technology, and since 1997, I have been working with ArcSDE Geodatabases, right from its initial release. Over the past 32 years, my passion for GIS has only grown stronger." | “ I do not fear computers. I fear the lack of them." Isaac Isimov |