=?iso-8859-2?q?Logov=E1n=ED_v=B9ech_DMLp=F8=EDkaz=F9_v=A0PostgreSQL?=?

Milan Zamazal pdm na zamazal.org
Čtvrtek Květen 23 22:43:53 CEST 2002


>>>>> "JS" == Jan Serak <sherry na pikebo.cz> píše:

    JS> Předně: k obnovení dat od poslední zálohy takový log nestačí,
    JS> protože nemáš pokryté DDL. 

Zapomněl jsem uvést, že se mi nejedná o univerzální řešení, nýbrž jen
o věc šitou na míru konkrétní aplikaci.  DDL pro mě není problém,
uživatelé tyto operace nebudou provádět ani je mít povoleny.

    JS> Navíc takový log je zcela nevhodný pro obnovu databáze ze zálohy
    JS> kvůli příliš vysoké úrovni jeho záznamů (4GL).  Lepší je logovat
    JS> low-level změny v databázi, protože obnova je pak řádově
    JS> rychlejší (ale musí to být featura DBMS).

Tak to myslím PostgreSQL nepodporuje, nebo ano?  Pro mé účely je nicméně
ta vysoká úroveň opět postačující, jedná se pouze o obnovu od posledního
dumpu, tj. od rána, a typicky jde jen o několik tisíc až desítek tisíc
operací.

    JS> A sledování chování uživatelů? To je IMHO natolik mission
    JS> dependent věc, že obecné řešení asi ještě nevzniklo. Co je
    JS> účelem? Napravovat chyby uživatelů nebo dokazovat, kdo chybu
    JS> způsobil, nebo sledovat uživatele (zaměstnance) jestli se
    JS> neflákají nebo je buzerovat, že na to málo, co udělají,
    JS> spotřebují zbytečně moc strojového času?

Dokazovat, kdo způsobil chybu.

    JS> Na každou variantu se pak dá nasadit jiný styl sledování, ale v
    JS> zásadě stejně bude platit, že je nesmysl sledovat každý
    JS> izolovaný příkaz DML (jde-li např. o živou aplikaci, dává smysl
    JS> sledovat spuštění nějaké rutinní akce a nikoli každý z jejích xy
    JS> příkazů).

Rád si nechám poradit něco lepšího.  Je ovšem důležité, aby to
z klientského připojení nešlo ošidit.

    JS> To je právě to, proč to nemůže řešit DBMS. Jak naloguješ DML
    JS> příkazy, které vkládají do této logovací tabulky?

A to jsem si dal pozor, abych uvedl "_uživateli_ provedené příkazy" :-).

    JS> Jak obnovíš ze zálohy databázi, když nemáš zazálohovaný poslední
    JS> stav této tabulky (neboť byl jen uvnitř databáze, kterou už
    JS> nemáš).

To je jednoduché -- v pravidelných intervalech se její obsah stahuje na
jiný stroj.  Připomínám, že půjde typicky jen o několik tisíc až desítek
tisíc záznamů.

    JS> Obecně lze říci, že vhodným nástrojem na sledování změn v
    JS> citlivých datech, jsou triggery, nasazené na vybraných
    JS> tabulkách. Tyto triggery pak mohou logovat všechny změny do
    JS> logovací tabulky. Ale vždy se to bude týkat jen podmnožiny celé
    JS> databáze.

Toto řešení sice teoreticky připadá v úvahu, jenomže potíž je v tom, že
těch tabulek je v databázi docela dost a navíc je na nich navěšena
spousta RULEs.  Rád bych se vyhnul zákonitým problémům s údržbou, takže
hledám jiné řešení.

    JS> 1. účel - obnova z databáze: musíš mít nástroj, který stojí mimo
    JS> logovanou databázi (tj. nemůže to být tabulka v této databázi),
    JS> a logovat by měl low-level změny, nikoli provedené DML (a
    JS> DDL!!!!) příkazy. Ideální je, když je to featura DBMS (nebo je
    JS> DBMS svobodný a člověk si to může dobastlit ;-)

Viz výše a k tomu poslednímu: ani jako svobodný člověk nemám odvahu
seriózně bastlit v PostgreSQL :-).

    JS> 2. účel - sledování uživatelů: je nutné řešit na aplikační
    JS> úrovni (třeba těmi triggery) a smířit se zatím s tím, že
    JS> univerzální řešení neexistuje (nebo nějaké univerzální řešení
    JS> vytvořit ;-)

Doufal jsem, že mi někdo nějaké poradí :-).

Každopádně díky.

Milan Zamazal

-- 
real programmer?  don't get me started.  if you need to hide your
pathetic excuse for a carreer behind super-macho languages like C, C++,
and/or Perl instead of writing clean, maintainable, efficient code, you
aren't much of a real programmer in my view.  -- Erik Naggum in comp.emacs


Další informace o konferenci Test