Appropriate Specs for a new ArcSDE Server

[AdamCrateau1]

Hello,

We are planning to replace our ArcSDE Server instance (VM server) with another, and wondering what system-specs are recommended.  Our current server has 4.00 GB RAM and a single 2.0 GHz Processor.   Is this sufficient?  

From my understanding once the geodatabase is setup on the RDBMS, the SDE server is more of a background process for license validation, etc, and not directly involved with Client::Server traffic.  Is this correct?

We are currently experiencing latency and slow performance with our 10.2.2 geodatabase in a 2012 SQL environment. Our plan is to create a new 10.4.1 GDB hosted in 2014 SQL, load the data onto the new and then abandon the old.  This will give us an opportunity to increase the specs on the SQL server, as well as align the GDB version with our Desktop version (10.4.1).

The question remains for me, what impact does the ArcSDE Server play in this scenario... Does it have potential to be a bottleneck?

Thank you

[AlexanderBrown5 · Accepted solution]

Adam,

As of 10.3, there is no longer an installer for ArcSDE.  The three tiered ArcSDE application connections are now favored by direct connections.  

Of course, if you have older applications running on your production environment making ArcSDE application connections...than you need to determine a plan to update those apps (if any, are they useful?).  If they are essential in any way, upgrading to 10.4.1 will break all ArcSDE application connections.

Here is a good resource:

Where is the install for ArcSDE 10.3? | Support Services Blog 

~Alex 

[AdamCrateau1]

Very good, thank you Alex.

In that case, how does the licensing aspect work?    Is the licensing information baked into the geodatabase, or is there some validation going on against a codefile or other service?  Is there an online resource you could point me to that helps define how licensing works with enterprise GDBs?

Thanks!

[AsrujitSengupta]

Each sde geodatabase has its own licensing. This can be checked in the Server_config table, AUTH_KEY parameter, inside the geodatabase.