Command utilities, installed with ArcGIS Data Store, provide the data store administrator tools to manage data stores. This page 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
This utility is 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.
You can run the allowconnection utility 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
This utility is used with all 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 after setting a backup location, 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 after setting a backup location, a full backup is created. Because 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.
You can run the backupdatastore utility on the primary relational data store machine. This utility can be run from any machine that is a member of your tile cache or 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 file name>] [--store {relational | tileCache | spatiotemporal | graph}] [--location <backup_arguments>] [--prompt {yes | no}]
Arguments for the --location parameter are as follows and must be separated with semicolons (;):
- type=—Valid types are fs (file share), s3 (Amazon Simple Storage Service (S3) bucket), or azure (Microsoft Azure Blob storage container). You can only use file shares for graph store backups.
- name=—If you assigned names to the backup locations you configured for your data store, you can use the location name to specify where you want backup files created when running the backupdatastore utility.
- location=—If you do not specify a backup location name, you must specify the backup type and location. For file shares, provide the file path. For S3 buckets, provide the bucket name. For Azure Blob storage containers, provide the container name.
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 file named localbu5 is created for the spatiotemporal big data store in a file share location, which you named gadbu when you configured the backup location.
./backupdatastore.sh localbu5 --store spatiotemporal --location 'name=gadbu' 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 in an Azure Blob storage container named blob4backups, and the backup file created is named spds311016:
./backupdatastore.sh spds311016 --store spatiotemporal --location 'type=azure;location=blob4backups' 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
Legacy:
Esri has deprecated the changebackuplocation utility. It is still present to allow existing scripts to continue working. Otherwise, use the configurebackuplocation utility.
changedatastoremode
This utility is used with relational and spatiotemporal big 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 can 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.
You must run the changedatastoremode utility on the primary relational data store machine, not the standby machine.
Note:
If ArcGIS Data Store places your relational data store in read-only mode due to insufficient disk space, automatic backups are also disabled to avoid filling the disk further. Therefore, you must reset your automatic backup schedule using the updatebackupschedule utility after you place the relational data store back in read-write mode.
When your spatiotemporal big data store gets close to running out of disk space, ArcGIS Data Store places it in read-only mode to avoid data corruption. You can use the changedatastoremode utility to return a spatiotemporal big data store to read-write mode after you have added sufficient disk space to the spatiotemporal big data store machines.
Syntax
changedatastoremode {readonly | readwrite} [--prompt {yes | no}] --store {relational | spatiotemporal}
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 ArcGIS Enterprise, editing data through a hosted feature layer, or adding CSV files to a map viewer.
./changedatastoremode.sh readwrite --store relational --prompt no
To place a spatiotemporal big data store in read-write mode, specify spatiotemporal with the --store option as shown in the following example:
./changedatastoremode.sh readwrite --prompt no --store spatiotemporal
changedbproperties
This utility is used with relational, tile cache, 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 | tileCache | spatiotemporal} [configuration options]
The following are supported configuration options:
- 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 less than 10. When you change the maximum number of connections allowed, the number is changed on both the primary and standby data store machines. This parameter is not supported for spatiotemporal big data stores or tile cache data stores.
- pitr—This setting indicates whether ArcGIS Data Store creates 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 incremental backups of your ArcGIS Enterprise deployment.
- enablessl—This parameter controls use of the Transport Layer Security (TLS) protocol when populating the tile cache data store and for communication between the relational data store and the hosting server.
Supported options for the enablessl parameter are as follows:
- true—This is the default option. This means that the Transport Layer Security protocol will be used when writing scene layer data to the tile cache data store when you specify --store tileCache and when communicating between the relational data store and hosting server when you specify --store relational.
- false—Specify false and --store tileCache to use HTTP communication from the hosting server when writing to the tile cache data store. Specify false and --store relational to use HTTP communication between the hosting server and relational data store.
- 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. The rebalance operation 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 to 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 option is used to set 15 as the number of minutes after which the spatiotemporal big data store will automatically change rebalance to true.
./changedbproperties.sh --store spatiotemporal --max-rebalance-off 15
In this example, the enablessl parameter is used to configure the tile cache data store to use Transport Layer Security when the container is created and when writing data to the tile cache data store.
./changedbproperties.sh --store tileCache --enablessl admin,data
changeloglocation
This utility is used with all data store types.
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.
The ArcGIS Data Store account must have write privileges to the folder you specify.
Syntax
changeloglocation <directory path>
Example
In this example, log files will be created in the local directory, ../datastorefiles/logs.
./changeloglocation.sh '../datastorefiles/logs'
changenosqldslocation
This utility is 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 may 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 (Microsoft Windows).
Syntax
changenosqldslocation <path> [--prompt {yes | no}]
Example
In this example, the databases that store scene layer caches will be created in a shared directory named dstorecache on machine server2.
./changenosqldslocation.sh /net/server2/dstorecache
changepassword
This utility is 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
This utility is used with relational and tile cache data stores.
When you restore your relational or tile cache data store, ArcGIS Data Store extracts the compressed backup files on a staging location. That means you must have a staging location that can accommodate this uncompressed data. If you have a lot of data in your relational or tile cache data store, 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/rbustage.
./changestaginglocation.sh /net/sanmarcos/rbustage
configurebackuplocation
This utility is used with relational, tile cache, and spatiotemporal big data stores and graph stores.
The configurebackuplocation utility allows you to specify the location where ArcGIS Data Store writes backup files for both scheduled backups and backups created with the backupdatastore utility. This command also allows you to alter properties of a backup location and remove a backup location.
Relational data stores are created with a default, local backup location. To avoid data loss, configure a default backup location by registering a remote file share using the change option.
Tile cache data stores created in primary-standby mode have a default backup location; tile cache data stores created in cluster mode do not. In either case, use the configurebackuplocation utility with the register option to specify a shared network location, an Amazon Simple Storage Service (S3) bucket, or a Microsoft Azure Blob storage container to securely store tile cache data store backups. You cannot use a local drive for tile cache backup files if the data store is running in cluster mode.
Spatiotemporal big data stores are not created with a default backup location. Before you can begin creating backups, you must run the configurebackuplocation utility with the register option to specify a file share location, an Amazon Simple Storage Service (S3) bucket, or a Microsoft Azure Blob storage container for these backups. You cannot use a local drive for spatiotemporal big data store backup files.
Graph stores are not created with a default backup location. Before you can begin creating backups, you must run the configurebackuplocation utility with the register option to specify a file share. Only file share locations are supported.
You can register a second backup location to store the backups you create using the backupdatastore utility. You can use a shared file directory, an S3 bucket, or an Azure Blob storage container for secondary backup locations for all but the graph store. For graph stores, second backup locations can be only file shares.
For more information on setting backup locations, see Manage data store backups.
Syntax
configurebackuplocation --location '<backup_location_arguments>' [options]
Use the --location option to specify where you want ArcGIS Data Store to store backup files. For tile cache data stores or spatiotemporal big data stores or to register a secondary backup location for a relational data store, specify the following arguments separated by a semicolon (;) and enclose the entire argument string in single quotation marks ('): --location 'type=fs|s3|azure;location=<backup_location>;[name=<backup_location_name>];[username=<AWS_access_key_ID_or_Azure_account>];[password=<AWS_secret_access_key_or_Azure_account_key>]'. An explanation of each of these arguments is provided in the following list:
- type=—Specify what type of location to use for backups. You can specify s3 to store backups in an Amazon S3 bucket, azure to store backups in an Azure Blob storage container, or fs to store backups in a file share (this is the default).
- location=—For file shares, specify the file path. For Amazon S3 buckets, specify the bucket name. For Blob storage containers, specify the container name.
- name=—You can assign a name to the backup location. For example, if your backup location is a file path, such as \\sharedserver_sharedfolders_datastorebackups, you can designate a name for this location, such as dsbackups. When you run the backupdatastore, listbackups, or restoredatastore utility, provide this name instead of the full path.
If you do not provide a name when you configure the data store backup location, ArcGIS Data Store assigns a default name.
- username=—Required if your backup location is an S3 bucket or a Blob storage container. For S3 buckets, provide the access key ID for your Amazon Web Services (AWS) account. For Azure Blob storage containers, provide the name for the Microsoft Azure storage account that can access the Blob storage container.
- password=—Required if your backup location is an S3 bucket or a Blob storage container. For S3 buckets, provide the secret key for your AWS account. For Azure Blob storage containers, provide the key for the Azure account you specified with the username argument.
- endpointsuffix=—This option allows you to indicate where your Azure Blob storage container is located. By default, the is endpointsuffix assumed to be core.windows.net. If your container is in the Microsoft Azure Government cloud environment, set endpointsuffix=core.usgovcloudapi.net. If your container is in a private cloud, set endpointsuffix to the EndpointSuffix of your Azure private cloud. This option is only used if you store your backups in an Azure Blob storage container.
Additional options you must provide with the configurebackuplocation utility are as follows:
- --store {relational | tileCache | spatiotemporal | graph}—Specify the type of ArcGIS Data Store for which you're configuring a backup location. The default value is relational.
- --operation {change | register | unregister | list | setdefault}—The default value is change. The following is an explanation of each option:
- change—Use this option to change any of the following:
- Specify a different shared file location for scheduled relational data store backups. The location set with the change option is always the default backup location for relational data stores.
- Alter the name you assigned to the backup location.
- Update the authentication information you set for backup locations on Azure or S3. For S3, you can change the information you previously specified with the username and password options. For Azure, you can change the password value.
- register—Use this option to register a backup location. The first backup location you define for a spatiotemporal big data store or graph store is set as the default backup location. When you register another backup location for a tile cache or spatiotemporal big data store or a graph store, a secondary backup location is registered.
When you specify the register option with a relational data store, it always registers a secondary backup location. The secondary backup location stores manual backups generated with the backupdatastore utility.
Note:
When you use the register option, you must provide information for the --location option.
- unregister—Use this option to remove a secondary backup location from a data store. If only one backup location is registered, you can use the unregister option to completely remove the backup location for a tile cache or spatiotemporal big data store or a graph store.
- list—Lists all backup locations registered for a data store.
- setdefault—If you have multiple backup locations for a tile cache or spatiotemporal big data store, you can use setdefault to designate one of the backup locations as the default location. This location is where scheduled backups are written and is the default location used if you run the backupdatastore, listbackups, or restoredatastore utility without specifying a backup location.
- change—Use this option to change any of the following:
- --force {true | false}—Used only with relational data stores, this option allows you to change the default backup location even if the existing default backup location is unavailable.
When you change the default backup location for a relational data store, ArcGIS Data Store copies the existing backup files from the old location to the new location. If ArcGIS Data Store cannot access the old location, it cannot copy the files. In previous releases, this would cause the configurebackuplocation tool to fail. If you want to proceed with changing the default backup location without copying existing backup files, specify --force true.
The default value for this option is false, which means you cannot change the default backup location if ArcGIS Data Store cannot access the existing default location.
- --prompt {yes | no}—The default value is yes.
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 second backup location on Azure is registered for the same relational data store.
./configurebackuplocation.sh --operation register --store relational --location type=azure;location=mybackups;name=secondrelloc;username=myazureaccountlogin;password=zpw4myazureaccount 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. A name, fshare, is assigned to the backup location.
./configurebackuplocation.sh --operation register --store spatiotemporal --location 'type=fs;location=/net/sharedmachine/ge_bu;name=fshare'
In this example, a second backup location on AWS is specified for the same spatiotemporal big data store. A name, awsloc, is assigned to the backup location.
./configurebackuplocation.sh --operation register --store spatiotemporal --location 'type=s3;location=mybucket;name=awsloc;username=abcdefg1234567;password=z9y8x7w6v5u4t3s2r1q0'
In this example, a third backup location on Azure is specified for the spatiotemporal big data store.
./configurebackuplocation.sh --operation register --store spatiotemporal --location 'type=azure;location=myblobs;name=mazloc;username=myazureaccountlogin;password=zpw4myazureaccount'
In this example, the S3 bucket is set as the default backup location for the spatiotemporal big data store.
./configurebackuplocation.sh --operation setdefault --store spatiotemporal --location 'name=awsloc'
In this example, all backup locations for the spatiotemporal big data store are listed.
./configurebackuplocation.sh --operation list --store spatiotemporal Backup locations for spatiotemporal big data store: ================================================================ Name Type Location isDefault ================================================================ fsshare fs /net/sharedmachine/ge_bu false awsloc s3 mybucket true mazloc azure myblobs false
configuredatastore
This utility is used with all data store types.
After you install ArcGIS Data Store, you can run the configuredatastore utility to create a data store and register it with a GIS Server site. You can create the following types of data stores using this command:
You can also run the configuredatastore utility to upgrade a data store after updating the ArcGIS Data Store software on all machines in the data store.
Syntax
configuredatastore <ArcGIS Server admin URL> <ArcGIS Server administrator> <ArcGIS Server administrator password> <data directory> [--stores {relational | tileCache | spatiotemporal | graph}] [--mode {primaryStandby | cluster}] [--machines <machine names>]
- <ArcGIS Server admin URL>—This is the GIS Server site that is used or will be used as the ArcGIS Enterprise hosting server. The ArcGIS Server admin URL is in the format https://gisserver.domain.com:6443. Note that even if your GIS Server site uses a web adaptor, you must provide the URL in the aforementioned format.
- <ArcGIS Server administrator>—Provide the user name for a built-in (not organization-specific) user who has administrator privileges in the GIS Server site.
- <ArcGIS Server administrator password>—Provide the password for the built-in ArcGIS Server administrator user.
- <data directory>—The data directory is the location on the local machine where you want the data store files to be created.
- {relational | tileCache | spatiotemporal | graph}—Specify the type of data store to create. 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 relational and tile cache data stores on the same machine with a shared data store directory, specify --stores relational,tileCache. Esri strongly recommends that you run spatiotemporal big data stores and graph stores on machines separate from other data stores or software. Failing to do so can result in poor performance, or even render the data store unusable.
- --mode—This optional operation applies to tile cache data stores only. By default, new tile cache data stores are created in primaryStandby mode. Graph stores are created in singleInstance mode and cannot be altered at this time.
Tile cache data stores created in primaryStandby mode can contain two machines. The standby tile cache data store contains the same data as the primary. If the primary data store fails, the standby becomes the primary tile cache data store. If you need to store large numbers of scene layer caches and, therefore, you need your tile cache data store to scale to include three or more machines, create a tile cache data store in the cluster mode. You can also use the mode operation to switch your tile cache data store from one mode to another.
- Graph stores are created in single instance mode and can contain only one machine.
Configure a specific type of data store
You specify the type of data store to create using the following settings with the --stores option:
- relational
- tileCache
- spatiotemporal
- graph
To configure more than one data store type on the same machine, separate the types with a comma. For example, to configure both a relational and tile cache data store on the same machine, specify --stores relational,tileCache.
Note:
Data stores configured on the same machine compete for memory and other resources, negatively affecting performance and possibly causing the data stores to stop working. This is especially true for spatiotemporal big data stores and graph stores; do not configure a spatiotemporal big data store or graph store on the same machine as another data store or other ArcGIS component.
If you script the creation of multiple spatiotemporal big data store machines, one spatiotemporal big data store machine must be manually configured with the GIS Server site before you can script the creation of additional spatiotemporal big data store machines. Include wait times in your script to be sure the additional spatiotemporal big data store machines are not added at the same time.
See Create a data store for more information.
Configure data stores after updating ArcGIS Data Store installations
As part of upgrading ArcGIS Data Store, you must reconfigure the existing data store machines. After you install a new version of ArcGIS Data Store over the existing ArcGIS Data Store on every data store machine, you can log in to any machine in a data store and run the configuredatastore utility to finish upgrading that particular data store. For example, you can run configuredatastore on the primary relational data store machine, and the standby machine will also be upgraded.
If a machine contains both a relational and tile cache data store, specify --stores relational,tileCache when you run the configuredatastore utility, and it updates all the machines in both data stores.
To reconfigure updated spatiotemporal big data store machines, log on to any of the machines in the spatiotemporal big data store and run the configuredatastore utility. This updates all machines in the spatiotemporal big data store.
If you have not installed the new version of ArcGIS Data Store on all machines, configuration cannot proceed.
See Upgrade ArcGIS Data Store for more information.
Change the mode of a tile cache data store
If you upgrade from 10.7.1 or earlier, your tile cache data store is automatically in primary-standby mode. If you require more machines in your tile cache data store because you have a large number of scene layers, you can change the tile cache data store mode to cluster, and add more machines to your tile cache data store. Once you add more machines, caches for new scene layers will be stored on the new machine (or machines). Existing caches will not be stored on the new machines unless you create a full backup of the tile cache data store and restore it after you add the new machine or machines.
Similarly, if you created the tile cache data store at 10.8 or chose cluster for the tile cache data store mode when you created it but you later find the cluster mode performs too slowly for you, you can switch the tile cache data store to primary standby mode if you don't truly need the storage afforded by multiple machines. The tile cache data store cannot contain more than two machines, though, before you switch to primary-standby mode.
Note:
You can use the --mode operation to specify the tile cache data store mode when creating the data store or to change the mode of the tile cache data store, but you cannot change the mode when upgrading a tile cache data store.
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://gisserver.domain.com:6443, 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://gisserver.domain.com:6443 admin Iph33l$ik /dstore/data --stores relational
In the following example, an existing tile cache data store is changed to cluster mode:
./configuredatastore https://gisserver.mydomain.com:6443 portaladmin S00perSecret dsstore/scenedata --stores tileCache --mode cluster
deletebackup
This utility is used with relational data stores and graph stores.
The deletebackup utility allows you to delete backup files you created for relational data stores or graph stores. First, run the listbackups utility to see the names and creation times of the backups created using the backupdatastore utility. You can then run the deletebackup utility to delete the backup files 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
This utility is used with all data store types.
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 data
- 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 and spatiotemporal big data stores will be placed in read-only mode and tile cache data store 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 and whether you can restore the relational data store to a specific point in time.
- Whether or not the data store is running (Data store status)
- Whether or not SSL communication is enabled on the relational data store.
- The date and time that the standby relational or tile cache (primary-standby mode) data store became the primary data store (Last failover); not displayed if fail over 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 coordinating machine (Current coordinator in cluster)
- A list of all machines in the tile cache or spatiotemporal big data store cluster (Registered <data store type> machines); shows all machines in cluster regardless of their status
- The mode configured for a tile cache data store, either cluster or primary-standby.
- Whether a relational or spatiotemporal big data store is in READWRITE or READONLY mode (Data Store mode)
Syntax
describedatastore
Example
The describedatastore utility returns general information that applies to all data stores on a machine and returns separate sections that contain information specific to each type of data store.
You should have different data stores on different machines, but to allow you to see the information returned for each type, the following output shows a machine that has all ArcGIS Data Store types on the same machine. The first section (General Information) is always returned. The data store sections returned by describedatastore vary depending on what type of data store is present on the machine.
./describedatastore.sh General Information of ArcGIS Data Store on machine.domain.com ============================================================== ArcGIS Data Store release....10.9.0.1234 Staging location............./arcgis/datastore/staging Log location................./arcgis/datastore/logs Free disk space..............174.00GB Threshold for READONLY mode..2048MB 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 SSL enabled...............true Last failover.............20150130190334005 Member machines...........MACHINE1.DOMAIN.COM, MACHINE4.DOMAIN.COM Maximum connections.......150 Owning system URL.........https://gisserver.domain.com:6443/server/admin Portal for ArcGIS URL.....https://portal_webadaptor.domain.com/portal Number of connections.....8 connection(s) to managed database Data Store mode.....................READWRITE Is Point-in-time recovery enabled...No Query optimizer enabled.............Yes Information for tile cache data store ds_wztxj7um ============================================================== Data location............./home/ags/arcgis/datastore/usr/arcgisdatastore/nosqldata Data store status.........Started Last failover.............20200130190334005 Backup location.........../net/sharedir/datastore/backup Is backup folder shared...true Mode......................primary-standby Member tile cache machines.......MACHINE1.DOMAIN.COM, MACHINE2.DOMAIN.COM Owning system URL.........https://gisserver.domain.com:6443/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 coordinator in cluster...MACHINE1.DOMAIN.COM Registered spatiotemporal machines..MACHINE1.DOMAIN.COM, MACHINE2.DOMAIN.COM, MACHINE3.DOMAIN.COM Owning system URL...................https://gisserver.domain.com:6443/arcgis/admin Portal for ArcGIS URL...............https://portal_webadaptor.domain.com/portal Data Store mode.....................READWRITE Information for graph store x2b7s0n ============================================================== Deployment mode................................singleInstance Access endpoint................................MACHINE1:9829 Registered graph store machines................MACHINE1.DOMAIN.COM Owning system URL...................https://gisserver.domain.com:6443/arcgis/admin Portal for ArcGIS URL...............https://portal_webadaptor.domain.com/portal
diskcleanup
This utility is used with relational, tile cache, and spatiotemporal big data stores.
The diskcleanup utility removes temporary files left over from operations such as restoredatastore and upgrading ArcGIS Data Store. Certain files are retained after upgrading that would allow you to troubleshoot a failed upgrade or restore operation. Once you confirm your upgrade or restore operation is successful and the system is working as expected, you can run this tool to remove those temporary files and regain free disk space on the data store machines.
This utility cleans up disk space on one machine at a time. If you need to clean up files on more than one machine in the same data store, you must run the tool on each machine.
Syntax
diskcleanup
Example
To run the diskcleanup utility, you must confirm that you want to proceed.
./diskcleanup
You are attempting to cleanup some archived data generated as part of ArcGIS Data Store upgrades or backup-restore operations. Once removed, this data can't be recovered. Do you want to continue (Yes or No)?
exportmanageddb
Legacy:
Esri 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.
importmanageddb
This utility is 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 option set to false.
The importmanageddb utility does not import spatiotemporal big data stores.
Syntax
importmanageddb <source backup location> <backup name> [options]
Supported options 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 option 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 option is required if you specify --bound true or do not specify the --bound option. Supply the user name of the ArcGIS Server administrator.
- [--server-password <password of ArcGIS Server admin>]—This option is required if you specify --bound true or do not specify the --bound option. 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 option, relational is assumed.
- [--include-tilecache {true | false}]—This option is present for backward compatibility. If you do not specify the --stores option or you specify --stores relational, you could control whether the tile cache data store was restored or not using this option.
- [--bound {true | false}]
- If you specify --bound true or do not specify the --bound option, you must specify the URL of a GIS Server site with the --server-url option and specify the ArcGIS Server administrator's credentials with the --server-admin and --server-password options. If you are importing to the same 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.
- If you specify --bound true or do not specify the --bound option, you must specify the URL of a GIS Server site with the --server-url option and specify the ArcGIS Server administrator's credentials with the --server-admin and --server-password options. If you are importing to the same 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.
- [--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-url https://gisserver.domain.com:6443 --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 option. 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 Aup.4s --stores relational --bound true --server-url https:\\newgisserver.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 --stores relational,tileCache --bound false
listadminusers
This utility is used with all data store types.
The listadminusers utility returns the user names and passwords for the administrator, replica owner, and geodatabase administrator of a relational data store. It returns the administrator for tile cache and spatiotemporal big data stores and for graph stores.
Syntax
listadminusers
Example
In this example, listadminusers is run on a machine where only a relational data store is installed.
./listadminusers.sh
Admin users for relational data store ds_abcd1234 ================================================= Database Admin User.... adm_32ret / tT30sbYk22jF Database Repl User..... dsrepuser / uWn/MV0678h4 GDB Admin User......... sde / iO=Qst751epb
In this example, listadminusers is run on a machine where only a spatiotemporal big data store is installed.
./listadminusers.sh
Admin users for spatiotemporal big data store bds_abcd1234 ================================================= Store admin user.... els_321ret / B1as70fF1
In this example, listadminusers is run on a machine where only a graph store is installed.
./listadminusers.sh
Admin users for graph store s2t0ic1 ================================================= Store admin user....root / ypz5kx2c5tk4fequ
listbackups
This utility is used with relational, tile cache, and spatiotemporal big data stores and graph stores. When run for relational data stores, the listbackups utility only functions on the primary data store machine.
The listbackups utility returns the names of backup files 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.
When you run the listbackups utility, specify the backup location for which you want to see the list of backup files. If you do not specify a location, the listbackups utility returns backups for the default backup location.
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 | graph}] [--location '<location_arguments>']
If you do not specify a data store type, the utility defaults to relational and returns the backups for the relational data store running on that machine.
The location parameter is used with spatiotemporal big data stores and relational data stores. Arguments are as follows:
- name=: The name of the backup location. You specified this name when you configured the backup location or, if you didn't specify a name, ArcGIS Data Store assigned a default name.
- location=: Either the path to the shared file directory, S3 bucket name, or Blob storage container name.
Example
In this example, spatiotemporal big data store backups are listed for the backup location named sbdsbu:
./listbackups.sh --store spatiotemporal --location 'name=sbdsbu' Backup_Name Status Backup_Time Mode ======================================================================= backup1 BackupComplete 2016-07-11 09:47 manual Backups located at: '/net/myserver.ntw.com/spatiotemporal'
listmanageduser
This utility is used with all data store types.
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 scene cache owner for tile cache data stores, and the owner of the graphs in the graph store.
Syntax
listmanageduser
Example
In the following example, listmanageduser is run on a machine that contains a relational and tile cache data store. The machine is the primary relational 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
In the following example, listmanageduser is run on a graph store machine.
./listmanageduser.sh
Managed user for graph store s2t0ic1 ================================================ UserName Password mu_vwmp8c6 m5c2so76y3b0qczf
registerdatastore
This utility is used with all data store types.
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 data store machine or primary machine of a tile cache data store that is running in primary-standby mode. It can be run on any tile cache (cluster mode) or 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 | graph}
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. The ArcGIS Server primary site administrator user name is agsadmin with the password Tan$p0n.
./registerdatastore.sh https://gisserver.domain.com:6443 agsadmin Tan$p0n --stores relational
removemachine
This utility is used with relational, tile cache, and spatiotemporal big data stores.
Use the removemachine utility to remove a machine from a data store that contains more than one machine. The removemachine utility is used in the following scenarios:
- Remove a standby machine from a relational data store. You can run this utility on the standby machine or from the primary machine in the case where the standby machine is unavailable.
- Remove a machine from a tile cache data store. You can run this utility on any machine in the tile cache data store, but you cannot run removemachine on a tile cache data store composed of only one machine.
- Remove a machine from a spatiotemporal big data store. You can run this utility on any machine in the spatiotemporal big data store, but you cannot run removemachine on a spatiotemporal big data store composed of only one machine.
Syntax
removemachine <machine name> --store {relational | tileCache | spatiotemporal} [--force {true | false}] [--prompt {yes | no}]
--force—By default, this is set to false. Specify true with this option only if the registered ArcGIS Server site is unavailable.
--prompt—By default, this is set to yes. If you do not want to confirm the action, specify no with this option.
Example
In this example, the spatiotemporal big data store machine, gefour, is removed from the data store.
./removemachine.sh gefour --store spatiotemporal
In this example, the hosting server site is unavailable and the relational data store machine, fsdata, is removed from the data store.
./removemachine.sh fsdata --store relational --force true
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.
restoredatastore
This utility is used with relational, tile cache, and spatiotemporal big data stores and graph stores.
If you lose access to the data used by your hosted feature layers, hosted spatiotemporal feature layers, hosted scene layers, archived real time data, or knowledge graph layers, 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, do not configure the data store, and restore a 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.
If you need to replace one of the machines in a multimachine tile cache data store, you'll most likely need to rebalance the scene layer caches across the tile cache data store. Part of that process requires you to restore the tile cache data store, setting the replicatedata option to true. See Recover a data store for instructions.
The restoredatastore utility can be run on the primary relational data store machine. It can be run on any of the tile cache or spatiotemporal big data store machines.
Syntax
restoredatastore [options]
Supported options are as follows:
- [--store {relational | tileCache | spatiotemporal | graph}]—Indicates the type of data store you want to restore.
- [--target {most-recent | <yyy-mm-dd-hh:mm:ss> | <name of backup file>}]—All data store types support the backup file name with the target option. A time stamp and most-recent are only supported for relational data stores.
- [--source-loc <parent directory of the source backup file location>]—This is the top-level directory where the backup files you want to use to restore the data store are located. This will be the path to a file share location or, a backup location name, or an Amazon S3 or Azure Blob storage backup location. Only file share locations are supported for graph stores.
- [--bound {true | false}]—The --bound option is only supported with relational data stores.
- [--data-dir <new data store directory>]—This is the ArcGIS Data Store directory on the machine where you are restoring the database. Only use --data-dir if you are restoring the data store to a new machine. When restoring to a new machine, you must also specify the --source-loc option.
- [--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 option to specify the URL of the new GIS Server site. Note that if you specify a new site URL and have not 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 option is required if you specify --bound true or do not specify the --bound option. Supply the user name of the ArcGIS Server administrator.
- [--server-password <password of ArcGIS Server admin>]—This option is required if you specify --bound true or do not specify the --bound option. Supply the password for the ArcGIS Server administrator.
- [--loaddata {true | false}]—Supported with tile cache and spatiotemporal big data stores and graph stores. Set this option to false when you need to restore the 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 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 option is set to true.
- [--replicatedata {true | false}]—Supported with tile cache data stores. Set this option to true when you need to rebalance scene cache data after adding a machine to the tile cache data store.
- [--mode {primaryStandby | cluster}]—When you restore a tile cache data store to a new machine, specify whether you want a two-machine tile cache data store for high availability (primaryStandby) or a scalable multimachine tile cache data store (cluster).
- [--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 ArcGIS Enterprise.
Examples
In this example, the most recent backup is from the default relational data store backup location and will be restored to the existing data store. 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. However, you do have to specify the GIS Server URL and administrator credentials.
./restoredatastore.sh --target most-recent --server-url https://gisserver.domain.com:6443 --server-admin siteadmin --server-password SAup.4s 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 the default relational data store backup location 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 --server-url https://gisserver.domain.com:6443 --server-admin siteadmin --server-password SAup.4s 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, the relational data store is restored to a new machine using a backup file named movedatastore. When you restore to a new machine, you must specify the location of the backup file and the location of the new ArcGIS Data Store data directory. Since the hosted feature services are still running on the same GIS Server site with which the relational data store is registered, --bound true is not required, but the GIS Server URL and administrator credentials are required.
./restoredatastore.sh --target movedatastore --source-loc /net/buserver/data/backups --data-dir /usr/datastore --server-url https://gisserver.domain.com:6443 --server-admin siteadmin --server-password SAup.4s 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 the following example, the tile cache data store is restored to a new machine. When you restore to a new machine, you must specify the location of the backup file and the location of the new ArcGIS Data Store data directory. Since the scene services are still running on the same GIS Server site with which the tile cache data store is registered, --bound true is not required, but the GIS Server URL and administrator credentials are required.
./restoredatastore.sh --store tilecache --source-loc /net/buserver/scenedata/backups --data-dir /usr/datastore --server-url https://gisserver.domain.com:6443 --server-admin siteadmin --server-password SAup.4s 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, the tile cache data store is restored from a file named mybackupfilename to rebalance scene cache data after a new machine is added to the tile cache data store.
./restoredatastore.sh --store tilecache --target mybackupfilename --serverurl https://gisserver.domain.com:6443 --server-admin siteadmin --server-password myAdminPWd! --replicatedata true 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 the following example, a spatiotemporal big data store backup file (bds1) is restored from a named backup location (awsloc).
./restoredatastore.sh --target bds1 --store spatiotemporal --source-loc 'name=awsloc' --server-url https://gisserver.domain.com:6443 --server-admin siteadmin --server-password SAup.4s 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
This utility is 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
This utility is used with all data store types.
You can use the unregisterdatastore command utility to do the following:
- Unregister a primary relational data store machine from your GIS Server site.
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 tile cache or spatiotemporal big data store.
- Unregister a graph store.
Note:
You must delete the hosted layers that use the data in relational, tile cache, or spatiotemporal big data store before you unregister it. If you don't, you will have unusable layer items left in the portal and unusable services running on the hosting server. You must also delete hosted knowledge graph items before unregistering a graph store; if you do not, you'll leave unusable knowledge graph services running on the ArcGIS Knowledge Server site.
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 relational, tile cache, or spatiotemporal big 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 (in primary-standby mode) data store machine after you have run the removemachine utility to remove the standby machine. Unregisterdatastore can only be run for a tile cache (cluster mode) or spatiotemporal big data store once you have one machine left after having run the removemachine utility to remove all the other machines from the data store.
Syntax
unregisterdatastore --stores {relational | tileCache | spatiotemporal | graph} [--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
This utility is 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
This utility is used with relational, tile cache, and spatiotemporal big data stores and graph 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 or graph 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 data store machine. The tool can be run on any tile cache or spatiotemporal big data store machine.
Syntax
updatebackupschedule [--store {relational | tileCache | spatiotemporal | graph}] [--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
This utility is 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
This utility is used with all data store types.
You can replace the self-signed certificate used to authenticate communication 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.
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.
./updatesslcertificate.sh /usr/files/mysignedcert.pfx ps4mycert dsmachinename