Salesforce

BI Timestamp mismatch after removing database .lk file and starting a second session against database while first session is still running.

« Go Back

Information

 
TitleBI Timestamp mismatch after removing database .lk file and starting a second session against database while first session is still running.
URL NameP32238
Article Number000128512
EnvironmentProduct: Progress,OpenEdge
Version: All supported versions
OS: All supported platforms
Question/Problem Description
Date/Timestamp mismatch errors truncating the before-image file 886 887 888
Date/Timestamp mismatch errors connecting to database 886 887 888
Progress session terminated Abnormally but process remain running at the OS level.
.lk file deleted by user
New session started while old processes are still running.
Steps to Reproduce
Clarifying Information
Error Message** The database was last used <date/time>. (886)
** The before-image file expected <date/time>. (887)
** Those dates don't match, so you have the wrong copy of one of them. (888)
Cannot find or open file dbname.lk errno = 2. (43)
Defect Number
Enhancement Number
Cause
  • If a Progress session dies but the process does not end it may still write to Progress files. 
  • If the .lk file is removed a new session can be started against the database, while the previous session is still writing.
  • Whenever a Progress process is started with the immediate intent to connect to a database, the process checks if there is a .lk file.
  • If the Progress process does not see the .lk file, which is the indicator to Progress that the database is in use, it will start but the new Progress session cannot update all database files because some of those files will likely still be in use by the old process(es).
  • However the files it does modify, will now have a time stamp which will be different from all other database files.
  • This will cause the database to have a timestamp difference when the next process which has full control of all files detects the file(s) with different time stamps.
  • The following entries were found in the database showing that Watchdog was running at the same time as the Truncate:
    proutil -C truncate bi session end. (334)
    WDOG 7: Transaction backout completed. (2253)
    WDOG 5: Stopped. (2520)

    This is an example where two processes were running which theoretically can not coexist:
    • Watchdog can only run if a database is served.  
    • Proutil can only truncate a bi if a database is not served.
      The .lk file was removed without shutting down the database and then the truncate was run.
Resolution
To avoid re-occurrence when a Progress session dies, ensure that the process is also gone at the Operating System level. If the process is still running, be sure to remove it completely. Before deleting the database .lk file make sure there are no processes accessing the database.

To recover, revert to site-specific DR plan which may include:

a.  Failover the target replication database. First ensure that all available AI files have been applied. See Article   b.  Restore from the previous backup, incremental backups and roll forward the after image files (if enabled).

Under the described circumstances, forcing into the database by skipping crash recovery is ill advised.
 
Workaround
Notes
Keyword Phrase
Last Modified Date11/20/2020 7:23 AM

Powered by