Privire de ansamblu:
Depanare este dificil atunci când dezvolta funcţionalitate particularizate pentru Windows SharePoint Services 3.0 (WSS) sau Microsoft Office SharePoint Server (MOSS). Vinovatul principal este că SharePoint suprafeţe în mod normal, foarte puţine informaţii de diagnosticare pe browser-ul atunci când apare o eroare. Această intrare de blog descrie modul de a localiza suplimentare generate de sistemul de informaţii de diagnostic care adesea poate oferi suplimentar că pic de detaliu, că unul are nevoie pentru a identifica cauzele profunde. Acest lucru poate duce apoi la rezolvarea problemei.
Am folosit aceasta tehnica cu mare succes de a rezolva altfel misterioase erori.
Abordare:
SharePoint salvează o mare cantitate de informaţii într-un jurnal diagnostic într-un fişier jurnal în 12 stup.
"Stupul 12" este, de obicei, situat la "C:\Programul FilesCommon FilesMicrosoft SharedWeb Server Extensions12 ". (Nu sunt sigur în cazul în care este posibil pentru 12 stup să trăiască oriunde altundeva, de fapt).
Ideea este de a localiza fişierul de log curent, forţa de eroare şi apoi deschide rapid fişierul jurnal. Aceste fişiere de jurnal sunt caracterizate de:
- Cantităţi mari de informaţii. SharePoint genereaza o cantitate foarte mare de informaţii de diagnostic şi scrie-l ca fişier jurnal foarte repede. Trebuie sa fii rapid cu degetele pentru a capta.
- Multiplicitate. SharePoint nu se scrie într-un singur fişier jurnal, dar mai degrabă generează mai multe fişiere de jurnal în ordine.
- Copiaţi şi lipiţi frumos în MS Excel.
Metoda mea preferată:
- Deschidere sus un ferestre explorer arătând spre 12 hivelogs.
- Sortează vizualizarea pentru a arăta de data modificării (cele mai recente primul).
- Evidenţiaţi fişierul jurnal cele mai actuale.
- Într-o fereastră de browser-ul web, forţa de eroare să apară.
- Deschideţi fişierul de log curent rapid şi copiaţi conţinutul său la MS Excel.
- Sari la final şi să analizeze înregistrările.
Alte note:
În mod implicit, jurnal diagnostic este situat în 12 hiveLOGS Director.
MS Best practices (ca pe Mike T. de la Microsoft) de stat care fişierele jurnal ar trebui să fie salvat de un hard disk separat. O face acest lucru prin intermediul admin centrală. Administratorul de sistem să fi făcut acest lucru, în acest caz, evident, trebuie să găsiţi fişierul jurnal acolo în loc de implicit 12 stup locaţie).
Acest articol abordează probleme cum ar fi:
- Flux de lucru SharePoint nu a pornit datorită unei erori interne.
- (mai mult pentru a fi adăugat în timp)
- Această intrare a fost util diagnosticarea erori de flux de lucru (ex. "Fluxului de lucru nu a pornit datorită unei erori interne").
Deci, sunt momente când mă duc la 12 stup de activitate şi de a găsi nu este puţin pentru nimic în ele, chiar dacă nivelul de logare sunt astfel încât trebuie să existe date acolo. De exemplu, Eu stau aici în căutarea la ferestre explorer vedere folderului jurnalele şi văd că, în medie, jurnalele sunt 1-2 concert. Dar apoi văd mai multe ore în care jurnalele sunt 10k. Acum, site-uri sharepoint în cauză se folosesc destul de mult 24 ore zi. Aşa ceva se întâmplă cu fire/proceselor generatoare de informaţii care le împiedica jurnalizarea informaţiilor, Mi-ar trebui să-şi asume. Deci, Cum îmi dau seama ce cauzează această problemă?
Am descoperit toate acestea, atunci când m-am dus pentru a merge la jurnalele pentru a încerca şi depanare o problemă. Un utilizator a adăugat o componentă web part și partea web spune-le pentru a verifica jurnalele. Dar desigur, nu este nimic în Jurnalul.
ajută-mă cu eroare: JURNAL ID 5566