Apply Asset package remains completely frozen after running for hours

JürgenBiendara

Hi all,

As part of our customer's UTforArcGIS to UtilityNetwork migration, the data is being prepared in an Asset Package. Due to the large amounts of data and two independent source databases (north/south), separate APs are created for each domain and database. These must now be integrated into a central AzureSQL Enterprise GDB.

We have already tested various technical approaches for this:

• Apply Asset Package
• Append via GeoToolbox
• Append via ArcPY
• Direct filling via FME and ESRI Geodatabase SDE Writer

In all cases, we can successfully load data except for the UN FC. With the UN FC, performance drops so significantly that line FCs such as GASLine are not  loaded.

The EGDB has already been freshly set up again and started directly with Stage Utility Network and Apply Asset Package (see attached log).

Here is an overview of the amount of data we are currently trying to load into the UN:

During the overall migration, many times the number of objects shown above will need to be transferred.

The software currently in use can be found in the attached log file. As you can see from this, the loading process for the GASLine feature class has stalled and has not yet been completed. No GASLine objects have arrived in the database yet. GASDevice had a loading time of over 6 hours, while GASJunction took over 7.5 hours (even though GASJunction has even more objects than GASLine).

We have no idea what could be causing these long runtimes and the process to get stuck and would appreciate any idea/help on how we can get the data into the database. How can we get to the bottom of the runtime problem, or are there any known bottlenecks when using Apply Asset package?

Thanks and best regards,
Jürgen

ApplyAssetPackageLog.txt

KatieSmith_0-1741714924223.jpeg

GIS_kiwi4

@JürgenBiendara  – We used FME to load data into the enterprise geodatabase after running the Stage Utility Network tool.

I can’t say for certain if that’s the case here, but we noticed performance was significantly better when the process was executed “closer” to the enterprise geodatabase.

For example, running ArcGIS Pro on a laptop with an SDE connection to Azure was extremely slow. Once we switched to running ArcGIS Pro directly on the Portal server (via remote desktop), performance improved considerably.

Also quite interesting to see the log that all the other feature classes were quick to write even though they have similar number of features.

Just wondering if you can try just loading Electric Devices when you apply asset package next time so as to test if it actually needs 7 hours. 

Longshot but also worth checking if SQL Server is not resources constrained (IOPS, CPU, RAM etc) .
Any logs on the SQL server that might point to any errors?

Also worth checking are the settings on SQL side of things like data and log autogrowth, etc.