MajorTom67 said:
Vielleicht sind tatsächlich die Indices zu klotzig
Na das mit dem klotzig war nicht wirklich negativ gemeint; Die MS-SQL Server 6-7 waren noch schlau genug zu versuchen, Indices zu benutzen die bereits die benoetigten Spalten enthielten und dann im optimalen Fall gar nicht mehr auf die eigentliche Datengrube zuzugreifen. Das bringt bei lesen/suchen Aktionen schon einiges (man denke nur an die unzaehligen sortierten Auflistungen die Anwender sich anzeigen lassen) zumal die Indices meist eher in den Arbeitsspeicher passen als dann auch die gesamte Datengrube ... Wie gross ist eigentlich die Datenbank/sind die Indices?
Ich habe schonmal eine "objektorienterte" Datenstruktur auf einer relationalen engine abgebildet ... sollte "Engine-unabhaengig" sein (Chefetage und Marketing wollten es so), da kamen dann halt alle Spalten auch in die Indices rein und die Hardware Anforderungen wurden entsprechend hoch gezogen ;>
Wir hatten da das Problem, dass selbst Erstellungsscripte auf Oracle, PostgreSQL und MS-SQL identisch sein sollten was Konsequenzen mitunter fuer's locking hatte und da mussten dann halt die einzelnen queries so schnell durch sein, dass sie sich nicht im Wege stehn (bei 10 - 15 tsd. Anfragen in 3 Stunden taeglich einmalig zwischen 7 und 10 Uhr halt aber nicht alles aus Dialoganwendungen heraus).
Das war nicht lustig und konnte auch nur interdisziplinaer (Entwicklung client, Entwicklung Server Komponenten, Datenbankentwicklung) halbwegs geloest werden.
Naja aber das mit den indices ist immer ein Zweischneidiges Schwert und hochindividuell unter Einbeziehung der Umfeldes abzuwiegen.
Wenn ich einen schlanken Index habe (optimal nur numerische Werte mit Maschinenwort-Laenge und davon dann auch noch moeglichst wenige) dann sind Such-, Sortier-, Einfuegeoperationen am schnellsten; Die dazugehoerenden Daten schaufeln muss ich allerdings so oder so noch, kein Anwender sucht nach internen Satznummern einer Datenbank.
Die Indices so fett machen, dass sie nicht mehr in den Arbeitsspeicher passen hingegen ist auch Mist und bei haeufigen Aenderungen evtl. zu langsam.
Multiple Indices speziell fuer einzelne Anwendungsfaelle sind eine tolle Sache brauchen aber halt auch zusaetzlichen Platz im Arbeitsspeicher.
MajorTom67 said:
Als Hinweis vielleicht: die DB wächst täglich um 260-270MB
Die DB oder die translogs?
Letztes Jahr hatte ich noch einen Kunden erleben duerfen, der unser "Verfahren" seit Jahren einsetzte. Laut Marketing und Chefetage mussten wir ja DB-unabhaengig sein, weil die Kunden bereits die Server im Einsatz hatten samt hochqualifizierter Administration und Konfiguration und so, wir sollten dann halt in eine bestehende (eh-da) Umgebung rein gehn koennen statt unsere eigene Engine mitzubringen (zu der dann aber auch der Rest optimal passen wuerde).
Naja, jedenfalls kam der Kunde samt Administratoren spezialisiert auf diese DB-Engine nicht damit zurecht (und hatte es auch nicht selbst gemerkt), dass inzwischen die translogs >80 GB auf dem einzigen Volume des Servers beschlagnahmten, als da der Platz ausging sagte der Server halt "uff". ;>
Denen durften wir (Entwickler) dann erstmal verklickern, dass man translogs nach einer Sicherung abschneidet.
MajorTom67 said:
Der Flaschenhals scheint tatsächlich die HD zu sein, wel, wie wir herausbekommen haben, immer beim Schreiben auf die HD diese extremen Verzögerungen auftreten.
...
Wir hatten anfänglich das Prob, daß die DB nicht auf die vollen 6 reservierten GB zugreifen wollte, wass durch WPA (?) geändert wurde. Gebessert hat sich praktisch nichts.
Mit dem "Vollschreiben des RAM" waren tatsächlich die Transactionlogs gemeint, und da wurde schon reduziert, soweit möglich, da unsere Chefitäten umfangreiche Recherche-Möglichkeiten zur Überwachung der Leistung der Mitarbeiter verlangen.
Wenn das so ist ist das wohl tatsaechlich kein Ding fuer die Entwickler mehr, wenn die Datenbankdateien (auch translogs) so gut wachsen, tun sie das ja weil sie das auch sollen. ;>
Nichts desto trotz scheint das Teil ja am Limit zu kratzen.
MajorTom67 said:
Mir persönlich ist leider auch nicht bekannt, an welchem Hebel gedreht werden müßte, um die "kleineren Häppchen" wegschreiben zu lassen,
Mir faellt da was anderes ein...
Es gibt bei MS-SQL pro Datenbank Einstellungsmoeglichkeiten fuer die (initialen) Dateigroessen und die "Zuwachsgroessen", dort wo auch angegeben wird, wo die Dateien liegen sollen (fuer Datenbank und translog).
Dort kann man dann angeben, um wieviel (MB oder %) die Datei vergroessert werden soll, wenn sie voll wird.
Das koennte dann in euerm Fall wenn denn soviele neue Daten anfallen (zumindest in den translogs) helfen. Einfach mal richtig gut groesser machen. Kleine Haeppchen bringen hier wenig weil die Daten in der Datei ja beim Vergroessern nicht unberuehrt bleiben. Wenn ihr den Platz auf dem Datenvolume nicht anderweitig braucht einfach mal alles grosszuegig sinnvoll auf die Dateien aufteilen, dann entfaellt dieses staendige Erweitern und neu Organisieren der Dateien schonmal.
Alternativ wenn noch nicht so gehandhabt koenntet ihr dem SQL-Server bei Gelegenheit auch mal einfach eine rohe Partition zum selbermachen geben (ich nehme an ihr habt im Moment noch ein normales Dateisystem auf einer Partition und darin die Datenbankdateien).
Und nochwas ... wenn man nach angemessenem Zeitraum die translogs sichert und abschneidet wachsen sie auch nicht mehr dann erledigt sich das auch. Kommt halt darauf an, wie lange die fuer die Auswertungen eurer Chefitaeten gebraucht werden.
Soweit die Massnahmen um HD-Zugriffe die auf einen Schlag anfallen (Vergroessern der Dateien) abzufangen.
Eine andere Sache ist die, mal mit der Prozessorbelegung rumzuspielen, dass waehrend das OS mit Dateisystemzugriffen zugange ist der SQL-Server nicht gestoert ist; Der MS-SQL Server hat noch ein paar Einstellungsmoeglichkeiten fuer die CPU-Nutzung/Bindung bei SMP-Systemen, hau da mal Deinen Kollegen an das koennte noch interessant sein.
Unter Umstaenden macht es Sinn den SQL-Server nur auf einer CPU laufen zu lassen, wenn er im Gegenzug vom Tagesgeschaeft des OS unberuehrt bleibt (Vorausgesetzt natuerlich das reicht dann noch).
MajorTom67 said:
Dieses Ergebnis hatte ich schon, als ich darauf hinwies, daß laut Microdoof SQL-DB'en durchaus hin und wieder defragmentiert werden sollten, was bis heute nicht passiert ist. Auch die HD ist ziemlich fragmentiert (bei der letzten Überprüfung über 80%), da das aber ein RAID-Array ist, meinte unser Admin mit SQL-Kenntnissen, das bräuchte man nicht defragmentieren...
Nun das ist nun wirklich nicht mehr Sache eines Entwicklers
(Zu der Sippschaft zaehle ich mich auch wenn ich dummerweise nicht spezialisiert bin.)
Wenn die Defragmentierung nichts von dem RAID weiss bringt es wirklich nicht viel weil dort die aufeinander folgenden Sektoren einer Datei eh nicht auf derselben Platte sein sollten (RAID 5 nehme ich an?).
Ich sehe aber im Moment eh mehr in dem Groesenwachstum der translogs, die sich taeglich um 2-3 hundert MB aufblasen und dann den Inhalt womoeglich noch reorganisieren da hilft auch Defragmentieren nicht. (300 MB einfach nur wegschreiben glaub ich nicht dass das so lange und so intensiv aufhalten wuerde.)
Mit Defragmentieren der DB meinst Du wohl das was sich klassicherweise Reorganisation der DB schimpft (aus einem Land vor unserer Zeit als Backup noch DaSi hiess und man keine Umlaute in der shell hatte ;> wink@DJ), auch das geht einen Entwickler eigentlich nichts an insofern ...
Aber grundsaetzlich sollten Datenbanken
natuerlich regelmaessig im Wartungsfenster auch
einen Reorg durchlaufen sag nicht, das macht ihr nicht.?!
Findet sich bei MS-SQL glaube ich auch irgendwo unter Wartungsjobs des Servers da wo auch die hauseigenen Sicherungen eingerichtet werden.
Schaut erstmal nach den Dateigroessen und zieht die von vorne herein so hoch, dass schonmal die Dateien die Woche unter nicht vergroessert werden muessen (da kann man schonmal schaun wie der Fuellgrad jeweils ist und der Wachstumsfaktor eingestellt ist um zu sehen ob das ein Problem sein koennte).
Wenn ich mich recht entsinne ist die standard Einstellung fuer den Wachstumsfaktor eine absolute und kleine Zahl wenn das nicht geaendert wurde ist das bei 300 MB Wachstum am Tag natuerlich fatal.!
Noch was ... Da bei euch ja das Fuehren und Aufbewahren der translogs "ausschliessslich" ein Beduerfnis der Chefetage befriedigt und ja wohl die translogs auch das Problem sind sollte auch der Verursacher der die Leistung beansprucht dafuer aufkommen, also im Zweifel mal in Richtung mehr Hardware/Cluster aus 2 Servern zu Lasten des Deckungsbeitrages der Chefetage hinarbeiten ;> .
Ciao,
Mercy.
