nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Enterprise Geodatabase Maintenance Process Using non-SDE account

Raj-Chavada

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?

Encontre mais publicações marcadas com

Enterprise geodatabase

Geodatabase Administration

Versioning

Accepted answers

VinceAngelo

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

All comments

George_Thompson

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 .

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

Raj-Chavada

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.

George_Thompson

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.

VinceAngelo

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.

- V

Participe da Conversa

Membros conectados podem postar, seguir atualizações e mais. Novo aqui? Registre uma conta gratuita.

Links Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.