Zilele aceastea primeam din ce în ce mai multe sesizări că, Portalul este din ce în ce mai indisponibil cu erori care mai de care mai ciudate de genul HResult-uri. Spațiul pe disc disponibil pe serverul de baze de date era 0! La o primă privire am spus că trebuie să fie de cantitatea mare de fișiere stocată… Dar… ca să se poată efectua rapid operațiuni trebuia golit din spațiu. Soluția: Backup de câteva ore la SharePoint și apoi golit tranzaction log:
– Fiecare comanda se executa pe rand. P_PortalFEAA_Content este numele bazei de date care ține un anumit site.
ALTER DATABASE P_PortalFEAA_Content
SET RECOVERY SIMPLE;
GO
– Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (P_PortalFEAA_Content_log, 1);
GO
– Reset the database recovery model.
ALTER DATABASE P_PortalFEAA_Content
SET RECOVERY FULL;
În felul acesta am eliberat 40 Gb. Și totuși nu este suficient.
Unde și ce date ține SharePoint?
Trebuia să găsesc o explicație… de ce baza de date este atât de imensă:
Prima tabelă la care m-am gândit pentru a putea determina cantitatea de fișiere stocate este AllDocs. 101.711 linii, 92 Mb. Asta înseamnă că nu aici este spațiul mare ocupat.
Următoarea tabelă în listă: AllDocStreams: 8101 linii 3,6 Gb. Tot nu-i bai. Ce conține această tabele? După cum v-ați imaginat: fișiere. Structura tabelei:
[Id] – Id-ul fișierului
[SiteId] – Site-ul în care se află stocat fișierul respectiv
[DeleteTransactionId] – Asta nu stiu ce inseamnă 
[ParentId] – Dacă este într-o anumită librărie și acolo într-un director
[Size] – Dimensiunea în biți a fișierului
[Level] – Pe ce nivel de directoare se află fișierul
[Content] – Conținutul fișierului… stocat în format Hexazecimal. Nu știu dacă are sens să insistăm.
3 Gb nu erau chiar așa multe date stocate, așa că am trecut la celelalte tabelele… până am ajuns la AuditData.
Puteți număra? AuditData – 101.165 Gb, Index – 20 GB – 357.742.142. Milioane de înregistrări, Gb de date.
Așadar tabela de audit este una din cele mai importante tabele din SharePoint conținând un istoric al tuturor acțiunilor întreprinse într-un portal.
Hai să vedem puțin structura tabelei acestea:
[SiteId] – În ce site se întâmplă povestea
,[ItemId] – Asupra cărui element/obiect se întâmplă o acțiune
,[ItemType] – tipul elementului asupra căruia se desfășoară acțiunea: 1, 2, 3, 4, etc
,[UserId] – ID-ul utilizatorului ca s-a ocupat cu acțiunea asupra obiectului/elementului
,[MachineName] – Numele calculatorului de pe care a făcut acțiunea. Este posibil să ia și valori nule
,[MachineIp] – IP-ul calculatorului de pe care s-a făcut o anumită acțiune
,[DocLocation] – locația documentului / paginii / obiectului asupra căruia s-a desfășurat acțiunea. Exemplu: News/PublishingImages/Promo/Licitatie_mos_craciun.jpg
,[LocationType] – un tip de locația care la mine apare permanent cu 0.
,[Occurred] – Data și ora la care s-a produs evenimentul. Exemplu: 2009-01-01 00:01:30.000 Asta înseamnă că în noaptea de anul nou cineva se uita pe Portal. Ciudat… Nu eram eu!
,[Event] – ID-ul acțiunii, evenimentului: 3, 2, 1până pe la 100.
,[EventName] – Numele evenimentului. Poate fi NULL.
,[EventSource] – Sursa evenimentului: 0, 1, 2
,[SourceName] – Numele sursei. Poate fi de asemenea NULL.
,[EventData] – Poate fi null la vizualizare, sau poate conține o versiune a documentului accesat modificat: <Version><Major>0</Major><Minor>6</Minor></Version>
De unde se configurează auditul și ce opțiuni avem?
Auditul s econfigurează pentru fiecare Web application în parte. Sau site ca să fim mai expliciți. Acest lucru se efectuează din Site Settings, Configure Audit Settings
Super faine opțiuni… numai că în momentul în care ai 14.000 de utilizatori, mare parte readeri, îți trebuie server special numai pentru audit. În contextul meu opțiunea viewing items in list este oarecum hazardată. Chiar dacă este foarte important să știi de câte ori a fost văzut un anunț, nu poți diminua performanțele implementării doar pentru acest lucru. Eu personal nu aș renunța la toate aceste opțiuni dacă aș fi într-o firmă de dimensiuni mai mici pentru că în felul acesta am istoricul tuturor acțiunilor efectuate.
Postulat
De multe ori în raportul performanță, jurnalizare/audit majoritatea renunța la audit. De ce? Pentru că e mai bine să meargă bine, decât să meargă binișor dar în siguranță.
De unde vedem rapoartele de audit?
Rapoartele de audit le putem vizualiza tot din Site Settings de la opțiunea View Auditing Reports:
Problema tipurilor acestea de rapoarte este că sunt generate în XML. XML este un fișier de tip text la urma urmei pe care poți să-l deschizi și în Excel. Dar dacă ai 101 Gb de date? Nici unul din aceste rapoarte nu se poate deschide în contextul cantității uriașe de date de la mine.
Aparent nu se afișează nici o eroare dar nici raportul nu este generat.În EventViewerputem identifica totuși două mesaje de eroare care nu sunt deosebit de explicite:
Provider [ Name] Office SharePoint Server
– EventID 6482
[ Qualifiers] 0
Level 2
Task 1328
Keywords 0x80000000000000
– TimeCreated [ SystemTime] 2009-05-31T12:31:13.000Z
EventRecordID 99047
Channel Application
sau
– Provider [ Name] Office SharePoint Server
– EventID 7076
[ Qualifiers] 0
Level 2
Task 1328
Keywords 0x80000000000000
– TimeCreated [ SystemTime] 2009-05-31T12:31:13.000Z
EventRecordID 99048
Ambele au legătură cu memoria de pe serverul de SQL care nu are posibilitatea în cazul meu să proceseze toată cantitatea de informații.
O rezolvare elegantă este să faci o aplicație cu reporting services sau cu Analysis Service ca să extragi datele de acolo și să le afișezi altfel pe web.
Se pot șterge înregistrări din AuditData?
Da. Dar numai după ce au fost exportate în altă parte/format, etc. Teoretic!. Condițiile care trebuei îndeplinite sunt: trebuie să ai multă răbdare, în funcție și de numărul de înregistrări pe care le ai, și spațiu pe disc pentru tran log. După ce se termină operațiunea de ștergere, goliți din nou tran log.
De exemplu aici șterg doar înregistrările aferente anului 2008:
delete from auditData
where YEAR(Occurred)=’2008′
În cazul în care spațiul pe disc necesar ștergerii nu este suficient, puteți să rafinați opțiunea de ștergere, în așa fel încât să ștergeți pe luni combinat permanent cu operațiunea de golire a transaction log.
În cazul în care ați făcut backup și vreți să ștergeți fără să duceți în transaction log, puteți face : truncate auditdata
După ce ați terminat de șters trebuie să faceți un SHRINKFILE și pe fișierele bazei de date pentru redimensiunarea fișierelor.
Atenție: În mod implicit auditul nu este activat. Activați-l!
Spor la succes!
Valy Greavu - Live Blog 