Re: WHY index can corrupted???

Umberto, One could fight about what one should call such caching hardware. You could try to protect it using emergency power supply. Otherwise it will not only corrupt databases but also ordinary file systems it hosts. One can call that unreliable at the least. With cooked files Informix did not use to guarantee data integrity in a political sense. But internally cooked chunks are opened using the O_SYNC os flag (see "man 2 open"). I believe that most modern operating system honor this by returning from a write only after the data is really on disk (but there is the same problem with write cache of course). If this holds data integrity is not endangered even on cooked chunks. Michael > > Michael, > Art has correctly pointed out that caching controllers may potentially > cause corruption. That kind of corruption: > - is not due to hardware failure, but to the way the hardware works > ordinarily > - is not due to the database engine > > So you have a corruption which is not a bug and is not caused by > faulty > hardware... > > I agree that a good controller should have a way to disable its cache > if I don't want it (on database disks, for example), but if the > manufacturer doesn't give you a way to do that... > I'd call that too-smart hardware: it tells the engine that data has > been > flushed before it has been really, and the db faithfully marks that > data > as already written. It works as a charm until power outage or > overheating > force a disk farm stop... You are lucky if it's just an index > involved! > > With Oracle and ordinary datafiles, the problem is even greater. You > have > OS buffering too. Greater flexibility, but less robustness. It tells > you > that a datafile needs recover, you give RECOVER DATABASE, and > sometimes > it's all OK. I wonder what has been done when it succeeds. If datafile > was corrupt, how can it recover without physical restore? Why doesn't > it > attempt that directly by itself? Well, maybe I'm too curious, I like > to > "look under the hood" to understand... Of course, using cooked files > exposes Dynamic Server to the same problem. > > So that's another possible cause. Summarizing them all: > > - bugs > - crashes with cacheing controllers > - improper shutdowns > - buffered log or unlogged databases > - usage of cooked files instead of raw devices with databases > > > Umberto Quaia > > -- === Michael Mueller ================== Tel. + 49 8171 63600 Fax. + 49 8171 63615 Web: http://www.mm.kay-mueller.de http://www.planets.kay-mueller.de ======================================