DB Shutdown

[USername70]

Hello, I am new to this site so please tell me if I am in the wrong forum for these questions.

I have a database version 9.1D running on 2003 server. The other day the database shutdown. It came right back, but I am trying to determine the cause in an attempt to prevent it in the future (what a concept, I know).

I have a few questions.

1.) What does "SRV", "Usr" and "BROKER" mean?
2.) What are the numbers next to them? i.e. "SRV 6", "Usr 43"
3.) Is there any meaning to the usernum values? Any where to see which user this is?
4.) From searching on the web I found out that the database will shut itself down to prevent corruption if a process has data "locked" and then dies. What does this mean exactly? Does it mean: If I am making updates to the database and my machine gets disconnected from the network or turned off?


From the logfile:
14:50:02 SRV 6: Logout usernum 225, userid $SYSAdmin, on CCHQ88HF1. (739)
14:50:04 Usr 43: Userid is now $SYSAdmin. (708)
14:50:06 SRV 6: Logout usernum 224, userid $SYSAdmin, on CCHQ88HF1. (739)
14:50:10 SRV 2: Logout usernum 237, userid $SYSAdmin, on CCHQ88HF1. (739)
14:50:47 BROKER 0: User 43 died with 1 buffers locked. (2523)
14:50:47 BROKER 0: Begin ABNORMAL shutdown code 2 (2249)
14:50:48 SRV 2: Stopped. (2520)
14:50:48 SRV 1: Stopped. (2520)
14:50:48 SRV 7: Stopped. (2520)
14:50:48 SRV 3: Stopped. (2520)
14:50:48 SRV 4: Stopped. (2520)
14:50:48 SRV 6: Stopped. (2520)
14:50:48 SRV 5: Stopped. (2520)
14:50:48 SRV 9: Stopped. (2520)
14:50:48 SRV 8: Stopped. (2520)
14:50:48 BROKER 0: Disconnecting dead user 43. (2527)
14:50:50 Usr 42: Logout by $SYSAdmin on CON:. (453)
14:50:50 Usr 41: Logout by $SYSAdmin on CON:. (453)
14:50:51 BROKER : Multi-user session end. (334)

Thank you in advance for your time!

 

[TomBascom]

You are in the right forum!

9.1D is ancient, obsolete and unsupported. You should upgrade.

SRV is a "server" process for a pool of remote clients. A USR is one of those clients (a USR can also be a local "self service" client if it is running on the same physical server). Remote clients use TCP/IP sockets to communicate with the database. Self service clients use shared memory. A broker is the process that listens for connection requests from clients and establishes the mapping between a client and a server (it will also start new servers if needed).

The numbers are the connection or "usr" number. Thing of it as a session Id.

You can see more information regarding live users in PROMON or by writing a VST (Virtual System Table) query. Or download ProTop

The "lock" in question is a fine grained lock (or "latch" or "mutex") on shared memory. It is not a record lock. The db doesn't really shutdown to "prevent corruption". It shuts down because a user who was holding a latch died without cleaning up after themselves. The latch is still held in that users name so in actuality nobody who wants to work with the database is able to proceed -- they are all frozen. The db engine then has two choices -- clear the latch and carry on, or shutdown. Most times the information necessary to safely clear the latch is not available -- it was in the private memory of the process that died. So the only viable choice is to shutdown. But data was never actually at risk of corruption at any time.

 

[USername70]

Thank you Tom. By viewing the log file, does it indicate that the "issue" was initiated or "caused" by the machine named "CCHQ88HF1". I know that "CCHQ88HF1" is the name of a computer that attaches to the database. Maybe my igorance is causing me to ask the wrong questions. I am trying to determine why the database shut itself down..

 

[TomBascom]

User 43 caused the problem. There isn't enough log file shown to say where that user came from. (There should be more info about user 43 higher up in the log).

 

[USername70]

Is this "14:50:04 Usr 43: Userid is now $SYSAdmin. (708)" the same user as "14:50:47 BROKER 0: User 43 died with 1 buffers locked. (2523)"? I dont see anything that would indicate which machine was "User 43"..

 

[TomBascom]

There are should be two messages at login. i.e.:

   103: (452)   Login by tom on /dev/pts/1.
   103: (708)   Userid is now tom.

They may be separated by other messages for various reasons and the userid might be different if the Progress login name deosn't match the OS name. But the first one tells you what device user 103 logged in with, the second what the eventual Progress userid is. You're only showing the 2nd message for user 43 above so we cannot tell what device that user cam from. You need to search backwards in the log for the previous user 43 messages.

 

[rstanciu]

This abnormal termination of the process will still hold latches (locks) in shared memory.
Typicaly cause to terminate abnormally:
1. sending a kill signal (other than SIGHUP) to the process
2. shutting off a terminal while in an active Progress session and the terminal (PC with terminal emulation does not send a SIGHUP).
3. the process aborting as a result of a system error.