If you don't need the web services you publish to access your source data, ArcGIS Server can copy the service data when you publish. The copy of the data is placed in a location that is accessible to the ArcGIS Server site.
Copying data when you publish can be useful when your source data is behind a firewall but the web services are not. It can also help you keep your internally edited datasets separate from the ones you make available through web services. Copying the data ensures that the service you publish (for example, a map service) will have no trouble accessing its source datasets.
Several factors affect whether ArcGIS Server copies the data and, if it does copy, where it places the data. For example, when you publish to a stand-alone or federated ArcGIS Server site from ArcMap, data is automatically copied if your data source is not registered with your ArcGIS Server site. The copied data is placed in a folder on one of the ArcGIS Server machines. The exception to this is if your ArcGIS Server site has a managed database and you publish a feature service or WFS-T service; in that case, the data is copied to the managed database.
Automatic data copying was introduced prior to the introduction of hosted web layers and before ArcGIS Pro existed. Therefore, the workflows described in this topic cover publishing from ArcMap to an ArcGIS Server site.
When you publish from ArcGIS Pro, you choose to reference registered data or copy data when you publish. If you choose to copy data, a hosted web layer is always created; therefore, the workflows described in this topic do not apply.
Before copying your data when publishing from ArcMap to an ArcGIS Server site, examine the following scenarios and consider how your workflows relate.
If the data you want to copy does not require an enterprise geodatabase
If the data you want to copy to the server does not require an enterprise geodatabase, ignore the data source is not registered with the server and data will be copied to the server warning in the Prepare window (or mark it as an exception) and publish the service. Your data is automatically copied to files or a file geodatabase on one of the ArcGIS Server machines. No further action is required on your part.
When to use automatic data copying when working with a cloud-based server
Copying data to the server can be convenient when your ArcGIS Server site is running in a cloud environment such as Amazon Web Services or Microsoft Azure and you cannot or do not want to log in to the cloud machine. In the cloud, the server needs its own copy of the data because it would be inefficient and in some cases impossible for it to retrieve the data from your machines on premises. This method of copying the data is convenient; however, if you publish many services that use the same datasets, it can cause duplicate data to accumulate on the server.
When to use automatic data copying when working with an on-premises server
If you don't have log-in rights to your on-premises ArcGIS Server machines, automatic data copying can allow you to still be successful at publishing services.
You also might decide to copy the data in this manner if you want to publish a snapshot of your dataset. For example, suppose that you have a geodatabase that is constantly being modified by dozens of editors. Every month, this data goes through a quality assurance process to make sure that it meets your organization's data integrity standards. You want to publish the data only if you know it has met the standards.
After quality checking your data, you can publish and have the data copied to the server. This ensures that your web users see the quality-checked data while allowing your editors to continue making changes to your working geodatabase each day. Every month, following the quality assurance process, you can republish the copy of the data on the server by overwriting the service.
If the service type you want to publish requires an enterprise geodatabase
If the service type you want to publish requires an enterprise geodatabase, you must first create an enterprise geodatabase and register it as the ArcGIS Server site's managed database. When you publish feature or transaction-enabled WFS (WFS-T) services, the data referenced by your GIS resource is copied into this enterprise geodatabase.
When to use this scenario
Use this scenario to publish feature services or WFS-T services. When you publish, ArcGIS Server automatically places a copy of your data in the managed database, since these service types explicitly require an enterprise geodatabase. The managed database can only be used with feature or WFS-T services, along with any capabilities concurrently published with these service types. For example, you can publish a feature service with the KML capability enabled, but you cannot solely publish a KML service and copy the data to the managed database. You can only use a managed database with a stand-alone or federated ArcGIS Server site, only one geodatabase can be registered to fill this role, and you cannot synchronize changes between the managed database and your data source.
This scenario can also be used when your ArcGIS Server site is running in a cloud environment such as Amazon Web Services. For example, the cloud server needs its own copy of the data because it would be inefficient and in some cases impossible for the feature or WFS-T service to retrieve the data from your machine on premises. In this case, you avoid having to log in to the cloud machine, since the data is automatically copied to the managed database when publishing.
Once published, you and your users should only work with the data exposed by the feature or WFS-T service. If you want to update the data in the managed database, you can add the feature or WFS-T service to ArcMap and use the local editing commands to upload the new data. Additionally, you'll need to overwrite your service before clients can see the changes on the web.
Each service that you publish contains its own copy of the data in the managed database. If you publish another service that uses the same source datasets, you will have two copies of the dataset in the managed database.
The lifetime of the data in the managed database is directly controlled by the lifetime of the service. For example, if you delete the service, the data it references in the managed database will be deleted. If you want to save your data before deleting the service, you can use the tools in ArcGIS Desktop to export the enterprise geodatabase data into a file geodatabase that you can transfer to your local machine.
When using this scenario, keep in mind the following:
- You must explicitly create an enterprise geodatabase before registering it as the ArcGIS Server site's managed database.
- A managed database must be an enterprise geodatabase (file geodatabases are not permitted).
- You can only register a managed database with a stand-alone or federated ArcGIS Server site. You cannot use this federated server as an ArcGIS Enterprise portal's hosting server.
- Only one managed database is allowed per ArcGIS Server site.
- ArcGIS Server must have access to the enterprise geodatabase.
- Registering an empty geodatabase is permitted.
- The data in the feature service or WFS-T service you want to publish can originate from anywhere (for example, a shapefile or a file geodatabase).
- Deleting the service deletes the service's data.
- Whenever you update your data source and want the change reflected in the service, you must overwrite the service to update the dataset or datasets in the managed database.
When to not use this scenario
- If you want to publish a service type other than a feature or WFS-T service.
- If your data already resides in an enterprise geodatabase.
- If you want to publish database tables accessed through an OLE DB connection file (.odc)
- If you want to synchronize changes between the publisher's machine and the managed database.
Best practices for data copying
Large copy jobs may take several hours or longer to complete. Clients can continue to use other services on your server while copying occurs.
To avoid copying an excessive amount of data, a best practice is to keep the full extent of your data frame no larger than necessary. For example, if you have a dataset that covers the world, but your map service only needs to be used in a single country, set a custom full extent on your data frame to enclose just the country of interest. For full instructions, see Setting a custom full extent for your Data Frame.
Similarly, examine whether there are any nonessential layers in your map service that could be removed before you copy. For services with an enormous amount of source data, you might choose to manually move the data to the server to avoid duplicating data.
Whenever copying data to the server, ensure that the ArcGIS Servermachine or managed database machine has enough available disk space to receive the copy. This space may be larger than you anticipate if you fail to account for the size of all the layers in the service at the full extent of the service.
Copying OLE DB data sources
OLE DB connections provide uniform access to data from a variety of sources, but are nonspatial connections. If your data originates from database tables accessed through an OLE DB connection file (.odc), the OLE DB data sources are copied to the server and converted to file geodatabase tables.
Datasets that cannot be copied
Some types of data cannot be copied to the server as part of the publishing process. These include selection layers, custom layers, video layers, and tool layers.
Disabling data copying
If you're an ArcGIS Server administrator and you want to prevent publishers from automatically copying data to the server when they publish, you can disable data copying using the ArcGIS Server Administrator Directory. For full instructions, see Disable automatic data copying when publishing to the server.