Problem with Progress: shared memory

Kopperton

Member
I am having a huge problem! After some update to Unixware server here is the error:

SYSTEM ERROR: Can't attach shared memory with segment_id: 1999 for /db/nxt
There is no server for database /db/nxt. (1423)


ran:
# proutil -C dbipcs
PROGRESS Version 9.1D09 as of Tue May 20 03:27:00 EDT 2005
PROGRESS SHARED MEMORY STATUS
ID ShMemVer Seg# InUse Database
0 - - - (not PROGRESS)
1 - - - (not PROGRESS)
2 - - - (not PROGRESS)


system is Unixware. Help please!
 

bulklodd

Member
I don't know the reason. But I suspect the problem can be solved by moving database files into another folder. Don't forget about 'prostrct repair'. I can assume you can just use another symblic link name to start database without moving of it.
 

Kopperton

Member
Something is weird here.
I tried your suggestion bulklodd. Both ways I get the following:

ERROR: Unable to locate database plugin - insure AdminServer
is running and is properly configured (DBMan023)
 

vinod_home

Member
Hi,

This is a simple error. Lookup the progress knowledge base always..

Status: Verified

SYMPTOM(s):

.lk file present in database directory

Database fails to start.

There is no server for database <>. (1423).

System Error: Can't attach Shared Memory with segment_id: <> for <>

CAUSE:

Database was not shut down before Server was rebooted.

FIX:

Remove .lk file and then restart the database
 

bulklodd

Member
Probably you're right. But it seem to me 'lk file' problem was fixed in PROGRESS 8.2. I saw this problem once on Unixware, renamed db and forgot about it :)
 

Kopperton

Member
remove .lk file. same thing.

here is the odd part! I ran "proutil -C dbipcs" and look what I get:

PROGRESS SHARED MEMORY STATUS
ID ShMemVer Seg# InUse Database
0 - - - (not PROGRESS)
1 - - - (not PROGRESS)
2 - - - (not PROGRESS)
199 9118 0 No /db/nxt


just for info:
SHMAX is 75000000, the physical memory is 2Gb
swap is 730mb free

more weird errors:
semGetId: Second call to dbMSG008
There is no server for database /db/nxt. (1423)
 
KB P27242, 15912 details a similar problem, and suggests deallocating the segment incorrectly attached to the DB.

I do not have the expertise to know if this is the correct approach for you.
 

Kopperton

Member
can not seem to find it but what do you mean "deallocating the segment incorrectly attached to the DB"? This database worked previously. Now I can not even re-install.
 
Kopperton said:
can not seem to find it but what do you mean "deallocating the segment incorrectly attached to the DB"?


Here's the KB entries I mentioned:


-------

P27242:


FACT(s) (Environment):

UNIX

SYMPTOM(s):



Shared-memory segment already exist for <database-name>. (1172)

Invalid address to attach the shared memory segment (1173)

SYSTEM ERROR: Invalid shared memory segment identifier (1174)

SYSTEM ERROR: Unspecified shared memory error errno= (1180)

Shared memory in use by another process. (1260)

There is no server for database <dbname>. (1423)

CAUSE:

Shared memory for the database is still being addressed by the system
even though the database is no longer running.

FIX:

The memory segment must be identified and removed.

1. Use Progress command "proutil -C dbipcs" or UNIX command "ipcs" to
identify shared memory segment

2. Use the UNIX command ipcrm -m (ID#), to remove the shared memory
segments for the database which has crashed and you wish to restart.
(See the man pages on your system)

On Linux RedHat 7.2 and 7.3 the option to remove the shared memory is
ipcrm shm <id >

-----

15912

GOAL:

How to find Shared Memory used by database proutil -C dbipcs

GOAL:

How to find and remove invalid or orpahned Shared Memory using dbipcs
and IPCRM.

FIX:


In some support cases you may need to know what Shared Memory
Segments are attached to Progress Databases. (For example; in the case
of a database crash where the shared memory was not released and you
cannot restart the database - when you are getting a 'shared memory
already in use' error) In cases like this to determine what shared
memory segments are used by databases use the command:

proutil -C dbipcs (notice no dbname!)

This will display all databases on system and the shared memory ID
used by each as in the example below.

PROGRESS SHARED MEMORY STATUS
ID ShMemVer Seg# InUse Database
68 - - - (not PROGRESS)
100 3 0 YES /db/work5/sports
101 3 1 - /db/work5/sports
120 3 0 NO /db/work5/test
150 2 - - (unsupported shared memory version)


ID indicates the shared-memory ID.

ShMemVer specifies the shared memory version.

Seg# indicates the shared-memory segment number. One database can own
more than one segment.

InUse Specifies whether the segment is in use. YES or NO are display
only if the segment # is 0. All other segments show a dash(-)

Database represents full pathname to database - This column will even
represent non-progress db's and different versions of progress db's (
an unsupported shared memory version (-) is another version of
progress)
You can then use the UNIX command ipcrm -m (ID#), if necessary, to
remove the shared memory for the database which has crashed and you
wish to restart. (See the man pages on your system)

To see the amount of shared memory in use by a database, use the
PROMON activity screen for that database.


-----


Lee
 

Kopperton

Member
hmmm very very weird things are happening...

/etc/conf/bin/idtune -g SEMMSL

gives me:
300 150 25 300

that is bad. How can I maximize it?

---
/etc/conf/bin/idtune SEMMSL 2000
UX:idtune: ERROR: The requested value for Tunable Parameter SEMMSL, 2000,
is higher than the upper limit in mtune, 300.
SEMMSL left unchanged.
 
Top