Warum werden meine Datenbanken so groß?!

C.Kaiser Als Antwort am 9 Feb. 2012 11:28

Die LDF-Dateien speichern sämtliche Transaktionen welche die Datenbank durchführt (Transaction Log). Wenn ihr das Full-Recovery-Modell für die Datenbanken anwendet, müssen die Transaktion-Logs separat gesichert werden, damit die Datei (LDF) wieder von vorne beschrieben wird.

Ob Ihr den Vollständigen Wiederherstellungsmodus braucht kann ich Dir nicht sagen, hier sind aber ein paar Hinweise die es zu beachten gilt_
http://www.sqlskills.com/BLOGS/PAUL/post/Importance-of-proper-transaction-log-size-management.aspx

b k Als Antwort am 9 Feb. 2012 11:35

Ja, soweit war mir das schon klar... aber warum sollten gerade bei der Administration so viele Transaktionen stattfinden? Wenn ich an der DB den Modus auf Masse/einfach stelle, will das System aber auch nicht mehr... also einfach umstellen und auf die Möglichkeiten verzichten, ist auch nicht...

Und bei den Benutzerprofilen ist es ja die .mdf, die 5GB überschreitet...

C.Kaiser Als Antwort am 9 Feb. 2012 12:34

Sharepoint ist, und das hat sich mit Version 2010 noch "verschlimmert", auch im Hintergrund sehr gesprächig.

Rufe beispielsweise mal die "HealthReport"-Liste auf (Zentraldministration der gelbe / rote Balken beim Start oder ~/Lists/HealthReports/) und lass die die Anzahl der Versionen für ein Element anzeigen. Alleine daran wirds schon deutlich.

Um welche Profiledatenbank handelt es sich denn (Beispiele bei einem Kunden mit 40000 Profilen):
- SyncDB: 12GB
- ProfileDB: 3.5GB
- SocialDB: 3MB  ( ;-) )

Man müsste da mal nachschauen, was da so alles gespeichert wird.

b k Als Antwort am 9 Feb. 2012 13:21

Ohje, da hast du mich ja auf eine Fährte gebracht.... hätte nicht gedacht dass auf die Admin "listen" auch Versionierung läuf... macht doch an der Stelle wenig Sinn, oder? Warum interessiert es mich, wann sich die Fehlermeldung wiederholt usw? Würde dafür die Versionierung einfach mal ausschalten, oder kann das Probleme geben?

Die DB mit den 5GB ist die SyncDB.... das erscheint mir bei deinem Bsp. mit den 12Gb für 40000 Profile doch VIEL zu mächtig, bei garantiet unter 50 Profilen?

C.Kaiser Als Antwort am 9 Feb. 2012 13:32

Problematisch ist bei der Health-Liste ja vor allem der TimerJob der den Festplattenplatz prüft, da würde ich die JobDefinition eventuell von stündlich auf täglich setzen und bevor ich die Versionierung ganz abstelle die Versionen begrenzen -> aber Achtung : das ist ohne Gewähr, da ich nicht weiß wie sich Sharepoint da verhält und ob das ein Problem ist.

Beim Sync würde ich mal schauen wie oft die Synchronisation läuft und wie oft das erforderlich ist. Hier läuft der Sync einmal täglich und die Benutzergruppenkompillierungen einmal wöchentlich. Eventuell habt ihr hier Zeitpläne die deutlich häufiger laufen.

b k Als Antwort am 9 Feb. 2012 13:58

Ok... habe jetzt den Timer mal auf monatlich gesetzt (der motzt ja eh schon viel zu früh) und alle alten Versionen raus (waren tatsächlich an die 3000 Versionen O_O). Jetzt ist die Frage, wird der Speicherplaz nochmal freigegeben, oder ist der durch die DB jetzt einfach belegt?

Bei den Profilen standen beide Syncs auf 1x Täglich. Habe die Kompilierung jetzt auch mal auf wöchentlich gesetzt, aber das allein dürfte doch nicht so extrem Speicherplatz belegen, oder? Ein vorhandenes Profil sollte doch nur um neue Werte ergänzt werden und nicht nachher x-fach in der DB liegen, oder täusche ich mich da?

C.Kaiser Als Antwort am 9 Feb. 2012 14:08

Bzgl. der Sync-DB schau mal hier:
http://paulliebrand.com/2011/05/26/user-profile-synchronization-database-growing-out-of-control/