Select to view content in your preferred language

Some questions on ArcGIS Enterprise SQL server best practices.

3138
13
05-12-2023 04:54 AM
MDB_GIS
Frequent Contributor

I've found myself acting as the database administrator for our organization despite never having any formal database training, so I have a few questions. 

  • What are the best practices as far as user logins on the sql server? We currently have a "GISadmin" login and then a bunch of individual user logins. The GISadmin login has been used as sysadmin and only used for administrative tasks like reconciling versions and database maintenance. However we have recently had an issue trying to create a parcel fabric on the eGDB and I think it has something to do with the GISadmin having sysadmin privileges. Looking around, it seems like it is recommended that sysadmin versions should not own data. Is that correct? If that is the case, who should there be a designated "data_owner" login that owns all data? If so, what server roles and permissions should that login have? 
  • Adding on to the previous question, are there any other user logins that are considered best practices outside of the standard admin login and individual users? If yes, what are they and what is their purpose and what permissions would they need?
  • Is it better to create users using the ArcGIS Pro tool or in SSMS? I have been using SSMS because, at first, it seemed easier. I could create the login and then map it to all databases at once using the Login>properties>user mapping window and then grant permissions. If I use the arcgis pro tool, I had to run the "Create Database User" tool for each enterprise geodatabase (so in my case 4 times). I recently found out, however, that the arcgis pro tool also creates user schemas in each database, which is not done automatically if you map the user in SSMS. Is there anything else that is missed if you create it using SSMS? 
  • Are there any free/affordable training options for someone out there for someone like me who has no database admin experience but needs to learn it? It would be great if it was geared toward GIS database admin. The problem I'm having is that most sources I have come across don't really touch the GIS side of database administration. I need to find something that will help me better understand the SQL server management side of things while wearing the GIS glasses. 
13 Replies
George_Thompson
Esri Notable Contributor

Yes, if SDE Owned Schema is unchecked, it creates a DBO schema EGDB.

When you created data and it showed as DBO.name, then I would guess that you have "SYSADMIN" under your user.

Here is the doc that states it must be a database user:

  • The feature dataset in an enterprise geodatabase must be from a database connection established as a database authenticated user. This user must have database privileges to create content and cannot be an OS-authenticated, the database administrator, or the geodatabase administrator account. The connected user becomes the parcel fabric owner and administrator.

https://pro.arcgis.com/en/pro-app/latest/help/data/parcel-editing/createaparcelfabric.htm

Hope this helps.

--- George T.
0 Kudos
MDB_GIS
Frequent Contributor

So does that mean that the parcel fabric dataset will ALWAYS have a username in front of it? Am I interpreting that correctly?

0 Kudos
George_Thompson
Esri Notable Contributor

yes, it would be something like "PARCEL.FABRIC" or "<dataowner>.<featuredataset_name>"

--- George T.
0 Kudos
JackHorton
Esri Contributor

There are two things in play here.  It sounds like your geodatabase was created using the DBO schema.  That means that all the internal repository tables are owned by DBO, and it has nothing to do with who owns the parcel fabric.  When you copied the feature dataset containing your parcel fabric into the geodatabase, if you were connected as a user called TestGISAdmin, then all the tables in the feature dataset will be owned by TestGISAdmin.  The names of the tables follow the format of DatabaseName.OwnerName.TableName, so TestGISAdmin would be a part of all the tables created by TestGISAdmin.  That is why the recommended practice is to have your enterprise tables be owned by "headless users", not people's actual names.

0 Kudos