Disconnect a user

[RandellMcGlynn]

Hi, I'm having an issue with SDE. As of now we have a lock on our SDE database that i cannot figure out who it is. It tells me the user is "SDE", of course this could be a number of people. Is there a way to disconnect the user "SDE"? I know it will knock off more than one user, but I am alright with that.

[JacobBoyle]

you can use the SDEMON command to kill a connection by Process ID (PID).  Remember, case counts!

sdemon �??o kill �??t {all | <pid>} [�??D <database_name>] [-s <datasource>] -i <direct_connect_string> �??u <user_name> �??p <password>

[RandellMcGlynn]

quick question:

When I want to start it back up, do I use the start command?

also how do I find out the correct PID? or should I just use "all" for -t? We only have one SQL Server so "all" should be fine correct?

[VinceAngelo]

How many users do you have connecting as SDE?  In an ideal world, the the number of
users that hold the SDE password is quite limited.  The SDE user should not ever own
spatial data, and should only be used to administer the ArcSDE installation.

Once a session is killed, it cannot ever be restarted.  Killing all sessions is generally a rare
occurance -- I wouldn't recommend using 'sdemon -o kill -t all' except under exceptional
conditions.

- V

[JacobBoyle]

How many users do you have connecting as SDE?  In an ideal world, the the number of
users that hold the SDE password is quite limited.  The SDE user should not ever own
spatial data, and should only be used to administer the ArcSDE installation.

Sadly, the scenario where people work from SDE seems to happen a lot more than I personally first thought.  I think there's still a disconnect between IT and GIS still.  I really hope that the changes that are coming in 10.1 will go a long way towards bringing GIS more into the general IT fold.

I also think that this is symptom of GISers being jack of all trades.

[RandellMcGlynn]

How many users do you have connecting as SDE?  In an ideal world, the the number of
users that hold the SDE password is quite limited.  The SDE user should not ever own
spatial data, and should only be used to administer the ArcSDE installation.

Once a session is killed, it cannot ever be restarted.  Killing all sessions is generally a rare
occurance -- I wouldn't recommend using 'sdemon -o kill -t all' except under exceptional
conditions.

- V

Let me see if I understand this correctly. The SDE user should not be used to do normal GIS tasks like, building map documents and such? Should each GIS user have their own username and password and work from the SDE that way?

The reason I need to kill the session is because there is a lock on the one dataset we are using and I cannot register it as versioned, and it is saying the lock is coming from the user "SDE" 4 times. I'm assuming this is because people have it open on their maps. In the past we would just restart the server, but I know restarting a server is supposed to be a last resort, so I'm trying to come up with a better solution to our problem.

Thanks

[JacobBoyle]

Let me see if I understand this correctly. The SDE user should not be used to do normal GIS tasks like, building map documents and such? Should each GIS user have their own username and password and work from the SDE that way?

Thanks

Yes, you should not be using SDE as a working account, SDE is meant to be used as administrative account only.

You have 2 options, you can inherit user names and passwords from your windows authentication you use in house, or you can setup user names and passwords in the database, both have their benefits and disadvantages.

[VinceAngelo]

There are many ways to organize, but best practice includes:
+ Reserve the 'SDE' user for administration of the instance; keep the password
closely held
+ Create "data ownership accounts" to actually own spatial data layers
+ Use DBTUNE keywords to distribute tables and indexes across the available
independent disks (treat a RAID array as one disk [or partition thereof])
+ Individual users should have their own login to the database
+ Use database roles (groups) to manage access to the tables, granting
users that need access the role(s) necessary to make edits
+ Web service(s) should use independent logins granted the minimum necessary
(often read-only) access to reduce the risk of DOS attacks.
+ While feature datasets appear to be an easy way to organize tables into
folders, they exist for managing complex data relationships that require all-
or-nothing access -- use them sparingly, and only for data that must be
edited with a shared long transaction across many tables.

Making fundamental schema changes (like versioning a table) requires exclusive
access to the table(s) involved. If the tables are part of a service, that service
must be stopped before the changes can be made. Shutting down the server can
be an acceptable way to get exclusive access, but Direct Connect connections
will also need to be taken offline to obtain some locks.

- V

[RandellMcGlynn]

Oh boy, I have a lot of work to do. Thank you for the guidance. Unfortunately I have more questions now.

Lets assume, I have some data layers that were created with one of the data layer owner accounts, and people are using the data (with non owner accounts). If I edited it with a owner account would it override any locks they might have created by viewing it?

So should all of my data feature layers (that do not have relationships) just be in the root of the database? or is there a better way to organize them than with datasets?

[VinceAngelo]

The documentation provides an overview on locks, but one of the key points is that
locks aren't ever overridden. Once you aquire a lock, you must relinquish it before
you lose it (unless your session is disconnected). That said, SQL edits don't pay any
attention to ArcGIS locks, so realtime updates can still be performed on layers with
non-exclusive read locks.

I wish I had a better answer for you, but RDBMSes have a fundamentally flat architecture;
when you use them you need to be using naming conventions for organization. I've used a
number of paradigms at different sites, but many of them have taken source, class, scale
topology, and/or projection into account:

NGA.DTED_LEVEL1_NW
NGA.VPF_WATER_RIVERS_1M_L
USGS.SRTM_3METER_WGS84

- V