Unable to restart a database after an outage with errors "Can't attach shared memory with segment_id" and 1423

DBDOWN after an outage with errors "Can't attach shared memory with segment_id" and 1423
Unable to restart database after a power outage with error 1423.
Database cannot be opened with error (1423) 
Database will not restart after and unintended outage or deliberate reboot without first gracefully shutting databases down with: Database fails to start or connect in single user mode after a black out with error 1423
Single user connection cannot attach shared memory after a server reboot.
 

There have been no PROSTRCT REPAIR operations on any databases on this file server
There have been no OS copies of this database that have since been started without first repairing the database structure
This database has not been restored with PROREST with missing backup volumes from a multiple volume backup

A .lk file still exists from prior to system power outage or reboot while the database is running or still in the process of being shutdown.

The .lk file has several pieces of information to prevent multiple processes taking control of the database simultaneously.

One of these pieces of information is the primary shared memory segment ID that the database broker creates when the database is served that is also stored in the database Master Block.

Since a machine outage occurred, the normal database code to remove the .lk file was unable to run, therefore it remains on disk after the server is rebooted.  Subsequent attempts to start the database identify the old .lk file with invalid information.

The message reported indicates that the process which attempted to connect to the database read the .lk file and then tried to attach to the shared memory segment listed in the file which is no longer possible since all shared memory segments were destroyed during the machine reboot and have since been used by other shared-memory processes.

Upgrade to OpenEdge 10.2B or later. Where OpenEdge has been enhanced to first attempt to verify there is no valid shared memory segment that matches the one in the .lk file and will remove the outdated .lk file before attempting to access the database.

If you are already using OpenEdge 10.2B or later and the issue still persists, then use the workaround below.

1. Check that there are no processes using the DB files.
2. If no processes are accessing the database files, then remove .lk file that was left behind
3. Truncate the database BI before starting the database:
If no errors are encountered while truncating the BI file the database will be ready to start normally after the truncate BI completes, otherwise you will need to go to backup.

While server outage is unavoidable at times, a reboot is manageable and the process should be reviewed in terms of shutting down the AdminServer (if in use) and databases prior to issuing the reboot.

Progress Articles:

 The database .lk file.  
 PROUTIL -C HOLDER or BUSY incorrectly shows db as running after a server reboot  
 How to find and remove invalid or orphaned Shared Memory using dbipcs and IPCRM.  
 Shared Memory client connects to the wrong database after power failure or abnormal shutdown