We have a database maintenance Python script (very similar to this one Esri recommends) and it kills all users with arcpy.DisconnectUser() before performing maintenance operations. This script is executed by Task Scheduler on Windows Server 2012 r2. Our ArcSDE 10.0 run on Oracle 11g on a Linux server. Here is an older, similar discussion that ended in a suggestion to enable TCPKEEPALIVE.
What we've found is that when the script kills all users, all connections in the SDE.Process_Information table go away (as expected) but the associated database/os process for each connection (gsrvr) remains. This is a problem because they build up and eventually hit the limit set in the Oracle initialization parameters. With further testing, we found that running the kill all users SDEMON command locally on the Linux server would kill the connections and clean up all associated gsrvr processes and sessions.
We are currently testing two possible solutions:
My questions are:
Solved! Go to Solution.
We decided to enable the TCPKEEPALIVE option using the default KeepAlive ettings in Linux. We've continued using the same Python script with arcpy.DisconnectUser() and closely monitoring the sessions and processes in V$SESSION and V$PROCESS. It seems that TCPKEEPALIVE is reliably cleaning up the old processes (and sessions) after arcpy.DisconnectUser(). This will be our solution until our next ArcSDE upgrade.
One could argue this is a bug, but even if it is a bug, there is a low probability it will be addressed. The issue appears to be cleaning up the ArcSDE application server connections, and the ArcSDE application server no longer exists at ArcGIS 10.3. Sure, ArcGIS 10.3 clients can connect to existing ArcSDE application servers (I think), but Esri won't put a high priority or much resources into addressing an issue with arcpy.DisconnectUser when the issue is dealing with retired functionality.
The SDE command line tools also don't exist at 10.3, but if older versions of them are working for you, I would say that seems like the best path forward. Regarding Plink, why not just install the SDE command line tools on the machine the database maintenance script is running on. That way, you wouldn't have to use Plink and remote into another machine.
Since the ArcSDE application server is dead, I would suggest you start considering changes to your architecture in the coming year or so. In the meantime, goes with whatever works for you because getting potential bugs fixed for retired functionality is an uphill battle.
Thank you Joshua, I appreciate your reply. I'll try running SDEMON from the Windows Server like you suggested. We will continue testing and I'll post back if there are any significant developments.
We decided to enable the TCPKEEPALIVE option using the default KeepAlive ettings in Linux. We've continued using the same Python script with arcpy.DisconnectUser() and closely monitoring the sessions and processes in V$SESSION and V$PROCESS. It seems that TCPKEEPALIVE is reliably cleaning up the old processes (and sessions) after arcpy.DisconnectUser(). This will be our solution until our next ArcSDE upgrade.