9
Schwerwiegende EA Fehler Exchange 2010
Geehrte Community,
von einer Sekunde auf die andere können Clients nicht mehr mit dem Exchange 2010 kommunizieren und das EventLog schießt im Sekundentakt folgende Fehler raus:
Quelle: ESE
ID: 482
Der angeforderte Vorgang konnte aufgrund einer Dateisystemeinschränkung nicht abgeschlossen werden.
Quelle: MSExchangeIS
ID: 1159
Datenbankfehler Datenträger-E/A-Fehler in Funktion EcCreateNewTable während des Zugriffs auf Datenbank 'Mailbox Database'.
Laut Microsoft (https://support.microsoft.com/en-us/kb/555423/de) liegt das an zu wenig Speicherplatz? Auf der Platte auf der sich die MBD sich befindet sind noch ca 80GB frei.
Was mich aber sehr wundert ist, dass bei ca 100 Mitarbeitern die Datenbank fast 500GB groß ist.
Ausserdem: Das tägliche Backup kürzt die Logfiles wie es sein soll, dennoch existieren über 7.000 Logfiles (die heute) geschrieben wurden.
Mir fehlt der Vergleich zu anderen Exchange Datenbanken anderer Unternehmen, aber mir scheint das schon sehr viel zu sein?
Ich habe das Gefühl der Fehler liegt wo anders begraben...
Jemand eine Idee?
LG
von einer Sekunde auf die andere können Clients nicht mehr mit dem Exchange 2010 kommunizieren und das EventLog schießt im Sekundentakt folgende Fehler raus:
Quelle: ESE
ID: 482
Der angeforderte Vorgang konnte aufgrund einer Dateisystemeinschränkung nicht abgeschlossen werden.
Quelle: MSExchangeIS
ID: 1159
Datenbankfehler Datenträger-E/A-Fehler in Funktion EcCreateNewTable während des Zugriffs auf Datenbank 'Mailbox Database'.
Laut Microsoft (https://support.microsoft.com/en-us/kb/555423/de) liegt das an zu wenig Speicherplatz? Auf der Platte auf der sich die MBD sich befindet sind noch ca 80GB frei.
Was mich aber sehr wundert ist, dass bei ca 100 Mitarbeitern die Datenbank fast 500GB groß ist.
Ausserdem: Das tägliche Backup kürzt die Logfiles wie es sein soll, dennoch existieren über 7.000 Logfiles (die heute) geschrieben wurden.
Mir fehlt der Vergleich zu anderen Exchange Datenbanken anderer Unternehmen, aber mir scheint das schon sehr viel zu sein?
Ich habe das Gefühl der Fehler liegt wo anders begraben...
Jemand eine Idee?
LG
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 275428
Url: https://administrator.de/contentid/275428
Printed on: April 20, 2024 at 03:04 o'clock
9 Comments
Latest comment
Nabend,
also ein E/A Fehler kann auch eine Defekte HD, RAID ODER CONTROLLER SEIN!
500 GB finde ich bei 100 Usern nicht viel...
7.000 Logfiles ist doch evtl.etwas viel, sind alle von Heute ?
80 GB ist etwas sehr eng...da mußt du schon noch etwa 1TB dabei tun...
prüfe mal deine DB ob sie den status „Clean Shutdown hat.
eseutil /MH „Mailbox Database.edb" >>status.txt
falls die Exchange Datenbank korrupt ist, kannst du noch nicht mal ein ESEUTIL /R oder ein ESEUTIL /P machen,
du brauchst mindestens einmal die db größe + 30 %
also besorg erstmal platz!
lg
Frank
also ein E/A Fehler kann auch eine Defekte HD, RAID ODER CONTROLLER SEIN!
500 GB finde ich bei 100 Usern nicht viel...
7.000 Logfiles ist doch evtl.etwas viel, sind alle von Heute ?
80 GB ist etwas sehr eng...da mußt du schon noch etwa 1TB dabei tun...
prüfe mal deine DB ob sie den status „Clean Shutdown hat.
eseutil /MH „Mailbox Database.edb" >>status.txt
falls die Exchange Datenbank korrupt ist, kannst du noch nicht mal ein ESEUTIL /R oder ein ESEUTIL /P machen,
du brauchst mindestens einmal die db größe + 30 %
also besorg erstmal platz!
lg
Frank
Danke für deinen Beitrag. Eine defekte Festplatte schließe ich aus, denn es handelt sich hier um ein System (OS 2008 R2 + Exchange mit DB)
Ja, die Logfiles sind alle von heute.
Das aus- und wieder Einbinden der DB funktioniert ohne Probleme:
Eseutil /MH Ergebnis:
Die Festplatte ist "nur" 700GB Groß, davon sind eben noch 80GB frei, 500 benötigt die Datenbank
Ja, die Logfiles sind alle von heute.
Das aus- und wieder Einbinden der DB funktioniert ohne Probleme:
Eseutil /MH Ergebnis:
DATABASE HEADER:
Checksum Information:
Expected Checksum: 0x52a6386f
Actual Checksum: 0x52a6386f
Fields:
File Type: Database
Checksum: 0x52a6386f
Format ulMagic: 0x89abcdef
Engine ulMagic: 0x89abcdef
Format ulVersion: 0x620,17
Engine ulVersion: 0x620,17
Created ulVersion: 0x620,17
DB Signature: Create time:08/27/2012 20:11:02 Rand:2335250 Computer:
cbDbPage: 32768
dbtime: 5501208947 (0x147e5c973)
State: Clean Shutdown
Log Required: 0-0 (0x0-0x0)
Log Committed: 0-0 (0x0-0x0)
Log Recovering: 0 (0x0)
GenMax Creation: 00/00/1900 00:00:00
Shadowed: Yes
Last Objid: 1033678
Scrub Dbtime: 0 (0x0)
Scrub Date: 00/00/1900 00:00:00
Repair Count: 0
Repair Date: 00/00/1900 00:00:00
Old Repair Count: 0
Last Consistent: (0x5CD24F,359,109) 06/23/2015 19:03:45
Last Attach: (0x5CD21D,9,86) 06/23/2015 17:21:59
Last Detach: (0x5CD24F,359,109) 06/23/2015 19:03:45
Dbid: 1
Log Signature: Create time:08/27/2012 20:11:00 Rand:2337046 Computer:
OS Version: (6.1.7601 SP 1 NLS ffffffff.ffffffff)Die Festplatte ist "nur" 700GB Groß, davon sind eben noch 80GB frei, 500 benötigt die Datenbank
500 GB? Ich meine irgendwo gelesen zu haben, dass Microsoft empfiehlt, ab 120 GB aufzuteilen. Schon allein wegen der Wiederherstellungszeit (von z.B. einzelnen Elementen).
Damit kannst du dir die Postfachgrößen anzeigen lassen:
Wie groß die Datenbank tatsächlich ist (man muss sie nämlich ab und zu im Offline-Modus defragmentieren, bei 500GB würde das entsprechend dauern), lässt sich damit prüfen:
Du könntest also Platz schaffen, wenn du die DB offline defragmentierst. Siehe hier: http://exchangeserverpro.com/defrag-exchange-2010-mailbox-database/
Vielleicht hast du aber auch viele Postfachleichen:
Also als erstes Offline-Defrag oder neue Platten... weil wahrscheinlich hast du dieses Problem: http://blogs.technet.com/b/mikelag/archive/2011/02/09/how-fragmentation ...
Damit kannst du dir die Postfachgrößen anzeigen lassen:
Get-MailboxStatistics -server servername | sort TotalItemSize -desc | FT DisplayName,TotalItemSize,DatabaseWie groß die Datenbank tatsächlich ist (man muss sie nämlich ab und zu im Offline-Modus defragmentieren, bei 500GB würde das entsprechend dauern), lässt sich damit prüfen:
Get-MailboxDatabase -Status | ft name,databasesize,availablenewmailboxspace -autoDu könntest also Platz schaffen, wenn du die DB offline defragmentierst. Siehe hier: http://exchangeserverpro.com/defrag-exchange-2010-mailbox-database/
Vielleicht hast du aber auch viele Postfachleichen:
Get-MailboxDatabase | Clean-MailboxDatabase
get-mailboxdatabase | get-mailboxstatistics | Where{ $_.DisconnectDate -ne $null } |fl displayName,Identity,disconnectdate,databasenameAlso als erstes Offline-Defrag oder neue Platten... weil wahrscheinlich hast du dieses Problem: http://blogs.technet.com/b/mikelag/archive/2011/02/09/how-fragmentation ...
Moin,
wie ich schon geschrieben habe, der TO braucht erst Neue Platten, weil die temp. db beim offline-defrag etwa die gleiche größe hat
...du kannst keine 500 gb in 80gb reinzaubern
und wenn du du platte ganz voll zauberst.... Mahlzeit
lg
Frank
wie ich schon geschrieben habe, der TO braucht erst Neue Platten, weil die temp. db beim offline-defrag etwa die gleiche größe hat
...du kannst keine 500 gb in 80gb reinzaubern
und wenn du du platte ganz voll zauberst.... Mahlzeit
lg
Frank
Hi,
er kann die temp.db auslagern, z.B. auf einen anderen Server per UNC-Pfad (Freigabe). Siehe Anleitung.
er kann die temp.db auslagern, z.B. auf einen anderen Server per UNC-Pfad (Freigabe). Siehe Anleitung.
Vielen Dank für eure Unterstützung.
Ich bin folgender maßen vorgegangen:
1. externen Speicher eingebunden um die temp db umzuleiten
2. Reparatur
3. Defragmentierung (40GB wurden frei gemacht)
4. Vollbackup um die Logs zu kürzen
Die Datenbank lässt sich wieder einbinden und der Fehler scheint fürs erste behoben zu sein.
Geholfen hat dabei: http://community.spiceworks.com/how_to/2217-repairing-a-corrupt-or-dirt ...
Zwei Punkte sind aber weiterhin offfen:
1. Es ist nicht ersichtlich was der Fehler war. Die Reparatur und Defrag. sollten eigentlich keine E/A Fehler beheben können?
2. Für heute wurden inzwischen wieder über 11.000 Logs geschrieben (dabei ist es erst 13:00)
Zweiteres macht mir am meisten Sorgen
Ich bin folgender maßen vorgegangen:
1. externen Speicher eingebunden um die temp db umzuleiten
2. Reparatur
3. Defragmentierung (40GB wurden frei gemacht)
4. Vollbackup um die Logs zu kürzen
Die Datenbank lässt sich wieder einbinden und der Fehler scheint fürs erste behoben zu sein.
Geholfen hat dabei: http://community.spiceworks.com/how_to/2217-repairing-a-corrupt-or-dirt ...
Zwei Punkte sind aber weiterhin offfen:
1. Es ist nicht ersichtlich was der Fehler war. Die Reparatur und Defrag. sollten eigentlich keine E/A Fehler beheben können?
2. Für heute wurden inzwischen wieder über 11.000 Logs geschrieben (dabei ist es erst 13:00)
Zweiteres macht mir am meisten Sorgen
klar kann er das... sogar auf eine usb platte da brauch ich keine anleitung
ist alles nur langsamer und- na ja- nicht grade toll!
evtl. könnte der TO auch schnell eine sata/sas... etc... ins system hängen... zum auslagen der temp etc...
lg
frank
da brauch ich keine anleitung ist alles nur langsamer und- na ja- nicht grade toll!
evtl. könnte der TO auch schnell eine sata/sas... etc... ins system hängen... zum auslagen der temp etc...
lg
frank
hi,
11.000 logs....
Diese Dateien bilden das Repository für Datenbankvorgänge wie das Erstellen oder Ändern einer Nachricht !
Ergo.... du hast Bewegung auf deneim Exchange. Sind deine User alle am Mailen, bzw. bekommen alle viele Mails ?
schon mal in die Toolbox und Warteschlangenanzeige geschaut ?
nich das dein Server am spamen ist
stichwort: AV Proggi für den Exchange
etc... etc... etc..
lg
Frank
11.000 logs....
Diese Dateien bilden das Repository für Datenbankvorgänge wie das Erstellen oder Ändern einer Nachricht !
Ergo.... du hast Bewegung auf deneim Exchange. Sind deine User alle am Mailen, bzw. bekommen alle viele Mails ?
schon mal in die Toolbox und Warteschlangenanzeige geschaut ?
nich das dein Server am spamen ist
stichwort: AV Proggi für den Exchange
etc... etc... etc..
lg
Frank
Hallo Frank,
Die 11k Logs haben sich aufgeklärt. Nach dem online schalten der Datenbank waren ca 800 Mails in der Warteschlange. Das hat diese Bewegung erzeugt. Seitdem liegen die logs bei Max 2.000 / Tag.
Der I/O Fehler tauch auch nicht mehr auf. Reparatur und Defrag hat anscheinend geholfen (obwohl man kein Feedback bekommt ob Fehler bei der Reparatur überhaupt gefunden wurden)
Die 11k Logs haben sich aufgeklärt. Nach dem online schalten der Datenbank waren ca 800 Mails in der Warteschlange. Das hat diese Bewegung erzeugt. Seitdem liegen die logs bei Max 2.000 / Tag.
Der I/O Fehler tauch auch nicht mehr auf. Reparatur und Defrag hat anscheinend geholfen (obwohl man kein Feedback bekommt ob Fehler bei der Reparatur überhaupt gefunden wurden)
