Moin,
ehrlich gesagt: Keine Ahnung. Bei Ex 2010 habe ich noch nie eine Datenbank defragmentiert.
Schätzungen im Internet gehen von einer Rate von 10 bis 20 GB pro Stunde aus. Das wären bei Dir also zwischen 16 und 32 Stunden.
Dazu kommt in Deinem Szenario noch, dass Du unbedingt vorher ein Backup machen musst (Verlustrisiko der TEMP-DB) und der Kopiervorgang der TEMP-DB. Das dürfte nochmal mindestens eine Stunde sein.
Moin,
bei einer DAG geht Defragmentieren nicht.
- Kopien löschen
- Datenbank defragmentieren
- Kopien wieder anlegen
Wobei eine DAG ja keine bit-identische Kopie ist, wie mir meine Erinnerung sagt. Insofern, vielleicht reicht ja das jeweilige löschen der Kopie. 
einen Versuch wäre es wert.
Moin,
ich habe das schon mal in einer Testumgebung durchgespielt.
Wenn man in einer DAG eine DB defragmentiert (oder repartiert), betrachtet Exchange die Kopie als "fehlerhaft / unsynchron" und die einzige offizielle Lösung lautet: Re-Seeding.
Und das kommt faktisch Wegwerfen + Neumachen gleich.
Ob die beiden Kopien bit-gleich sind (bei mir in Test waren sie es), kann man streiten. Aber sie sind inhaltsgleich. Die Online-Defragmentierung und 24x7 Scanning möchte sicher in beiden Datenbanken die gleichen Inhalte vorfinden.
Zitat
RobertW schrieb:
Ob die beiden Kopien bit-gleich sind (bei mir in Test waren sie es), kann man streiten. Aber sie sind inhaltsgleich. Die Online-Defragmentierung und 24x7 Scanning möchte sicher in beiden Datenbanken die gleichen Inhalte vorfinden.
Die gleichen Inhalte schon, aber was soll ich mit den leeren Datenbank-Seiten in der neuen Kopie?
Bye
Norbert
Ich habe mir das mal auf einem Server (DAG, 2 Knoten) hier angesehen:
[PS] C:\>Get-MailboxDatabase -Status -Server sv0075 | sort-object Name | ft Name,DatabaseSize -AutoSize
Name DatabaseSize
---- ------------
DB01_0075 296 GB (317,836,558,336 bytes)
DB02_0075 346.9 GB (372,463,697,920 bytes)
DB03_0075 412.9 GB (443,330,134,016 bytes)
DB04_0075 360.6 GB (387,227,648,000 bytes)
DB05_0076 392.8 GB (421,721,079,808 bytes)
DB06_0076 391.6 GB (420,513,644,544 bytes)
DB07_0076 410.8 GB (441,048,956,928 bytes)
DB08_0076 340.8 GB (365,887,029,248 bytes)
[PS] C:\>Get-MailboxDatabase -Status -Server sv0076 | sort-object Name | ft Name,DatabaseSize -AutoSize
Name DatabaseSize
---- ------------
DB01_0075 296 GB (317,836,558,336 bytes)
DB02_0075 346.9 GB (372,463,697,920 bytes)
DB03_0075 412.9 GB (443,330,134,016 bytes)
DB04_0075 360.6 GB (387,227,648,000 bytes)
DB05_0076 392.8 GB (421,721,079,808 bytes)
DB06_0076 391.6 GB (420,513,644,544 bytes)
DB07_0076 410.8 GB (441,048,956,928 bytes)
DB08_0076 340.8 GB (365,887,029,248 bytes)Die Zahlen stimmen mit denen überein, die mir der Explorer anzeigt.
Also ich denke schon, dass die sogar bit-gleich sind.
Und ehrlich gesagt, denke ich auch, dass es das leichteste ist: Mit zwei identischen Kopien die gleichen Transaktionen durchführen führt dann automatisch zum gleichen Ergebnis.
OK, dann gehts nicht. Zeit gespart.
Dafür weiß ich wie ich auf "nicht bitidentisch" komme. 
http://www.mcseboard.de/topic/…-database-offline-defrag/
Früher war ich nämlich anderer Meinung wie man dort lesen kann. 
Bye
Norbert
Interessant an meinem Post #6 im MCSEBOARD ist, dass es die gleichen Datenbank sind - nur gut 1,5 Jahre früher. Da war die Migration der Postfächer noch nicht abgeschlossen.
Beide Datenbanken habe im Dezember 2011 nach einem Plattenfehlers eines der beiden Server ein Re-Seeding bekommen. Schade, dass ich damals nicht den Stand der anderen 6 DB protokolliert hatte.
Das mit der Defragmentierung von damals stimmte aber, daran kann ich mich erinnern: Die passive, angehaltene Kopie war nicht Clean Shutdown.
im Endeffekt sind Diskussionen darüber aber müssig, da wir nur von Erfahrungen und Beobachten reden können, solange nicht ein MSFT-Mensch die Tatsachen offenlegt.
Aber irgendwie spannend, hinter die Kulissen zu schauen.
Wenn ich mit Kunden rede, sage ich an der Stelle übrigens auch nicht "bit-identisch", sondern nur "inhaltsgleich" - was bei einer SQL-Datenbank sehr viel Platz für Spekulationen offen lässt.