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

[Karel Zak]

On Fri, May 24, 2002 at 02:37:20PM +0200, Ing. Pavel PaJaSoft Janousek wrote:
> 	A nevedete zurnal o operacich, kdyz je to tak kriticke (samozrejme
> podporeny transkcemi)? - Samozrejme je to nutno na aplikacni urovni,
> osobne nevidim duvod, proc by to (ani na vyzadani) mel resit databazovy
> stroj.

 Tazatel by asi chtel nejaky on-line backup, coz je vec kterou PostgreSQL
 zatim nema i kdyz jeji implementace by snad nemusel byt tak narocna.
 Bude-li v nasledujici 7.3 si nejsem jist.
 
> > 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.
> 
> 	A to je IMHO kamen urazu. 1. systematicnost opravneni je vice nez
> nedostatecna, na naprave se udajne pracuje - to rika Karel Zak, nicmene
> aspon co ja vim, je stejna uz od verze 5, existence zhruba podobnych
> moznosti v pg_hba.conf stale stejna a GRANT/REVOKE zmeny rovnez
> nedoznalo (na jakykoli databazovy objekt, kdyz byl pridan, pravidla sla
> samozrejme vyuzit i na nej)... Docela by mne zajimalo, jak by mi v
> PostgreSQL nekdo mohl zakazat provest napr. create table...

 V soucasne devel verzi jsou jiz implementovane schmeta, takze je zde
 prostor konecne cistym zpusobem implementovat prava i k databazim.
 Existuje i patch (od mne:-), ktery pridava NOCREATETABLE option do
 CREATE USER, mam pocit, ze to par lidi pouziva. Prave na ty
 schemata se cekalo pred tim nez se nekdo pusti do prace na systemu
 prav.

> 	A nejsou lepsi replikace? PostgreSQL 8.0, ktery to ma mit built-in
> jeste neni, ale projekt existuje davno a myslim, ze pouzitelnost je
> velka - odkaz najdete na technologicke stranke v domene postgresql.org.

 IMHO bych to co neni v oficialnich zdrojakach nepouzival. DB neni
 ovladac ke zvukovce...
 
On Fri, May 24, 2002 at 08:31:17PM +0200, Milan Zamazal wrote:
> 
> O řešení na aplikační úrovni, tj. že k databázi bude přístup pouze přes
> speciální serverovou aplikaci, uvažuji.  To je ovšem značně netriviální,
> zejména z hlediska bezpečnosti a robustnosti.  Právě to byl cíl mého
> dotazu -- tomuto řešení se pokusit vyhnout, díky využití nějakého
> dostatečně jednoduchého mechanismu na serveru.
 
 Jak tu dale nekdo naznacoval tak by stalo za to vedle zivych tabulek
 vytvaret nejaky datawarehouse kde bude zaznamenan kazdy byte. Otazkou
 bude jak snadno z toho zpetne budete schopen obnovovat data.
 
> skeptický, dokud nejsou pořádně odladěny.  Pokud by to mělo ohrozit
> robustnost serveru, tak raději použiji to aplikační řešení.

 S trochou fantazie by asi sel pouzit nejaky trigger, ktery bude nekam
 zapisovat veskera DELETE/UPDATE/INSERT data.
 
On Fri, May 24, 2002 at 04:07:40PM +0200, Jan Serak wrote:
> 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.

 Toto by melo byt proveditelne reseni (na misto rowid (oid) bych
 pouzil nejake administratorem ovladatelne id (sequence), ktere
 nepujde v radkach modifikovat. Nemuselo by to byt ani moc pracne 
 ten trigger napsat (mozna cca 150 radek v C?)

> > 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 by nemel byt problem.
 
> 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.

 V PostgreSQL ma trigger u UPDATE k dipozici jak stara tak nova data.
 Neni tedy problem ukladat do logu jen opravdove zmeny a ne cele radky.

On Fri, May 24, 2002 at 10:25:09PM +0200, Milan Zamazal wrote:
> Díky, Sherry, za podrobný rozbor problematiky.  Budu si to muset ještě
> přebrat, jenom doplním několik drobností:
> 
> - Využití "euid" procedur by mohlo být elegantním řešením, bohužel to
>   nevypadá, že by PostgreSQL něco takového poskytoval.  Zdá se, že
>   procedury vždy běží pod uživatelem, který je spouští.
> 
> - Rules v PostgreSQL jsou něco podobného jako triggery.  PostgreSQL
>   nabízí obojí, dost se to překrývá a není mezi tím úplně zřetelný
>   rozdíl, zhruba lze říci že rules jsou spíše deklarativní, zatímco
>   triggery procedurální.
 
   Prave, ze RULEs bezi pod uzivatelem ktery je vytvoril a triggrey
   pod tim uzivatelem ktery vyvolal danou udalost (+ to co jste
   rekl).
 
> - S tím rozšířením tabulek o platnost a uživatele není problém až tak ve
>   dvou sloupcích navíc (stejně už je ve většině tabulek máme), jako
>   spíše v množení řádků.  Pokud mi totiž nestačí pouze údaj o poslední
>   modifikační akci, je místo UPDATE nutno provádět (UKONČI-PLATNOST +
>   INSERT).  Ale i tak to může být také použitelné.

 Nelze ten archiv vytvaret bokem. Tedy tabulky ktere pouziva
 aplikace obsahuji jen aktualni data a vedle je kopie tabulky s celou
 historii tak jak bylo popsano. IMHO mit v bezne pouzivanych tabulkach
 i nepouzivana data je dost vykonostne na nic. Do datewarehouse nedelam,
 i kdyz by mne to celkem zajimalo :-)

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/
 
 C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz