Umdimensionieren

[Erlkönig 10]

Hallo,

ich hab da eine DB mit 20GB auf der jetzt schon extrem viel Last ist (Branchenapplikation "all in one" mit einem Haufen Referenzierungen, Abfragewütigen Usern, einem Haufen Reports etc.).

 

Nun werden beim nächsten Versionsupgrade die Dokumente (alles was das bisherige Office Paket) binär und als Text in die Datenbank wandern was bei mir Kopfschmerzen hinsichtlich Systembremsen verursacht (Volltextsuche zB ),

 

 

Wie steuert man hier am besten gegen?

 

Ich dachte an eigene SQL-Instanz (RAM & Prozessorbeschränkung auf die Prozesse) sowie eine eigene LUN für diese DBs.

 

Gibts da sonst noch was zu beherzigen, bzw. wo oder noch besser wie findet man Dokus nach denen man hier vorgeht?

 

Danke und lieben Gruß

 

Erlkönig

[NilsK 2.934]

Moin,

 

was meinst du mit "eigene SQL-Instanz"? Einen separaten Server? Oder eine zweite Installation auf demselben Server?

 

Letzteres sowie eine Ressourcenbeschränkung würden nach hinten losgehen. Ob ersteres nötig ist, kann man ohne nähere Analyse nicht beantworten.

 

Sprich mit dem Hersteller der Applikation die Anforderungen und Systemempfehlungen ab. Und schau dir allgemeine Empfehlungen zur SQL-Optimierung an; TechNet ist eine gute Quelle dafür.

 

Grundsätzlich: Ein Datenbankserver braucht RAM. Und eine schnelle Anbindung ans Storage. In deinem Fall lässt sich sicherlich auch über getrennte Datenbereiche für die strukturierten (Tabellen) und die unstrukturierten Daten (Dokumente, Binaries, Massentext) was machen. Alles Weitere könnten wir hier nur orakeln*.

 

Gruß, Nils

* Man beachte das tolle Wortspiel. ;)

[Erlkönig 10]

Danke für die Hinweise!

 

Einen separaten Server? Oder eine zweite Installation auf demselben Server?

eine zweite Installation in Form einer zweiten benannten Instanz, die eine andere DB ansteuert, die physikalisch einen eigenen RAID hat war bzw. ist mein Ansatz.

 

Sprich mit dem Hersteller der Applikation die Anforderungen und Systemempfehlungen ab.

 

:) In diesem Prozess der Ausarbeitung von Empfehlungen stecke ich gerade. Nur das er zu mir gekommen ist.

 

TechNet ist eine gute Quelle dafür.

Dort wird zu diesem Thema der Wald wird wegen zuvielen Bäumen nicht gefunden. :confused:

 

Ein Datenbankserver braucht RAM. Und eine schnelle Anbindung ans Storage.

Beides soweit gegeben, auf jeweils fünf User kommen im Schnitt 8GB.

Ich könnt wenn es Sinn macht auch einen zweiten HBA verbauen lassen um die Datenbank mit Doks usw dezidiert ansteuern zu lassen.

 

In deinem Fall lässt sich sicherlich auch über getrennte Datenbereiche für die strukturierten (Tabellen) und die unstrukturierten Daten (Dokumente, Binaries, Massentext) was machen.

Genau das wurde von DEV angedacht, von dort aus landeten wir bei einer zweiten Datenbank (eigene Spindeln) auf einer einer eigenen SQL-Instanz.

 

Wo bzw. noch besser wie find ich im Technet zu so einem konkreten Thema was?

 

gruss,

Erlkönig

[NilsK 2.934]

Moin,

 

ich habe keine Ahnung, wie ihr auf die Idee mit der zweiten Instanz kommt. Lasst das bleiben, das ist Unsinn. SQL Server hat ein hervorragendes Speichermanagement, das problemlos auch mit mehreren Datenbanken unter Last klarkommt. Im Normalfall sollte man nicht daran drehen.

 

Performance-Optimierung für Datenbanken ist ein sehr umfangreiches Thema. Ohne genaue Analyse und genaue Kenntnis der Applikation wird man da nicht weit kommen. Die pauschalen Empfehlungen, die man hier geben kann, habe ich genannt. Ja, damit muss man sich im Zweifel intensiv beschäftigen, mit "mal eben" ist da nix.

 

Bedenke aber: Die weitaus meisten Performanceprobleme bei real existierenden Datenbankapplikationen sind nicht durch den Server verursacht, sondern durch die Applikation. Stichworte: Schlecht aufgebaute Abfragen, zu große Datenbewegungen und vor allem Parallelitäts- und Sperrkonflikte.

 

Wenn der Entwickler der Datenbank zu dir kommt, um nach Empfehlungen zu fragen, spricht das IMHO nicht für ihn.

 

Gruß, Nils

[Erlkönig 10]

um nach Empfehlungen zu fragen, spricht das IMHO nicht für ihn.

Man nimmt was man auf der Lohnliste hat :-)

 

 

Stichworte: Schlecht aufgebaute Abfragen, zu große Datenbewegungen und vor allem Parallelitäts- und Sperrkonflikte.

Das übersteigt meine AOR, ich kann nur sagen:

 

a) Daten abtrennen und in eigene Datenbank -> eigene DB auf eigenen Spindeln mit eigenem 4GB FC-HBA ?

b) eigene Instanz und dieser 30GB RAM zuweisen

c) beides

 

Frage zur Erklärung:

Datenbereiche trennen heißt bei Dir jetzt in der DB umbauen aber in der gleichen Datenbank bleiben, aber der mehr Spindeln und einen zweiten HBA geben?

 

Danke,

Erlkönig

[NilsK 2.934]

Moin,

 

schmink dir bitte endlich die eigene Instanz ab. Die gibt dir ausschließlich Nachteile.

 

Alles, was ich dazu sagen kann, habe ich gesagt. Konkretere Empfehlungen werde ich in diesem Rahmen nicht aussprechen, das wäre unseriös.

 

Gruß, Nils

[Greg 10]

Hallo

 

Eine zweite Instanz bringt hier eigentlich nur etwas, wenn die Temp-DB das Problem darstellen würde. Das ist zwar möglich, muss aber zuerst analysiert werden. Ein Nachteil ist, dass Du bei einer zweiten Instanz die ganzen Konfigs wieder erstellen musst (Security, Wartungspläne, etc).

 

Es ist auch möglich, die Datenbank- und Logfiles innerhalb der gleichen Instanz auf separate LUN's zu packen. Dann DB-Files von Logfiles physisch trennen, die Temp-DB trennen und richtig konfigurieren, etc. Zu diesen Themen findest Du im TechNet trotz Bäumen sicher auch den Wald :-).

 

Wichtig ist es herauszufinden, wo das Problem liegt. Dazu gibt es diverse Tools (Profiler, Tuning Advisor, Performance Monitoring, etc.) Anbei sende ich Dir zwei Links die Dir vielleicht einige Einstiegspunkte liefern (Einer ist übrigens vom TechNet):

 

Troubleshooting Performance Problems in SQL Server 2005

Truly Level 400 Microsoft SQL Server 2008 and SQL Server 2005 Performance Monitoring & Tuning Workshops & Webcasts - Webcasts 4

 

Viel Erfolg

Gruss Greg