Die Diskussion driftet gerade leicht von der ursprünglichen Frage weg - und anhand einer kleinen Rechnerei seht ihr auch gleich, warum es eigentlich total irrelevant ist wie viele Datenbanken (zahlenmäßig) da so vor sich hin existieren.
Ich habe mir mal aus einer Installation mit 3 Servern, davon 2 im Cluster und aktivem Domain Catalog die Zeiten herausgesucht. Und etwas experimentiert.
Ein Server (ich nenne ihn mal C) dreht nur für den Traveler und langweilt sich zu Tode - hier brauchte der Cataloger ca. 4s für alle(!) 126 DB's (=31,5 DB's je Sekunde, rein rechnerisch).
Dann kommen zwei geclusterte Server mit fast identischem Setting und DB-Umfang, da wird's gleich etwas spannender.
Server A - hier brauchte der Cataloger ca. 6min für 1337 DB's (=3,7 DB's je Sekunde).
Server B - hier brauchte der Cataloger ca. 48min für 1348 DB's (=0,45 DB's je Sekunde).
Es macht auch keinen wirklichen Unterschied ob die Cataloger im Datenbank-Modus oder als Domänenkatalog unterwegs sind - eine kurze Replikation zusätzlich sollte kaum der Rede wert sein.
Rein rechnerisch sind auch die in einem anderen Post erwähnten 16.000 DB's in unter 24h kein Problem - Server C könnte in 24h bei ca 30 DB's je Sekunde problemlos weit über 2.000.000 Datenbanken abfrühstücken und selbst der langsamste der drei (Server B) käme immer noch auf >38.000 DB's(!).
Es kommt also nicht wirklich auf die schiere Menge sondern auf andere Dinge an.
Wir haben hier beispielsweise für den nahezu gleichen Datenbestand der Server A+B einen Unterschied vom Faktor 10! Das kann ja nicht an einer handvoll Datenbanken liegen, oder?
Oh doch! Aber nicht an der DB-Anzahl.
Zuerst hatte ich die Last der Maschine B im Verdacht den Unterschied zu verursachen - aber morgens 3 und nachmittags 17 Uhr unterscheidet sich die Laufzeit nur um 1-2 Minuten; also Gedanke verworfen - andere Ursache.
Ich habe mir dann mal den Performancemonitor geschnappt und etwas genauer hingeschaut, was der Cataloger denn da so treibt, was er öffnet und wo er länger braucht.
Zusätzlich habe ich die Protokollierung am Server selbst eingeschaltet (log_catalog=1) um festzustellen ob es außer den angezeigten Datenbanken auch noch andere Zugriffe gibt.
Und au ja - die gibt es. Etwas überraschend für mich trieb sich der Cataloger nämlich nicht nur in den Datenbanken selbst sondern auch länger in den FT Dateien und (weniger überraschend) den ausgelagerten NDX Dateien herum.
Die größte Überraschung aber war, dass 90% der zusätzlich benötigten Zeit auf das Konto von 4-5 Datenbanken ging, in zweien trieb sich der Cataloger geschlagene 10 Minuten herum während er die restliche Masse quasi nebenbei verarbeitet hat.
Mit etwas Überlegung (und etwas Erfahrung aus diversen Performance-Analysen und -Optimierungen) kommt man zu folgenden Schlüssen:
Der Knackpunkt ist nicht die Last des Servers durch Nutzer oder Agenten sondern I/O. Je mehr man die I/O optimiert umso flotter kommt der Cataloger durch.
Im obigen Fall haben Server A+B die FTI und NDX zwar beide ausgelagert aber ratet mal, welcher Server die Verzeichnisse auch auf einem separaten LW verwendet und dadurch u.a. die Disk Queue (Warteschlange für Dateioperationen = I/O-Limit) und den Durchsatz (nochmal I/O) vervielfacht.
Was macht den Cataloger so I/O-intensiv? Er zählt. Er zählt und baut sich dafür scheinbar on-the-fly Query um Query zusammen für ACL, Dokumente, Design-Dokumente, gelöschte Dokumente, Profil-Dokumente, Nutzungsstatistiken (...).
Und in Datenbanken mit Millionen von Dokumenten aller Arten zählt er auch mal etwas länger. Und wenn die DB's und Indizies fragmentiert im Filesystem herumliegen noch länger.
Und wenn der Server auf der gleichen Platte nebenbei noch Compact, DBMT oder andere I/O-intensive Dinge tut noch viel länger.
Und wenn der Cataloger dann dabei noch auf DB's trifft, die lange nicht geöffnet wurden oder deren Zeitpunkt zum Prunen von Löschungen erreicht ist dann triggert er zuerst die entsprechenden Aufräumtasks und wartet so lange untätig.
Und last but not least: falls der Server während dieser Warterei herunterfährt wird er am nächsten Tag an der gleichen Stelle vermutlich wieder warten müssen.
HTH,
Carsten
Thema: cataloger wird innerhalb von 23 Std. nicht fertig (Gelesen 6551 mal)