Die heute übliche Hardware für ein SQL Server System wird zumeist schon von Beginn an sehr groß dimensioniert: Quadcore-(Multi)-CPUs, 64bit-System, 4GB oder mehr RAM und große, schnelldrehende Festplatten (SAS, SAN & Co) vielleicht sogar mit einem RAID 10 (bitte kein RAID 5...). Damit ist im Regelfall ausreichend Kapazität vorhanden, um auch größere Datenbanken vernünftig betreiben zu können.
Wenn sich ein Engpass ergibt, so kann das meist durch weitere CPUs und mehr RAM behoben werden. Aber wie ist das mit der Festplatten-Performance? Lässt sich diese weiter steigern?
Nachdem kaum eine Datenbank komplett im Speicher gehalten werden kann, ist das Auslagern, Nachladen, Indizieren und Schreiben von Transaktionen und Commitment ein wichtiger Index für die Gesamt-Leistung des SQL Systems. Und oft ist der Flaschenhals im IO-Subsystem zu finden!
Oder umgekehrt: Kann man auch schon im Vorhinein Aussagen über die Leistung eines SQL Server-Systems treffen und die IO Performance messen?
Genau zu diesem Zweck gibt es das SQLIO.exe Tool und die (englische) Seite Predeployment I/O Best Practices. Die Aussagen beziehen sich zwar auf SQL Server 2005, dürften aber ebenso auf SQL Server 2008 anwendbar sein.
Diese Tabelle von Predeployment I/O Best Practices zeigt eine Übersicht der nützlichen Tools, ich habe auch gleich die Download bzw. Info-Links beim Tool hinterlegt:
Tool | Zweck | I/O Muster | Hersteller |
Performance capacity | User defined— | Microsoft | |
Performance capacity | User defined— | Open Source | |
Functional correctness | Simulates SQL Server I/O patterns | Microsoft |
...und noch die folgenden Links zum Thema:
- Disk Subsystem Performance Analysis for Windows
- Storport in Windows Server 2003: Improving Manageability and Performance in Hardware RAID and Storage Area Networks.
Wie so oft gilt: Viel nachzulesen und zu testen. Ich denke aber, proaktives Planen ist besser als reaktives Ärgern. ;-)
Beitrag von Toni Pohl
Categories: Developer, Microsoft, Tools
Source: https://blog.atwork.at/post/SQL-wie-speicherst-du-Oder-Planen-eines-SQL-Server-Systems