Kbase P26005: Database eventually shuts down due to lack of available semaphores at startup (6270)
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
7/25/2008 |
|
Status: Verified
SYMPTOM(s):
Error incrementing semaphore, current value = 0, error = 298 (6270)
Unable to clear semaphore. (1715)
semRdyLog: semUnlkLog ret = -1
Abnormal shut down with lock stack underflow 0
Begin ABNORMAL shutdown code 2 (2249)
No mulit-user session end
Lock file still present
Database started through Progress Explorer
Many Progress databases running concurrently
proshut dbname -by appears to hang
cannot start a promon session indicating that the login semaphore is locked
Backup 24 hours old, would prefer not to have to go to it
Database restarted daily
FACT(s) (Environment):
Progress/OpenEdge Versions
Windows
CAUSE:
The database was started without enough semaphores. At the beginning of the multi-user session, the following errors were posted to the logfile alerting the database administrator of such:
BROKER 0: Error incrementing semaphore, current value = 0, error = 298 (6270)
BROKER 0: Unable to clear semaphore. (1715)
BROKER 0: semRdyLog: semUnlkLog ret = -1
error 298 on Windows means "Too many posts were made to a semaphore"
There is a limit of 65,534 (64KB-1) posts allowed per event semaphore. If this limit is reached, then the ERROR_TOO_MANY_POSTS return code is returned.
Evidently enough semaphores were allocated for Progress to start and allow a certain number of users to connect. However, when Progress started running out of semaphores, the Abnormal shutdown was triggered and ran out of resources to complete the shutdown.
FIX:
Clear shared memory by rebooting the system as follows:
1.) Change the Progress AdminService (if in use) startup to MANUAL
2.) Send out a shutdown alert to users
3.) Gracefully shut down all other databases on the server
4.) Reboot the server
5.) Single user access the database in question to force roll back recovery so that all incomplete transactions are rolled back.
6.) Truncate the bi file and backup the database
7.) Re-start the database
8.) Send out a re-connect alert to users
Consider your current memory requirements - for each database on the system, you are addressing the product of:
Number of Database Buffers (-B) x Database Blocksize (-blocksize)