SQL Server: Performance-Optimierung

Datenbank-Dimensionierung – Theorie

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Was ist für eine sinnvolle Dimensionierung der Datenbank zu beachten? Der Trainer erläutert außerdem, wie Daten und Indizes sinnvoll getrennt werden können.
04:20

Transkript

Wenn Sie eine Datenbank anlegen oder eine Datenbank betreiben, dann werden Sie sicherlich eine gewisse Vorstellung davon haben, wie groß in der Tat die Menge der Daten ist, die dort Platz finden sollen. Was Sie nicht tun sollten, ist die Datenbank gerade so groß anlegen, dass die Daten wirklich in diese Datenbank rein passen, aber nichts mehr frei ist in dieser Datenbank. Das bedeutet nämlich wenn dann neue Daten hinzukommen, dass der SQL Server die darunter liegenden Dateien, genannt Medien, erweitern muss, und wenn das in entsprechend kleinen Häppchen passiert, das natürlich da das Problem ist, das der SQL Server immer wieder mal ein paar MB einfügen muss und es macht nicht wirklich Spaß an der Stelle das kostet Performance und hat bei physikalischen Datenträgern immer noch das Problem, das damit die Datenbankmedien sehr stark fragmentieren und das ist nicht wirklich eine gute Geschichte. Insofern planen Sie im Voraus: Wie groß wird meine Datenbank selbst wenn Sie es nur schätzen, letztendlich ist es diesen Aufwand wert. Der nächste Punkt: Der SQL Server beherrscht es, das Medien oder Datenbanken wenn notwendig automatisch vergrößert werden, das ist der Punkt, den ich gerade schon angesprochen hab, der bei physikalischen Platten dann für Fragmentierung sorgt. Das ist etwas, wo Sie genau drüber überlegen sollten, ob das ein gutes Feature für Sie ist. Wenn Sie auf Ihrem SQL Server mehrere Datenbanken und damit auch mehrere Anwendungen höchstwahrscheinlich betreiben, dann können Sie sich sehr leicht ein Szenario vorstellen, wo eine der Anwendungen nicht genau das tut, was sie tun soll und entsprechend die Datenbank schlicht vollmüllt mit mehr oder minder sinnvollen oder sinnlosen Daten an der Stelle. Das geht dann so lange, bis die entsprechende Partition voll ist und das hat wiederum Auswirkungen auf alle Datenbanken Die können nämlich dann alle insgesamt nicht weiter wachsen an der Stelle. Deshalb kann es eine Überlegung sein, das man durch die Vorausplanung sagen kann: OK, ich weiß, meine Datenbank wird so groß. Ich gehe hin, baue eine große Reserve ein. Heutzutage sind ja auch Kapazitäten von Festplatten oder von Massenspeichern nicht mehr wirklich so teuer, gehe aber auf der anderen Seite dafür hin und schalte die automatische Vergrößerung aus. Das heißt, wenn eine Anwendung möglicherweise irgendwann einmal Amok läuft und anfängt, die Datenbank vollzumüllen, dann betrifft das nur sie selber. Denn irgendwann wird sie an das Limit kommen, an ihre Größe und darf nicht mehr weiter wachsen. Die Anwendung selber erzeugt natürlich dann Fehler, das ist schlecht für die Anwendung, es hat aber den Vorteil, das andere Anwendungen, sprich andere Datenbanken, nach wie vor so funktionieren wie sie in der Tat auch funktionieren sollten. Eine gute Sache. Dann können Sie eine Datenbank auf mehrere Dateien erweitern. Damit ist jetzt nicht gemeint, dass Sie ein Datei für das Transaktionsprotokoll und eine Datei für ??? Data also für die restlichen Daten in Tabellen und Indizes haben sollten. Sondern damit ist gemeint, dass Sie die Möglichkeit haben, dass die Datenbank so erweitert wird, das sie entsprechend beispielsweise die Daten innerhalb der Tabellen in ein Medium einer Datei legen und alle Informationen über Indizes entsprechend in eine andere Datei. Warum sollte man das machen? Wenn Sie unterschiedliche physikalische Laufwerke haben, können Sie damit die Arbeit ein bisschen verteilen an der Stelle. Das setzt aber voraus, dass Sie nicht nur getrennte physikalische Laufwerke haben, sondern dass Sie natürlich auch getrennte IO Controller haben, sonst haben Sie da wieder einen Bottleneck. Das kann eine gute Idee sein. Ich möchte Sie aber davor warnen, jetzt Zu viel Detailplanung da reinzustellen. Es kann schlicht und ergreifend Sie irgendwann mal einholen. Das werden Sie ganz genau planen, dass diese Tabelle in dieser Datei und diese Tabelle in dieser Datei und dieser Index dort und so weiter, dass Sie sehr viel Aufwand haben aber der Nutzen relativ klein ist. Also da würde ich, mein Tipp relativ leicht anfangen. In vielen Fällen reicht es schon, völlig aus, dass ich hingehe und die Daten einer Tabelle in eine Datei und die Indexdaten der Tabelle in einer anderen Datei ablege. Selbst wenn beide am Anfang möglicherweise auf ein und derselben Festplatte, auf ein und demselben IO Laufwerk liegen, habe ich damit zumindest die Möglichkeit, später einmal hinzugehen und zu sagen: OK, ich trenne das, wenn ich entsprechend die Hardware und letztendlich auch den Bedarf habe an der Stelle.

SQL Server: Performance-Optimierung

Lernen Sie den Umgang mit Indizis und Tools, um die Leistungsfähigkiet Ihrer SQL Server Datenbank effektiv zu erhöhen.

3 Std. 20 min (32 Videos)
Derzeit sind keine Feedbacks vorhanden...
Hersteller:
Software:
Exklusiv für Abo-Kunden
Erscheinungsdatum:04.05.2017

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!