Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

We have an issue where users do not close ArcGIS and layers get locked, and sometimes this affects our nightly updates for some of the layers. I know you can individually remove a lock using the ArcSDE command (which we do), but does anyone know of a way I can create a script that can be run every night to get rid of the locks?

We are running ArcSDE 9.2 and Desktop 9.3.1.

Thanks

share|improve this question
2  
What flavor/version of database - SQL Server, Oracle, etc.? –  Chad Cooper Jan 18 '12 at 12:16

3 Answers 3

up vote 1 down vote accepted

For this scenario I run the sdemon command from a python script using the following:

import subprocess
#Kill all ArcSDE connections
subprocess.call('sdemon -o kill -t all -u <sdeadminusername> -p <password> -N', shell=True)


#Kill all Direct Connections, (ArcGIS 10.0 only)
subprocess.call('sdemon -o kill -t all -i sde:sqlserver:SERVERNAME-u <sdeadminusername> -p <password> -D sde -N', shell=True)
share|improve this answer
    
'sdemon -o kill -t all -i sde:oracle11g -s SERVERNAME -u <sdeadminusername> -p <password> -D sde -N' –  twisig Jan 19 '12 at 13:47

Used to run into this problem a lot, and our DBAs had what they called "the kickout script" that they ran on the database, which in our case was SQL Server 2005/2008. Basically, you are killing all connections to the database, which boots out your users, which in turn releases the locks. We had to do this in order to run nightly updates on SDE featureclasses.

I'm not going to include any SQL here, as there are many ways to accomplish this. If you have a DBA (or know one), get with them, they should be able to help. For examples, here is a post on DBA.se for SQL Server and here is one on SO regarding Oracle. I'm including those two database flavors as they seem to be the most common out there for SDE.

You can then wrap up the SQL into a stored procedure and schedule the script to be run using something such as sqlcmd for SQL Server:

sqlcmd -S <machine_name> -E -d <database> -Q "exec <stored_procedure>"
share|improve this answer

The sdemon -o kill -t all switches will do the same thing except at the sde level.
You should try to have all connections closed prior to doing that.
It is not a bad Idea to also roll all versions up to default (if that is your model), and I normally compress the db before and after killing all state, table, and layer locks.
sdemon run alone will get you all the options including status, and info.

share|improve this answer
1  
You're right, Brad. I'm pretty sure our DBAs did a sdemon -o kill -t all before they ran the SQL script to kick all users out at the DB level. –  Chad Cooper Jan 18 '12 at 14:32
    
I think if you kill all sde pids it will lose all connections. Perhaps they ran the kickout and then the sdemon? –  Brad Nesom Jan 18 '12 at 15:20
    
Not sure what the order was honestly, and that was at a past job. To us it was sort of a "black box" job that the DBAs ran, as we of course didn't have that level of access to production. –  Chad Cooper Jan 18 '12 at 15:55
2  
In 9.x sdemon -o kill did not kill direct connections. That's probably why they ran the database level kick routine. –  Jeff Berry Jan 19 '12 at 1:06
1  
Also, if you have map services running, it is necessary to stop those services as well. If you simply kill those connections, they will reestablish the connection if the map service is in use. See the answer to this question for a script to shutdown maps services. link –  Jeff Berry Jan 19 '12 at 1:22

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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