We routinely exceed ArcSDE's connection limit, about once a week. Many of the "connections" are nothing but orphaned records in the SDE.PROCESS_INFORMATION table. Is there any way to clean up these connections periodically? I just service packed ArcSDE to 9.3.1 SP2, hoping this would resolve the problem. (It did not.) Currently I restart the arcsde service to clean up the connections, a pretty inelegant solution.

This is the error, by the way:

Failed to connect to database. Maximum number of connections to instance exceeded

My workaround:

My solution was simple: restart the SDE service weekly, and double the number of allowed connections. This is of course not a solution; shame on ESRI for shipping enterprise software that requires such a workaround. After all, it's still possible to exceed the maximum connections; I can only hope that our current level of use doesn't lead to this.

I altered the init.d script to prevent sdemon from prompting the user to confirm they want to stop the service (this is what the -N argument does). I added a restart option as well.

# arcsde Init file for starting and stopping ArcSDE 9.3
# chkconfig: 35 90 40
# description: ArcSDE startup script

# Source function library.

. /etc/rc.d/init.d/functions


case "$1" in
echo -n $"Starting ArcSDE:"
su - $SDE_OWNER -c "$SDEHOME/bin/sdemon -o start -p pwd"
echo "OK"
echo -n $"Stopping ArcSDE:"
su - $SDE_OWNER -c "$SDEHOME/bin/sdemon -o shutdown -p pwd -N"
echo "OK"
cd "$CWD"
$0 stop
sleep 5
$0 start
echo $"Usage: $0 {start|stop|restart}"

Then I created a cron job to restart the service once weekly:

# restart arcsde once weekly at 5am Saturdays
0 5 * * 6 service arcsde restart

I also increased the maximum number of allowed connections from 64 to 128 by editing the $SDEHOME/etc/giomgr.defs file:

CONNECTIONS      128     # maximum number of connections
                         # NOTE:  On windows machines, you may need to
                         # increase server non-interactive desktop memory.
                         # Consult the ESRI support site for more information.

Then I imported the new settings:

$ sdeconfig -o import -f $SDEHOME/etc/giomgr.defs -i esri_sde -u sde

That was it. We'll see how it goes.

  • 1
    How have you verified that the entries in the process_information tables are indeed orphaned connections? Sep 21, 2010 at 15:00
  • They are not all orphaned, of course, but I have found 2-week-old connections from workstations with uptime < 24 hours.
    – nw1
    Sep 21, 2010 at 15:41
  • 1
    One thing I've been told: if orphaned connections exist, the process to clean them up isn't kicked off until there's a collision. Meaning, if you've got max connections set to 100 and there are 50 entries in process_info and let's say 20 of which are orphaned, connections won't be cleaned up until SDE tries to put that 101st entry in process_info. Anyway, you're saying your'e actually getting the max connections exceeded message so that process to clean up connections should be getting triggered. I'd investigate how people using those workstations are disconnecting. Sep 21, 2010 at 16:31

5 Answers 5


There's an esri knowledge base article that talks about how orphaned connections are SUPPOSED to be handled. Of course, as others have pointed out, the simple (but not necessarily elegant) solution is to just restart your service.


You might also consider having your users direct connect and bypass the service altogether. This cleared up some issues I was having with services getting hung and resulted in some slight increase connection speed for users.

  • Yes, and this also reduces the load on the machine; since the users PC handles the DAL keeping SQL just as a datastore versus having it do more programmatic support of the data.
    – D.E.Wright
    May 6, 2011 at 16:24

This is an answer that was sent from my supervisor to a client yesterday on this issue.

To increase the number of ArcSDE connections the following type of syntax can be used on the ArcSDE server:

sdeconfig -o alter -v CONNECTIONS=140 -u sde -p sde_password -i sde_instance

where "sde_instance" is the ArcSDE service name or port number.

You can verify that this change has been made using the command:

sdeconfig -o list -u sde -p sde_password -i sde_instance.*

  • Yes, in fact I did this in addition to creating a cron job that restarts the arcsde service once weekly.
    – nw1
    Sep 23, 2010 at 12:26

We always just bounced the server periodically to do this...


Have you read this post on the ESRI Forum it's bit old but there are scripts that does what you want to do?

  • I did run the script posted by T B once, but it had no effect. It's almost 5 years old, so I suspect too much has changed in the environment since then.
    – nw1
    Sep 21, 2010 at 15:37
  • I wouldn't assume too much has changed on the SDE side. Got a link to the script you ran? Sep 21, 2010 at 16:33
  • I don't think there should be any big differences between 9.2 and 9.3.1, ESRI changed the way geodatabases are handled but that's in ArcGIS 10. We are restarting our ArcSDE as a lot of others are suggesting, so I can't share any experience on using the scripts. Sep 21, 2010 at 17:00
  • the GDB stuff changed (tables with GDB prefixes were consolidated), but I'm pretty sure the underlying SDE stuff is the same. Sep 21, 2010 at 18:18
  • @Swingley I totaly agree with you. Sep 21, 2010 at 18:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.