Jak mazat deletion stubs
Popíšu jednoduchý trik, který většina adminů pravděpodobně zná, nicméně snad jej někdo shledá zajímavým. K tomu přidám ještě povídání, jak se v Notesech vlastně dokumenty mažou a odstraňují.
Když v Lotus Notes smažete dokument, neodstraní se z databáze všechny informace o něm. Proč? Je to kvůli replikaci. Kdybychom smazali úplně celý dokument, při další replikaci by se zjistilo, že tento dokument chybí a přitáhnul by se znovu se serveru, kde nebyl smazán. Proto Notesy po smazaném dokumentu nechávají tzv. deletion stub. Je to malinký zbytek dokumentu, obsahuje unikátní číslo (UNID) a příznak, že byl smazán a kdy. Při další replikaci se zjistí, že dokument byl smazán, a deletion stub se šíří mezi servery stejně, jako běžný dokument. Místo, které zbylo po smazaném dokumentu se může znovu použít, Notesy tam uloží menší dokument nebo místo "setřesou" při nejbližším compactu.
A jak dlouho zůstává takový deletion stub v databázi? Musí tam zůstat tak dlouho, aby se stihnul zreplikovat na co nejvíce serverů (tedy alespoň několik dnů, pro případ, že by server neběžel, spadla síť apod.). Ale ne zase moc dlouho, protože i deletion stub zvyšuje režii databáze a zabírá místo. Lotus Notes k řízení odstraňování deletion stubs používají nastavení v Replication Settings, záložka Space Savers, pole Remove documents not modified in the last ... days.
Tento řádek řídí dvě věci: pokud je zaškrtnut checkbox na začátku, pak se pravidelně odstraňují dokumenty, které jsou starší (nebyli od té doby modifikovány) než uvedený počet dní. Používá se to například u logových databází, kde nepotřebujeme zpravidla příliš staré údaje.
Dále, ať už checkbox zaškrtnutý je nebo není, se podle tohoto čísla odstraňují deletion stubs. V obou případech jde o úplné odstranění, po dokumentech nezůstane deletion stub, ale celý kompletně zmizí.
A kdy toto odstraňování probíhá? Na serveru běhá proces updall, který se (defaultně) spouští každou noc ve dvě hodiny ráno. Ten se (mimo jiné) podívá do databáze, zdali tam není nějaký starý dokument nebo deletion stub na odstranění. Vzhledem k možnému počtu databází se to ale nedělá při každém spuštění tohoto procesu! Každá databáze má svůj interval a odstraňování probíhá jen v některých dnech. Tento interval odmazávání se počítá přímo z doby, po které se mají dokumenty odmazávat (ta je defaultně 90 dní), jedná se o třetinu této doby. Znamená to tedy, že první "prošlý" dokument nebo deletion stub je odstraněn teprve po 4/3 doby, uvedené v políčku.
Příklad: Máme novou databázi, v Replication Settings zašktrnutý checkbox a nastaveno 90 dní. Předpokládejme, pro zjednodušení, že každý kalendářní měsíc má 30 dní.
1. ledna vytvoříme dokument a dále jej neupravujeme. 2. ledna vytvoříme dokument a hned jej smažeme, vznikne deletion stub.
1. února se spustí updall a chce odstraňovat v naší databázi, protože uplynula jedna třetina dní (uvedených v Replication Settings) od vzniku databáze. Nic ale neodstraní, protože žádný dokument není starší, než 30 dní.
1. března se opakuje situace jako před měsícem.
1. dubna se opakuje situace, jako před měsícem.
2. dubna by se mohl odstranit dokument, založený 1. ledna, protože právě dnes je starší než 90 dní, ale smůla, na dnešní den nevychází v naší databází odstraňování - to bylo včera a bude opět za 29 dní.
1. května se konečně odmaže jak dokument z 1. ledna, tak deletion stub z 2. ledna, protože oba jsou starší, než 90 dní.
A trik tedy zní: pokud nastavíte číslo na nulu a buď otevřete databázi v klientu nebo na ni pustíte updall, odstraní se ihned všechny deletion stubs. POZOR! Nesmíte současně zaškrtnout checkbox, jinak byste odstranili úplně všechny dokumenty, nejen ty smazané. Také se ujistěte, zda jste předtím zreplikovali databázi s ostatními servery, aby se na ně přenesly nejnovější deletion stubs. Po odstranění můžete vrátit číslo (a případně i checkbox) na původní hodnoty.
O tom, jestli operace proběhla úspěšně, se můžete přesvědčit příkazem show database databaze.nsf, která hned v prvním řádku napíše počet počet aktivních dokumentů a počet deletion stubs (více o příkazu show database).
Předchozí: Konec podpory R5
Následující: Kniha o vývoji v ND6 konečně vyšla