Re: Killing of sqlturbo

Michael Schunk writes: [on using kill -9 of sqlturbo ] |> It might kill your database, as it killed ours :-( |> |> Our programmers did this very often when they were testing new |> applications using Informix Online 4.10. |> They did so until two weeks ago. Then a collegue killed an |> sqlturbo which was in a critical section. That crashed the |> whole online system, leaving the database corrupted. If possible, I'd be interested to hear just how the database was "corrupted". |> tbcheck didn`t help, we had to re-initialize and restore from |> backups. |> |> I told them to use tbmode -z instead. Sometimes it seems not to work, |> the sqlturbo still continues, I have been told. But as a last help you can |> always take the db offline :-) |> |> My only question: If an abnormal abortion of an sqlturbo corruptes the |> database, this might also occur in the case of a system crash or a power |> failure. Is this true? Are there any ways to repair the db instead of |> using a backup? A system crash or power failure should not corrupt your system - it is a different situation than killing an sqlturbo. As I mentioned in a previous post, putting OnLine into abort mode is supposed to prevent any corruption from occuring. Here's how: When a process is in a critical section of code (typically writing data) or holds a latch when it dies, there is no way to know just what, exactly, it was doing before its demise. We can't tell how it had changed the latched entity, or how much of its i/o it completed. Without being able to clean these up, allowing the system to run could cause a curruption of shared memory or a partial write of data to be committed to disk. By aborting, we eliminate the shared memory corruption. In the process of aborting, the partially-written data may be written to disk, but when fast recovery occurs during restartup, it should overwrite the page with its before image (from the physical log), apply any transactions from the logical log, then roll back any incomplete transactions. This should leave your database in a consistent state. I am willing to admit that there are circumstances whereby the database could be corrupted by a kill -9, but I can't think of any offhand. The problem, typically, is that we only hear "the database was corrupted" and never have a chance to look at it to see what, exactly, was corrupted. Anyway, in the case of a system failure, everything stops at once. The pages in shared memory are not flushed to disk. So what is out there (on disk) is "good" data. Fast recovery will recover any transactions committed (whose transaction records have been flushed to disk), assuming you are using logging. Barring that, it will restore the system to its point at the time of the last checkpoint. If you should have a disk crash, it is likely that you will have no option but to restore from archive. For something like a power failure, you should not see any corruption and thus should not have to restore from archive. Dave Disclaimer: These opinions are not those of Informix Software, Inc. ************************************************************************** "I look back with some satisfaction on what an idiot I was when I was 25, but when I do that, I'm assuming I'm no longer an idiot." - Andy Rooney