Data storage considerations for ArcGIS Server

When deploying ArcGIS Server, you need to choose where to place the source data for your GIS services. This topic discusses some appropriate scenarios for using ArcSDE geodatabases and file geodatabases.

When to use ArcSDE versus file geodatabases

It is generally recommended that you use an enterprise ArcSDE geodatabase to maintain the source data for your services. ArcSDE offers high-availability support, backup and recovery, concurrency, scalability, and a tendency to provide superior throughput. However, this recommendation is provided with the assumption that your organization has a dedicated database administrator (DBA) to optimize, tune, and maintain the enterprise ArcSDE geodatabase.

If your organization does not have a DBA on staff and your published data is relatively static, then using a file geodatabase may be a good alternative. File geodatabases generally provide great performance without needing extra configuration or tuning. Depending on the characteristics of the GIS data, in some cases, extra optimization and tuning of an enterprise ArcSDE geodatabase might be required to surpass the performance of a file geodatabase.

Before you choose to use a file geodatabase, remember that some functionality of ArcSDE geodatabases, such as versioning, geodatabase replication, and historical archiving, are not available in file geodatabases. Also, standard DBMS capabilities such as logging, backup and recovery, and failover configuration are not available in file geodatabases.

Considerations for file geodatabases

When you use a file geodatabase as a data source, you should place an identical copy of the file geodatabase on each SOC machine. For example, for a distributed ArcGIS Server deployment with three SOCs on different servers, each SOC should access its own copy of the file geodatabase. The SOCs should not access the same file geodatabase over the network.

This configuration minimizes network communication traffic among the different ArcGIS Server components and reduces I/O contention when accessing the file geodatabases. Factors that influence potential disk I/O contention for a shared file geodatabase include the number of layers in the map service, the nature of the data in the file geodatabase, and the file storage device.

File geodatabases work well when accessed in read-only mode by concurrent processes, but they remain locked for editing while under heavy use. Because of this, in scenarios where the file geodatabase is a publication geodatabase (in one-way replication workflows), replica synchronization needs to occur during periods of inactivity in the map service or by releasing the file geodatabase from being used by the map service. Releasing the geodatabase can be done by stopping the service or, for multiple-SOC deployments, by temporarily disconnecting the SOC machines from the SOM, then reconnecting them after the file geodatabase has been updated.

File geodatabases and map caching

File geodatabases work well for map caching scenarios. By placing an identical file geodatabase on each machine working on the cache, you can eliminate the many calls to the ArcSDE database that would need to occur across the network. This can lighten the load on your database and speed up the caching.

You can use one-way replication from ArcSDE to create these file geodatabases. You can even replicate into the projection of the map that will be cached. A common example is caching a Web map in the WGS 1984 Web Mercator (Auxiliary Sphere) projection used by ArcGIS Online, Bing Maps, and Google Maps. This is not usually a recommended projection for storing your enterprise datasets in ArcSDE, but it is a good projection for caching a Web map from a file geodatabase.