13
SQL Server Best Practice
Hallo,
ich habe hier 3 VMWare Hosts, auf denen insgesamt 15 MS SQL-Server laufen.
Bei diesen Datenbanken ist alles dabei, von klein ca. 200 MB für Drucker Monitoring bis 200 GB für ERP System.
Hier kommt es natürlich zu Performance Engpässen.
Ich denke, dass Best Practice folgendes wäre:
1. Alle Datenbanken auf ein Cluster mit zwei MS SQL Servern konsolidieren, damit der Overhead durch die einzelnen Instanzen reduziert wird.
2. Diese Server mit genügend Ressourcen ausstatten und den gesamten zugewiesenen Arbeitsspeicher am Host reservieren.
3. Eventuell noch einen 4. Host ins VMWare Cluster dediziert für einen der Datenbankserver hängen.
Oder habt ihr einen besseren Vorschlag?
ich habe hier 3 VMWare Hosts, auf denen insgesamt 15 MS SQL-Server laufen.
Bei diesen Datenbanken ist alles dabei, von klein ca. 200 MB für Drucker Monitoring bis 200 GB für ERP System.
Hier kommt es natürlich zu Performance Engpässen.
Ich denke, dass Best Practice folgendes wäre:
1. Alle Datenbanken auf ein Cluster mit zwei MS SQL Servern konsolidieren, damit der Overhead durch die einzelnen Instanzen reduziert wird.
2. Diese Server mit genügend Ressourcen ausstatten und den gesamten zugewiesenen Arbeitsspeicher am Host reservieren.
3. Eventuell noch einen 4. Host ins VMWare Cluster dediziert für einen der Datenbankserver hängen.
Oder habt ihr einen besseren Vorschlag?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 320510
Url: https://administrator.de/contentid/320510
Printed on: April 19, 2024 at 20:04 o'clock
13 Comments
Latest comment
Hi
Auf jeden Fall die Server zusammenlegen. Das ist ziemlich Unsinn das so zu machen, wenn es da nicht irgendwelche expliziten Gründe dafür gibt.
Aber auf jeden Fall muss auch analysiert werden, wo denn die Performanceprobleme herkommen. Ist es die Prozessorpower? Oder doch eher die Festplattenleistung und/oder zu wenig RAM ?
Der Overhead macht sicher einen kleinen Anteil aus, aber eher nicht so stark, das man da nach einer Konsolidierung einen Nennenswerten unterschied bemerken würde
Auf jeden Fall die Server zusammenlegen. Das ist ziemlich Unsinn das so zu machen, wenn es da nicht irgendwelche expliziten Gründe dafür gibt.
Aber auf jeden Fall muss auch analysiert werden, wo denn die Performanceprobleme herkommen. Ist es die Prozessorpower? Oder doch eher die Festplattenleistung und/oder zu wenig RAM ?
Der Overhead macht sicher einen kleinen Anteil aus, aber eher nicht so stark, das man da nach einer Konsolidierung einen Nennenswerten unterschied bemerken würde
Moin,
sehe ich auch so, stelle erst mal fest ob es hakt und gehe die ganze Sache dann strukturiert an.
RAM ist schließlich nicht der einzige Punkt bei SQL Performance.
Wieviele Datenbanken sind das?
Du könntest auch darüber nachdenken die weniger "wichtigen" oder kleinen DBs auf einen "kleinen" SQL Server zu spielen und für die "fetten" DB einen entsprechenden Server einrichten.
Gruß
sehe ich auch so, stelle erst mal fest ob es hakt und gehe die ganze Sache dann strukturiert an.
RAM ist schließlich nicht der einzige Punkt bei SQL Performance.
Wieviele Datenbanken sind das?
Du könntest auch darüber nachdenken die weniger "wichtigen" oder kleinen DBs auf einen "kleinen" SQL Server zu spielen und für die "fetten" DB einen entsprechenden Server einrichten.
Gruß
Ich denke, dass das Performanceproblem von der CPU Auslastung her kommt. Ich dachte, dass man hier etwas durch die Konsolidierung Ressourcen einsparen könnte und falls das nicht genug ist, eventuell einen weiteren Host hinzufügen...
Also Datenbaken sind pro Server eine + DMS-Server 40 DBs
Also Datenbaken sind pro Server eine + DMS-Server 40 DBs
ui also das sieht nicht gut aus. Kaum Batchanforderungen, aber massive CPU-Zeit mit vielen Locks.
Das müsste man sich zwar genauer ansehen, aber ich tippe hier jetzt mal darauf, das die Queries ### sind, und/oder der Plancache kaputt ist.
Schau dir mal an auf welchen DBs die Locks liegen und ob ihr einfluss auf die dort ausgeführten Queries habt. Wenn da irgendwelche Eigenentwicklungen dabei sind, sollten sich die Entwickler dringend an SQL Abfragen fortbilden
Das müsste man sich zwar genauer ansehen, aber ich tippe hier jetzt mal darauf, das die Queries ### sind, und/oder der Plancache kaputt ist.
Schau dir mal an auf welchen DBs die Locks liegen und ob ihr einfluss auf die dort ausgeführten Queries habt. Wenn da irgendwelche Eigenentwicklungen dabei sind, sollten sich die Entwickler dringend an SQL Abfragen fortbilden
Dann ist's ja schon mal nicht der RAM 
Performance bei SQL ist grob gesagt:
RAM
CPU
HD
Wartung
Design
Und dazwischen noch 'ne ganze Menge Kleinigkeiten, wie z.B. die Zugriffskonfiguration der Clients (IP oder Name) etc.
Google mal nach Tools für die Performancemessung und agiere danach.
Performance bei SQL ist grob gesagt:
RAM
CPU
HD
Wartung
Design
Und dazwischen noch 'ne ganze Menge Kleinigkeiten, wie z.B. die Zugriffskonfiguration der Clients (IP oder Name) etc.
Google mal nach Tools für die Performancemessung und agiere danach.
Zitat von @SeaStorm:
Schau dir mal an auf welchen DBs die Locks liegen und ob ihr einfluss auf die dort ausgeführten Queries habt. Wenn da irgendwelche Eigenentwicklungen dabei sind, sollten sich die Entwickler dringend an SQL Abfragen fortbilden
Schau dir mal an auf welchen DBs die Locks liegen und ob ihr einfluss auf die dort ausgeführten Queries habt. Wenn da irgendwelche Eigenentwicklungen dabei sind, sollten sich die Entwickler dringend an SQL Abfragen fortbilden
Das würde ich nicht nur auf die Eigenentwicklungen begrenzen
Das war ein Screenshot von unserem HR-Server, die Software ist eigentlich für bis zu 10.000 Mitarbeiter ausgelegt, also denke ich mal, dass die Abfragen so schon ok sind...
Wie würdet ihr hier weiter vorgehen?
Wie würdet ihr hier weiter vorgehen?
wie gesagt: Analyse der Performanceprobleme.
Erst mal rausfinden warum die CPU-Zeit hier so gigantisch ist. Kann natürlich sein das du dem Ding nur 100 MHz zugewiesen hast und er deswegen nix hinbekommt, aber davon gehe ich mal nicht aus.
Schau deshalb erst mal bei den Aktiven/aktuellen Ressourcenintensiven Abfragen, welche da so viel CPU Zeit brauchen und schau wo die herkommen.
Und dann die üblichen verdächtigen bei SQL:
Sind das Parametrisierte Abfragen? Wenn nein: Ändern! Wenn da nur ein String (also "SELECT * FROM Tabelle WHERE Name = 'Hans'" anstatt "SELECT * FROM Tabelle WHERE Name=@Name" ) in der Abfrage ist, wird das nicht gecached und bei jedem erneuten query erneut kompiliert.
Damit zusammenhängend: Funktioniert der Plan-Cache? Wenn der nicht funktioniert, wird jede abfrage jedes mal aufs neue kompiliert. Das Kostet richtig Power.
Sind die Abfragen und Indexe aufeinander abgestimmt? Wenn nein: Anpassen. Falls möglich an Abfrage und Index, ansonsten Indexe erstellen, die besser passen.
Sind die Statistiken aktuell (und nicht kaputt)?
Laufen die Sicherungen? Wenn nicht: Schlag irgendjemanden der dafür verantwortlich ist. Aus Prinzip. Wenn die Backups nicht laufen, werden die Umlaufprotokolle auch nicht entfernt. Und wenn kein Backup da ist, habt ihr echt ein Problem
Mir macht das ein bisschen sorgen, das da so viele Waiting Tasks sind. Das kann daher kommen, das eure Abfragen zu lange laufen und deshalb die nachkommenden Abfragen hinten anstehen müssen, bis die Tabellen wieder frei sind, oder es gibt tatsächlich Programmbedingte Tablelocks, was übel ist. Aber da muss dann der Hersteller der Software was ändern. Wenn das was bekanntes ist, sollte der das wissen und vermutlich schon längst gepatched haben.
Wie viel CPU hat die VM denn effektiv? Und wie stark ist der HV ausgelastet ?
Erst mal rausfinden warum die CPU-Zeit hier so gigantisch ist. Kann natürlich sein das du dem Ding nur 100 MHz zugewiesen hast und er deswegen nix hinbekommt, aber davon gehe ich mal nicht aus.
Schau deshalb erst mal bei den Aktiven/aktuellen Ressourcenintensiven Abfragen, welche da so viel CPU Zeit brauchen und schau wo die herkommen.
Und dann die üblichen verdächtigen bei SQL:
Sind das Parametrisierte Abfragen? Wenn nein: Ändern! Wenn da nur ein String (also "SELECT * FROM Tabelle WHERE Name = 'Hans'" anstatt "SELECT * FROM Tabelle WHERE Name=@Name" ) in der Abfrage ist, wird das nicht gecached und bei jedem erneuten query erneut kompiliert.
Damit zusammenhängend: Funktioniert der Plan-Cache? Wenn der nicht funktioniert, wird jede abfrage jedes mal aufs neue kompiliert. Das Kostet richtig Power.
Sind die Abfragen und Indexe aufeinander abgestimmt? Wenn nein: Anpassen. Falls möglich an Abfrage und Index, ansonsten Indexe erstellen, die besser passen.
Sind die Statistiken aktuell (und nicht kaputt)?
Laufen die Sicherungen? Wenn nicht: Schlag irgendjemanden der dafür verantwortlich ist. Aus Prinzip. Wenn die Backups nicht laufen, werden die Umlaufprotokolle auch nicht entfernt. Und wenn kein Backup da ist, habt ihr echt ein Problem
Mir macht das ein bisschen sorgen, das da so viele Waiting Tasks sind. Das kann daher kommen, das eure Abfragen zu lange laufen und deshalb die nachkommenden Abfragen hinten anstehen müssen, bis die Tabellen wieder frei sind, oder es gibt tatsächlich Programmbedingte Tablelocks, was übel ist. Aber da muss dann der Hersteller der Software was ändern. Wenn das was bekanntes ist, sollte der das wissen und vermutlich schon längst gepatched haben.
Wie viel CPU hat die VM denn effektiv? Und wie stark ist der HV ausgelastet ?
Aber wenn ich unter "Aktuelle ressourcenintensive Abfragen" nach sehe, werden mir sehr viele Einträge angezeigt.
Wie kann ich die Funktion des Plan-Cache prüfen?
Die Abfragen haben Größtenteils Parameter.
Wie prüfe ich, ob die Abfragen zu den Indexen passen? Das ist eine Kauf Software, hier würde ich ungerne etwas an der Tabellen Struktur ändern... (auch aufgrund fehlender Erfahrung mit SQL Datenbankdesign und co.)
Wie kann ich die Statistiken überprüfen? Woher weiß ich, ob hier was kaputt ist?
Laufen die Sicherungen? => Ja, mittels Veeam Backup und Replication
Wie viele "Waiting Tasks" ist denn so normalerweise akzeptabel?
Der VM ist aktuell ein Socket mit zwei virtuellen Kernen zugewiesen. Das HA ist zu ca. 60 % Ausgelastet. Ressourcenpools oder ähnliches ist aktuell noch nicht definiert.
Wie kann ich die Funktion des Plan-Cache prüfen?
Die Abfragen haben Größtenteils Parameter.
Wie prüfe ich, ob die Abfragen zu den Indexen passen? Das ist eine Kauf Software, hier würde ich ungerne etwas an der Tabellen Struktur ändern... (auch aufgrund fehlender Erfahrung mit SQL Datenbankdesign und co.)
Wie kann ich die Statistiken überprüfen? Woher weiß ich, ob hier was kaputt ist?
Laufen die Sicherungen? => Ja, mittels Veeam Backup und Replication
Wie viele "Waiting Tasks" ist denn so normalerweise akzeptabel?
Der VM ist aktuell ein Socket mit zwei virtuellen Kernen zugewiesen. Das HA ist zu ca. 60 % Ausgelastet. Ressourcenpools oder ähnliches ist aktuell noch nicht definiert.
Wie groß ist die DB?
Wieviel Speicher hat der Server/SQL Server?
Aktueller Patchstand?
Wartungspläne aktiv und funktionieren?
Was sagt der Hersteller Support zur Performance?
Wieviel Speicher hat der Server/SQL Server?
Aktueller Patchstand?
Wartungspläne aktiv und funktionieren?
Was sagt der Hersteller Support zur Performance?
Oha 2 Kerne ist schon arg wenig.
Du solltest dir die Wartungspläne ansehen. Damit einmalig die Statistiken und Indexe neu erstellen ( Nicht regelmäßig! )
Waiting Tasks sind erst mal gar keine akzeptabel. Das heist, das ein Task darauf wartet, das ein anderer die Tabelle, auf die der erste zugreifen will, frei macht.
PlanCache lässt du besser erst mal in Ruhe, wenn du keine Ahnung davon hast. Erst mal die Probleme drumherum lösen und den Performanceengpass eingrenzen
Du solltest dir die Wartungspläne ansehen. Damit einmalig die Statistiken und Indexe neu erstellen ( Nicht regelmäßig! )
Waiting Tasks sind erst mal gar keine akzeptabel. Das heist, das ein Task darauf wartet, das ein anderer die Tabelle, auf die der erste zugreifen will, frei macht.
PlanCache lässt du besser erst mal in Ruhe, wenn du keine Ahnung davon hast. Erst mal die Probleme drumherum lösen und den Performanceengpass eingrenzen
1,5 GB
davon MS SQL: 12,288 GB
Windows: 2012R2 Datacenter (Version 6.3 Build 9600)
Wieviel Speicher hat der Server/SQL Server?
Server: 14 GBdavon MS SQL: 12,288 GB
Aktueller Patchstand?
SQL: 12.0.5000.0Windows: 2012R2 Datacenter (Version 6.3 Build 9600)
Wartungspläne aktiv und funktionieren?
Verwaltung => Wartungspläne? Sind keine Vorhanden.Was sagt der Hersteller Support zur Performance?
"Es gibt wohl ein Problem mit der Performance des SQL-Servers."
Moin,
Um überhaupt mal einen Ansatz zu finden, wäre es hilfreich wenn du deine komplette Umgebung beschreibst inkl. Hardware und Software. Anschließend die Empfehlungen der Softwarehersteller, welche die 15 Datenbank-Server.
Ich kann mir gut vorstellen, dass ein Großteil oder sogar alle Datenbank-Server inkl. Application/RDS-Server einfach nicht nach Herstellervorgabe konfiguriert sind um Ressourcen zu sparen. Das kann gut gehen muss es aber nicht. Daher erstmal die Basis (deine Infrastruktur und die VMs mit den Herstellervorgaben) abgleichen.
Gruß,
Dani
Das war ein Screenshot von unserem HR-Server, die Software ist eigentlich für bis zu 10.000 Mitarbeiter ausgelegt, also denke ich mal, dass die Abfragen so schon ok sind...
Es kann auch für 100.000 MA ausgelegt sein. Am Ende muss die Infrastuktur entsprechend dimensoniert sein.Um überhaupt mal einen Ansatz zu finden, wäre es hilfreich wenn du deine komplette Umgebung beschreibst inkl. Hardware und Software. Anschließend die Empfehlungen der Softwarehersteller, welche die 15 Datenbank-Server.
Ich kann mir gut vorstellen, dass ein Großteil oder sogar alle Datenbank-Server inkl. Application/RDS-Server einfach nicht nach Herstellervorgabe konfiguriert sind um Ressourcen zu sparen. Das kann gut gehen muss es aber nicht. Daher erstmal die Basis (deine Infrastruktur und die VMs mit den Herstellervorgaben) abgleichen.
Gruß,
Dani
