Re: Kernel locks or file locks?

Hi, I have a tool called lsof to list open files and the process that opened them. I will try to use it the next time this happens to see if I can kill the process and free up the table. Thanks Bob Brass jsturm@garnet.msen.com (Jeffrey Sturm) writes: >Robert Brass (bbrass@world.std.com) wrote: >: Hi, >: Sometimes a table gets locked up. We called informix and they said >: we needed to reboot the system to free up the locks, because we >: had kernel level locking. They said it was operating system dependant that >: determins whether we have file locks that can be easily removed or >: kernel locks which can only be removed by a reboot. I have never heard >: of such a thing. Is this true? Can I somehow switch to file level locking? >: Do I need to check with SUN? If it is true, is there anyway to get the >: locks released without rebooting? >The locks are maintained by the kernel but held by processes. If a lock >is not released it should be sufficient to somehow terminate the guilty >process (but without using kill -9, if possible). If locks are still held >with no DB processes running then you have problems with the OS. An OS >upgrade might be an appropriate remedy. BTW zombie processes can >never hold locks. It is possible for a process to become stuck in kernel >mode, so that it cannot be killed, but this is usually caused a kernel >bug. >It is unfortunately difficult to tell what locks are held and by which >processes at any time. I don't know whether Sun provides a tool to help >with this. All this information can in theory be gathered by probing >kernel memory. >File-based locking works poorly at best, and should be avoided. That's >why Informix doesn't use it when kernel-based locking is available. >Informix OnLine uses another locking scheme based on shared memory. It >is efficient and yet does not rely directly on the kernel, so it tends >to be more consistently implemented across different platforms. It also >does not require a reboot--bringing OnLine off-line is enough to clear >any locks held. (That can be just as traumatic as a reboot, however, unless >you have multiple OnLine instances running. Then only the affected instance >need be stopped.) There are other reasons to use OnLine in favor of SE; >you may want to consider it. >-Jeff