Config Refresh Timer Job
- Posted by Jana Babáčková
- On 22.10.2013
- 0
„Config Refresh“ je jedna ze základních, pravidelně se opakujících úloh systému zvaných „timer jobs“, které spouští nejrůznější služby, rozesílají e-maily nebo probírají stará a nepotřebná data. Jejich instance se vztahují vždy k nějaké službě a nebo webové aplikaci. Všechny úlohy obsahují definici toho co dělají a jak často to dělají, řídí je „SharePoint 2010 Timer Service“ (SPTimerv4) a strašně moc věcí je na nich závislých. Konkrétně „Config Refresh“ hlídá veškeré změny konfigurační databáze a aktualizuje všechno co je na ní závislé v intervalu pouhých 15 vteřin, což je neuvěřitelně málo. Jen dvě systémové úlohy mají dovoleno opakovat se častěji než po minutě a obě se týkají databází, takže je jasné, proč jeden minutový výpadek SQL serveru dokáže plnit logy tolika červenými křížky. Navíc těch pár vteřin co úloha běží, testuje server také sám sebe (metodou HTTP Throttlingu) a pokud si dostupný není, vysílá okamžitě povel k pozastavení všech úloh, které mohou počkat až do spuštění další instance, která proběhne v pořádku. Výsledek takového testu najdete v ULS logu:
Aby servery farmy, jejich objekty a všechna možná nastavení zůstala konzistentní, zapisují se změny do „Configuration cache“ („object cache“, „file cache“, „system cache“, „timer cache“ nebo prostě jen „cache“, každý jí říká trochu jinak), což je složka plná .xml souborů (jednotlivých změn), kterou najdete na adrese:
%SystemDrive%\ProgramData\Microsoft\ SharePoint\Config\určité_GUID
Složka „ProgramData“ je skrytá a jaké GUID máte hledat Vám prozradí následující klíč v registrech:
Atribut ID
Bohužel, občas mezi servery a jednotlivými jejich složkami dojde k nekonzistenci a začnou se dít divné věci – nemůžete založit novou webovou aplikaci, nejde aktivovat „feature“ nebo se zastaví „Timer job“ a přičin může být celá řada – krátkodobý výpadek SQL serveru, aktualizace nainstalovaná jen na jednom ze serverů farmy nebo zakázaný systémový účet služby apod. Jestli máte problém zjistíte velmi rychle, stačí porovnat počet souborů „cache“ složek všech serverů farmy.
Jak opravit synchronizaci, když součty nesedí? Není to těžká práce, jen tak trochu… otravná.
- Zastavte „SharePoint 2010 Timer“, jako službu serveru nebo pomocí příkazové řádky
net stop „SharePoint 2010 Timer“ - Najděte složku se správným GUID na adrese %SystemDrive%\ProgramData\Microsoft\ SharePoint\Config, otevřete ji a smažte všechny .xml soubory uvnitř. Nemažte celou složku a nemažte cache.ini soubor.
- Otevřete soubor cache.ini v poznámkovém bloku a nastavte číslo uvnitř (ať je jakékoliv) na hodnotu „1“
- Spusťte „SharePoint 2010 Timer“, jako službu nebo pomocí příkazové řádky
net start „SharePoint 2010 Timer“ - Opakujte tyto tři body pro všechny servery farmy
- Zkontrolujte obsah složek, jestli soubory přibývají a počty sedí
Pokud se Vám do toho nechce, máme pro Vás dobrou zprávu, existuje na to skript :o) Ale tak ať víte, co přesně dělá. Podrobnější návod pro čištění „cache“ najdete tady, „timer job“ reference pro 2010 je zde, pro 2013 zde a podrobnější povídání o „Config Refresh“ jobu najdete například tady.
Pro výpis všech naplánovaných úloh použijte PowerShell:
Get-SPTimerJob | Sort-Object title | ft title,name
Pro výpis všeh naplánovaných úloh pro konkrétní službu nebo aplikaci použijte PowerShell:
0 comments on Config Refresh Timer Job