detekce nabořených indexů

[Pavel Fiser]

Ahoj všem,

1. U zákazníka je DB (17GB), kde se nenápadně nabořil index a v důsledku toho některé sestavy zobrazovaly jen část dat. Po zjištění plánu, které indexy dotaz sestavy používá a jejich aktivací se problém odstranil. 

2. Asi po 14 dnech začal blbnout jiný index, tentokrát u FK a při insertu lhal, že Foreign key reference target does not exist. Takže jsme radši udělali backup+restore (gfix jsem bohužel nezkusil z časových důvodů). 

3. Asi 2 hodiny po restoru se opět objevil problém 1., na jiném indexu. Jeho aktivace pomohla.

Takže mám zásadní dotazy:

a. Lze nějak spolehlivě preventivně zkontrolovat korektnost indexů?

b. Mohl problém 3.způsobit admin v momentě, kdy ihned po restore provedl tvrdé copy .fdb na záložní disk bez stopnutí FB (k DB nebyl nikdo připojen)?

c. Co může být příčinou nabořených indexů? Mohl by indexy v DB nabořit aplikační server, který občas spadne na nějakou vnitřní chybu (AV) v souvislosti s vlákny, který je klientem FB běžícím na stejném serveru (připojený přes localhost)?

V daném období není ve firebird.log vidět žádný pád FB, pouze poměrně dost chyb typu:

INET/inet_error: read errno = 10054

INET/inet_error: select in packet_receive errno = 10038

Jedná se o server  WI-V2.1.3.18185 Firebird 2.1 (64bit).

Díky moc za každý tip. PF.

[Jiri Cincura]

2009/12/4 Pavel Fiser <fiser...@gmail.com>:

> 3. Asi 2 hodiny po restoru se opět objevil problém 1., na jiném indexu. Jeho
> aktivace pomohla.

To je docela divny. Neni tam nejaky chybujici hardware?

> a. Lze nějak spolehlivě preventivně zkontrolovat korektnost indexů?

Zkontrolovat asi ne. Jedine znovu vytvorit.

> b. Mohl problém 3.způsobit admin v momentě, kdy ihned po restore provedl
> tvrdé copy .fdb na záložní disk bez stopnutí FB (k DB nebyl nikdo připojen)?

No zalezi jak soubor kopiroval. Pokud nelocknul soubor, tak je to OK -
nicmene takovahle zaloha je dost naprd. Ma tak 50% sanci, ze nebude
fungovat. ;) Pokud locknul, tak by FB mel zacit rvat (pokud neco
zapisoval).

> c. Co může být příčinou nabořených indexů? Mohl by indexy v DB nabořit
> aplikační server, který občas spadne na nějakou vnitřní chybu (AV) v
> souvislosti s vlákny, který je klientem FB běžícím na stejném serveru
> (připojený přes localhost)?

Nemelo by se to stat. Ale chyby v SW jsou vsude, i ve FB. :(

Spis bych se podival na IO a memory subsystem toho serveru. Mozna tam
neco nefunguje spolehlive.

> V daném období není ve firebird.log vidět žádný pád FB, pouze poměrně dost
> chyb typu:
> INET/inet_error: read errno = 10054
> INET/inet_error: select in packet_receive errno = 10038

To jsou vsechno sitove chyby. Zadny velky problem (z pohledu serveru).

--
Jiri {x2} Cincura (CTO x2develop.com)
http://blog.cincura.net/ | http://www.ID3renamer.com

[Pavel Fiser]

> 3. Asi 2 hodiny po restoru se opět objevil problém 1., na jiném indexu. Jeho
> aktivace pomohla.

To je docela divny. Neni tam nejaky chybujici hardware?

Jak to poznat? V event-logu win není nic podezřelého, dál mé znalosti nesahají :-( 

Skutečností (která s tím nemusí jistě souviset) je, že na starém serveru podobná věc už jednou nastala asi po 2 letech provozu, na novém teď první (celkem druhý) případ po 1/4 roce.

 

> b. Mohl problém 3.způsobit admin v momentě, kdy ihned po restore provedl
> tvrdé copy .fdb na záložní disk bez stopnutí FB (k DB nebyl nikdo připojen)?

No zalezi jak soubor kopiroval. Pokud nelocknul soubor, tak je to OK -
nicmene takovahle zaloha je dost naprd. Ma tak 50% sanci, ze nebude
fungovat. ;) Pokud locknul, tak by FB mel zacit rvat (pokud neco
zapisoval).

Kopíroval ho total commanderem z jednoho lok.disku na druhý, trvalo to asi 4 minuty. Nevím jak jednoduše poznat jakým způsobem to TC lockuje. Ale chápu to dobře, že nabořit pův.DB by se takto podařit nemělo?

 

> c. Co může být příčinou nabořených indexů? Mohl by indexy v DB nabořit
> aplikační server, který občas spadne na nějakou vnitřní chybu (AV) v
> souvislosti s vlákny, který je klientem FB běžícím na stejném serveru
> (připojený přes localhost)?

Nemelo by se to stat. Ale chyby v SW jsou vsude, i ve FB. :(

Spis bych se podival na IO a memory subsystem toho serveru. Mozna tam
neco nefunguje spolehlive.

Můžeš být trochu konkrétnější - nějaký diagnostický nástroj, postup...?

 

Dík moc za odpovědi.

PF.

[Jiri Cincura]

2009/12/6 Pavel Fiser <fiser...@gmail.com>:

> Kopíroval ho total commanderem z jednoho lok.disku na druhý, trvalo to asi 4
> minuty. Nevím jak jednoduše poznat jakým způsobem to TC lockuje. Ale chápu
> to dobře, že nabořit pův.DB by se takto podařit nemělo?

Zalezi jak si TC ten soubor otevre. Ale krome toho, ze je ta zaloha
naprd, by to DB nemelo naborit aniz by zacala prudce rvat, ze je neco
spatne.

> Můžeš být trochu konkrétnější - nějaký diagnostický nástroj, postup...?

MemTest na pamet. Na disk, hmm, ja vetsinou necham porad dokola
kopirovat par GB generovanych dat + kontrola SHA1.