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

[Jan Serak]

Milan Zamazal wrote:
> 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.

Super!

> 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í.

Nevim. PostgreSQL do hloubky neznam (jsem hnusny zapskly komercni
Oraclista ;-)

> Dokazovat, kdo způsobil chybu.

To je OK. Takze:

1. jestli klienti mohou pouzivat prime zadavani DML prikazu (napr.
nejakym
standardnim klientem a nikoli aplikacnim programem, je to blby. 
Reseni je asi pouze brutalni silou: dobre mirenym programkem nad
metadaty
(doufam, ze PostreSQL ma neco jako data dictionary ;-) vygenerovat pro
kazdou tabuli ve schematu trigger, ktery bude logovat veskere zmeny
(v Oracle staci jediny, nebot v jeho tele lze zjistit (pocinaje snad
7.3.2),
zda se updatuje, insertuje nebo deletuje). Problem tohoto reseni spociva
v tom, ze v triggeru se patrne nebude dat rekonstruovat DML prikaz,
ktery
jej vyvolal, takze se bude muset spoustet s kazdym modifikovanym radkem
a do logu zapisovat potrebne informace (typ DML, tabulka, rowid, stara
hodnota, cas, uzivatel), z cehoz se nebude dat vygenerovat posloupnost
skutecne provedenych informaci, ale posloupnost zmen v jednotlivych
radcich. Tudiz ten log asi dost naroste.
Dalsi reseni je vazane na Oracle, nebot nevim, jak to v PostreSQL je.
Spociva ve vlastnosti Oraclu, ze storovane procedury se provadeji s
jakymsi euid vlastnika procedury, nikoli pod ruid toho, kdo proceduru
spustil. Tim padem vsichni uzivatele mohou mit pristup k tabulkam pouze
read-only a vsechny DML, ktere aplikace bude potrebovat provadet, musi
byt narvany ve storovanych procedurach (pro kazdou blbou zmenu v
databazi).
Tim lze logovat pouze spoustene technologicke celky a pro jednu akci
se vygeneruje jediny zaznam, bez ohledu na to, kolik DML prikazu tato
akce provedla. Vlastnik / spravce aplikace musi znat, co jednotlive
technologicke celky pusobi v datech, aby si mohl pozjistovat, co se
v tomto behu stalo. Nicmene vinik bude nalogovan, nebot funkce ``user''
vraci realne jmeno uzivatele a pristupova prava pro zapis do dat,
ktere fakticky ten uzivatel nema (ma jen pravo execute na tuto
storovanou
proceduru), se obejdou pres euid vlastnika storovane procedury. Problem:
nevim, jestli se PostgreSQL v tomto chova jako Oracle ;-)

2. Pokud je aplikace udelana tak, ze klienti nemaji moznost posilat
primo
DML prikazy (nemaji zadneho standardniho klienta, ktery umozni uplne
vsecko,
na co ma uzivatel pravo), pak je to take pomerne jednoduche. Moznost
poslani podvrzeneho DML prikazu pres sitove rozhrani klienta a serveru
se da zabranit cryptovanim komunikace. Zabranit svevolnemu nainstalovani
klienta schopneho komunikovat se serverem primo nezbude nez
administrativne.

>     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" :-).

IMHO databaze nedokaze rozlisit, proc na ni nekdo zada provedeni
nejakeho
DML, zdali je to nekdo/neco, co primo poslalo nejaky DML, nebo je to
spusteno
nejakym programem (i kdyby, tak nepozna, jestli je ten program soucasti
aplikace, tj. duveryhodny, nebo podvrzeny) nebo co je spusteno z
databazoveho
triggeru (ona takova soustava triggeru, kdyz je dobre napsana, tak
aplikaci
staci dat jeden DML prikaz, a triggery vygeneruji takovy stoh modifikaci
dat, ze z toho jde cloveku hlava kolem ;-)

> 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ů.

Tim mym resenim z toho problem bude. Trigger nesesklada originalni DML
prikaz,
tudiz se musi logovat zmeny v jednotlivych radcich a jednotlivych
sloupcich
tabulky.

> 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í.

To jsem Te asi zklamal, co? Nastesti nevim, co jsou RULEs (constrainty,
alias integritni omezeni typu foreign key, primary key atd.?). Jiste je,
ze tyto logovaci triggery by nemel byt problem vygenerovat, a kdyz
ten trigger nebude delat nic jinyho, nez insert jednoho zaznamu do
logovaci
tabulky, zadne constrainty to nema sanci narusit (v aplikaci). Spis je
to problem objemu vznikajicich dat a asi tez zpomaleni aplikace.

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

:-)))) To ja taky ne. Ale mam krasnou alibistickou vymluvu, protoze
ja s Oraclem nehnu, ani kdybych chtel ;-)

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

Jeste me napada jedna vec (mam v tomhle celkem stesti, ze se OLTP uz moc
nevenuju, protoze delam datawarehousy a tam jakekoli logovani tohoto
typu
je zcela absurdni; proto zasahovat primo pres DML ma pouze spravce,
cele zpracovani gigadat je v C-cku a storovanym PL/SQL, formulare vesmes
jen na prohlizeni atd.). Ale pouzivame tam technologii pro aktualizaci
ciselniku (nudne, stale se opakujici cinnosti, ktere jsou pod uroven
admina ;-)
jednu vec: nemame nalogovano, jakym postupem se dospelo k soucasnemu
stavu ciselniku, ale mame v kazdem ciselniku sloupecky, kam trigger
zaznamenava,
kdo a kdy naposledy zmenil zaznam. Delete aplikace nedovoluje (kdyz se
ciselnik
aktualizuje, zmeni se "rusenemu" zaznamu datum platnosti na vcerejsi,
takze pro
aplikaci je to domluveny signal neexistence zaznamu - btw. je to beztak
nutnost,
protoze se nam stava, ze zpracovavame data pul i vice roku zpetne a
potrebujeme
stav ciselniku platny v te dobe, nikoli nynejsi) a ostatni zmeny v
zaznamech
maji uvedeneho vinika primo v datech ciselniku. Je to taky svym zpusobem
brutalni sila, mit kazdou tabulku o dva sloupce sirsi, ale dokazatelnost
a nepopiratelnost holt neco stoji.

> 
> Každopádně díky.

Neni zac...

								Sherry