Számítógépes dokumentáció
Oracle visszaforgatási szegmensek
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).
- A következetesség biztosítása az adatbázisból (olvasható konzisztencia) [1. megjegyzés].
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 a farok fogalma. véleményem szerint jobban segít megérteni a visszatérési 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
Az olvasások konzisztenciája összefüggésbe hozható? Fagyasztás? adatokat a DBMS-ben bármikor, és a felhasználó kap egy jelentést ezen adatokról. 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 (különben az adatok drasztikusan csökken a versenyképesség), így a tartalma az adatbázis folyamatosan változik is? Fagyasztott? Az adatok az adatbázis pillanatfelvétele egy bizonyos időpontban. Az ilyen pillanatfelvételek mechanizmusa az Oracle DBMS-ben rollback szegmensek (undo szegmensek) révén valósul meg, amelyek tárolják az adatok régi adatait. 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 bizonyos ponton a kiválasztott operátor leolvassa a táblázat egy sorát, és egy idő után ismét ugyanazt a sort olvassa (2. Megjegyzés). akkor az Oracle ugyanazokat az információkat 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űvelet során más tranzakciók által elért adatokat olvassa el. A felhasználó kifejezetten ilyen tranzakciót indíthat a meghatározott tranzakció-tranzakció olvasott írás utasítással. 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 meg lehet olvasni más felhasználók által módosított és elkövetett adatokat [3. megjegyzés]. Megjegyzendő, hogy az ORA-1555 hiba előfordulása akkor lehetséges, ha az Oracle nem tud konzisztenciát biztosítani a kijelölt utasítás szintjén. 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. Rátérve szereplők kiválasztásához különböző részein a tranzakció ugyanazokat az adatokat vonalak Oracle biztosítja akár ugyanazon konzisztens adatok, amelyek az adatbázisban jelen, amikor a tranzakció kezdődött (set tranzakció csak olvasható), vagy hiba ORA-1555.
- 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. Ezekkel ügyletek ugyanakkor által kibocsátott különböző felhasználók, a módosítás következtében az adatokat az adatbázis, mint ha a megfigyelt szekvencia, azaz először egy felhasználó megkezdi és befejezi a tranzakciót, miután megtartotta második tranzakció, akkor 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 sorozatképesíthető tranzakciók mindig következetesek, azaz minden minta megkapja az adatokat a? Snapshot-ból? bázis, amelyet az operátor-készlet kiadásának idején hoztak létre, a tranzakcióelkülönítési szint sorozatozható. Feltéve, hogy a felvétel csak a munkaasztal a felhasználó, lehet kezelni serializable tranzakciók: tranzakciók mind a csak olvasható (read only) a kimeneti DML utasítások (beszúrás, törlés és frissítés). Ez akkor megfelelő, ha a komplex jelentés megszerzésére szolgáló program megőrzi az eredményeket a köztes munkalapokon [4. megjegyzés]. 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 mondjuk, hogy a fej és a farok [prim.5] rollback szegmens elején a második blokk első mértékben után azonnal a fejléc (lásd. Ábra. 1). 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ásd, ahol a fej visszaszorítás szegmensek legfeljebb a lehetséges mértékben és az egység az V. táblázat $ ROLLSTAT oszlopokban és Curext Curblk rendre (első mértékben száma 0).
Miután a tranzakciót az elkövetési utasítás követi, a visszahúzó szegmens farkája a fejre kerül (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ók a blokkok blokkjába kerülnek, a szegmens fejét és a tranzakciókat az óramutató járásával megegyező irányban továbbítják. Miután a tranzakciót elkövették, az 1-es és 2-es kiterjesztésű regisztrációs adatok "inaktívak"? és felhasználható az adatok korábbi verzióinak lekérésére, vagyis a következetessé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. amely ugyanaz, a fej az első fokig mozog (6. megjegyzés). 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 a szegmensre, akkor a szegmens farka megegyezik a visszagörgetési szegmenshez rendelt első aktív roll tranzakció és a szegmens fej farkájával. az aktív tranzakció utolsó regisztrált visszaállítási információjának fejével. Mivel a tranzakciókat az üzemeltető követi, a visszahúzó szegmens farka megpróbálja felzárkózni a fejjel. Ha minden tranzakció fix, és nincs aktív tranzakció ebben a visszagörgetési szegmensben, akkor a szegmens farka megegyezik a fejével [7. megjegyzés] (3. ábra). A mértéket több tranzakcióból származó visszavezetési információk írására használják, de minden egyes blokk blokkolja az információkat egyetlen tranzakcióból.
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éle módon: az operátor megváltoztatása visszaforgatásával. zsugorodik és automatikusan meghatározza az optimális tárolási kifejezést a visszagörgetési szegmens létrehozásakor vagy módosításakor. Az első módszer, bár számos "zátony" van. általában nem okoz kérdéseket. De a második út még mindig okozza. Ezekben az esetekben gyakori kérdés. És miért húzódott vissza a visszagörgetési szegmens 20 megabájtra, és nem akar zsugorodni, bár az optimális beállítás 5 megabájtos. 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 egy adott felhasználó vagy üzemeltető fegyelmezetlen kezdett a tranzakció lebonyolítására (például bevezetett bármely táblázatban) nem fejezték be a elkövetni üzemeltető, és elment a dolgát sokáig. A tranzakcióhoz tartozó visszavezetési információk bizonyos visszagörgetési szegmensben kerülnek rögzítésre, vagyis a szegmensfej bizonyos távolságot fejlesztett ki, é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 mozogni olyan mértékben, amely a farok, akkor hozzáad egy új mértékben, és a fej mozog vele. 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 olyan rendszert kell kialakítania, amely a fegyelmezetlen felhasználók felvételére szolgál, pl. 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 lévő szegmensek száma, annál kevésbé valószínű, hogy növelik a visszaforgatá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 az adatok konzisztenciáját támogató mechanizmusról. 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őt elérjék, mondjuk néhány órára. De gyakorlatilag lehetetlen ezt több nyilvánvaló okból is elvégezni, amelyek közül a legfontosabb. Nem lehet előzetesen 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 [8. megjegyzés] és feloldható, vagyis végrehajtja a tranzakciókat. 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 adatbázisok orosz nyelvű irodalmában a konzisztencia fogalmát "integritás" -ként fordítják le. ami véleményem szerint téves, mert az orosz szó? integritás? az angol szót "integritás" fordítására fenntartották.
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ása szinonimája. állítsa be az ügyletet.
4. By the way, verziótól kezdődően Oracle 8.1.5 szerver végrehajtott speciális munka asztalok, dolgozik egy munkamenet vagy ügylet felhasználó, ami DML műveleteket hajtanak végre sokkal gyorsabb, mint a hagyományos táblák, mert frissíti a rekordot a naplók (újra naplók) blokkolva van. Ez azt is eredményezi, hogy a lemez memóriát a redo naplókban mentettük.
5. Az állat, amelyet elképzelni kell, ha a kifejezést használja? és "farok"? - a 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 lehet eltávolítani 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.