FAQ: How have unique indexes on geodatabase-managed Global IDs changed?
How have unique indexes on geodatabase-managed Global IDs changed?
Esri’s software releases of products ArcGIS Desktop 10.5.1 and ArcGIS Pro 2.0 include fundamental behavior changes to geodatabase-managed Global IDs.
What is a geodatabase-managed Global ID?
A geodatabase-managed Global ID field is a non-editable UUID column that the geodatabase is responsible for populating. A Global ID field can be added through the geoprocessing tool Add Global ID, or through Python using the following arcpy module:
AddGlobalIDs_management (in_datasets)What has changed?
At ArcGIS Desktop 10.5.1 and ArcGIS Pro 2.0, the following behavior occurs:
- Add Global ID now creates a unique index on the Global ID field to preserve uniqueness across features in the underlying table or feature class.
Versioned Class Behavior
- On Registration as Versioned, ArcGIS discovers the Global ID column and creates a unique index on the base table on the Global ID column. No new indexes are created on Adds and Deletes tables.
- Add Global ID to a class registered as versioned creates a new unique index on the Global ID field. No new indexes are created on Adds and Deletes tables.
Non-versioned Archive Class Behavior
- On Enable Archiving, the Global ID column is discovered and creates a unique index on Global ID and GDB_TO_DATE columns
- Add Global ID to an archived enabled class creates a unique index on the Global ID and GDB_TO_DATE fields. The H Table gets a non-Unique index on Global ID column.
|Class Type||Pre-condition||Operation||Index Type||Index Names||Columns|
|Non-versioned||Add Global ID||UNIQUE||UUID_<regid>||GLOBALID|
|Non-versioned||w/Global ID||Enable non-versioned archiving||UNIQUE||UUID_<regid>||GLOBALID, GBD_TO_DATE|
|Non-versioned||Archive -Enabled||Add Global ID||UNIQUE||UUID_<regid>||GLOBALID, GBD_TO_DATE|
|Non-versioned||w/Global ID||Register as Versioned||UNIQUE||UUID_<regid>**||GLOBALID|
|Non-versioned||w/UUID||Register as Versioned||NO||NEW||INDEX|
|Non-versioned||w/Global ID and irregularly-named index on Global ID||Register as Versioned||UNIQUE||IRREGNAMEDINDEX**||GLOBALID|
|Versioned||Add Global ID||UNIQUE||UUID_<regid>**||GLOBALID|
|Versioned||w/Global ID||Enable Archiving||UNIQUE||UUID_<regid>***||GLOBALID|
|Versioned||Archive -Enabled||Add Global ID||UNIQUE||UUID_<regid>**||GLOBALID|
|Non-versioned||w/Global ID and db unique constraint||Register as Versioned||UNIQUE||UUID_<regid>**||GLOBALID|
*** H table is created and gets NONUNIQUE index on GLOBALID column
Why has this changed?
Unique index creation on Global ID columns is in direct response to data corruption cases. This change ensures duplicate Global IDs do not populate the base table during operations on versioned and non-versioned archive-enabled classes. Operations such as sync and replication have a dependency on the uniqueness of Global IDs, and enforcing unique Global IDs at the database is a strong preventative step to potential duplication problems.
The cost of this data integrity is the amount of time spent at index creation (Add Global ID / Register As Versioned / Enable Archiving). The underlying DBMS platform is now asked to create a new, larger structure. Additionally, some DBMS platforms require that remaining indexes on the table must also be rebuilt.