Re: MORE RAM - BIG CONTROLLER CACHE / DB ON RAW - DB ON FS

Greg wrote: > > [...] Staged / asynchronous writes are about > all controller memory is good for (and it's *really* great for that...) What are staged / asynchronous writes, and why is it the only thing controller memory is good for? -- /* ----------------------------------------------------- * * Willem Roos wroos@shoprite.co.za * * roosj@mweb.co.za * * 0(+27)21 980 4941 * * 0(+27)21 919 0198 * * ----------------------------------------------------- */

Willem Roos wrote: > > Greg wrote: > > > > [...] Staged / asynchronous writes are about > > all controller memory is good for (and it's *really* great for that...) > > What are staged / asynchronous writes, and why is it the only thing > controller memory is good for? > > -- > /* ----------------------------------------------------- * > * Willem Roos wroos@shoprite.co.za * > * roosj@mweb.co.za * > * 0(+27)21 980 4941 * > * 0(+27)21 919 0198 * > * ----------------------------------------------------- */ The disk array cache is invisible to the database, much like L1 cache on your PC is invisible to the program you're running (i.e. Netscape...). Informix thinks its writing to disk, but the disk array responds that the I/O is complete as soon as it is written to the disk arrays static memory (which is orders of magnitude faster than disk), giving the appearance of a disk subsystem that is as fast as memory, not disk. The data is actually written out asynchronously (sometimes called staged) while the DBMS goes off fat, dumb and happy that the I/O has been done very quickly. Of course, the key issue here is you have to have absolute trust in your disk array to not lose the data before it gets to disk, or youre looking at corruption and a restore. Staged writes are wonderful things at checkpoint time. Hence my praise for it. All major DBMS's cache hundreds to thousands of MBytes in memory onboard the server, which services 95-99% of all read accesses. Hence my assertion that spending memory on the disk array for read access is largely pointless. greg

In article <36A4F008.55D0@cyberramp.net>, greg@cyberramp.net (Greg) wrote: [cutting] > > Of course, the key issue here is you have to have absolute trust in your > disk array to not lose the data before it gets to disk, or youre looking > at corruption and a restore. Staged writes are wonderful things at > checkpoint time. Hence my praise for it. If you are using NVRAM then you shouldn't have a problem, but some of the cheaper manufacturers use non-NVRAM so if the array disappears so does part of your data probably > > All major DBMS's cache hundreds to thousands of MBytes in memory onboard > the server, which services 95-99% of all read accesses. Hence my > assertion that spending memory on the disk array for read access is > largely pointless. True, but it can be a godsend for writes, with the above proviso. I like getting my writes confirmations from RAM, sub-milli-second response time up until you run out of cache then you are back to a 'normal' system. Paul Watson # I don't suffer from WF Software Ltd. # stress, I'm just Tel. (+44) 1436 674729 # a carrier Fax. (+44) 1436 678693 # www.wfsoftware.co.uk