Skip To Content

ArcGIS Data Store command utility reference

Command utilities, installed with ArcGIS Data Store, provide the data store administrator tools to manage data stores. This topic describes the utilities and provides syntax and examples.

All utilities must be run on the ArcGIS Data Store machine. You can find the utilities in the <ArcGIS Data Store installation directory>/datastore/tools directory.

You can type the utility name followed by --help to get syntax assistance.

allowconnection

Used with relational data stores.

For security reasons, all connections to the data store are made through the GIS Server site by default. If you want to open a relational data store for connections from an additional machine, you can use the allowconnection command utility.

The allowconnection utility can be run on the primary relational data store machine only.

Syntax

allowconnection <host name> <user name> [<database>]

Specify the name of the computer you want to allow to connect to the relational data store (host name) and one of the database accounts used by the data store (user name): either the data store administrator, replica owner, geodatabase administrator, or managed user (the user who publishes feature layer data), which you can obtain using the listadminusers or listmanageduser utility. You can also specify the name of the primary relational data store database but, since there is only one, this value is optional.

Example

In this example, a connection is allowed from the workcom computer to the relational data store when connecting as the hqo.n_1E7 managed user.

./allowconnection.sh workcom hqo.n_1E7

backupdatastore

Used with relational, tile cache, and spatiotemporal big data stores.

If you need to create a relational data store backup between scheduled backup times, use the backupdatastore utility. Use this utility to manually create a full backup prior to upgrading the data store or before making a large number of changes to the data store.

The first time you run the backupdatastore utility for a tile cache data store, backup copies are made of all existing tile cache data store databases. Subsequent use of the backupdatastore utility creates backup copies of any tile cache data store databases created since the last time you ran the utility.

The first time you run the backupdatastore utility for a spatiotemporal big data store, a full backup is created. Since spatiotemporal big data stores can be very large, subsequent use of the backupdatastore utility creates a backup file containing only the changes since the initial full backup.

The backupdatastore utility can be run on the primary relational or tile cache data store machine. This utility can be run from any machine that is a member of your spatiotemporal big data store.

In all cases, be sure your backup location is large enough to accommodate your backups. To change data store backup locations, use the configurebackuplocation utility.

Syntax

backupdatastore [<backup name>] [--store {relational|tileCache|spatiotemporal}] [--prompt <yes | no>]

Example

In this example, a full backup file named project1bu is created in the backup location you specified for the data store using the configurebackuplocation utility. By default, backups are created for relational data stores; therefore, in the following example, a relational data store backup is created.

./backupdatastore.sh project1bu

You are going to back up the data store. This could take some time, depending on the size of your data store.
Please do not interrupt the process once it has started.

Do you want to continue (Yes or No)?Yes

In this example, a backup is created of a spatiotemporal big data store, and the backup file created is named spds311016:

./backupdatastore.sh spds311016 --store spatiotemporal

You are going to back up the data store. This could take some time, depending on the size of your data store.
Please do not interrupt the process once it has started.

Do you want to continue (Yes or No)?Yes

changebackuplocation

Used with relational data stores.

Legacy:

Esri has deprecated the changebackuplocation utility. It is still present to allow existing scripts to continue working, but you should start using the configurebackuplocation utility with the change option instead.

Relational data store backup files are stored on the same machine as the data store by default. You should move your backup files to a separate machine to ensure you can access them if the machine where ArcGIS Data Store is installed is inaccessible.

Be sure the login that runs the changebackuplocation utility has read and write permissions on the shared directory.

The changebackuplocation utility only applies to backups created for a relational data store.

Syntax

changebackuplocation <new directory path> [--is-shared-folder <true|false>] [--keep-old-backups <true|false>]

Specify --is-shared-folder true if the backup location is on a shared network machine. If you want existing backup files to be moved to the new location, specify --keep-old-backups true.

changedatastoremode

Used with relational data stores.

The changedatastoremode utility allows you to place a relational data store in read-only mode while you perform maintenance on the data store. For example, if you need to perform a maintenance task that will cause the data store to restart, such as changing the backup location from one drive to another drive or changing database properties, you could place the relational data store in read-only mode so no users are in the process of publishing or editing data when the data store restarts.

The changedatastoremode utility is also used to place the relational data store back in a read-write mode after you finish maintenance or after you add enough disk space to the primary data store machine to allow the data store to function properly in read-write mode.

The changedatastoremode utility can be run on the primary relational data store machine only.

Note:

If ArcGIS Data Store placed your relational data store in read-only mode due to insufficient disk space, automatic backups were also disabled to avoid filling the disk further. Therefore, you will also need to reset your automatic backup schedule using the updatebackupschedule utility after you place the relational data store back in read-write mode.

Syntax

changedatastoremode readonly|readwrite [--prompt <yes|no>]

Example

In this example, the relational data store is placed back in read-write mode, meaning clients can resume such activities as publishing hosted feature layers to the portal, editing data through a hosted feature layer, or adding CSV files to the portal map viewer.

./changedatastoremode.sh readwrite --prompt no

changedbproperties

Used with relational and spatiotemporal big data stores.

The changedbproperties utility allows you to change different properties depending on the type of data store you run it against.

Syntax

changedbproperties --store <relational | spatiotemporal> [configuration operations]

Supported configuration operations:

  • disk-threshold-readonly: This setting controls when a relational data store will be placed in read-only mode to avoid loss of data due to insufficient disk space. The default disk space value is 1024 MB. Specify sizes in MB.
  • max-connections: Use this parameter to specify the maximum number of connections allowed to a relational data store. Relational data stores accept up to 150 connections by default. You can use the --max-connections property with the changedbproperties utility to change the number of connections allowed. When determining how many connections your data store requires, take into consideration that ArcGIS Data Store internal processes can take up to five connections. Also consider how many concurrent connections your ArcGIS Data Store machine can accept and continue to perform well. If the machine running ArcGIS Data Store doesn't have a lot of memory, you may need to decrease the number of connections allowed.

    The number specified cannot be smaller than 10. When you change the maximum number of connections allowed, the number is changed on both the primary and standby data store machine. This parameter is not supported for spatiotemporal big data stores or tile cache data stores.

  • pitr: This setting determines if ArcGIS Data Store will create incremental backups of the relational data store, thereby allowing you to recover the relational data store to a point in time. Possible inputs for this option are enable or disable. Point-in-time recovery is disabled by default.
    Note:

    You must enable point-in-time recovery if you will use the webgisdr utility to create backups of your ArcGIS Enterprise deployment.

    This option is new in ArcGIS Data Store 10.5.1.

  • heap-size: Use this parameter to change the amount of heap memory (in MB) used by a spatiotemporal big data store. By default, this type of data store will use half the available RAM when it starts. This parameter is not supported for relational or tile cache data stores.
  • rebalance: By default, this parameter is set to true, which means data in a spatiotemporal big data store will distribute data to other machines if any one machine is unavailable. If you need to perform maintenance on one spatiotemporal big data store machine, such as upgrading it, you can temporarily shut off rebalancing by setting this parameter to false. Rebalance will be suspended for the amount of time set for the max-rebalance-off parameter. This parameter only applies to spatiotemporal big data stores.
    Legacy:

    In ArcGIS 10.4.x, this option was reallocation.

  • max-rebalance-off: The setting for this parameter is used when you set the rebalance parameter to false. By default, max-rebalance-off is set to 60 minutes. That means, if you temporarily shut off rebalancing, it will start again after 60 minutes. If you need more or less time than that perform the maintenance task for which you suspended rebalancing, change the time setting for max-rebalance-off. This parameter only applies to spatiotemporal big data stores.
    Legacy:

    In ArcGIS 10.4.x, this option was max-allocation-off.

  • prompt: When you run this utility, you are prompted to confirm the action you specified. If you automate the use of this utility, set the prompt parameter to false; otherwise, the script will not proceed until you answer the prompt.

Example

In this example, the number of maximum connections allowed to a relational data store is set to 100:

./changedbproperties.sh --store relational --max-connections 100

You are changing the following database properties:
         max number of connections to 100 (on all relational data store machines)

Changing database configurations could cause the database to restart. Please do not interrupt the process once it has started.

Do you want to continue (Yes or No)?Yes

In this example, the max-rebalance-off operation is used to set to 15 the number of minutes the spatiotemporal big data store will automatically change rebalance to true.

./changedbproperties.sh --store spatiotemporal --max-rebalance-off 15

changeloglocation

Used with relational, tile cache, and spatiotemporal big data stores.

If you do not want the data store to use the default error log file location of <ArcGIS Data Store installation directory>\arcgisdatastore\logs, you can run the changeloglocation utility to create error log files in a different directory.

Syntax

changeloglocation <directory path>

Example

In this example, log files will be created in the local directory, ../datastorefiles/logs.

./changeloglocation.sh '../datastorefiles/logs'

changenosqldslocation

Used with tile cache data stores.

Tile cache data stores can get large if you store a lot of high-resolution tiles in it. In those cases, you might want to move the data to another drive on the same server or to a shared location on a different server.

If you move the data to a shared directory, you must grant read and write permissions on the directory to the user running the ArcGIS Data Store process (Linux) or service (Windows).

Syntax

changenosqldslocation <path> [--prompt {yes | no}]

Example

In this example, the databases that store scene layer caches will now be created in a shared directory named dstorecache on machine server2.

changenosqldslocation /net/server2/dstorecache

changepassword

Used with relational data stores.

ArcGIS Data Store randomly generates user names and passwords for the database accounts used for relational data stores. If your site requires you to set your own passwords, obtain the passwords for data store accounts, and run changepassword to reset passwords.

Use the listadminusers utility to get user names and passwords for administrator users and the listmanageduser utility to get the user name and password for the feature data owner.

The changepassword utility can be run on the primary relational data store machine only.

Syntax

changepassword <user name> <new password> [--prompt {yes | no}]

Tip:

If you need to script password changes, include a flag to suppress the confirmation prompt, as in the following example:

changepassword gwi_n2Te0 Phfl4mp! --prompt no

Example

In this example, the password is changed for user gwi_n2Te0 to Phfl4mp!.

./changepassword.sh gwi_n2Te0 Phfl4mp!

You are going to change the password for user gwi_n2Te0.
Do you want to continue (Yes or No)?Yes

changestaginglocation

Used with relational data stores.

When you restore your relational data store, ArcGIS Data Store extracts the compressed backup files on a staging location. That means you need to have a staging location that can accommodate this uncompressed data. If you have a lot of data in your relational data store, you might want to set up a separate staging location and specify that for recovery.

Syntax

changestaginglocation <directory path>

Example

In this example, the designated staging location is /net/sanmarcos/stage.

./changestaginglocation.sh /net/sanmarcos/stage

configurebackuplocation

Used with relational, tile cache, and spatiotemporal big data stores.

The configurebackuplocation allows you to specify the location to which ArcGIS Data Store will write backup files. This command also allows you to remove the backup location if you no longer require ArcGIS Data Store backups.

Relational and tile cache data stores are created with a default, local backup location. Use the change operation to specify a more secure backup location for relational data stores.

Spatiotemporal big data stores are not created with a default location. Before you can begin creating backups, you must run the configurebackuplocation utility with the register operation to specify a shared network location for these backups. Spatiotemporal big data stores require a shared network location; you cannot use a local drive for these backup files.

Syntax

configurebackuplocation --location <backup_location> [operations]

Supported operations are as follows:

  • --store <relational|tileCache|spatiotemporal>: The default value is relational.
  • --operation <change|register|unregister>: The default value is change.
  • --prompt <yes | no>: The default value is yes.

The register and unregister operations are used with spatiotemporal big data stores only.

If you do not specify the --store operation, relational is assumed.

Note:

The location operation is required if you specify the register or change operation.

Examples

In the first example, the backup location for a relational data store is set to a directory named fsdata_bu on a machine named myshare.

./configurebackuplocation.sh --operation change --store relational 
--location /net/myshare/fsdata_bu

You are going to change the backup location of the data store. Existing backups will be copied to the new location and it could take a few moments.
Please do not interrupt the process once it has started.

Do you want to continue (Yes or No)? Yes

In this example, a backup location on a network share is registered for a spatiotemporal big data store.

./configurebackuplocation.sh --operation register --store spatiotemporal 
--location /net/sharedmachine/ge_bu

configuredatastore

Used with relational, tile cache, and spatiotemporal big data stores.

After you install ArcGIS Data Store, you can run the configuredatastore utility to create a data store and register it with an GIS Server site. You can create the following types of data stores using this command:

  • A data store for your hosted feature layer data (relational data store)
  • A data store for hosted scene layer tile caches (tile cache data store)
  • A data store for the data created when you run GeoAnalytics Tools or a data store to archive observational data from an ArcGIS GeoEvent Server (spatiotemporal big data store)

You can also run the configuredatastore utility to reconfigure a data store after upgrading it.

Syntax

configuredatastore <ArcGIS Server admin URL> <ArcGIS Server administrator> <ArcGIS Server administrator password> <data directory> [--stores <relational|tileCache|spatiotemporal>] [--nosql-only true|false]

The ArcGIS Server admin URL is in the format https://gisserver.domain.com:6443/arcgis. Note that even if your GIS Server site uses a web adaptor, provide the URL in the aforementioned format.

Provide the user name and password for a built-in (not enterprise) user who has administrator privileges in the GIS Server site.

The data directory is the location on the local machine where you want the data store files to be created.

Though it is not recommended, you can configure more than one type of data store on the same machine by specifying each store type separated by a comma (no spaces). For example, to configure both a relational and tile cache data store on the same machine with a shared data store directory, specify --stores relational,tileCache. Esri strongly recommends you run spatiotemporal big data stores on machines separate from other data stores or software.

Legacy:

In previous releases, you would specify the --nosql-only operation set to true to create a data store only for scene layer cached tiles. This operation is still present so existing scripts continue to function. In future, use the --stores operation set to tileCache instead.

Configure a specific type of data store

You can configure an ArcGIS Data Store for hosted feature layer data by specifying relational with the --stores operation.

To publish a hosted scene layer, you need a data store for scene caches and a data store for hosted feature layer data because ArcGIS creates a hosted feature layer, hosted scene layer, and scene cache when you publish a hosted scene layer. You can either specify relational,tileCache with the --stores operation to configure both types of data store, or specify only tileCache with the --stores operation and use your own managed database as the data store for hosted feature layer data.

Note:

Be aware that if you use your own managed database for hosted feature layer data, you cannot use ArcGIS Data Store tools to administer the database. In other words, you manage users and backups using tools available with your DBMS. You also cannot take advantage of high availability functionality offered through ArcGIS Data Store, and the hosted feature layers you publish to your portal will not have as much functionality nor be as scalable as the hosted feature layers created when your hosting server uses a relational data store.

If you use the ArcGIS GeoEvent Server and want to store high volume and high velocity observational data, create a spatiotemporal big data store by specifying spatiotemporal with the --stores operation.

See the ArcGIS GeoEvent Server help for more information on working with spatiotemporal big data stores.

If you want to use GeoAnalytics Tools in the portal map viewer or from ArcGIS Pro, create a spatiotemporal big data store by specifying spatiotemporal with the --stores operation.

Note that if you script the creation of multiple spatiotemporal big data store machines, one spatiotemporal big data store must be configured with the GIS Server before you can script creation of additional spatiotemporal big data store machines.

You can create more than one type of data store on the same machine or even create all three types of data store on the same machine; however, Esri does not recommend this, as the data stores will compete for memory and other resources, negatively affecting performance.

Example

In this example, a data store for hosted feature layer data (relational data store) is created. The URL for the GIS Server site that will use the data store is https://dataserver.mydomain.com:6443/arcgis, the site administrator user name and password are admin and Iph33l$ik respectively, and the data directory for the data store is /dstore/data

./configuredatastore.sh https://dataserver.mydomain.com:6443/arcgis admin Iph33l$ik /dstore/data --stores relational

deletebackup

Used with relational data stores.

The deletebackup utility allows you to delete backup files you created for relational data stores. First, run the listbackups utility to see the names and creation times of your manual backups. You can then run the deletebackup utility to delete the manual backup you no longer need.

Note that you can only delete backups that are not required to recover your data store. For example, you cannot delete the most recent full backup of a relational data store.

Syntax

deletebackup <backup name> [--prompt <yes | no>]

Example

./deletebackup.sh featuresMarchbu
You are attempting to delete backup 'featuresMarchbu'. This operation is irreversible.

Do you wish to continue (Yes or No)?yes

Operation completed successfully

describedatastore

Used with relational, tile cache, and spatiotemporal big data stores.

The describedatastore utility allows you to see the following information about an ArcGIS Data Store installation:

  • The software release number for the ArcGIS Data Store installation
  • The staging location used by the data store for restoring
  • The log file location for the data store
  • The amount of available disk space left on the machine where ArcGIS Data Store is installed
  • The free disk space threshold at which a relational data store will be placed in read-only mode and tile cache and spatiotemporal big data stores will be stopped
  • Backup locations used by each type of data store
  • Whether the relational or tile cache data store backup location is on a network share
  • How often a backup is created of the data store (Backup schedule)
  • How many days relational data store backup files are retained
  • Whether or not the data store is running (Data store status)
  • The date and time that the standby relational or tile cache data store became the primary data store (Last failover); not displayed if failover has never occurred
  • The names of the machines that participate in the relational or tile cache data store (Member machines)
  • Maximum connections allowed to a relational data store
  • The URL of the GIS Server site with which the data store is registered (Owning system URL)
  • The URL of the portal that is using the GIS Server site as its hosting server (Portal URL)
  • The number of current feature layer connections to the relational data store
  • A list of all machines currently participating in the spatiotemporal big data store (Machines in spatiotemporal cluster)
  • The machine within the spatiotemporal big data store that is currently designated the master machine (Current master machine in cluster)
  • A list of all machines in the spatiotemporal big data store cluster (Registered spatiotemporal machines); shows all machines in cluster regardless of their status

Syntax

describedatastore

Example

The describedatastore utility returns general information that applies to all data stores on a machine and returns specific separate sections that contain information specific to each type of data store.

Although you will likely have different data stores on different machines, the following output shows a machine with all three types on the same machine so you can see the different sections for each type:

./describedatastore.sh

General Information of ArcGIS Data Store on machine.domain.com
==============================================================
ArcGIS Data Store release....10.5.0.7777
Staging location............./arcgis/datastore/staging
Log location................./arcgis/datastore/logs
Free disk space..............174.00GB
Threshold for READONLY mode..1024MB

Information for relational data store ds_sthiu0_5T
==============================================================
Backup location.........../net/nwshare/dsbackups
Is backup folder shared...true
Backup schedule...........{"schedule-starttime":"00:00:00","schedule-frequency":"Every 7 DAYS"}
Days backup retained......31
Data store status.........Started
Last failover.............20150130190334005
Member machines...........MACHINE1.DOMAIN.COM, MACHINE4.DOMAIN.COM
Maximum connections.......150
Owning system URL.........https://gisserver_webadaptor.domain.com/server/admin
Portal for ArcGIS URL.....https://portal_webadaptor.domain.com/portal
Number of connections.....8 connection(s) to managed database

Information for tile cache data store ds_wztxj7um
==============================================================
Tile cache location......./arcgis/datastore/nosqldata
Data location............./arcgis/datastore/nosqldata
Data store status.........Started
Last failover.............20150130190334005
Backup location.........../arcgis/datastore/backup
Is backup folder shared...false
Member machines...........MACHINE1.DOMAIN.COM
Owning system URL.........https://gisserver_webadaptor.domain.com/server/admin
Portal for ArcGIS URL.....https://portal_webadaptor.domain.com/portal

Information for spatiotemporal big data store ds_qpko99Cl
==============================================================
Max rebalance off time..............60 minutes
Automatic rebalance ................On
Machines in spatiotemporal cluster..MACHINE1.DOMAIN.COM, MACHINE2.DOMAIN.COM, MACHINE3.DOMAIN.COM
Current master machine in cluster...MACHINE1.DOMAIN.COM
Registered spatiotemporal machines..MACHINE1.DOMAIN.COM, MACHINE2.DOMAIN.COM, MACHINE3.DOMAIN.COM
Owning system URL...................https://gisserver_webadaptor.domain.com:6443/arcgis/admin

exportmanageddb

Legacy:

Esri has deprecated the exportmanageddb utility at 10.5.1. The functionality has been incorporated into the backupdatastore utility. The exportmanageddb utility is still present to allow existing scripts to continue working, but you should start using the backupdatastore utility to create a backup file instead, then use the restoredatastore utility to restore the data store from the backup file.

Used with relational and tile cache data stores.

The exportmanageddb utility creates a dump file of the relational data store, metadata about the data store, and all databases that store hosted scene layer tile caches. Export the data store if you need to make a backup to be restored to an ArcGIS Data Store installation that is on a machine with a different operating system or is a different ArcGIS Data Store release.

Be sure no one edits feature layers or publishes to your portal before you import the data store to the new machine. Also be sure the location to which you export the data store contains enough storage space for the relational data store's dump file and copies of all your hosted scene layer tile cache databases.

The exportmanageddb utility does not export spatiotemporal big data stores.

Syntax

exportmanageddb <output location> <backup name> [operations]

The output location is the location on disk where the folder (<backup name>) and exported files will be created. You must have write access to this location.

Supported operations include the following:

  • [--stores {relational|tileCache}]: Indicates which data store type you want to export. If your relational and tile cache data stores are running on the same machine and you want to export both, specify both separated by a comma; for example, type --stores relational,tileCache. If you do not specify the --stores operation, relational is assumed.
  • [--include-tilecache <true|false>]: This operation is present for backward compatibility. If you do not specify the --stores operation or you specify --stores relational, you could control whether the tile cache data store was exported or not using this operation.
  • [--prompt {yes|no}]: Determines whether you must answer a prompt to run the utility.

Example

In the following example, the dump file, copies of the hosted scene layer cache databases, and associated data store files are output to a shared network directory named movedsfirstexp on a server named backupserver. .

./exportmanageddb.sh preupgradeexp /net/backupserver movedsfirstexp --stores relational,tileCache

You are attempting to back up database 'db_e3hsm'. This could take a long time, depending on the size of your data.
Please do not interrupt the process once it has started.

Do you want to continue (Yes or No)?Yes

importmanageddb

Used with relational and tile cache data stores.

If you exported an ArcGIS Data Store containing hosted feature layer or hosted scene layer cache databases (or both), you can use the importmanageddb utility to restore the data store. You can restore to an upgraded ArcGIS Data Store machine or to an ArcGIS Data Store installation on a machine with a different operating system than the source ArcGIS Data Store.

If you want ArcGIS Data Store to be registered with the same GIS Server site it was before, specify --bound true and do not specify a --server-url. Note that --bound is set to true by default. Be sure to restart the GIS Server site after restoring.

If you restore and want to register the data store with a new GIS Server site, specify the --server-url when you import the data store.

By default, the relational data store and all the hosted scene layer cache databases that make up the tile cache data store in the export file are imported. If you do not want to include the hosted scene layer cache databases, specify the --include-tilecache operation set to false.

The importmanageddb utility does not import spatiotemporal big data stores.

Syntax

importmanageddb <source backup location> <backup name> [operations]

Supported operations include the following:

  • [--server-url <ArcGIS Server URL registered with data store>] : If you specify --bound true and have already moved your services to a new GIS Server site, use the --server-url operation to specify the URL of the new GIS Server site. Note, though, unless you have also moved the services to this new server, the data in the data store will not be accessible.
  • [--server-admin <user name of ArcGIS Server admin>]: This operation is only optional if you specify --bound false; otherwise, you must supply the user name of the ArcGIS Server administrator.
  • [--server-password <password of ArcGIS Server admin>]: This operation is only optional if you specify --bound false; otherwise, you must supply the password for the ArcGIS Server administrator.
  • [--data-dir <data store data directory>]: The ArcGIS Data Store directory. By default, this is the ArcGIS Data Store directory of currently registered data stores.
  • [--stores {relational|tileCache}]: Indicates which data store type you want to import. If your relational and tile cache data stores are running on the same machine and you want to import both, specify both separated by a comma; for example, type --stores relational,tileCache. If you do not specify the --stores operation, relational is assumed.
  • [--include-tilecache <true|false>]: This operation is present for backward compatibility. If you do not specify the --stores operation or you specify --stores relational, you could control whether the tile cache data store was restored or not using this operation.
  • [--bound {true|false}]: There are three different scenarios for the --bound operation.
    • If you specify --bound true or do not specify the --bound operation, you must specify the URL of a GIS Server site with the --server-url operation. If you are importing to the same that GIS Server site ArcGIS Data Store was registered with when you exported the data store, specify the URL of that GIS Server site and provide the ArcGIS Server administrator's user name and password. To bind the data store to a new GIS Server site, provide the URL and administrator credentials of this new site.
      Note:

      Only specify information for a new GIS Server site if you have already moved your web services to this new GIS Server site.

    • If your data store will no longer use the previous GIS Server site and you have not yet moved all your services to the new GIS Server site, specify --bound false. You must then run the registerdatastore utility to configure the data store with the new GIS Server site after you move the services to this new site.
  • [--prompt {yes|no}]: Determines whether you must answer a prompt to run the utility.

Example

In the following example, the data store is restored to a newer release ArcGIS Data Store installation. The new ArcGIS Data Store data directory is specified. The data store is still bound to the existing GIS Server site, so the data store and existing hosted feature and scene layers continue to function. Restart your GIS Server site to allow hosted feature and scene layers to be published to the new machine.

./importmanageddb.sh /net/backupserver/expdir preupgradeexp --source-loc  --data-dir /usr/arcgis/datastore 
--server-admin siteadmin --server-password SAup.4s --bound true

In this example, both the GIS Server site and relational data store have been moved to new machines. The web services have already been moved to the new GIS Server site, so the new site's URL is specified with the --server-url operation. The backup name is movedbexp, and it is stored at /net/backupserver/expdir.

./importmanageddb.sh /net/backupserver/expdir movedbexp --data-dir /usr/arcgis/datastore 
--server-admin siteadmin --server-password SAup.4s --stores relational --bound true --server-url https:\\mynewserver.domain.com:6443

In this example, web services have not been moved to the new GIS Server site. The tile cache and relational data stores will not be functional until services are moved and you subsequently register the data store with the new GIS Server site. The backup name is movedsfirstexp, and it is stored at /net/backupserver/expdir/movingexp2.

./importmanageddb.sh /net/backupserver/dbdump/movingexp2 movedsfirstexp --data-dir /usr/arcgis/datastore 
--server-admin siteadmin --server-password SAup.4s --stores relational,tileCache --bound false

listadminusers

Used with relational data stores.

The listadminusers utility returns the user names and passwords for the administrator, replica owner, and geodatabase administrator of a relational data store.

Syntax

listadminusers

Example

./listadminusers.sh

Admin users for relational data store ds_abcd1234
=================================================
Database Admin User.... adm_11zyx / tT30!bYk22jF
Database Repl User..... dsrepuser / uWn/MV0678h4
GDB Admin User......... sde / iO=Qst751*pb

listbackups

Used with relational, tile cache, and spatiotemporal big data stores. When run for relational or tile cache data stores, the listbackups utility only functions on the primary data store machine.

The listbackups utility returns the names of full relational data store backups and the location to which they are written. The listbackups utility also returns the backup status (whether it completed or not), the time the backup started, and whether the backup was created manually using the backupdatastore utility or created automatically by ArcGIS Data Store.

You can run listbackups to see whether a backup completed or is still running, determine how many manual backups you have, or confirm a file name before running the deletebackup utility.

Syntax

listbackups [--store <relational|tileCache|spatiotemporal>]

If you do not specify a data store type, the utility returns a list of backups for all data stores running on the machine where the utility is run.

Example

In this example, backups are listed for a spatiotemporal big data store:

./listbackups.sh --store spatiotemporal

Backup_Name                      Status           Backup_Time         Mode
====================================================================================
backup1						                    BackupComplete   2016-07-11 09:47    manual

Backups located at: '/net/myserver.ntw.com/spatiotemporal'

listmanageduser

Used with relational, tile cache, and spatiotemporal big data stores.

The listmanageduser utility returns the user name and password of the account that owns the hosted feature layer data in relational and spatiotemporal big data stores. This utility also returns the user name and password of the data owner for tile cache data stores.

Syntax

listmanageduser

Example

In the following example, listmanageduser is run on a primary machine that contains a relational and tile cache data store.

./listmanageduser.sh

Managed user for relational data store ds_abcd1234
=======================================================
UserName     Password       Database
gwi_n2Te0    4cXddhZhve=Y   db_qv5e1

Managed user for tile cache data store tcs_e41f0rj2
=======================================================
UserName     Password
usr_n8778    y47ccno913

In this example, listmanageduser is run on a spatiotemporal big data store machine.

./listmanageduser.sh

Managed user for spatiotemporal big data store bds_6udbx4321
=================================================================
UserName     Password
fmr_o1He3    5vZggkPbaw.T

registerdatastore

Used with relational, tile cache, and spatiotemporal big data stores.

The data store retains information about the GIS Server site machine names. If you move your GIS Server site to new machines (for example, if you got new hardware or if the existing GIS Server machines failed), you must unregister the data store from the GIS Server site to remove this information. Once you configure GIS Server on a new machine (or machines), you can register the data store with the GIS Server site using the registerdatastore command utility.

Note that this is used to register the data store to the same GIS Server site it was registered to previously. The data store contains the data for the hosted layers on the existing GIS Server site. Registering it to a different GIS Server site does not re-create the hosted feature layers, scene layer caches, or stream service data archives.

The registerdatastore utility can be run on the primary relational or tile cache data store machine. It can be run on any spatiotemporal big data store machine.

Syntax

registerdatastore <ArcGIS Server URL> <ArcGIS Server site administrator user name> <ArcGIS Server site administrator password> --stores <relational|tileCache|spatiotemporal>

Though not recommended, if you have multiple different types of data stores installed on the same machine, you can register them at the same time by specifying the data store type separated by a comma (no spaces); for example, type --stores relational,tileCache.

Example

In this example, a relational data store is reregistered to a GIS Server site with the URL https://gisserver.domain.com:6443/arcgis. The ArcGIS Server primary site administrator user name is agsadmin with the password Tan$p0n.

./registerdatastore.sh https://gisserver.domain.com:6443/arcgis agsadmin Tan$p0n --stores relational

removemachine

Used with relational, tile cache, and spatiotemporal big data stores.

Use the removemachine utility to remove one of the following from an ArcGIS Data Store installation:

  • Remove a standby machine from a relational data store. Can be run on standby machine or from the primary machine in the case where the standby machine is unavailable.
  • Remove a standby machine from a tile cache data store. Can be run on standby machine or from the primary machine in the case where the standby machine is unavailable.
  • Remove a machine from a spatiotemporal big data store. Note that you cannot run removemachine on a spatiotemporal big data store composed of only one machine.

Syntax

removemachine <machine name> --store <relational|tileCache|spatiotemporal> [--prompt <yes | no>]

Example

In this example, the spatiotemporal big data store machine, gefour, is removed from the data store.

./removemachine.sh gefour --store spatiotemporal

removestandbymachine

Legacy:

Esri has deprecated the removestandbymachine utility. It is still present to allow existing scripts to continue working, but you should start using the removemachine utility instead.

You can use the remove ArcGIS Server REST command from the ArcGIS Server site administrator to remove a standby machine from a relational or tile cache data store. However, if the GIS Server site is unavailable, you won't be able to log in to the site administrator to do this. In those cases, run the removestandbymachine utility to remove a standby machine from the data store.

The removestandbymachine utility can only be run on the standby machine of a relational and tile cache data stores.

Syntax

removestandbymachine <machine name> --store <relational|tileCache> [--prompt <yes | no>]

restoredatastore

Used with relational, tile cache, and spatiotemporal big data stores.

If you lose access to the data used by your portal's hosted feature layers, hosted scene layers, or archived real time data, use your backup files and the restoredatastore command utility to recover your data store.

If you cannot recover the data store, install ArcGIS Data Store on a new machine and restore the most recent backup to the new machine.

If you use a relational data store and want to roll the hosted feature layer data back to a specific time in the past, restore on top of the existing relational data store. Note that you can only restore to a previous relational data store state for which you have backup files available. For example, if you only retain backups for five days, you can only recover the data store to a point in time within those five days.

The restoredatastore utility can be run on the primary relational or tile cache data store machine. It can be run on any of the spatiotemporal big data store machines.

Syntax

restoredatastore [operations]

Supported operations are as follows:

  • [--store {relational|tileCache|spatiotemporal}]
  • [--target {most-recent | <yyy-mm-dd-hh:mm:ss> | <name of backup file>}]: This operation is only supported for relational data stores.
  • [--source-loc <location of source backup files>]
  • [--bound {true | false}]
  • [--data-dir <new data store directory>]
  • [--server-url <ArcGIS Server URL registered with data store>] : If you specify --bound true to keep the data store registered with the same GIS Server site it was registered with when you created the backup, specify the URL of that GIS Server site. If you specify --bound true and have moved your services to a new GIS Server site, use the --server-url operation to specify the URL of the new GIS Server site. Note, though, unless you have also moved the services to this new server, the data in the data store will not be accessible.
  • [--server-admin <user name of ArcGIS Server admin>]: This operation is only optional if you specify --bound false; otherwise, you must supply the user name of the ArcGIS Server administrator.
  • [--server-password <password of ArcGIS Server admin>]: This operation is only optional if you specify --bound false; otherwise, you must supply the password for the ArcGIS Server administrator.
  • [--loaddata {true | false}]: Only supported with spatiotemporal big data stores. Set this operation to false when you need to restore the spatiotemporal big data store to a new set of machines, but the data will not fit on the first machine. This allows you to restore the data store's schema, add more machines to the spatiotemporal big data store to accommodate all the data, and then run the restoredatastore utility again with --loaddata set to true to restore the data. By default, this operation is set to true.
  • [--prompt {yes | no}]

When restoring after a crash or to move the relational data store, specify --target most-recent. If restoring a relational data store to a point in time, specify the date and time (in UTC) to which you want to restore the data store. If you have a specific backup file you want to restore, specify the backup file name instead. If you do not specify a target, the most recent backup is restored.

By default, the restored data store is associated (bound) with its GIS Server site. Only specify --bound false if you want to restore the data store without maintaining the association with the data store's GIS Server site. You would only do this as a last resort if the previous GIS Server site was lost and could not be recovered; you could restore the data store unbound and configure it with a new federated GIS Server site. However, the layers that used the data in the data store would no longer exist. You would have to connect to the data store database to extract the data to another format and republish it to the portal.

Examples

In this example, the most recent backup is from /net/buserver/data/backups to /usr/arcgisdatastore. Since the default store type is relational, and it remains bound by default to the GIS Server site with which it was registered, you do not have to specify --store relational or --bound true.

./restoredatastore.sh --target most-recent --source-loc /net/buserver/data/backups --data-dir /usr/arcgisdatastore

You are attempting to restore the data store from a data store backup. This process could take a long time, 
depending on the size of your data. Please do not interrupt the process once it has started.

Do you want to continue (Yes or No)?Yes

In this example, a relational data store that has point-in-time recovery enabled is restored from /net/buserver/data/backups to the state it was in at 2:30 p.m. (UTC) on July 17th, 2014.

./restoredatastore.sh --target 2014-07-17-14:30:00 --source-loc /net/buserver/data/backups

You are attempting to restore the data store from a data store backup. This process could take a long time, 
depending on the size of your data. Please do not interrupt the process once it has started.

Do you want to continue (Yes or No)?Yes

See Recover a data store for steps and an example of restoring a spatiotemporal big data store after hardware failure.

revokeconnection

Used with relational data stores.

If you used the allowconnection utility to temporarily allow another client to connect directly to the relational data store, you can revoke the connection ability by running the revokeconnection utility.

The revokeconnection utility can be run on the primary relational data store machine only.

Syntax

revokeconnection <host name> <user name> [<database>]

Example

In this example, the data store database will no longer accept connections from the workcom machine when logged in as user hqo.n_1E7.

./revokeconnection.sh workcom bn0_3Wa.m hqo.n_1E7

unregisterdatastore

Used with relational, tile cache, and spatiotemporal big data stores.

You can use the unregisterdatastore command utility to do the following:

  • Unregister a primary relational or tile cache data store machine from your GIS Server site. Only do this if you have deleted the hosted feature, tile, and scene layers that use the data in the data store. If you don't, you will have unusable layers left in your portal and unusable services running on your hosting server.

    Note that if you have a standby machine, you must first remove it from the data store before you can unregister the primary machine.

  • Unregister a single-machine spatiotemporal big data store.

You would unregister a data store from your GIS Server site if you decide you no longer want to use the data store or the services that depend on it. When you unregister a machine from the data store, the GIS Server site can no longer connect to that machine, and all services that contained data from the unregistered data store will no longer function. This command does not delete the data, however; if you decide you still need the data store, you can use the registerdatastore or configuredatastore utility to add it back.

The unregisterdatastore utility can only be run on the primary relational or tile cache data store machine after you have run the removemachine to remove the standby machine. Unregisterdatastore can only be run for a spatiotemporal big data store once you have one machine left after having run the removemachine to remove all the other machines in the spatiotemporal big data store.

Syntax

unregisterdatastore --stores <relational|tileCache|spatiotemporal> [--prompt {yes | no}]

If you have more than one type of data store installed on the same machine and want to unregister more than one at a time, specify each data store type separated by a comma (no spaces). For example, to unregister a relational and tile cache data store, type --stores relational,tileCache.

Example

Here, the unregisterdatastore utility is run to unregister the relational and tile cache data stores from the GIS Server site. A prompt is returned, which is the default behavior. To suppress the prompt, specify --prompt No.

./unregisterdatastore.sh --stores relational,tileCache

You are going to unregister the data store.
Do you want to continue (Yes or No)?Yes

updatebackupretaindays

Used with relational data stores.

ArcGIS Data Store retains relational data store backup files for seven days by default. You can change how often backup files are purged from the backup directory by running the updatebackupretaindays utility.

The updatebackupretaindays utility can be run on the primary relational data store machine only.

Syntax

updatebackupretaindays <number of days>

Example

In the following example, backup file retention time is changed to 10 days:

./updatebackupretaindays.sh 10

updatebackupschedule

Used with relational, tile cache, and spatiotemporal big data stores.

By default, ArcGIS Data Store creates a full backup of the relational data store every four days. You can change how often a full backup is created by running the updatebackupschedule utility.

There are no default automatic backups for tile cache or spatiotemporal big data stores. To set an automatic backup schedule for a spatiotemporal big data store, you must first set a valid backup location.

Specify a start time using 24-hour clock notation, for example, 00:00:00 for midnight and 13:00:00 for 1 p.m. Use the frequency option to specify the number of days between backups. To disable automatic backups, set the frequency to 0. If you disable automatic backups, be sure to run the backupdatastore utility to create backups manually.

You can run the updatebackupschedule utility on the primary relational or tile cache data store machine. The tool can be run on any spatiotemporal big data store machine.

Syntax

updatebackupschedule [--store relational|tileCache|spatiotemporal] [--starttime <local server time>] --frequency <number of days>

If you do not specify a new start time, the existing start time setting does not change. If you do not specify a data store type, relational data store is assumed.

Example

In this example, full backups of a relational data store will take place at 11 p.m. (local server time) every 10 days:

./updatebackupschedule.sh --starttime 23:00:00 --frequency 10

In this example, a backup schedule is set for a tile cache data store. After the initial backup copy of all tile cache data store databases, ArcGIS Data Store copies newly created data store databases to the location specified with the configurebackuplocation every 14 days.

./updatebackupschedule.sh --store tileCache --frequency 14

updatelicense

Used with relational data stores.

If your ArcGIS Server license expires, you must update the license on the ArcGIS Server site. The license information is also stored in the ArcGIS Data Store relational data store; therefore, after updating the license of the ArcGIS Server site with which the data store is configured, you must update the license in the data store. To do that, run the updatelicense utility from the machine where your primary ArcGIS Data Store is installed. If you have a standby ArcGIS Data Store, the updated license will be replicated to it.

Syntax

updatelicense

Example

After you update the ArcGIS Server license, run the updatelicense utility to move the new license to the data store.

./updatelicense.sh

updatesslcertificate

Used with all data store types.

Before you create any data store, you can replace the self-signed certificate used to authenticate communication with the Data Store Configuration wizard, between the hosting server and the data store, and between data store machines with a certificate verified and signed by a certifying authority (CA) or domain certificate. When using a CA-signed certificate, you will not receive security warnings when you run the Data Store Configuration wizard.

Syntax

updatesslcertificate <source certificate file name with path> <password for the source certificate file> <alias for the certificate>

Example

After you receive a CA-signed certificate file, run updatesslcertificate to replace the ArcGIS Data Store self-signed certificate before you proceed with creating a data store.

./updatesslcertificate.sh /usr/files/mysignedcert.pfx ps4mycert dsmachinename