Is This Content Helpful?
We're glad to know this article was helpful.
When starting an ArcSDE service, the giomgr process is started and connects to the Oracle database as the SDE user. The giomgr's main job is to service requests for new connections and instance specific information. Giomgr also monitors gsrvr processes and cleanup, wherever it is needed.
When a client connects to ArcSDE in a three-tier setup, a dedicated gsrvr process connects to Oracle as that user.
To see if the giomgr process is connected to Oracle as the SDE user, use the following SQL:
select program, serial#, username
If the sdemon -o info -I users command is not reporting the currently connected users, the cause is that the giomgr process has most likely lost its connection to the RDBMS.
1) In Oracle, this can happen if Oracle is configured for server timeouts or if the administrative user kills the connection using Oracle DBA tools.
2) Also, if Oracle is shut down without shutting down ArcSDE services, there could still be ArcSDE processes running on the Server (giomgr and gsrvr’s). Although the giomgr process connection to Oracle is lost, the giomgr process may still be up, but it will not be able to communicate with Oracle. If Oracle is brought back up, the process does not reconnect.
In this scenario, no users are reported from sdemon commands nor is a new giomgr in the Oracle sessions table. However, the SDE.Process_information table can still have entries. These are orphaned process entries that only get cleaned out when the ArcSDE service is stopped and restarted, or by removing the orphaned entries manually.
If versions are being actively edited or reconciled when Oracle is shut down, orphaned rows may be encountered in the sde.State_locks or sde.Layer_locks tables. This may also require the ArcSDE service to be stopped and restarted (or the orphaned entries to be removed manually) after Oracle is restarted.
This situation can occur during a cold backup, when Oracle has been shut down with the immediate option without first shutting down ArcSDE.
Any RDBMS action, that causes the giomgr process to lose the connection, results in this problem occurring.
The solution is to shut down and restart the ArcSDE service after having restarted Oracle. This reconnects ArcSDE to Oracle as the Oracle SDE user.
If a situation is encountered where restarting the ArcSDE service is unable to clean out the orphaned entries in the SDE.Process_information table or SDE.State_locks table, the solution is to clean these out manually.
If this problem continues to occur, it must be determined why Oracle would be dropping the connection from the giomgr process.
For further information on the giomgr and gsrvr processes in ArcSDE 9.0 or 9.1, refer to the "Managing ArcSDE Application Servers" book available on the ArcSDE installation CD. For ArcSDE 9.2 and later releases, consult the ArcGIS Web help.