SNIP

Hi Al,

I thought that I recognized that Compaq reference. Went to my (just recently finished it) copy of "Inside SQL Server 7.0" and sure enough, there it was.
It states definitively that write-back caching *must* be diabled unless the controller is guaranteed to complete I/Os posted as I/O Complete ACROSS A FAILURE - and not just a power failure (they cite a single-bit parity error as well). Of course I presume this is in the context of SQL Server.

Their reasoning is that some controllers have been found to "lie" (their term) about the I/O Complete, posting it as such when it hasn't physically been written back. Seems to me that is the whole point of "write-back" caching.
The Compaq they cite apparently has on-board battery backup to preserve data and logic to write the stored data first on resumption.

I would think, since the danger here is strictly from a motherboard/power failure, that it would be safer and cheaper, *if* SQL Server detected an 'non-guaranteed' HD adapter, for SQL Server to modestly delay the "final consequence" of a I/O Complete to give it a chance to really be written. Possibly staying 1-behind for any drive or something like that (with a time limit of course).

IN ANY CASE. . .

The issue at hand is categorically NOT related to failure/resumption of service without loss of data, the issue is why did a FLUSH work when a UNLOCK didn't.
In this case, based on what the "Inside SQL Server 7.0" book has to say, disabling the write cache (assuming it is otherwise designed/operating correctly) is not the solution.

I don't know what is, but I do know that if this were a general 'problem' FP/VFP would have been dead long ago. I've got to suspect that the problem at hand is related to settings in VFP or the OS.

Cheers,

JimN


>
>I think we may be arguing semantics here. I'm using "write cache" and "write behind" interchangeably. The purpose of this technique is precisely to post a notification back to the OS when in fact it has not been committed to disk. By decoupling, the controller can use advanced techniques to increase effective throughput and decrease the number of actual, physical writes the system has to perform. In order to do that reliably, the controller has to maintain cache coherency, which is non-trivial but is well understood.
>
>You're absolutely right that such controllers must be backed up by UPSs, or data loss may result on loss of power. This holds true of desktops/workstations that employ this technique, as well as servers.
>
>People think nothing of using multi-CPU Xeon servers with multi-level processor caches up to 2MB in size. Conceptually, a properly implemented read-and-write disk cache is exactly the same thing and operates just as transparently. We don't get warnings from Intel or AMD to disable CPU caches if database applications are run on them; there is no reason to do so on a caching disk subsystem, either.