Exchange themablog
RSS
Overzicht van artikelen >
De log bestanden van Exchange zijn te herkennen aan het volgende hexadecimale formaat E0000000009.log. Een log bestand zal pas een opvolgnummer krijgen wanneer het log bestand is afgesloten. Elk log bestand is maximaal 1 MB groot. Wanneer de 1 MB wordt bereikt zal het log bestand worden afgesloten en zal er een nieuw log bestand aangemaakt worden. Dit proces wordt ook wel log file roll-over genoemd. Wanneer een log bestand wordt afgesloten ondanks dat de 1 MB niet gebruikt is, wordt dit een forward roll genoemd. Dit gebeurt bijvoorbeeld bij het maken van een backup.
In Exchange 2007 bevat de Extensible Storage Engine (ESE) Lost Log Resiliency (LLR). Dit component kan, in het geval er één of meerdere recente log bestanden niet aanwezig of beschadigd zijn, er toch voor zorgen dat de database gemount kan worden. Deze nieuwe functionaliteit is standaard actief op alle mailbox servers. In het geval van een CCR omgeving is deze functionaliteit alleen actief op de actieve node.
Zoals al eerder gemeld is de volgorde voor het wegschrijven van data in de database geheugen -> log -> database. LLR zorgt ervoor dat schrijfacties naar het log bestand worden vertraagd totdat het aantal log bestanden wat een server maximaal mag achterlopen is bereikt. Afhankelijk van hoeveel tijd dit in beslag neemt heeft dit ook een gevolg voor het updaten van de database zelf, deze updates hier naartoe worden namelijk ook op dit moment vertraagd.
Het checkpoint bestand bevat de naam van het laatste log bestand wat is toegepast op de database. Met LLR wordt er naast de informatie in het checkpoint bestand ook informatie aan het einde van elk log bestand toegevoegd:
Daarnaast bestaat er natuurlijk nog de manier van handmatig verwijderen. Hiervoor dient de database wel in een clean shutdown te zijn. Het handmatig opschonen van de logs is echter niet echter niet aan te raden.In principe blijven in alle overige gevallen de log bestanden bewaard. Log bestanden kunnen overschreven worden indien “circular logging” wordt gebruikt. Als dit het geval is dan staan er gemiddeld 20 log files op een Exchange (2007) server. Oudere logfiles worden dan overschreven en zijn niet meer beschikbaar. Nadeel hiervan is dat de kans op recovery afneemt. De laatste log files kunnen eventueel worden gebruikt na een crash van de server, maar recovery door het replayen van log files is niet meer aanwezig.
In Exchange 2007 kun je CCR combineren met circular logging. Dit wordt ook wel continuous replication circular logging (CRCL) genoemd. Het verschil met circular logging is dat CRCL geregeld wordt door de Microsoft Exchange Replication Service en circular logging wordt geregeld door de Microsoft Exchange Information Store Service. Normaliter zou een log bestand telkens hergebruikt worden, in het geval van CCR is dit natuurlijk wel wat lastiger, het log bestand dient immers eerst gekopieerd te worden naar de andere node. Om deze reden zal de Replication Service wachten met het overschrijven van het bestand totdat het bestand is gekopieerd naar de andere node en daar succesvol is verwerkt.
De information store ziet pas dat circular logging is ingeschakeld wanneer de database een keer gedismount en opnieuw gemount wordt.
Voor CCR, LCR en SCR omgevingen dienen onderstaande stappen uitgevoerd te worden:Nu vraag je je af "waarom via deze procedure?"
De Microsoft Exchange Replication Service, welke verantwoordelijk is voor het repliceren van de data, detecteerd automatisch of CCR aan/uit staat. Voor een database in een LCR omgeving is de Microsoft Exchange Information Store verantwoordelijk voor het detecteren van de aan/uit staan van circular logging. Wanneer de procedure niet gevolgd wordt kan dit tot gevolg hebben dan de Information Store denkt dat circular loggin aanstaat terwijl de Replication Service denkt dat deze uit staat.
Microsoft adviseert om circular logging niet te gebruiken vanwege de eerder genoemde reden, de kans op recovery neemt namelijk aanzienlijk af. Maar wanneer zou je nou wel gebruik kunnen maken van circular logging? Eén van de redenen zou kunnen zijn tijdens een migratie van mailboxen, tijdens dit proces wordt namelijk veel logging gegenereerd.
Niet vergeten na de migratie circular logging weer uit te zetten overigens ;-)
Exchange Transaction Logs
Geplaatst op 5-11-2009 11:16 door Johan VeldhuisZoals je misschien al weet bestaat een storage group van Exchange naast de database file uit:- Transactie logs, te herkennen aan een hexadecimale bestandsnaam en de extensie log. Daarnaast bestaan er nog twee vooraf gereserveerde log bestanden. Deze bestanden zorgen ervoor dat mocht een schijf vollopen de database toch netjes afgesloten kan worden.
- Checkpoint bestand, te herkennen aan de extensie chk.
Stap 1
De data staat in het geheugen en wordt weggeschreven naar een log bestand. Dit log bestand bevat alle wijzigingen die toegepast moeten worden op de database. Ontstaat er een fout tijdens zo’n transactie dan wordt de transactie in de log file gemarkeerd en start het wegschrijven opnieuw.Stap 2
De data wordt vanuit het geheugen weggeschreven naar de database file.Stap 3
Wanneer data uit het geheugen is toegepast op de database dan zal de checkpoint file bijgewerkt worden naar aanleiding van deze laatste transactie. Dit bestand houdt namelijk bij welke informatie uit welk log bestand als laatst succesvol is toegepast op de database. Wanneer je een database dismount, de checkpoint file verwijdert en de database vervolgens weer mount zullen alle log bestanden opnieuw afgespeeld worden en zullen de bestanden die nog niet zijn toegepast op de database aan de database toegevoegd worden.Maar waar zijn die log bestanden nou nog meer makkelijk voor?
Wanneer er geen logs gebruikt zouden worden en de database zou er plotseling mee stoppen dan zou het kunnen zijn dat de database niet meer gemount kan worden en er data verloren gaat. Met transactie logs worden de log bestanden tijdens het mounten van de database opnieuw toegepast op de database.De log bestanden van Exchange zijn te herkennen aan het volgende hexadecimale formaat E0000000009.log. Een log bestand zal pas een opvolgnummer krijgen wanneer het log bestand is afgesloten. Elk log bestand is maximaal 1 MB groot. Wanneer de 1 MB wordt bereikt zal het log bestand worden afgesloten en zal er een nieuw log bestand aangemaakt worden. Dit proces wordt ook wel log file roll-over genoemd. Wanneer een log bestand wordt afgesloten ondanks dat de 1 MB niet gebruikt is, wordt dit een forward roll genoemd. Dit gebeurt bijvoorbeeld bij het maken van een backup.
In Exchange 2007 bevat de Extensible Storage Engine (ESE) Lost Log Resiliency (LLR). Dit component kan, in het geval er één of meerdere recente log bestanden niet aanwezig of beschadigd zijn, er toch voor zorgen dat de database gemount kan worden. Deze nieuwe functionaliteit is standaard actief op alle mailbox servers. In het geval van een CCR omgeving is deze functionaliteit alleen actief op de actieve node.
Zoals al eerder gemeld is de volgorde voor het wegschrijven van data in de database geheugen -> log -> database. LLR zorgt ervoor dat schrijfacties naar het log bestand worden vertraagd totdat het aantal log bestanden wat een server maximaal mag achterlopen is bereikt. Afhankelijk van hoeveel tijd dit in beslag neemt heeft dit ook een gevolg voor het updaten van de database zelf, deze updates hier naartoe worden namelijk ook op dit moment vertraagd.
Het checkpoint bestand bevat de naam van het laatste log bestand wat is toegepast op de database. Met LLR wordt er naast de informatie in het checkpoint bestand ook informatie aan het einde van elk log bestand toegevoegd:
- Waypoint, dit is het log bestand dat minimaal nodig is om een succesvolle recovery uit te voeren.
- Committed log, welk log bestand als laatst is toegepast op de database.
- Lossless, er mag geen log bestand verloren gaan
- Good Availability, er mogen 3 log bestanden verloren gaan
- Best Availability, er mogen 6 log bestanden verloren gaan
Diskruimte en logging
Allemaal leuk en aardig al die log bestanden maar deze nemen dus ook diskruimte in beslag. De log bestanden worden pas verwijderd als er en full backup is gemaakt van de database.Daarnaast bestaat er natuurlijk nog de manier van handmatig verwijderen. Hiervoor dient de database wel in een clean shutdown te zijn. Het handmatig opschonen van de logs is echter niet echter niet aan te raden.In principe blijven in alle overige gevallen de log bestanden bewaard. Log bestanden kunnen overschreven worden indien “circular logging” wordt gebruikt. Als dit het geval is dan staan er gemiddeld 20 log files op een Exchange (2007) server. Oudere logfiles worden dan overschreven en zijn niet meer beschikbaar. Nadeel hiervan is dat de kans op recovery afneemt. De laatste log files kunnen eventueel worden gebruikt na een crash van de server, maar recovery door het replayen van log files is niet meer aanwezig.
In Exchange 2007 kun je CCR combineren met circular logging. Dit wordt ook wel continuous replication circular logging (CRCL) genoemd. Het verschil met circular logging is dat CRCL geregeld wordt door de Microsoft Exchange Replication Service en circular logging wordt geregeld door de Microsoft Exchange Information Store Service. Normaliter zou een log bestand telkens hergebruikt worden, in het geval van CCR is dit natuurlijk wel wat lastiger, het log bestand dient immers eerst gekopieerd te worden naar de andere node. Om deze reden zal de Replication Service wachten met het overschrijven van het bestand totdat het bestand is gekopieerd naar de andere node en daar succesvol is verwerkt.
De information store ziet pas dat circular logging is ingeschakeld wanneer de database een keer gedismount en opnieuw gemount wordt.
Voor CCR, LCR en SCR omgevingen dienen onderstaande stappen uitgevoerd te worden:
- Pauzeer de replicatie tijdelijk
- Schakel circular logging in/uit
- Dismount de database en mount deze vervolgens weer
- Schakel de replicatie weer in
Nu vraag je je af "waarom via deze procedure?"
De Microsoft Exchange Replication Service, welke verantwoordelijk is voor het repliceren van de data, detecteerd automatisch of CCR aan/uit staat. Voor een database in een LCR omgeving is de Microsoft Exchange Information Store verantwoordelijk voor het detecteren van de aan/uit staan van circular logging. Wanneer de procedure niet gevolgd wordt kan dit tot gevolg hebben dan de Information Store denkt dat circular loggin aanstaat terwijl de Replication Service denkt dat deze uit staat.Microsoft adviseert om circular logging niet te gebruiken vanwege de eerder genoemde reden, de kans op recovery neemt namelijk aanzienlijk af. Maar wanneer zou je nou wel gebruik kunnen maken van circular logging? Eén van de redenen zou kunnen zijn tijdens een migratie van mailboxen, tijdens dit proces wordt namelijk veel logging gegenereerd.
Niet vergeten na de migratie circular logging weer uit te zetten overigens ;-)
Reacties
Reageer op dit artikel |
Jetze Mellema is Infrastructure Consultant bij 
Peter Noorderijk is Infrastructuur Consultant bij 
Johan Veldhuis is Technical Consultant bij 
Kay Sellenrode is technical consultant bij