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.
3 year olds were not among our target customers
They make excellent testers.
>>1) You start an offline backup.
Having experience with other RDBMSes I would say, the word "offline" -- is asking for trouble in the first place. Everything should be online ( backups, schema changes, index rebuilds, db analyses etc). I understand that kill -9 and deleting .lk look bad. But for me the very first thing "offline backup" is looks as bad as the rest.
>> George wrote:
>>It would be hard to do a bad thing if the content of .lk file (265 bytes) would be a part of master block.
The .lk file was implemented in version 5 or may be earlier?
I believe it would be a good idea to reconsider what was done 25-30 years ago and store the contents of .lk somewhere else, like in master block as George suggests. It will eliminate all horror stories with deleting .lk at once. IMHO, it is worth putting on a road map.
i agree that would be better. but, in the event something goes wrong (i.e. crash, etc) and the database cant be started again, there would have to be a utility to clear the info in the master block.
> there would have to be a utility to clear the info in the master block.
That is the point. Utility will do all necessary checks unlike the 'rm' command run by DBA who may not understand the consequences of removing lk file.
the utility will need a -F switch