passt 10 Geschrieben 4. Januar 2012 Melden Teilen Geschrieben 4. Januar 2012 MSSQL Server 2008 R2 SP1 (Standard) Ist es möglich bei obigen MSSQL eine Datenbank in mehrere Dateien zu splitten und einzelne Tabellen bestimmten Dateien zuzuweisen? Gruß, Peter Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 4. Januar 2012 Melden Teilen Geschrieben 4. Januar 2012 Moin, ja, das ist möglich. Gruß, Nils Zitieren Link zu diesem Kommentar
Dr.Melzer 191 Geschrieben 4. Januar 2012 Melden Teilen Geschrieben 4. Januar 2012 Die Frage ist jetzt nur was du genau vor hast. Datenbank splitten um des Splitten willens wird wohl nicht dein Ziel sein. ;) Zitieren Link zu diesem Kommentar
passt 10 Geschrieben 4. Januar 2012 Autor Melden Teilen Geschrieben 4. Januar 2012 (bearbeitet) Wir haben Performanceprobleme mit unserem MSSQL. Ich suche jetzt Möglichkeiten die Geschwindigkeit zu erhöhen - erstmal nur theoretisch. Ein paar technische Daten zum MSSQL Server: 1x Quad-Core mit HyperV = 8 Kerne in der VM 22GB RAM HDD auf SAN mit Raid10. Der Windows Server ist eine VM, die auf einem eigenen Hardware Server sitzt und diesen Host nicht mit anderen VMs teilen muss. Eine unserer Vermutungen ist, dass das SAN evtl zu langsam ist. Deshalb die theoretische Idee, der VM eine weitere virtuelle Platte zu spendieren, die auf einem eigenen SAN liegen sollte und somit völlig von der ursprünglichen Platte getrennt ist. Die Platte soll dann für einen Teil der Datenbankdateien genutzt werden. bearbeitet 4. Januar 2012 von passt Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 5. Januar 2012 Melden Teilen Geschrieben 5. Januar 2012 Moin, ihr solltet solche Aktionen nicht aufs Geratewohl unternehmen. Bei SQL Server (und anderen Datenbanken) gibt es hunderte von Faktoren, die die Performance beeinflussen können. IO gehört sicher als wesentlicher Punkt dazu, ist aber längst nicht immer die Ursache für Probleme. Sind z.B. DB und Logs getrennt? Wie sieht es mit der Nutzung der TempDB aus und wo liegt die? Sind alle notwendigen Indizes vorhanden? Gibt es Sperrkonflikte oder andere Verzögerungen durch die Applikationslogik? Ist das SAN korrekt angebunden und vom LAN getrennt? ... usw. usf. Gruß, Nils Zitieren Link zu diesem Kommentar
zahni 554 Geschrieben 5. Januar 2012 Melden Teilen Geschrieben 5. Januar 2012 Aus Erfahrung kann ich sagen, dass es bei Datenbanken sehr viel bringt auf die jeweilige Query optimierte Indizies zu erstellen. Leider packen das Entwickler oft nicht, weil Hibernate oder ähnliche API's benutzt werden. Siehe dazu How To: Optimize SQL Indexes BTW: Wie viele Prozessoren hat denn die Hardware ? Du darfst auf keinen Fall sol viele VCPU's zuordnen, wenn die Hardware nur 8 Cores hat. Je nachdem, was der Host sonst noch macht, 2 bis max. 4 vCPU's Bei Nils gab es (glaube ich) einen Link zum Thema, wie viele VCPU's eine VM haben sollte... Zitieren Link zu diesem Kommentar
passt 10 Geschrieben 5. Januar 2012 Autor Melden Teilen Geschrieben 5. Januar 2012 @NilsK Vorab, ich werde keinenfalls den MSSQL betreffende Lösungsvorschläge selbsttätig ausführen. Dafür habe ich zu wenig Erfahrung damit. Der MSSQL Server hat seine beiden Platten auf ein und dem selben Raid des SANs liegen. Damit sind die Dateien für DB, T-Log und TempDB nicht getrennt. Ich weiß, dass das die Vorgaben zur optimierten Installation eines MSSQL durch Microsoft sind (Dokument habe ich jetzt nicht zur Hand). Für Indizierungsprobleme haben wir uns schon einen Profi für MSSQL (mit Dynamics NAV!) ins Haus geholt. Er konnte auch einiges erkennen und ändern, aber eine dramatische Besserung hat das nicht gebracht. Allerdings ist seine Aussage, dass die Performance des virtualisierten Windows Servers mit MSSQL schon sehr gut ist. Ob allerdings in NAV Probleme liegen, die nur die Anwendungsentwickler erkennen und lösen können, haben wir noch nicht geprüft. @zahni Bzgl der CPUs habe ich mich ein wenig vertan. Der Host hat 2x Quadcores. Hyperthreading (nicht HyperV!) ist abgeschaltet. Der VM des MSSQL sind alle 8x CPU-Kerne zugeordnet. Das sollte problemlos sein, da der Host keine weiteren VMs laufen hat. MSSQL in der Standardversion verwendet nur 4 Kerne, was man klar am Taskmanager erkennen kann. Die restlichen 4 Kerne dümpeln nur vor sich hin. Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 5. Januar 2012 Melden Teilen Geschrieben 5. Januar 2012 Moin, Der MSSQL Server hat seine beiden Platten auf ein und dem selben Raid des SANs liegen. das wäre Punkt 1, den man ändern sollte. Erfordert ggf. Umkonfiguration im SAN und in den Speicherpfaden der DB, aber nicht in der Datenbanklogik. Damit sind die Dateien für DB, T-Log und TempDB nicht getrennt. Ich weiß, dass das die Vorgaben zur optimierten Installation eines MSSQL durch Microsoft sind (Dokument habe ich jetzt nicht zur Hand). Da fehlt zwischen "dass das" und "die Vorgaben" aber ein "nicht", oder? Der VM des MSSQL sind alle 8x CPU-Kerne zugeordnet. Das sollte problemlos sein, da der Host keine weiteren VMs laufen hat. Nein. Der Host hat auch selbst was zu tun und braucht dafür CPU-Leistung. Das ist bei allen Virtualisierern so (wie sollte es auch anders sein?), bei Hyper-V und Verwandten aber besonders. faq-o-matic.net » Hyper-V-Sizing: Virtuelle und echte CPUs MSSQL in der Standardversion verwendet nur 4 Kerne, was man klar am Taskmanager erkennen kann. Die restlichen 4 Kerne dümpeln nur vor sich hin. Dann gibst du der VM natürlich auch nicht mehr als vier vCPUs. Siehe obiger Artikel. Gruß, Nils Zitieren Link zu diesem Kommentar
passt 10 Geschrieben 5. Januar 2012 Autor Melden Teilen Geschrieben 5. Januar 2012 Nein, mir ist schon bekannt, dass bei MSSQL Installation die drei Bereiche getrennt werden sollten. Bei der Installation hatte ich allerdings nichts zu sagen, muss jetzt aber die Performance Probleme ausbügeln. Bzgl VM hast du fälschlicherweise angenommen, dass ich HyperV einsetze. Es ist aber VMware ESX. Andererseits gehe ich davon aus, dass VMware und HyperV bzgl der Verwendung von vCPUs sich analog verhalten und werde die vCPUs der Maschine auf vier reduzieren. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.