Visszavonulások az oracle subdata-ban
Oracle visszaforgatási szegmensek
Dmitrij Bezrukov,
FORS-HOLDING CJSC
A visszagörgetési szegmensek, amelyeket a visszavonási szegmenseknek is neveznek (például az USN - Undo Segment Number) három fő feladat elvégzésére szolgálnak:
- A visszagörgetési parancs végrehajtása.
- Állítsa vissza a példányt a hiba után (példány-helyreállítás).
- Az adatbázisból származó adatok konzisztenciájának biztosítása (konzisztencia olvasása)
Az első és a második elemet a szakirodalomban kellő részletességgel és érzékenységgel lefedik, de nem láttam teljes leírást az Oracle funkcionalitásáról a 3. tétel alatt.
Szintén a szakirodalomban nem láttam egyértelműen leírni a visszahúzó szegmensek mechanizmusát. A legjobb leírás volt, furcsa módon a régi Oracle dokumentációban a 3., 4. és 5. verziókhoz. Igaz, hogy nem volt visszaállító szegmens akkoriban, hanem inkább egy képfájl volt, de a fogalmak ugyanazok maradtak. A "fej és farok" helyi koncepciója, véleményem szerint, jobban segít megérteni a visszatérő szegmensek szerkezetét.
Először beszéljünk következetességről, majd - a visszagörgetési szegmensek megszervezéséről. Természetesen ezek a témák nem terjednek ki a rollback szegmensek adminisztrációjának minden vonatkozására, de nagyon hasznosak a szerkezetük és működésük megértéséhez.
Az olvasási adatok konzisztenciája
A konzisztencia problémája a DBMS-ben lévő adatok "fagyasztásával" kapcsolatos, és a felhasználó ezen adatokra vonatkozó jelentést kap. Abban az időben a jelentés átvételét bármely felhasználó a többi felhasználó számára lehetővé kell tenni, hogy egyszerre módosítsa ugyanazokat az adatokat (egyébként drasztikusan csökken adatok versenyképesség), így a tartalom az adatbázis folyamatosan változik, és a „befagyott” az adatok egy pillanatkép (egy pillanatfelvétel) az adatbázis egy bizonyos időpontban. A mechanizmus az ilyen képeket a Oracle RDBMS keresztül rollback szegmensek (rollback szegmensek vagy visszavonás szegmensek), ahol a régi változat a adatok vannak tárolva. Abban az esetben, ha otchetet próbál olvasni a módosított adatokat a többi felhasználó hivatali ideje alatt, a régi verziót az adatok elején a jelentés olvasható a rollback szegmensek. Az Oracle nem biztosítja az adatok korábbi adatainak garantált leolvasását, mivel a többi felhasználó visszagörgetési szegmensbe teszi őket. Abban az esetben, cefrézés régebbi verziói adatok rollback szegmens, a felhasználó a jelentés futtatásakor, egy hibaüzenet „ORA-1555 Snapshot túl öreg, rollback szegmens túl kicsi”. Minél hosszabb a jelentés, annál valószínűbb, hogy felülírja az adatok régi verzióit. A FORCE-ben kifejlesztett GRC rendszer célja a régi adatok verziójának tárolása a jelentés időtartamára.
Az Oracle konzisztenciát biztosít az operátori és az ügyleti szinten.
Összhang az üzemeltető szintjén.
Az SQL nyelv kiválasztása mindig konzisztens adatokat olvas. Ez azt jelenti, hogy ha egy adott pontban a kijelölt utasítás leolvassa a táblázat egy sorát, és egy idő után ugyanazt a sort olvasja, az Oracle ugyanazt az információt vagy az ORA-1555 hibát kiadja.
Következetesség a tranzakciós szinten.
Az Oracle a következő tranzakciós típusokat támogatja:
- Olyan tranzakció, amely a mûködés során más tranzakciók által elért adatokat olvas. A felhasználó kifejezetten ilyen tranzakciót indíthat a meghatározott tranzakciós tranzakció olvasott írásbeli utasítás használatával. Az alapértelmezett tranzakció (a munkamenet kezdetétől az első commit / rollback parancshoz a commit / rollback-tól a következő commit / rollback-ig vagy a munkamenet végéig) egy ilyen típusú tranzakció. Mielőtt minden tranzakció megkezdődik, alapértelmezés szerint a beállított tranzakciós tranzakció olvasható írási utasítás implicit módon végrehajtásra kerül. Ha az ilyen típusú tranzakciók különböző részeiben lévő két kijelölési utasítás az adatbázis táblában található ugyanazon sorokra utal, akkor különböző (ütköző) eredmények érhetők el. Egy ellentmondás merül fel, ha bármelyik felhasználó módosítja és javítja a változásokat ezekre a sorokra a fenti két kijelölés közötti időintervallumban. Vagyis egy tranzakció keretében más felhasználók által módosított és elkövetett adatok is olvashatók. Meg kell jegyezni, hogy az ORA-1555 hiba előfordulása akkor lehetséges, ha az Oracle nem tud konzisztenciát biztosítani a kiválasztott szintre. amely szerepel ebben a tranzakcióban.
- A tranzakció "csak olvasható". A felhasználó elindíthatja az ilyen tranzakciót a beállított tranzakciós tranzakcióval, csak olvasható operátorral és befejezheti a commit / rollback utasítással. Egy ilyen tranzakció során csak a kijelölt állításokat használhatja. DML nyilatkozatok nem engedélyezettek. Amikor a kiválasztott operátorok a tranzakció különböző részeit ugyanazon adatvonalakra hívják, az Oracle a tranzakció megkezdésének időpontjában (csak a tranzakció csak olvasható) vagy az ORA-1555 hiba esetén ugyanazt a következetes adatokat adja ki, mint az adatbázisban.
- Serializálható tranzakció. Ez a tranzakció a tranzakciós tranzakció elkülönítési szintjével kezdődik. Az ilyen tranzakciók úgy vannak megtervezve, hogy sorozatosan frissítsék a frissítéseket, ha több felhasználó verseng ugyanezekkel az adatokkal. A különböző felhasználók által egyidejűleg kibocsátott tranzakciók segítségével az adatok adatbázisban történő módosításának eredménye olyan, mintha a megrendelést megfigyelték volna, azaz először egy felhasználó elkezdte és befejezte a tranzakciót, miután a második tranzakciót végrehajtotta, majd a harmadik, stb. Általánosságban elmondható, hogy a tranzakciók sorozatos lebonyolítása nagyon bonyolult, és nem mindig lehetséges a több felhasználó által egyidejűleg végzett tranzakciók sorba állítása. Ne feledje, hogy ha a táblázatban vagy táblában lévő rekordot csak egy felhasználó tartja fenn, akkor a szerializálás szükségessége megszűnik. A sorszámozható tranzakciók mindig következetesek, vagyis az összes minta megkapja az adatbázis "pillanatfelvétel" adatait a beállított tranzakciós elkülönítési szint időzítésével. Feltéve, hogy a rekordot csak a felhasználói munkalapok tartalmazzák, a sorozatos tranzakciókat kezelheti: csak olvasható tranzakciók DML-nyilatkozatok kiadásával (beillesztés, törlés és frissítés). Ez akkor hasznos, ha a komplex jelentés megszerzésére szolgáló program menti a közbenső munkalapokat, ahonnan a jelentés nyomtatódik.
A visszagörgetési szegmensek mechanizmusa
A visszagörgetési szegmens létrehozásakor a még üres kiterjedésű bányászkészletek kerülnek hozzárendelésre, az első Oracle blokk, amely az első szintre van fenntartva a tranzakciós táblához vagy a visszaforgatási szegmens címsorához. Azt fogjuk mondani, hogy a visszahúzó esemény feje és farka az első fokozat második blokkjának elején van a fejléc után (lásd az 1. ábrát). Amikor egy tranzakciót hozzárendel a visszagörgetési szegmenshez, a visszahúzási adatokat a második blokk kezdetétől kell rögzíteni, és minden egyes aktív tranzakciónak van egy fejjel és egy farka a visszagörgetési szegmensben. Amikor módosítja az adatátvitelt és kitölti a visszagörgetési szegmenst, a tranzakciófej előre lép, és töltse ki az első és esetleg a következő kiterjedésű blokkokat. Az ügylet farka egybeesik a visszahúzó szegmens farával (lásd a 2. ábrát). Láthatja, hogy hol található a visszagörgetési szegmens fejrésze a Curext és a Curblk oszlopokban a V $ ROLLSTAT oszlopban lévő mértékig és blokkban (az első mérték a 0-as szám).
Miután a tranzakciót a commit utasítás követi, a visszahúzó szegmens farkája a fej felé mozog (lásd a 3. ábrát). Itt a fej és a farok mutatják a következő farok blokk tranzakció első bájtját. Az e szegmenshez rendelt következő tranzakcióból származó visszavezetési információkat a blokkok blokkjaiban helyezik el, a szegmens fejét és az ügyleteket az óramutató járásával megegyező irányban továbbítják. A tranzakció lezajlása után az 1. és 2. bővítményben rögzített visszavezetési információ "inaktív" lesz, és felhasználható az adatok korábbi verzióinak lekérésére, azaz az egységesség biztosítására.
Az információ rögzítésekor egy hosszú tranzakció a visszavonási szegmens fejét mozgatja. Amikor a mérték meg van töltve, a fej átmegy a következő fokozatra, majd a következő mértékre, és így tovább - egy körben. Azt mondják, hogy a visszahúzó szegmensek gyűrűszerkezete (kígyó). Ez azt jelenti, hogy a negyedik fokozat kitöltése után a felvétel folytatódik az első vagy a. ami ugyanaz, a fej az első fokig mozog. Fontos szabályt figyeltünk meg: a visszahúzó szegmens farka soha nem mozoghat olyan mértékben, ahol a fej található. Így, ha a fej rollback szegmens van a mértékben a 4., az utolsó blokk megtelt (farok végére kerül mértékben), és hogy továbbra is a tranzakció további mozgása a farok igényel óramutató járásával megegyező irányban, a rollback szegmens ötödik mértékben hozzá (kígyó feszített), és a fej az első blokkjára lép (4. ábra). A kiterjesztések száma az adatbázis indítása óta naplózott a V $ ROLLSTAT nézet Kiterjesztések oszlopában.
Ha több tranzakció egyszerre ír vissza egy szegmensre visszavezetési információt, akkor a szegmens farka megegyezik az aktív tranzakció első visszahúzásának farka és a szegmens fej
Abban az esetben vettük figyelembe az esetet, amikor a bővítmények hozzáadódnak a visszaforgatási szegmensekhez. Most tekintsük át a kiterjesztett mechanizmusokat (a kígyó összezsugorodik) a visszahúzó szegmensekről. Mindenki tudja, hogy a kiterjesztések eltávolíthatók (visszatérés a szabad FET $ listához) kétféleképpen: az operátor megváltoztatása visszavezetési szegmensének kiadásával ... automatikusan csökken, és automatikusan megadja a rejtjelezési szegmens létrehozásakor vagy módosításakor a kifejezés kifejezés optimális szóját. Az első módszer, bár több "buktatós", általában nem okoz problémát. De a második út még mindig okozza. A szokásos kérdés az ilyen esetekben: "És miért állt vissza a visszagörgetési szegmens 20 megabájtra, és nem akar zsugorodni, pedig optimálisan 5 megabájtra van állítva?". A lényeg az, hogy elindítjuk a kiterjesztések visszavonási szegmensből történő eltávolításának eljárását, ezért létre kell hozni egy konkrét eseményt, nevezetesen az optimális ellenőrzést és a kiterjesztések végrehajtását, amikor a szegmensfej a következő fokozatra mozog. Így a visszagörgetési szegmens nem szűnik meg azonnal a tranzakció után, amely a visszagörgetési szegmens bővítését eredményezte. A tömörítés akkor jelentkezik, amikor a visszaforgatási szegmenshez rendelt egyéb tranzakciók a jelenlegi mértékig a végéig teljesítik. Az adatbázis kezdete óta a tömörítés száma a V $ ROLLSTAT nézet Shrink oszlopában kerül naplózásra.
Most vegye figyelembe az egyik problémát, a tranzakciók zárolásának problémáját. amely egy többfelhasználós rendszer rendszergazdáján fordulhat elő. Tegyük fel, hogy bármely szabálytalan felhasználó vagy operátor megkezdte a tranzakciót (például beillesztett egy sorot bármelyik táblázatban), nem töltötte be a követelés használatával, és hosszú ideje maradt a saját vállalkozásán. A tranzakcióhoz tartozó visszavezetési információk egy visszagörgetési szegmensben kerülnek rögzítésre, vagyis a szegmensfej egy kis távolságot mozgatott, és a tranzakció aktív maradt. A tranzakció farka a fej mellett van, valószínűleg ugyanabban a blokkban. A tranzakciót elhagyó felhasználó maradt, és sok más felhasználó továbbra is módosítja az adatokat. A különböző tranzakciókból származó visszavezetési információk az operációs visszagörgetési szegmensek között kerülnek rögzítésre, beleértve azt is, ahol a távollévő felhasználó tranzakcióját hozzárendelték. Ennek a szegmensnek a feje tovább halad az óramutató járásával megegyező irányba, és megközelíti azt a mértéket, amelyben a távolt felhasználó aktív tranzakciójának farka található. Ekkor az aktív blokkoló tranzakció farka az egész visszaállítási szegmens farkává vált. Mivel a fej nem tud elmozdulni a farok elhelyezkedésének mértékéig, új dimenziót ad hozzá, és a fej mozog rajta. Ezután egy másik, stb. annak ellenére, hogy minden méretű blokk inaktív a fej és a farok között (minden tranzakciót elkötelezettek tettek). Ez a visszavonási szegmensek táblaterületének túlcsordulásához vezethet. Ezért az erkölcs - az adminisztrátornak ki kell alakítania a fegyelmezetlen felhasználók felvételére szolgáló rendszert, például használjon idõt a profilban. bár ez nem mindig lehetséges. Annak megállapításához, hogy mely felhasználók blokkolják a visszagörgetési szegmenseket, a következő parancsfájlt futtathatja:
Minél nagyobb a szegmensben a bővítmények száma, annál kevésbé valószínű, hogy növelik a visszagörgetési szegmenset. Ebből a szempontból a húzó húsz kis kiterjedés jobb, mint két nagy kiterjedés, amelyek ugyanazon a helyen foglalnak helyet.
Most egy kicsit arról a mechanizmusról, amely támogatja az adatok következetességét. Miután a visszahúzó szegmens fejét teljes forradalom fejezi be, az inaktív tranzakciókból származó visszaállítási információkat felülírják az újakkal. Az ilyen felülírások (teljes fordulatszámok) a DBMS indításának kezdete óta a V $ ROLLSTAT nézet Wraps oszlopában jelennek meg. Így elméletileg lehetséges, hogy minden visszaforgatási szegmens olyan nagy legyen, hogy az aktuális tranzakciók nem eredményezik az összes visszacsapó szegmens fejét, hogy a teljes forgalmat egy elfogadható munkaidőre, például több órára teljesítsék. De gyakorlatilag ez nem lehetséges számos nyilvánvaló okból, a legfontosabb, hogy lehetetlen előre megjósolni az adatbázisfrissítések mennyiségét más tranzakciókkal. Így lehetetlen biztosítani a leolvasások garantált következetességét, azaz az ORA-1555 hiba garantált hiányát, például egy hosszú jelentés (csak olvasható tranzakció) esetén, ami jelentősen rontja a funkcionalitást. De szerencsére garantálhatod az olvasás konzisztenciáját. Ehhez csak akkor kell mesterségesen blokkolni minden műveleti visszaforgatási szegmenst rövid tranzakciókkal, mielőtt a jelentés elindul és feloldásra kerül, vagyis végrehajtja a tranzakciókat a végrehajtás után. Ezért több rekordot is megnyithat a visszagörgetési szegmensek számához, mindegyikben letiltja a visszagörgetési szegmenst egy rövid tranzakcióval, a beállított tranzakcióhasználat visszagörgetési szegmens üzemeltetőjével és futtatja a jelentést. Ebben az esetben a munkamódosítások hibaüzenetet kaphatnak az Oracle-ból, mert a blokkolt visszagörgetési szegmens bővítése nem lehetséges, de a jelentési munkamenet soha nem fogja megkapni az ORA-1555-öt.
1. Néha az orosz nyelvű irodalomban az adatbázisok esetében a konzisztencia fogalmát "integritásként" fordítják, amely véleményem szerint helytelen, mivel az "integritás" orosz szó az angol "integritás" szó fordítására fenntartott.
2. Feltételezzük, hogy a leolvasások közötti időintervallumon belül ez a sor módosítható más felhasználók által, ha a zárolást többször is elvégzik.
3. Az SQL szabványban az ilyen típusú tranzakciók neve: read committed. Az Oracle 8.1.5-től kezdődően a beállított tranzakciós tranzakció olvasható írási utasításának szinonimája van - a tranzakciós tranzakció elkülönítési szintjének elolvasása kötelező.
4. Az Oracle 8.1.5 verziójával kezdődően különféle munkatáblákat alkalmaznak, amelyek a felhasználó munkamenetében vagy tranzakcióin belül működnek, amivel a DML műveletek sokkal gyorsabbak, mint a rendszeres táblák, mivel a naplók frissítéseinek rekordja (redo naplók) blokkolva van. Ez azt is eredményezi, hogy a lemez memóriát a redo naplókban mentettük.
5. Állatok, amelyeket el kell képzelni, amikor a "fej" és a "farok" kifejezést használják - egy kígyó. A kígyó hajlamos felhúzni és harapni a farkát. A kígyó gumi, nyúlik és összehúzódik.
6. A kiterjesztések számozása nem sok értelemben van, és itt csak az egyértelműség érdekében van megadva. A visszagörgetési szegmens összes kiterjedésénél csak a mértéke van különleges státusszal, amelynek első blokkjában a tranzakciós táblázat található. Ennek a mértéknek a száma a DBA_EXTENTS nézetben 0, és nem távolítható el a visszaforgatási szegmensből
7. A kígyó csípte a farkát és megnyugodott.
8. Valójában a valóság bonyolultabb, mint az általam írt leírás, mivel az elkövetett tranzakciókról szóló információ felülírható egy új tranzakcióval a tranzakciós táblában, de szerencsére az Oracle meg tudja ezt érteni.