Can you sync one layer in your datastore on Enterprise Portal?

592
6
02-05-2021 07:43 AM
CarrieZind1
New Contributor II

When I add new layers to the SDE I always have to go to the Datastore > Layers > Sync for the new layer to be available on Portal. The sync takes a long time to complete. Is there an easier or quicker way to do this so that the layer is available sooner?

0 Kudos
6 Replies
jcarlson
MVP Regular Contributor

I don't think you can, unfortunately. I don't see anywhere in the docs where a subset of layers can be published, only that the whole thing gets refreshed. Starting in 10.8.1, it became possible to publish a single dataset, but right now it only applies to scene services, not really applicable to this situation.

The only way I can think of to get around this issue would be to organize your data on the back end, either with multiple schemas or SDEs.Does all your data need to be in a single SDE, or might it be possible to separate them into multiple SDEs?

We had a few non-spatial tables that were updated by a script, and we put those into its own schema on the SDE, then published the layers from that schema separately. But if you are publishing your datastore layers from the main "sdo" connection, that won't help you, as sdo can see layers in other schemas.

- Josh Carlson
Kendall County GIS
CalvinLietz
Esri Contributor

Hi Carrie,

As Josh said above, there is currently no way to select which layers you want to include when you publish layers in bulk from the data store item in Portal. If you are interested in publishing just a single service to your organization, I would recommended taking a look at one of the publishing workflows from a desktop client, such as ArcGIS Pro and ArcGIS for Desktop.

https://desktop.arcgis.com/en/arcmap/latest/map/publish-map-services/publishing-a-map-service.htm

https://pro.arcgis.com/en/pro-app/latest/help/sharing/overview/introduction-to-sharing-web-layers.ht...

-Calvin

CraigRussell
Esri Contributor

It is worth noting that while I think being able to just add a single feature class has merit, the idea of the synchronization in this context is to add new layers, remove layers where access has been revoked, and (from 10.8.1 onwards) update schemas and item details.

@jcarlson has touched on this, but if you're going to invest in bulk publishing layers from registered data stores (and I think most organizations should), then it is well worth looking at implementing database/permissions structures to complement the feature and its intended use.

I guess something to ask is what is "a long time to sync"?  How many layers from your enterprise geodatabase are you trying to sync?

0 Kudos
CarrieZind1
New Contributor II

It takes about 30 minutes and up to an hour and always fails. I think the error message is,
"failed to complete: something went wrong." There are about 65 layers.

0 Kudos
CraigRussell
Esri Contributor

I tested adding a new feature class to a registered geodatabase in ArcGIS Enterprise 10.8.1 which already had 50 feature classes and the sync only took around 30 seconds.  ArcGIS Server and the DB are on the same machine so there's zero latency, but that's still a significant difference in processing time.

A couple of things to check...

If any of the datasets that you're syncing participate in relationship classes, then the related data must also be synchronized as well, so the connecting user requires view privileges on both (I think I've seen this problem produce your error before).

Also, check the documentation field size in the GDB_Items table in your database using this query:

SELECT [ObjectID]
      ,[Name]
      ,DATALENGTH([Documentation])/1000 as DocumentSize_KB
	  ,[Documentation]
      ,[ItemInfo]
      ,[Shape]
      ,[ContingentValues]
  FROM [DATABASE].[sde].[GDB_ITEMS]
  ORDER BY DATALENGTH([Documentation]) desc

CraigRussell_1-1613537816321.png

Whenever you run tools against feature classes or geodatabases, the execution of that tool creates a lineage record in the XML:

CraigRussell_2-1613537881807.png

This article describes how to delete the geoprocessing history from both the workspace and feature class XML - How To: Delete geoprocessing history from a geodatabase (esri.com)

XML around 1Mb can cause a little bit of slowness, anything over 10Mb can cause serious problems.  I haven't encountered any scenarios where I've seen this directly affect the layer syncing process, but it is looking at the metadata (which comes from this documentation XML) so it could potentially be a factor.

0 Kudos
CarrieZind1
New Contributor II

This is no longer an issue anymore. It now takes about 30 seconds so I have just been resyncing if I add a new layer. I didn't do anything but I think our server manager made some changes that had positive impact. Thanks for everyone's help!

0 Kudos