Kbase P136887: Database did not shutdown when using scripts that call out dbman -stop to shutdown the database.
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
03/02/2009 |
|
Status: Verified
SYMPTOM(s):
Database did not shutdown when using scripts that call out dbman -stop to shutdown the database.
Do not see message: Shutdown request received from Admin Server. (8852) being written to the database log file.
Database log file showing message 8848, 9151, 9148 and 8845.
Connection to Admin Server lost. (8848)
Admin Server is shutting down, connection terminated. (9151)
Registration ACK not received, msgcode=<msgcode>. (9148)
Registration ACK not received, msgcode=-2. (9148)
Error registering with Admin Server. (8845)
When the AdminServer is being shutdown it posts an 8475 error to the admserv.log file.
Failure sending packet to broker process. (8475)
FACT(s) (Environment):
Database was started via scripts that issue the dbman -start command.
AdminServer is being shutdown by a user.
Linux
OpenEdge 10.0B05 Service Pack
OpenEdge Category: Database
CAUSE:
The AdminServer lost communication with the database prior to the database shutting down. This is because the script being used to stop processes did not validate that they were truly stopped prior to shutting down the AdminServer. This results in the AdminServer no longer being able to communicate with the database or other broker processes. Therefore any attempts to make use of the commands (dbman, asbman etc...) to shut down or stop these processes will fail until the AdminServer is brought back online.
FIX:
The issue is associated with the scripts being used to shutdown the database, AppServer Brokers and then finally the AdminServer. When using scripts to shutdown database brokers, AppServer Brokers etc. the recommendation is that the script validate that these brokers have been stopped prior to stopping the AdminServer. Failure to ensure that these brokers have stopped prior to stopping the AdminServer can result in these Servers no longer being registered with or able to communicate with the AdminServer, until the AdminServer is restarted.
To check on the status of a database you can use one of the following commands:
dbman -query -db dbname (Queries the Connection Manager for the status of the database db-name. )
proutil dbname -C busy (This command will return a message indicating the state of the database. The command also has return codes which can be queried via a UNIX or Windows command line or script for the state of the database.)
To get the database status, you must run PROUTIL with the BUSY qualifier and test the command return code in a UNIX script or Windows batch file. The return codes for the BUSY qualifier ar:
Return Code: Description:
0 Database is not in use.
6 Database is in use.
64 Database is in process of starting up.
proutil dbname -C holder (This command will also provide you a message as to the state of the database. This command also has return codes that can be queried via a UNIX or Windows command line or script.)
Return Code: Description:
0 Database is not in use.
14 Database locked by single user, PROUTIL or RFUTIL.
16 Database open in multi-user mode.
Sample scripts making use of the proutil command line options (BUSY and HOLDER) are available within the documentation in the Database Administration Guide.