I would like to know if someone would have some advice with an On-Premise, Federated Portal
10.3.1 installation, where the Managed database would be our SDE Enterprise
database instead of the Datastore. Anyone know of any downside or limitations we may encounter by not using the Datastore?
Using an Enterprise geodatabase (aka. ArcSDE geodatabase) as a managed data store (i.e., data storage option) for your ArcGIS Server site is fine. In this case, I am referring to the generic concept of a "data store" for ArcGIS Server. Help topic,
If you want to enable a hosting server for your Portal for ArcGIS, the "ArcGIS Data Store" (i.e., the software product) is the recommended option, because it has been optimized to store hosted services.
Q) Are you trying to configure and deploy a hosting server for your Portal for ArcGIS? If so, then you should use the ArcGIS Data Store instead of an Enterprise geodatabase.
Hope this helps,
As an early adopter of portal, I can attest to the speed benefit of using the Data Store over an SDE database,
The one downside, and it's minor if you pull the data in through portal, is that the Data Store Database is not SDE, and it's not able to be connected to like an SDE-enabled database, at least as I've found.
Curious about one thing.
Since the DataStore is a managed DB, it seems to mean from what I can tell so far that it's pretty much transparent to the user and to the admin. It just does it's thing.
Have you had any issues with things getting out of synch or mashed up?
No, it works seamlessly for the end user. There are documented ways to create backups, but we run in our whole GIS in a VMware environment with real-time replication to an offsite location, so we haven't bothered.
We still use traditional backups for SDE though. Some habits are hard to break
This page is worth a read What is ArcGIS Data Store?—Portal for ArcGIS (10.3 and 10.3.1) | ArcGIS for Server
Tom, the datastore can be implemented with backups fairly easy, don't let a little command line scare you!
This is a great place to start:
You can basically specify an off-location directory within your company network, set a schedule and it's pretty much a set it and forget it. We also have VM, so not only are the databases saved to an off-site location, but we also save images of our hosting server nightly.
Q) Are you trying to configure and deploy a hosting server for your Portal for ArcGIS? Yes
There are 2 goals we hope to achieve with our implementation of Portal :
1) Give Portal users the possibility to create new Feature Layers from Portal. From what we understand this can only be achieved if we use ArcGIS Data Store; using an Enterprise geodatabase as our Data store does not unlock this options.
2) We would like to be able to update features located in our Geotatabase using Feature Services for use in Collector. When Data Store (software) is installed all Feature Services are published as Hosted Feature Layers. When the feature layer is hosted in the Data store edits are no longer synched with our ArcGIS Server Geodatabase…
De : Derek Law
Envoyé : 7 octobre 2015 14:17
À : Champagne Line <LChampagne@GazMetro.com>
Objet : Re: - Managed database: SDE Enterprise database or Datastore
Managed database: SDE Enterprise database or Datastore
reply from Derek Law<https://community.esri.com/people/dlaw-esristaff?et=watches.email.thread> in Portal for ArcGIS - View the full discussion<https://community.esri.com/message/558397?et=watches.email.thread#558397>
for # 1
You don't need to use Data Store, but you do need to have a Managed Geodatabase for content to be published to. This can be an SDE Database or the Data Store, your choice, with the understanding that scenes (3d) can only be published to the Data Store.
You can publish data from SDE as Feature Services and edit them in Collector, Data Store is only used when you don't have data coming from a registered source with ArcGIS Server or for content that's created/uploaded in Portal.
"Give Portal users the possibility to create new Feature Layers from Portal. From what we understand this can only be achieved if we use ArcGIS Data Store; using an Enterprise geodatabase as our Data store does not unlock this options."
This is not correct. This works fine also with SDE Enterprise geodatabase, like in Oracle. You may also use the same geodatabase as you are using for other purposes (I do not know if this is recommended, and may of course have impact on response times). We do, and have Portal create new feature classes in a separate Oracle schema.
One benefit of using Enterprise geodatabase, is that the feature classes that users has created is visible as you are used to, like in Catalog. You may also read the feature classes from the Enterprise geodatabase with other tools.
(You might actually also overwrite data in a feature class created from Portal, with ie a FME job, if you have permission to the Oracle schema. We do this to help users get their data updated regulary.)
A constraint is that column names are limited by Oracle column limitations, and when users do like Share from ArcMap to create a new feature layer in Portal, this will fail with a 99999 error message with no further information, if their data definitions are rejected by Oracle. Column names that are accepted in a file geodatabase may be rejected. The most common issue I have encountered is column names longer that 30. Hopefully this works better with Data Store, it should accept all data types that accepted in a filegeodatabase. I have no experience with this.