Jump to content

Mehrere Datenfiles sinnvoll?


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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 von Coldasice
Link zu diesem Kommentar

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.

 

Link zu diesem Kommentar

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?

 

Link zu diesem Kommentar
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.

Link zu diesem Kommentar

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...

 

 

Link zu diesem Kommentar

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.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...