Logování všech DMLpříkazů v PostgreSQL?

Jan Serak sherry na pikebo.cz
Čtvrtek Květen 23 08:58:02 CEST 2002


Milan Zamazal wrote:
> 
> Chtěl bych se zeptat, zda lze nějakým *rozumným* způsobem v PostgreSQL
> logovat všechny uživateli *provedené* SQL příkazy modifikující data
> (nebo aspoň úplně všechny provedené SQL příkazy)?  Účel tohoto logu by
> měl být dvojí: Jednak možnost obnovení dat od poslední zálohy a jednak
> záznam o tom co kdo kdy s daty provedl.

Předně: k obnovení dat od poslední zálohy takový log nestačí, protože
nemáš pokryté DDL. Navíc takový log je zcela nevhodný pro obnovu
databáze ze zálohy kvůli příliš vysoké úrovni jeho záznamů (4GL).
Lepší je logovat low-level změny v databázi, protože obnova je pak
řádově rychlejší (ale musí to být featura DBMS).

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

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

<veselá historka>
V této souvislosti mne napadá požadavek jednoho našeho zákazníka
na úpravu části IS pro právníky (agenda smluvních vztahů), Chtějí
po nás nástroj, který by uvedl do původního stavu provedené změny,
které uživatel OMYLEM potvrdil.

Naší první reakcí bylo, že s řešením počkáme, až DBMS bude umět
SUPERROLLBACK, který vrátí commitované změny :-)
Jinak ale je to samozřejmě věc, kterou nemůže řešit DBMS, nýbrž
 musí být žešena aplikací (i když si zatím nedokážeme přesně
představit, co to v daném případě obnáší).
</veselá historka>

> 
> Výstup do logu při zapnutém `debug_print_query' mi nevyhovuje -- jednak
> dokumentace nezaručuje žádné jeho vlastnosti a jednak se příliš nehodí
> pro automatizované zpracování.  Raději bych, kdyby se příkazy
> s doplňujícími informacemi logovaly přímo do nějaké databázové tabulky.

To je právě to, proč to nemůže řešit DBMS. Jak naloguješ DML příkazy,
které vkládají do této logovací tabulky? Jak obnovíš ze zálohy databázi,
když nemáš zazálohovaný poslední stav této tabulky (neboť byl jen
uvnitř databáze, kterou už nemáš).

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

Ale abych odpověděl na Tvé dotazy z úvodu:

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

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

						Jan Šerák


Další informace o konferenci Test