No, jak bych to... Napsal jsi tu pět příspěvků a stále jsi nesdělil, jakou konkrétní SQL databázi tam máte. Jestli takhle komunikuješ i se supportem, tak se nedivím, že není schopný dát rozumnou radu.
Jelikož je ta DB tak tajná, tak mohu poradit jen obecně: Nevím o tom. že by nějaká SQL DB měla operaci "rebuild tabulky jen z určitých záznamů". Pokud by bylo potřeba něco takového dělat, tak viz předřečník - potřebné záznamy se odlijí do nové tabulky a tabulky se nějakým způsobem vymění.
V případě historických tabulek (reporty atp.) kam rutinně přibývají a odmazávají se řádky se to řeší partitioningem, kdy se pak dropne najednou celý partition - například měsíc nebo rok dat.
Nicméně tohle je, podle toho co píšeš, spíš nějaký číselník (?) Samozřejmě, pokud je takhle "průtočný" a má sloupeček s datem vytvoření, tak se to tak řešit dá taky. Ale je to tedy docela zvláštní pattern.
Dál stojí za poznámku, že DB operace jsou (pokud jsou dobře indexy) většinou log(n). Tedy pokud odmažeš 3/4 záznamů, tak to nejspíš pomůže, ale řádové zlepšení bych si od toho nesliboval. Maximálně kdybyste se potom najednou zase vlezli do cache, ale na to bych nespoléhal.
Celkově mi přijde, že by se na to měl nejdřív kouknout někdo, kdo DB rozumí, aby zjistil, v čem je přesně zakopaný pes. Trochu blbý v těchhle situacích je, že support aplikace sice zná aplikaci, ale nevidí do DB, aby zjistil, na čem přesně to vázne. DB admini zase koukají jen na DB a že je nějaká aplikace pomalá je nezajímá.
Na tohle téma mám takovou vtipnou historku: U jednoho mobilního operátora jsme měli aplikaci od vendora, co ukládala reportingová data do DB. Najednou se ukládání dat do DB hrozně zpomalilo, data se hromadila ve frontě v aplikaci a reporty se zpoždovaly víc a víc. DB admini lehce arogantně tvrdili, že u nich to není, že oni tam nic nedělali, že jsme určitě něco zmršili my. Udělal jsem nějaké testy a došel k tomu, že ta DB je prostě podivně pomalá, ale ani to s nimi nehlo. Po několika dnech, když už situace začínala být kritickou, manažer zákazníka donutil DB adminy ať se na to přeci jen kouknou. Poměrně rychle zjistili, že se na DB stroji projevil bug v ZFS, kdy se po překročení určitého procenta zaplněnosti výrazně zpomalil zápis na FS. Oprava byla jednoduchá - prostě odmazali nějaký balast, takže procento zaplnění disku spadlo pod kritickou mez a DB se zase zázračně rozjela. No, sypali si popel na hlavu docela dlouho.
Ta historika slouží pro ilustraci, že výkonové problémy jsou často komplexní a musí je řešit někdo, kdo má přístup ke konkrétní DB a potřebné znalosti.
14 Odpovědí
7008 Zhlédnutí