peternunaber
Goto Top

Defekten Informationsspeicher in erster Speichergruppe löschen (sbs2003)

Ein nicht mehr online zu schaltender Informationsspeicher eines Exchange 2003 (sbs2003) soll gelöscht werden, um die vielen Transaktionsprotokolldateien zu reduzieren. Der Speicher war wohl defekt (hat mein Vorgängeradmin so übermittelt) und liegt nun als "Leiche" mit in der Ersten Speichergruppe. Dieser defekte Informationsspeicher soll gelöscht werden.

...wie oben schon beschrieben.

Zuerst das Gute: der Exchange läuft, der aktuelle Informationsspeicher läßt sich bereitstellen. Datensicherung ist vollständig (auch Informationsspeicher) durchgelaufen

Das Problem: unter "Erste Speichergruppe" existieren 3 Punkte:
1. der defekte, alte Informationsspeicher namens "defekt", der gelöscht werden soll, sich aber nicht löschen läßt
2. der funktionierende "Informationsspeicher für öffentliche Ordner"
3. der Postfachspeicher

Wenn ich versuche den "defekt" Infospeicher zu löschen (rechte Maustaste), kommt die Aufforderung, den Infospeicher online zu bringen,
was nicht mehr geht. Es kommt unter anderem die Meldung: Wenn sie den Informationsspeicher für Öffentliche Ordner nicht onlien schalten können und sie diesen löschen möchten, entfernen sie die EDB-datenbankdateien und STM-Datenbankdateien des Informationsspeichers für Öffentliche Oderner manuell vom Computer, erstellen Sie den Informationsspeicher für öffentliche Odner neu, und versuchen Sie anschließend, den Informationsordner für Öffentliche Ordner erneut zu löschen.

Nun habe ich aber einen funktionierenden Informationsspeicher, und will keinen neuen erstellen!!! d.h. punkt zwei der Aufforderung ist schon geschehen.

Ziel ist es, die inzwischen weit über 10000 E00xxx.log Dateien zu reduzieren, da u.a. der Platz gebraucht wird. Die ganzen Transaktionslog werden einfach nicht abgearbeitet, auch nicht beim Neustart.

Weiterhin kann ich keine zusätzlichen Dateien entdecken, die auf einen weiteren Informationsspeicher hinweisen. Im Odner MDBDATA befinden sich priv1.edb, pub1.edb, tmp.edb, priv1.stm, pub1.stm und weitere weit über 10000 E00xxx.log Dateien.

Und nu? Danke für Eure Hilfe im Voraus....

Content-Key: 175642

Url: https://administrator.de/contentid/175642

Printed on: April 23, 2024 at 09:04 o'clock

Member: ollembyssan
ollembyssan Nov 02, 2011 at 12:15:55 (UTC)
Goto Top
Hallo,

ist etwas wirr geschrieben dein Beitrag...aber wenn Du dich etwas mit ADSIEDIT auskennst, dann kannst Du den defekten Informationsspeicher hiermit löschen, nicht die (Erste) Speichergruppe.

Grüße
Stephan
Member: peternunaber
peternunaber Nov 03, 2011 at 09:25:09 (UTC)
Goto Top
Hallo Stephan,

Danke für Deine Antwort. Zunächst noch einmal zur Erklärung: ich vermute, dass Aufgrund des einen "defekten" Informationsspeichers (hatte ich als "Leiche" bezeichnet) die Transaktionsprotokolle nicht verarbeitet werden, wenn das OnlineBackup vollständig durchgelaufen ist. Es geht also um 2 Dinge:

1. Transaktionsprotokolle in die Datenbank verarbeiten, um von den z.Z. 60 GB verbrauchten Speicherplatz runter zu kommen
2. Aufräumen, und den defekten Informationsspeicher entfernen.

Nun habe ich gelesen, dass nach einem vollständigen OnlineBackup (und das funktioniert ja) die Transaktionprotokolle verarbeitet werden, und damit weniger werden müßten. Aber genau dass passiert nicht. Meine Überlegung dazu ist momentan, die Umlaufprotokollierung einzuschalten, um die Verabeitung zu forcieren.

Ich mache im Moment noch einmal eine Offline-Sicherung des gesamten Verzeichnis Exchsrv zur Sicherheit.


Habe mich mit dem ADSI Edit beschäftigt. Unter:

Configuration - CN=Configuration - CN=Services - CN=Microsoft Exchange - CN=(Domain Name) - CN=Administrative Groups -CN=erste administrative gruppe - CN=Server - CN=(Server Name) - CN=Information Store - CN=Erste Speichergruppe

habe ich einen Eintrag mit CN=defekt (der defekte Inforamtionsspeicher heißt wirklich so) gefunden.

Meinst Du, ich soll diesen löschen?

MfG PeterNunAber
Member: ollembyssan
ollembyssan Nov 03, 2011 at 12:18:18 (UTC)
Goto Top
Hallo PeterNunAber,

ich verstehe nicht ganz, die Daten im "Defekten Informationsspeicher" können gelöscht werden, sind denn noch Daten darin vorhanden oder wurden die bereits verschoben?
Bei einer vollständigen Sicherung werden nicht mehr benötigte Transaktionsprotokolle gelöscht, richtig.

Wenn Du den defekten Informationsspeicher per ADSIEDIT löschst, dann verschiwndet dieser natürlich auch aus dem Exchange System Manager.
Ansonsten kannst Du nicht mehr benötigte Transaktionsprotokolle auch manuell löschen:
Zur Vorgehensweise siehe dazu:
http://support.microsoft.com/kb/240145/de

Grüße
Stephan
Member: peternunaber
peternunaber Nov 03, 2011 at 12:47:00 (UTC)
Goto Top
Hallo Stephan,

der "defekte" InfoSpeicher ist nicht mal mehr mit einer Datenbank verbunden, d.h. wenn ich auf den Pfad zur Datenbank gehe ,stehen dort eine old.pub (wahrscheinlich irgendwann umbenannt) und eine old.edb drin. Beide Dateien exitieren nicht physikalisch. Der defekte Infospeicher startet auch nicht mit. Es sind also keine Daten mehr drin...

Die automatischen "Aufräumdienste" gehen immer von einem fuktionierenden Informationsspeicher aus, soweit ich weiß. Wenn ich den Dienst des Informationsspeichers anhalte und neu starte, kommt ein Fehler EID 9519 "Fehler 0x8004010f beim Starten der Datenbank "Erste Speichergruppe\3847357a-... im MS Exchange-Informationsspeicher. Der zweite in der Speichergruppe liegende Informationsspeicher arbeitet einwandfrei, und läßt sich auch starten. Nun vermute nun, das die sich nicht abarbeitenden Transaktionslogs wegen des defekten Speichers noch da sind. Ich habe mal geschaut, das Datum der Dateien geht bis zum November 2009 zurück (13000 Dateien).

Auslöser der Missere ist eine versendete Massenmail mit ca. 15 GB Datenvolumen, welche über eine Bandbreite von ca. 60 kb/sek (!!!!) versendet werden sollten. Nun schaukelt sich der ganze Server auf, das MDBDATA ist in den letzten 4 Tagen um 40 GB gewachsen. Das Backupmedium kann die Gesamtgröße nicht mehr fassen und so weiter. (Sparzwang durch die Zentrale...) Das Verzeichnis MDBData ist um 60 GB gewachsen.

Deswegen möchte ich den defekten Informationsspeicher löschen und die Anzahl der Transaktionslogs wieder verkleinern. Umlaufprotokollierung wäre meine Idee, wenn ich den defekte InfoSpeicher gelöscht habe.

MfG PeterNunAber
Member: ollembyssan
ollembyssan Nov 03, 2011 at 13:12:00 (UTC)
Goto Top
Hallo PeterNunAber,

dann kannst Du zunächst das Vorhaben über ADSIEDIT lösen und den defekten Informationsspeicher löschen!
Aber auch nur den defekten Informationsspeicher, wie oben beschrieben unter:

CN=Configuration - CN=Services - CN=Microsoft Exchange - CN=(Domain Name) - CN=Administrative Groups -CN=erste administrative gruppe - CN=Server - CN=(Server Name) - CN=Information Store - CN=Erste Speichergruppe
CN=defekt (der defekte Inforamtionsspeicher).

Anschließend den ESM neustarten.

Grüße
Stephan
Member: peternunaber
peternunaber Nov 03, 2011 at 13:40:25 (UTC)
Goto Top
Hallo Stephan,

dann werde ich das mal so tun, wenn das Offline - Backup durch ist.

Wenn ich dem Informationsspeicher nach dem "ADSIEDIT - Löschen" neu gestartet habe, werde ich ein Onlinebackup anschieben. Dabei sollte dann ja aufgeräumt werden. Melde mich dann.

Danke erst einmal!!!

MfG PeterNunAber
Member: peternunaber
peternunaber Nov 04, 2011 at 09:05:03 (UTC)
Goto Top
Hallo,

mit einem Wort: Sieg!

Nach dem Löschen des defekten Informationsspeichers über ADSIEDIT habe ich noch alle verbleibenden, der GuID des defekten Speichers entsprechenden Einträge der Registry gesucht und per Hand gelöscht. Danach habe ich über Nacht ein Onlinebackup angeschoben, welches nach erfolgreichem Ablauf sämtliche 13000 Transaktionslogs verarbeitet und gelöscht hat. Ich brauchte also nicht den Weg über die Umlaufprotokollierung gehen.

Die Platte ist jetzt zwar um 65 GB leichter, aber das war ja auch das Ziel... Jetzt muss ich nur noch sehen, ob der verbleibende Informationsspeicher wieder kleiner wird. Der hat sich ja auch aufgrund der Mailsaktion um ca. 20 GB vergrößert.

Danke noch mal für die Hilfe.

Mit freundlichem Gruß
PeterNunAber