=?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