Einer meiner Kunden hat damit auch schon herumexperimentiert und hat eine 190 GB Datenbank auf 8 Einzeldateien separiert.
Der Gedanke dahinter war daß das SAN die IO-Transaktionen bei gesplitteten Datenbanken - die an unterschiedlichen SCSI Controllern gehostet werden - parallelisiert abarbeitet und somit z.B. ein "full table scan" auf nicht-indizierte Spalten dann achtfach
schneller vonstatten geht.
Am Ende zeigte sich aber daß das SAN selbst der Flaschenhals war, das war z.B. schon bei 40.000 iops "am Ende". Das hat er aber nur mit synthetischen Tests herausgefunden. Praktisch schicken alle 250 User "unserer" Applikation die der Kunde hat, im
Normalbetrieb zwischen 100 und 200 Transaktionen/Sekunde an den Server, was dieser dann in ca. 1000 iops aufgesplittet hat da die Statements "No SQL" waren.
Auch hat die Applikation, die die Datenbank nutzt, bei einer massiven Wartungsoperation weniger als 2000 iops an den Server geschickt so daß sich der Kunde am Ende dazu entschlossen hat, die Dateien wieder zusammenzuführen, und den Server mit 100% der Datenbankgröße
an Arbeitsspeicher auszustatten.
Mehr gewinnt man dann nur noch durch In Memory ab SQL 2014, da der physische Commit auf dem Datenträger nicht mehr als Teil einer Traksaktion betrachtet wird auf deren Commit man noch warten müßte (bei Schreibvorgängen) und bei lesenden Vorgängen entfällt
die Prüfung, ob die Daten schon gecacht sind oder nicht.
