Enterprise Geodatabase Maintenance Process Using non-SDE account

1627
4
Jump to solution
03-11-2021 04:11 PM
Raj-Chavada
New Contributor III

Hello,

We wanted to implement following automated workflow using python required for optimal performance of enterprise geodatabse using traditional (not branch) versioning functionality required for multi-user editing. 

- reconcile/post>compress>analyze update statistics on geodatabase system tables (owned by SDE table)

We have the script ready to go but have issue with the account. See below.

Due to the high default privileges and/or other concerns for SDE account, our DBA team do not want to share or use this account in our live/production environment wit the GDB admin team (me) and wants to use different (non-SDE ) account with custom privileges to carry out this operation.  This new non-SDE account works fine and getting the expected results in terms of the success of compress operation (state_ID = 1) surprisingly.  

So, as someone wearing a hate of GDB admin in the group, my question to the geodatabase admin team is should we use non-SDE account OR SDE account is recommended for setting up the maintenance workflow mentioned above? Are there any risks associated with using non-SDE account for the maintenance process?

 

1 Solution

Accepted Solutions
VinceAngelo
Esri Esteemed Contributor

It's clear why the DBA team would restrict DBA access to GIS administrators. It's also clear why GIS administrators would keep the SDE password away from DBAs.

It's not clear why the GIS administrator doesn't have SDE user access. This is a clear violation of SLA (Service Level Agreement) protocol.  Note that the SDE user should not have DBA privileges (except during upgrade, and then only briefly), so there really isn't any reason for the DBAs to restrict that account. 'SDE' should only be used for enterprise geodatabase administration, which is why it's clearly in the GIS admin responsibility zone.

Even if the extra account works perfectly for the most frequent procedures, it's not safe to assume that it will work for all required operations, and the extra work and risk doesn't seem worth the limited gain.

- V

View solution in original post

4 Replies
George_Thompson
Esri Frequent Contributor

I will say that you should add Rebuild Indexes (Rebuild Indexes (Data Management)—ArcMap | Documentation (arcgis.com)) to the process. You will also need to do this for each schema (data owner) in the Oracle Enterprise Geodatabase, hopefully SDE does not own all the data ;).

Recommended version administration workflow—ArcMap | Documentation (arcgis.com)

Does the non-SDE account have any other errors during the process?

--- George T.
Raj-Chavada
New Contributor III

Thanks, George! I should have specified that we have SQL Server 2016. Furthermore, our DBA have configured automatic update statistics on all tables. So, do we still need to run/schedule this via GDB data management tools? 

Not getting errors when running compress but unaware of risks associated with using non-SDE account. I hope this makes sense.

0 Kudos
George_Thompson
Esri Frequent Contributor

As long as the DBA's are running rebuilding indexes (if using SQL Geometry) / statistics, you should be ok to leave them out of the script.

I am not sure of all the risks with running the compress as a non-SDE account. If it seems to be working, with no errors, you may have a good workflow. It would be best practice to use the SDE user.

 

--- George T.
VinceAngelo
Esri Esteemed Contributor

It's clear why the DBA team would restrict DBA access to GIS administrators. It's also clear why GIS administrators would keep the SDE password away from DBAs.

It's not clear why the GIS administrator doesn't have SDE user access. This is a clear violation of SLA (Service Level Agreement) protocol.  Note that the SDE user should not have DBA privileges (except during upgrade, and then only briefly), so there really isn't any reason for the DBAs to restrict that account. 'SDE' should only be used for enterprise geodatabase administration, which is why it's clearly in the GIS admin responsibility zone.

Even if the extra account works perfectly for the most frequent procedures, it's not safe to assume that it will work for all required operations, and the extra work and risk doesn't seem worth the limited gain.

- V