Odată cu introducerea de schimb există o situație neplăcută - se pare că avem toate cerințele de la locul Bursei finalizate, dar în mod inevitabil diminuează ... încep să înțeleagă și să realizeze că toate tipurile de bușteni cresc mai repede decât ne-am așteptat, așa cum a face cu ei? Următoarele descriu modalități de a trunchia / muta diverse jurnale, în general, tot ceea ce ne va ajuta să rezolvăm problema. Separat, am act de faptul că toate informațiile sunt în TechNet Biblioteca tehnică 🙂 și aici doar ea a luat pentru o sarcină specifică: pentru a reaminti căile de soluționare a problemelor cu lipsa de spațiu datorită proliferării bușteni.
Busteni de tranzacție
Jurnalul de tranzacții este cel mai important element al Exchange. Iată un exemplu: atunci când trimiteți un mesaj, tranzacția este înregistrată mai întâi în jurnal. În timp ce tranzacția nu a fost transferată în baza de date Exchange, aceste date există numai în jurnalul de tranzacții și în memoria de sistem. În caz de accident, pierdeți conținutul memoriei și tot ce ați lăsat este înregistrările jurnalului de tranzacții. Aceste jurnale sunt importante pentru restaurarea unei baze de date corupte. Același lucru este valabil și pentru alte tranzacții: mesajele primite, elementele șterse și mesajele mutate în alte foldere. În consecință, aceste jurnale cresc foarte repede, cum să le reducem?
2. Activarea jurnalului circular
Când este activată înregistrarea circulară, jurnalul de tranzacții este șters imediat după ce tranzacțiile sunt plasate în baza de date.
Cu ajutorul EAC Circular Logging este inclusă după cum urmează:
Atunci când sunt create fișierele jurnal suplimentare circulare de logare ESE, în loc să suprascrie fișierul jurnal curent atunci când este necesar. Cu toate acestea, într-un mediu de replicare continuă (DAG), fișierele jurnal trebuie să livreze și să convertească jurnalele. Ca urmare, atunci când activați replicare continuă înregistrare circulară log fișierul jurnal curent nu este suprascrisă, iar pentru procesul de transport maritim și reluarea jurnalele sunt fișierele jurnal închise, adică, asigură continuitatea ziarelor și revistelor nu sunt eliminate pana cand acestea sunt necesare pentru replicare. Serviciul Microsoft Exchange Replication și serviciul Microsoft Exchange Information Store interacționează utilizând Remote Procedure Call (RPC) pentru a determina care fișiere log pot fi șterse.
3. Deplasarea jurnalelor de tranzacții
Ei bine, în cele din urmă putem muta jurnalele împreună cu baza de date într-o altă locație \ un alt disc.
Pentru aceasta, există un minunat cmdlet de mutare-bază de date. Iată un exemplu de transferare a bazei de date MDB01 și a jurnalelor de tranzacții pe discul M din directorul corespunzător:
Mutare-Databasepath "MDB01" -EdbFilepath "M: \ DB \ MDB01 \ bază de date \ mdb01.edb" -LogFolderpath "M: \ DB \ MDB01 \ busteni \"
Baze de date de așteptare
Desigur, acest lucru nu este un jurnal, dar dacă aveți nevoie să eliberați spațiul, atunci mutarea acestei baze de date vă poate ajuta. Baza de date de așteptare este un depozit temporar de mesaje care așteaptă următoarea etapă de procesare. Fiecare coadă este un set logic de mesaje care sunt procesate de serverul de transport într-o anumită ordine. Toate cozile sunt stocate într-o singură bază de date ESE. Cozi sunt plasate numai pe serverele cu cutie poștală sau pe serverele Edge Transport. Locația bazei de date a coada și a jurnalelor sale de tranzacții este controlată de cheile din fișierul de configurare XML al aplicației% ExchangeInstallPath% Bin \ EdgeTransport.exe.config.
Tot ce putem face cu ea este să-l mutăm într-un alt loc. Suficientă informație detaliată despre mutare este în biblioteca tehnetală din articolul Schimbați locația bazei de date pentru coadă
TransportLogs
Jgheaburile de transport oferă informații despre ceea ce se întâmplă în conducta de transport. Informațiile suficiente despre dezactivarea / activarea înregistrării și deplasarea acestora se găsesc în biblioteca tehnetară din articolul Jurnal de transport.
- Agende pentru agenți
- Conectivitate
- Rapoartele de urmărire a mesajelor și de livrare
- Trasarea conductelor
- Protocoale log
- Traseul tabelelor de masă
De exemplu, schimbați calea de stocare a Protocollogurilor prin EAC: servere \ servere \ selectați jurnalul serverului \ transport logs \ protocol
De exemplu, modificați calea pentru stocarea urmăririi mesajelor prin EAC: servere \ servere \ selectați jurnalul de urmărire a mesajelor serverului \ transport \ log.
În mod separat, observ că puteți să vă mutați într-un dosar local. Problema cu plasarea pe o resursă de rețea poate fi eludată prin utilizarea comenzii mklink și crearea unui link către resursa de rețea. De exemplu, creați linkul mklink / d "D: \ HubReceiveSMTPLog" \\ Server \ HubReceiveSMTPLog. Acum puteți utiliza setul de transport Set-TransportService și parametrul -ReceiveProtocolLogPath "D: \ HubReceiveSMTPLog" pentru a stoca jurnalele ReceiveSMTP în resursa de rețea. Această metodă este potrivită pentru alte bușteni.
IISlogfiles
În jurnalul IIS, veți avea informații cum ar fi conectarea ipad-ului la protocolul activesync. Mărimea jurnalelor IIS, dacă nu este urmată îndeaproape, poate fi foarte mare. Cum pot fi șterse sau mutate pe alt disc?
1. Ștergerea automată a buștenilor
Rulați scriptul ps1 în fiecare zi prin programator (schimbați calea de stocare a jurnalelor, dacă este necesar) și toate jurnalele dvs. IIS mai vechi de 30 de zile vor fi șterse fără a vă cere atenția.
foreach ($ File în get-childitem)
dacă ($ File.LastWriteTime -lt (Get-Date) .AddDays (-30))
Puteți rula scriptul ps1 prin intermediul planificatorului după cum urmează:
- Creați o sarcină în planificator
- Creați o acțiune: începeți un program
- În programul / scriptul: C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe
- În câmpul adăugați argumente (opțional): -command "pathTOscript \ name.ps1"
2. Deplasați jurnalele în altă locație
- Deschideți Managerul IIS din Instrumente de administrare și selectați Site Web implicit.
- Deschideți înregistrarea (faceți dublu clic pe pictograma Logging)
- Modificați stocarea jurnalelor
- Salvați modificările. Următorul fișier jurnal va fi scris într-o locație nouă de stocare
- Același lucru se poate face și cu powershell:
Set-ItemProperty "IIS: \ Sites \ Site Web implicit" -name logfile.directory "D: \ IISLogs"
Dosar de înregistrare
În cele din urmă, dosarul Jurnalizare, care în mod implicit este localizat în "C: \ Program Files \ Microsoft \ Exchange Server \ V15 \ Logging". Stochează o mulțime de bușteni de diverse servicii și poate ocupa un spațiu suficient de mare. Distribuită în special de volumul fișierelor de jurnal de diagnosticare și de performanță care se află în directorul "C: \ Program Files \ Microsoft \ Exchange Server \ V15 \ Logging \ Diagnostics
Pe Internet, a fost găsită o soluție simplă la această problemă, executată zilnic prin programator și toate jurnalele din aceste dosare mai vechi de 14 zile se vor opri să vă deranjeze 🙂
gci "C: \ Program Files \ Microsoft \ Exchange Server \ V15 \ Logging", "C: \ inetpub \ logs" -Director | gci -Include '* .log', '*. blg' -Recurse |. LastWriteTime -lt (Obțineți data) .AddDays (-14) | Eliminați-Articol
P.S. Personal prefer să taie doar diagnosticarea:
gci "C: \ Program Files \ Microsoft \ Exchange Server \ V15 \ Logging \ Diagnostics" -Director gci -Include '* .log', '*. blg' -Recurse |. LastWriteTime -lt (primiți-vă) .AddDays (-2) | Eliminați-Articol
Trimiteți-le prietenilor: