We conducted an investigation at the level of our enterprise SQL Server 2022 database because we have faced some wait time situations in the parcel fabric service, where the system stops responding for several minutes (around 40). It has been found that this wait time corresponds to "Resource_Semaphore". The queries causing these waits enforce the limit of parallelism through the hint "MAXDOP 1". MAXDOP refers to "Maximum Degree of Parallelism", which is a SQL Server configuration parameter that impacts query execution and controls the number of processors used for execution, thus affecting performance. "Incorrect MAXDOP settings can lead to performance bottlenecks, particularly with spatial or versioned queries in ArcGIS."
In our database, the value configured at the instance level is 6 for MAXDOP and at the database level, it is 0 (default = no limit).
Several documented bugs apparently related to this:
BUG-000151624 - Add MAXDOP 1 to all branch versioned queries that do not have a spatial or attribute-provided query filter.
- Submitted in 2022 and related to 10.9.1 Utility Network. It was supposedly fixed in patches in 11.1 and 3.1.
BUG-000176188 - ArcGIS Server feature service REST queries set the Maximum Degrees of Parallelism equal to one (MaxDOP =1) which causes long execution times in the database.
- Submitted in May 2025 and found in ArcGIS Server 10.9.1. It references the bug below due to documented duplication.
BUG-000176098 - SQL Server wait event resource_semaphore contention encountered because branch versioned queries on large tables with low selectivity result in the optimizer generating massive memory grants.
- Submitted in April 2025 and updated in July 2025. Supposedly addressed in ArcGIS Pro 3.5.
We recently updated to 11.5 and the database was updated using 3.5 Pro, so we should be up to date at the Enterprise level. However, our team of editors uses AG Pro 3.3.2 due to the problem, bug of the real curves with WMX...
The question is as follows: our database manager recommends creating 2 indexes, one on the records layer and another on the parcels layer. Both touch attributes like GDB_BRANCH_ID, OBJECTID, and even Shape.
We would like to know if there are no problems in creating indexes on our part on database objects, particularly on these system fields, since with the create indexes tool in Pro, which we use every day, at the database level, in the management studio, it is not reflected in these specific fields. If we create these indexes manually in Management Studio, can we further affect performance or even corrupt the data?
Thanks for you help.
Regards,
Diego Llamas