I am not an expert when it comes to Administering Multi-User Geodatabase. However, I refer to Esri's documentation for best practices and efficient workflows before putting on my GIS Admin's hat to perform any Geodatabase Administrative task.

Recently, one my tasks involved making schema changes (adding fields and deleting fields) to a feature class part of feature dataset which is registered as versioned. As per the Esri documentation here, it is required to unregister the dataset as Versioning before making any schema changes to the feature class. Keeping this mind, I followed the steps highlighted below:

  1. Take a Geodatabase and XML Backup of the Production DB
  2. Connected to the Geodatabase Administrative Account
  3. Removed all the locks from the dataset
  4. Connected to the Geodatabase Data-owner Account
  5. Unregister the Dataset as Versioning - ArcGIS Prompted me to compress the edits to the base - I checked option before hitting Continue (I remember checking the mark but have no way to confirm I did)

enter image description here

  1. Added the fields and deleted the fields required to complete the task
  2. Registered the feature dataset as versioned

ArcGIS for Desktop Version - 10.4.1 Oracle Enterprise Database Version - 11g

Later, the data owner reported that was data missing from the user's version. Upon investigating further, the data was missing from DEFAULT Version and User's Version (one year worth). The data was retrieved from the backup but my still need to know what caused such huge data loss.

My research tell me that the data loss occurred due to not checking the compress option. However, the data editor's version regularly post their edits to DEFAULT which should logically delete only the data (edits worth 3 days) that was not posted to Default before making the above changes.

I am asking for some guidance from experts in the field who can propose any reason for such huge data loss or guide me to the right direction to find a way to look into the System Tables to answer this question.

  • Besides the edits in the version, all uncompressed edits will be lost whether they were in the version or previously posted but still in the A&D tables. How often do you compress? How big are your A&D tables? They should be all empty before unversio ing. Going spelunking in the system tables is always fun. – Ben S Nadler Nov 12 '17 at 16:59
  • Thanks for your feedback, Ben! I just started working at this new place with no documentation in sight. The Compress is not run that often. I working on making it a schedule task to perform this maintenance task. – Raj Nov 12 '17 at 17:20
  • Glad you took the backup! What version of sde and Oracle are you working with? Look for and delete any edit versions and replica versions that will prevent a full compress and try again. It's not too bad. – Ben S Nadler Nov 13 '17 at 2:02

I am not a DBA either, however I have worked with them in the past. I seem to recall that Compression did not always return the DB to State 0 on one attempt. You might consult the State(?) tree to see if that is what is occuring here. The correction would be to run the Compression until the State(?) tree is returned to zero.

Not the answer you're looking for? Browse other questions tagged or ask your own question.