Mehrere Datenfiles sinnvoll?

[Coldasice 12]

Hi zusammen,

 

ich stelle eine Frage, die ich mir vermutlich schon selbst beantwortet habe, aber nicht ganz sicher bin, ob nicht doch irgendein Aspekt vergessen wurde.

Machen mehrere Datenfiles Sinn?

Ja -> Wenn die Files auf verschiedene physische Platten aufgeteilt werden können bzw. auf anderen LUNs liegen, damit würde man bessere IO Werte erreichen.

Außerdem wenn man Sinnvolle Dateigruppen hat, um bspw. Daten von den Indizes zu splitten.

 

Nein -> Wenn alles auf einer physischen Platte bzw. LUN liegt

 

Macht es evtl. Sinn, aber einer bestimmen Größe der DB die Files zu splitten!?

Kann das jemand bestätigen oder auch seinen Einwand mitteilen?

 

Gruß Timo

bearbeitet 26. Februar 2018 von Coldasice

[Dukel 454]

https://technet.microsoft.com/en-us/library/cc966534.aspx

Quote

Lining up the number of data files with CPU’s has scalability advantages for allocation intensive workloads.

• It is recommended to have .25 to 1 data files (per filegroup) for each CPU on the host server.

• This is especially true for TEMPDB where the recommendation is 1 data file per CPU.

• Dual core counts as 2 CPUs; logical procs (hyperthreading) do not.

Aber:

Quote

Try not to “over” optimize the design of the storage; simpler designs generally offer good performance and more flexibility.

• Unless you understand the application very well avoid trying to over optimize the IO by selectively placing objects on separate spindles.

• Make sure to give thought to the growth strategy up front. As your data size grows, how will you manage growth of data files / LUNs / RAID groups? It is much better to design for this up front than to rebalance data files or LUN(s) later in a production deployment.

 

Bei Problemen oder entsprechenden Anforderungen kannst du das machen. Da solltest du aber wissen, dass du das brauchst.

 

[v-rtc 88]

Sehr gute Frage. Hätte jetzt wie Du argumentiert. 

Die Frage die sich noch stellen könnte wäre, ob es eine VM ist oder ein physikalischer Server.

 

Grüße

 

Too late. Danke Dukel!

bearbeitet 26. Februar 2018 von RolfW

[zahni 554]

Man sollte  hier  in der Tat  das DB-Design kennen. Im Detail kenne ich mich dem SQL-Server nicht aus. Kann man Tabellen in dedizierte Files legen? Das was bei anderen System der Tablespace ist?

Das kann Auswirkungen auf die Performance haben. Positive aber  auch negative Auswirkungen. Es kann auch auf einer LUN Sinn machen, wenn der SQL-Server I/Os entsprechend aufteilen und parallelisieren kann.

Aber ob der MS-SQL-Server das alles kann und macht?

 

[mwiederkehr 373]

vor 1 Stunde schrieb zahni:

Kann man Tabellen in dedizierte Files legen? Das was bei anderen System der Tablespace ist?

Ja, das ist möglich. Es kann sinnvoll sein, grosse oder wenig genutzte Datensätze auf günstigeren Speicher (SAS statt SSD) auszulagern:

 

- vertikale Partitionierung: Wenn ein System zu jedem Produkt ein Bild in der Datenbank speichert, kann man diese Spalte in eine separate Datei auslagern (bzw. die Tabelle mit ID und Bild).

- horizontale Partitionierung: Alle Datensätze mit Datum von mehr als einem Jahr in der Vergangenheit kommen in eine andere Datei.

 

Muss aber sagen, dass ich einen solchen Fall in der Praxis noch nie hatte. Einerseits ist auch schneller Speicher nicht mehr so teuer oder man macht das Tiering direkt auf dem SAN.

[PowerShellAdmin 169]

Und dann werfe ich nochmal die Auslagerung von SQL-Cache und Tempdb ein, was sich wiederholende Selects beschleunigen kann.

Je nach DB Typ/Anwendung verursacht dies die primäre Belastung.

 

Kann z.B. in Azure sinnvoll sein - private Cloud bittet hier die günstige Möglichkeit von flüchtigen Storage mit höherer Iops Leistung.

 

Dazu kann man auch die DB so designen, dass hier Bestandteile direkt in den Ram ausgelagert werden oder entsprechend DB Partitionenaufbauen...

 

 

[Dukel 454]

Wie schon gesagt gibt es viele, sehr viele Stellschrauben, an denen man drehen kann.

Entweder ist das eine einfache DB, dann würde ich nicht so viel umstellen und die Standardeinstellungen wählen oder die DB ist essentiell, performancekritsch oder es gibt (performance) Probleme mit dieser DB. Dann kommt es aber sehr auf die DB und Anwendung an, was man dann ändern sollte.