Disable Network Topology takes too long, up to 10 hours

[VishApte_NGIS]

Hi,

I am working with a small-to-mid size Electric Distribution utility running UNM V5 and ArcGIS Enterprise 10.9.1. We have total ~500 HV subnetworks and ~30,000 LV subnetworks.

From time to time we need to disable network topology for UNM version upgrade, update topological rule etc. Every time we try to disable network topology, it takes really long time, between 3 hours to 10 hours. ArcGIS Pro machine is barely busy during this time and so is SQL Server 2022 where the UNM model is hosted.

We tracked SQL queries and it seems to inserting records in various tables such as ElectricSubnetLine, UN_xxxxx_SUBNETWORKS etc. Example below:

(@P1 smallint,@P2 nvarchar(255),@P3 datetime2,@P4 datetime2,@P5 int,@P6 int,@P7 datetime2,@P8 int)INSERT INTO SDO.ELECTRICSUBNETLINE (OBJECTID,SUBNETWORKNAME,TIERNAME,SUBNETWORKCONTROLLERNAMES,LASTUPDATESUBNETWORK,LASTACKEXPORTSUBNETWORK,SHAPE,GLOBALID,CreatedBy,CreationDate,ISDIRTY,LastUpdatedBy,LastUpdatedDate,GDB_GEOMATTR_DATA,GDB_FROM_DATE,GDB_BRANCH_ID) SELECT OBJECTID,SUBNETWORKNAME,TIERNAME,SUBNETWORKCONTROLLERNAMES,LASTUPDATESUBNETWORK,LASTACKEXPORTSUBNETWORK,SHAPE,GLOBALID,CreatedBy,CreationDate,@P1,@P2,@P3,GDB_GEOMATTR_DATA,@P4, @P5 FROM SDO.ELECTRICSUBNETLINE WHERE GDB_ARCHIVE_OID IN (SELECT GDB_ARCHIVE_OID FROM (SELECT GDB_ARCHIVE_OID ,ROW_NUMBER() OVER (PARTITION BY OBJECTID ORDER BY GDB_FROM_DATE DESC) rn,GDB_IS_DELETE FROM SDO.ELECTRICSUBNETLINE WITH (INDEX(gdb_ct1_1183))  WHERE OBJECTID= @P6 AND ((GDB_BRANCH_ID = 0 AND GDB_FROM_DATE <= @P7) OR GDB_BRANCH_ID = @P8)) MB_  WHERE rn = 1 AND GDB_IS_DELETE = 0)  OPTION (MAXDOP 1)

SQL Server instance has not shown any stress while the disable tool is running. Is the time taken for disabling network topology expected to be that long (~10 hours)? How can we expedite this? 

Thanks, 

Vish

[JohnAlsup]

Many things could cause this.  

First, are you using a Service or Database Connection?

If a database connection, are you on the same subnetwork as the database?  If not, this may be the cause.

If you are, then what database RDBMS is this?

It could be a RDBMS resource issue, such as disk performance, memory constrains, etc.

There have been many improvements to this process in more recent releases.  It could be this issues has been addressed in current software.  Not all of these changes can be back ported.  If you are using a database connection, you could try using a current ArcGIS Pro client to see if this resolves the issue.

[GrahamWood-HWC]

We’re having a very similar issue that impacts our ability to introduce changes overnight. We have about 10000 subnetworks.
I think branch versioning creates a pretty big overhead on the subnetworks too.