Vlákno názorů k článku Transakce a izolace transakcí v databázích od LENIN POWER! - Oracle nema uplny MVCC jako maji pgsql a...
-
Oracle nema uplny MVCC jako maji pgsql a firebird. Oracle pouziva before statement block level snapshoty a sdili stejny block ve snapshotu vice transakcemi misto aby mel pro kazdou svuj jako maji MVCC databaze. Oracle implementace ma pak problem s garbabe collection snapshot bloku (znama chyba snapshot too old) u dlouhotrvajicich transakci, coz je docela opruz a proto se doporucuje oracle neprovokovat dlouhymi transakcemi.
DB2 umi v 9.7 Oracle 'statement snapshot' read commited isolation level. Stejne jako Oracle tak i DB2 emuluje MVCC, ale nepouziva block level snapshot ale ARIES.
Clanek by chtelo rozdelit na vic dilu:jeden o races, druhy o transakcich a isolation levelech, treti o zamykani s probranim lock avoidance strategii. Skoda ze s tim autor seknul, ale chapu ho. -
Snapshot (neregistrovaný)Imho Snapshot too old je trosku neco jineho. Asi bych to nedefinoval jako problem s garbage collection snapshot bloku :-) Takova vec neni potreba. :-)
Vse je to zavisle na UNDO. Tzn. modifikovane bloky se ziskavaji z UNDO a u jiz commitnutych transakci se muze stat, ze se pubvodni bloky prepisou a nepodari se je v UNDO dohledat (snapshot too old). Zalezi tedy na nastaveni velikosti UNDO a undo retention time.
Obecne se jedna spis o problem dlouho bezicich query nad modifikovanymi daty.
Klasicky pripad je napr. commit v cyklu namisto po cele transakci.
Jde proste o to, ze po commitu jsou UNDO bloky uvolneny pro dalsi pouziti, pak uz je to jen o te velikosti UNDO a jeho nastaveni. Proste dokud neprovedu commit, tak jsou bloky v undo v bezpeci. :-)
Pri dostatecne sizovanem undo je mozne klidne vytahnout obraz tabulky nekolik dnu zpetne.
U rozsahlych modifikaci se muze stat naopak to, ze se modifikovane bloky jiz do UNDO nevejdou a cela transakce spadne na unable to extend undo segment. -
LENIN POWER! (neregistrovaný)Jenomze to je prave ten spatny design. Po comitu sice uvolni bloky pro dalsi pouziti ale soucasne si je v tablespace necha, kdyz by je jeste nejaka bezici transakce potrebovala. Cisti je podle timestamp ale nikoliv podle toho zda nad nimy jeste nejaka transakce operuje ci ne. Meli by mit alespon inuse counter pro kazdy blok aby se nestavalo ze zahodi nespravny blok i kdyz je v undo tablespace misto. Kdyz je ten cas zbytecne velky tak se tam zase flakaji bloky ktere by mohli byt uz davno smazane.
mssql ani db2 tyhle problemy nemaji, je to zasadni oracle missdesign ktery ma snad od nepameti. Meli by to u oraclu uz konecne predelat takhle je to zbytecnej opruz. -
Michal Kára (neregistrovaný)Je fakt, ze problemy s UNDO segmentem jsem uz take zazil. Ale pokud bych mohl ovlivnit, co ma Oracle opravit, tak jsou to rozhodne veci spojene s retezovou invalidaci kodu. Zmenite hlacivku package a lup ho - vse co package pouziva je nevalidni a musi se rucne prekompilovat (krom triggeru). A nejlepsi je, ze obcas ani zkompilovani nepomuze a je nutne zavrit a znovu otevrit spojeni do DB, aby se novy kod zacal pouzivat. Bleeee :-/
-
DK (neregistrovaný)No a stačilo to prostě říct :-).... ehm. a nainstalovat Oracle Database 11g
Pohled do New Features Guide říká:
[url]http://download.oracle.com/docs/cd/B28359_01/server.111/b28279/chapter1.htm#FEATURENO07519[/url]
[b]1.2.9.3 Finer Grained Dependencies[/b]
In previous releases, metadata recorded mutual dependencies between objects with the granularity of the whole object. For example, PL/SQL unit P depends on PL/SQL unit Q or that view V depends on table T. This means that dependent objects were sometimes invalidated when there was no logical requirement to do so. For example, if view V depends only on columns C1, C2, and C3 in table T and a new column, C99, is added, the validity of view V is not logically affected. Nevertheless, in earlier releases, V was invalidated by the addition of column C99.
Oracle Database 11g records dependency metatdata at a finer level of granularity so that the addition of C99 does not invalidate view V. Similarly, if procedure P depends only on elements E1 and E2 in package PKG, then if element E99 is added to PKG, procedure P is not invalidated. (In Oracle Database 10g, this change to PKG would invalidate procedure P.)
Více viz: [url]http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/dependencies.htm#CHDJIIFC[/url] -
Snapshot (neregistrovaný)To si nemyslim, ze se jedna o spatny design. Pri spravnem sizingu a nastaveni DB (UNDO) a samozrejme spravnem designu aplikace to nepredstavuje zadny problem. Udrzovani historie bloku je jen o diskovem prostoru.
Krome toho. Pokud uvazujeme dlouho bezici dotaz. Databaze preci nemuze dopredu vedet, ze ten konkretni blok v undo bude potrebovat. Ted konkretni blok se muze zmenit tisickrat. Pokud dotaz pobezi nekolik hodin tak databaze nema sanci podchytit, ktere bloky potrebovat bude a ktere se zmeni a bude je muset dotahnout z UNDO. To uz je vlastni resultset. ;-)
Snapshot too old je obecne problem v nastaveni DB(UNDO) nebo v navrhu aplikace. -
LENIN POWER! (neregistrovaný)porovnejte oracle 10 s db2 9.7
- oba dva umi statement snapshot MVCC emulaci
- db2 nepotrebuje UNDO segmenty
- db2 umi libovolne dlouhe transakce (od v8)
- db2 navic diky ARIES ani nepotrebuje hard checkpointy (flush datapages)
Takze tohleto je dukazem ze se to MVCC-like prostredi poradne naprogramovat da aniz by se musely heuristicky nastavovat parametry u UNDO segmentu (ktery ani db2 nema). Nizsi administrativni zatez databaze je pochopitelne vyhoda, stejne tak je vyhoda ze se o toto nemusi starat aplikace a muze si delat transakce dlouhe jak je libo (ackoliv delsi mohou potencialne vice lehnout na deadlock pri kolizi s ostatnimy transakcemi). O jakou dulezitou vlastnost oraclu je implementace v db2 ochuzena? kill session db2 umi (rika se tomu v db2 terminologii force application).
Ja nevim lidi mne pripada ze snad vubec neumite pracovat s informacemi, co vam na tom jeste neni jasne? -
ivan (neregistrovaný)Oracle napriklad umoznuje mit neomezene mnozstvi radkovych zamku - nema lock escalation. Na druhou stranu ovsem v Oracle neexistuje pametova struktura ktera by vam rekla ktere radky byly zmeneny/zamceny a kym.
Diky tomu, ze oracle nezamyka bloky ani tabulky vam nemuze nastat deadlock kdyz db zacnou dochazet zamky. Proste neni to ani lepsi ani horsi je to proste jinak. Jedine co s tim muzete delat je dekovat Bohu ze vymyslel JDBC, diky kteremu se tyhle rozdily mezi databazemi zastiraji a programatori v JAVE na takovehle veci vubec nemusi myslet :) -
Snapshot (neregistrovaný)Jasne je jedine. O DB Oracle toho zas tak moc nevite. Myslim, ze jsem vse vysvetlil docela nazorne. Nevim jaka je u vas presne definice "dlouhe transakce". Tyden dva? :-) Transakci na Oracle muzu mit rozjetou aniz by to narazelo na deadlock nebo neco podobneho. :-) V podani oracle je deadlock vzdy problem v navrhu aplikace.
Myslim, ze je zbytecne to rozebirat. Vase argumenty vypovidaji jen o neznalosti DB Oracle. :-) S prominutim. -
Lael Ophir (neregistrovaný)Jeho argumenty by mohly vypodívat leda o neznalosti omezení DB Oracle. Jenže on právě ta omezení popisuje. Vy je pokládáte za know how, on za nectnost dané DB. Obecně admini unixů a Oracle rádi vydávají znalost chyb a omezení za know how. Kdo chyby a omezení nezná, ten podle nich "neumí produkt". Nepřiznají si, že chyba není v lidech, ale v produktu.
-
Snapshot (neregistrovaný)Mno. Oracle ma chyb spoustu, ale popsane chovani k nim nastesti nepatri. :-) Admin nejsem. :-)
Nicmene mozna jde opravdu o uhel pohledu. Puvodne byla ma reakce na snapshot too old a jeho vysvetleni.
Vyzkousejte mi nejak vysvetlit v cem ono omezeni/chyba spociva?
Btw: Ktery produkt nema nejake omezeni. Urcite je lepsi o tech omezenich vedet aby clovek
mohl produkt efektivneji pouzivat a vyhnout se zbytecnym prekvapenim. Nebo to tak neni? :-)
Obvykle ma kazde omezeni nejaky duvod. V jednom smeru to neco prinese a z jine strany zese naopak.
Imho znalost omezeni produktu (at uz je to treba databaze) je soucasti znalosti produktu jako celku.
Nebranim se tomu, ze Oracle ma necnosti.. to urcite ma. Ale nesouhlasim s tim tak jak je popisovano chovani UNDO, protoze tak to nefunguje. :-)
