A newly discovered "worst practice" - Forum - OpenEdge RDBMS - Progress Community

A newly discovered "worst practice"

 Forum

A newly discovered "worst practice"

This question is not answered

Imagine this:

1) You start an offline backup.

2) Someone notices that the db is not running -- so they execute their usual scripts to restart things.

3) Step #1 is to shutdown down any running databases and stop any left over processes.  The *scripted* method is: a) kill -9 any running _pro* processes, b) sleep 5 seconds and then do the same for _mpro* processes, do it again just in case you missed any, c) wait 5 more seconds and kill -9 any _sql processes, d) wait 3 seconds and rm *.lk, and then, finally, ipcrm any shared memory segments that might be lying around.

3a) The shutdown script never even attempts a "proshut".  The very first thing it does is to "kill -9" stuff.

4) Now you can go ahead and start your db.

5) Notice that in step #3 no attempt is made to stop probkup?

6) After running for some time the db suddenly announces that the .lk file has disappeared and it shuts itself down.

7) When you try to restart it you discover that the bi file timestamp is out of sync with the database.

8) Interestingly -- the last message prior to the .lk file disappearing is that the backup completed.

9) If you restore that backup it is corrupt.

Something that I did not know:  probkup does not notice when its .lk file is deleted.  It also does not check when it is finished running to see if the .lk file is the same .lk file that it created.

--
Tom Bascom
tom@wss.com

All Replies
  • > Something that I did not know:  probkup does not notice when its .lk file is deleted.  It also does not check when it is finished running to see if the .lk file is the same .lk file that it created.

    The same is true, for example, for dbanalys (while dbanalys is a kind of read-only access).

    Single-threaded processes do not monitor for status of .lk files.

  • Why would they or should they?  The .lk file is there to protect the database from unauthorized access.  You remove the .lk file and bad things will typically happen.

    Mike

    Sent from my iPad
  • It would be a good idea if they at least noticed that the .lk file being deleted is not the one that the single-user session created and wrote an appropriate .lg message about that.

    But the real problem here is the shutdown script.

    --
    Tom Bascom
    tom@wss.com

  • Another slightly annoying detail that I had not noticed earlier is that probkup does not write anything obvious in the .lg to indicate that a backup is online or offline.  There are some subtle differences in the messages but nothing that jumps right out.

    --
    Tom Bascom
    tom@wss.com

  • I agree completely that removing the .lk file is asking for trouble.

    In a way I think it is helpful to have a nice, simple, and easy to reproduce example of one sort of trouble that can ensue.  

    --
    Tom Bascom
    tom@wss.com

  • Scripts should not delete .lk files but they can easy to do this.

    It would be hard to do a bad thing if the content of .lk file (265 bytes) would be a part of master block.

  • Is this about database backups or a way to send the database to the shredder? :-S

    The person who wrote the script probably hated Progress. Nice topic for the upcoming PUG! :-)

  • The offline backup was unusual.  Its role in this worst practices story is that it exposed the flaws of the shutdown script.

    --
    Tom Bascom
    tom@wss.com

  • By the way, I did wrote a script that deletes .lk file - the script builds the indexes after D&L and in parallel it runs tabanalys for table's areas. There are no reasons for offline tabanalys/dbanalys to create .lk file but it does. And dbanalys ignores the -RO option. That is why I was forced to play with .lk file.

  • Something used in specific circumstances like that (and which is written and used by an expert) is much less worrisome than something that runs every night.

    --
    Tom Bascom
    tom@wss.com

  • > On Jun 24, 2019, at 9:46 AM, George Potemkin wrote:

    >

    > wrote a script that deletes .lk file

    your use case, though it makes some sense, is not one that was contemplated.

  • 24 years ago (18 Oct 1995) Tom Bascom wrote:

    "The .lk file is a loaded pistol stored on a 3 year old's nightstand.  (With an extra large trigger that little fingers can pull more easily.)"

    Tom, can I use this phrase to make a tattoo? ;-)

  • Can I get a picture of that, please?!

    Sent from Nine

    Von: George Potemkin <bounce-GeorgeP12@community.progress.com>
    Gesendet: Montag, 24. Juni 2019 22:21
    An: TU.OE.RDBMS@community.progress.com
    Betreff: RE: [Technical Users - OE RDBMS] A newly discovered "worst practice"

    Update from Progress Community
    George Potemkin

    24 years ago (18 Oct 1995) Tom Bascom wrote:

    "The .lk file is a loaded pistol stored on a 3 year old's nightstand.  (With an extra large trigger that little fingers can pull more easily.)"

    Tom, can I use this phrase to make a tattoo? ;-)

    View online

     

    You received this notification because you subscribed to the forum.  To unsubscribe from only this thread, go here.

    Flag this post as spam/abuse.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Sure :)

    I remember that thread.

    And, as Mike asks, I'd like to see a photo of that.

    --
    Tom Bascom
    tom@wss.com

  • Or a live-tattoo-happening in Manchester, NH in October &#128521;

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.