Re: Schreibcache abschalten
From: Daniel Melanchthon (melanchthon_at_gmx.de)
Date: 05/31/04
- Next message: Hans Peter: "ntoskrnl.exe fehlerhaft oder existiert nicht"
- Previous message: Mario Arndt: "Re: Schreibcache abschalten"
- In reply to: Mario Arndt: "Re: Schreibcache abschalten"
- Next in thread: Mario Arndt: "Re: Schreibcache abschalten"
- Reply: Mario Arndt: "Re: Schreibcache abschalten"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 31 May 2004 13:23:03 +0200
Mario Arndt schrieb:
>>Den Plattencache kannst Du dann vergessen.
>
> Nö - weil der RAID-Controller bezüglich seiner Platten ebenfalls
> transaktionsorientiert arbeitet. Erst wenn eine Platte den erfolgreichen
> (physischen) Schreibvorgang zurück meldet, löscht er die entsprechenden
> Daten aus seinem Cache.
Das scheint dann wohl vom Controller selbst abzuhängen. Ich kann in
die Controller ja nicht reingucken und Hersteller halten sich damit
sehr bedeckt. Meinen Erfahrungen nach haben auch battery backup
controllern Probleme, die zu schreibenden Daten im Extremfall
konsistent zu halten, wenn writeback aktiviert ist. Denn die Ausfälle
bei Datenbanken, mit denen ich bisher zu kämpfen hatte, waren immer
darauf zurückzuführen und das bei unterschiedlichen Controllern.
Aber da heute frei ist, hab ich mal ein bißchen was von MS dazu
zusammengetragen:
Using Hard Disk Controller Caching with SQL Server
http://support.microsoft.com/default.aspx?scid=kb;en-us;46091
"The answer depends on which method is faster. Our experiments have
shown that the SQL Server cache is more efficient than the operating
system disk cache. However, we have no way of knowing whether or not
it is more efficient than the caching used by a particular type of
disk controller. The SQL Server cache probably does not work as fast
as a hardware cache; however, it has "inside knowledge" and can work
smarter."
Exchange DB and Caching Hard Disks and Controllers
http://support.microsoft.com/default.aspx?scid=kb;en-us;188589
"Use of a write-caching disk controller can seriously jeopardize the
typically reliable Exchange database data integrity. Significant data
corruption can result from a system failure when a write-caching
controller without an extremely reliable battery backup is used. This
type of controller can compromise the normally reliable Exchange
database recovery mechanism."
"Disk drive write caching is always considered dangerous and is not
recommended."
Auch die weiteren Artikel zeigen, dass Writeback-caching gefährlich
ist und man a) 100%ig sicher sein muß, dass die Hardware komplett
battery backed up ist, b) der RAID-Cache ECC unterstützt, c) die USV
am Besten redundant ausgelegt ist, d) das Operating den Server
genauestens behandelt und e) dass man regelmäßigst Backups zieht.
Using Disk Drive Caching with SQL Server
http://support.microsoft.com/default.aspx?scid=kb;en-us;234656
SQL Server and Caching Disk Controllers
http://support.microsoft.com/default.aspx?scid=kb;EN-US;86903
How to Identify Logical Corruption Problems in Exchange Server
http://support.microsoft.com/default.aspx?scid=kb;en-us;828068
Daher ist meine Empfehlung bei Kunden, den Writecache auf writethrough
zu schalten. Das Risiko ist einfach zu hoch.
Gruß!
Daniel
-- SYMPLASSON Informationstechnik GmbH http://www.symplasson.de Banging your head against a wall uses 150 calories an hour.
- Next message: Hans Peter: "ntoskrnl.exe fehlerhaft oder existiert nicht"
- Previous message: Mario Arndt: "Re: Schreibcache abschalten"
- In reply to: Mario Arndt: "Re: Schreibcache abschalten"
- Next in thread: Mario Arndt: "Re: Schreibcache abschalten"
- Reply: Mario Arndt: "Re: Schreibcache abschalten"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|