Unable to extend ID Table

Spravujete větší řešení postavené na platformě Lotus Notes  a setkali jste se s hláškou „Unable to extend ID table“? V tomto příspěvku se chci s Vámi podělit o zkušenosti s touto situací a jejími dopady na naše datové centrum, a zejména ukázat možnosti, jak si s touto situací poradit.

Symptomy:

Máte řešení se spoustou záznamů, které využívá replikaci mezi databázemi, k jejich distribuci do dalších lokalit nebo firem, a zároveň se ve zdrojové databázi pilně maže.  Potom při překročení hranice, z naší zkušenosti řádově několika milionů smazaných dokumentů, nepochybně dojde na tuto hlášku. Komunitu to trápilo celé roky, jak lze například vyčíst zde , a smyslupné řešení přišlo až před nedávnem.

V našem případě se jedná o architekturu aplikace pro kontrolu výskytu firem a osob v Insolvenčním rejstříku. Do hlavní databáze, tzv. matky, se stahují všechny záznamy publikované přes webové služby ministerstva spravedlnosti.  Pro každého klienta dané služby poté provozujeme jeho instanci, kam se replikují nové záznamy, a proti nim se provádí kontrola pro daného klienta a propisuje se na ně datum a výsledek kontroly. Po určité době provozu jsme přistoupili k plánovanému odmazávání starších událostí, tak abychom neudržovali instance o velikosti v desítkách gigabytů pro každého klienta služby, a využili jsme k tomu odmazávání v matce a následnou replikace mazání propagovat i do klientských replik.  A jednoho krásného dne se na monitoringu objevila výše uvedená hláška.  Samo o sobě to znamenalo pouze zastavení replikace, a nutnost řešit. Nicméně nedej bože, aby se na databázi v této situaci pustil běžný compact. Jakmile toto nastalo, ať už zásahem operátora, nebo serveru, došlo k zahlcení logu hláškou pro každý dokument, který se již do ID table nevešel, a při šikovně nakonfigurovaném monitoringu můžete lehce dospět k rozsáhlé IO bouři na vašem datovém úložišti  –> záznam vyvolá mail na monitoring, a tento provede pokus o doručení, a vzhledem k tomu, že se jedná řádově o miliony dokumentů, o neštěstí je postaráno.

Opatření:

Do verze 8.5 nejde řešit jinak, než vytvořením nové repliky z matky, případně pokud se nedejbože dostane do této situace zdrojová db, tak je třeba ji dostat ze zálohy a přes vytvořit novou kopii postavit znovu. Jak praktické! Zejména pokud se jedná o gigabytové databáze, což je v tomto případě pravidlem.

Pokud máte verzi Domino 9 a výše tak lze situaci řešit v rámci údržby takto: Přidejte do notes.ini parametr Create_R9_Databases=1, tak aby se vytvářeli nové db již na R9(ODS52).  Pokud již máte, nebo případně máte Create_R85_Databases=1, tak to stačí taky.   Sice to není zdokumentované, ale empiricky jsme zjistili, že ta ID table je zřejmě větší v těchto novým On-Disk-Structure formátech než ve výchozí R6(ODS43)

Následně lze na postižené databázové replice spustit compact s parametrem -REPLICA. Přiklad:  load compact
Cesta\XXX.nsf -REPLICA    Buduje celou repliku od nuly, takže nespouštět přes den…a následně opakujte replikaci obsahující mazané dokumenty, dokud zase neprojde na této chybě – a to se asi minimálně jednou stane – , pak spusťte tento compact znovu. jakmile doběhne replikace bez chyb máte prozatím vyhráno. Do budoucna ale naplánujte následující task na serveru: compact -REPLICA -IDS_FULL 080, který preventivně compact udělá v situaci, kdy se blíží zaplnění  ID tabulky na 80%.

Pokud nemáte Domino verzi 9, ale máte k dispozici aspoň klienta Notes 9, tak si můžete  tu problematickou repliku vzít offline a spustit tento compact lokálně,
například takto:

cd „c:\Program Files (x86)\IBM\Notes“
ncompact „C:\Temp\XXX.nsf“ -REPLICA

A následně repliku vrátit na server, zkusit znovu replikaci a opakovat postup dokud replikace neprojde.

David

Vložit komentář

Váše emailová adresa nebude publikována. Povinná pole jsou vyznačena *

Ochrana před spamem *

Můžete používat následující HTML značky a atributy: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>