5 Antworten in diesem Thema

[apg1980]

Hallo zusammen,

für einen Kunden schreibe ich gerade ein Powershellskript, dass bestimmte Datenbanken in einer DAG offline mit eseutil defragmentieren soll.

Der Ablauf des Skriptes ist wie folgt:

- Schwenk er aktiven Datenbank Move-ActiveMailboxDatabase
- Datenbank Kopie DAG anhalten Suspend-MailboxDatabasecopy
- Versuch passive Version zu defragmentieren
- Datenbank Kopie DAG fortsetzen Resume-MailboxDatabasecopy
- Schwenk der Datenbank zurück Move-ActiveMailboxDatabase

Im Prinzip macht das Skript was es soll.
Leider habe ich das Problem dass die angehaltene Datenbank einen Dirty Shutdown State hat.

Im Netz habe ich zum Thema schon einen Link gefunden My LCR / CCR / SCR / DAG database copy is in dirty shutdown state

Besteht überhaupt die Möglichkeit den Defrag durchzuführen ohne den Zugriff komplett zu verlieren.

So wie es im Moment aussieht komme ich um eine komplette Maintenance der Datenbank nicht herum.

Hat jemand von Euch diesbezüglich Erfahrungen um einen Hochverfügbaren Exchange dank DAG zu defragmentieren.

Hinweis: den Offline Defrag deshalb, weil ich den Whitespace freigeben möchte, die Onlinemaintenance brauche ich nicht zu erwähnen.

Vielen Dank schon mal im Voraus, und Liebe Grüße

[NorbertFe]

AFAIK sind die DB-Kopien in einer DAG bitgenau. Heißt, du kannst eine passive Kopie nicht defragmentieren, sondern mußt dazu die komplette DB offline schalten. Was genau versprichst du dir eigentlich von sowas?

Bye
Norbert

[apg1980]

Im Grunde verspreche ich mir zu vermeiden, dass es eine Downtime gibt.
Das Ergebnis sollte sein, dass der Whitespace in der Datenbank wieder als freier Storageplatz zur Verfügung steht und der Anwender das nicht mitbekommt.

[NilsK]

Moin,

deine beiden Anforderungen widersprechen sich. Offline-Defrag heißt Downtime. Punkt.

Warum meinst du, den Whitespace im Dateisystem freigeben zu müssen? Best Practice ist, dass die Exchange-Datenbanken ein ganzes Volume für sich haben, auf dem nichts anderes liegt. Dann braucht es dich bei "Whitespace" gar nicht zu kümmern, ob er innerhalb oder außerhalb der Datenbankdatei liegt.

Gruß, Nils

[NorbertFe]

Im Grunde verspreche ich mir zu vermeiden, dass es eine Downtime gibt.

Siehe oben. Das geht nicht. Die DB Copy ist bit-identisch.

Das Ergebnis sollte sein, dass der Whitespace in der Datenbank wieder als freier Storageplatz zur Verfügung steht und der Anwender das nicht mitbekommt.

Und warum ist das wichtig? Abgesehen von starker Reduzierung der Daten innerhalb der DB und deswegen erhöhtes Backup Aufkommen kann ich mir grad keinen weiteren sinnvollen Grund vorstellen.

Bye
Norbert

[RobertWi]

Moin,

gerade mal nachgeschaut, bit-identisch sind sie nicht (zumindest nicht zu 100%):

DB1: 146 GB (157.580.066.816 Bytes) <-> 146 GB (157.445.849.088 Bytes) (Differenz: 134.217.728 Bytes)
DB2: 196 GB (210.596.593.664 Bytes) <-> 196 GB (210.462.375.936 Bytes) (Differenz: 134.217.728 Bytes)

Die identische Differenz wundert mich etwas, aber ich habe definitiv auch schon andere Größenunterschiede nach dem Seeding gesehen.

Offline-Defragmentierung geht allerdings trotzdem nicht, ich habe es schon mal ausprobiert.

eseutil will nur Datenbanken offline defragmentieren, die den Status "Clean Shutdown" haben (was ziemlich verständlich ist). Eine passive Datenbank hat diesen Status aber per Definition nie, da immer mind. eine Log-Datei (kleine Ungenauigkeit in meiner Aussage wegen Transaction-Buffer, aber prinzipiell stimmt es).