az Oracle különböző módszereket kínál az adatblokkok sérülésének észlelésére és kijavítására. Az egyik módszer az objektum eldobása és újbóli létrehozása a korrupció észlelése után; ez azonban nem mindig lehetséges vagy kívánatos. Ha az adatblokk sérülése a sorok egy részhalmazára korlátozódik, egy másik lehetőség a táblázat újjáépítése az összes adat kiválasztásával, kivéve a sérült sorokat.
az adatblokkok sérülésének másik módja a DBMS_REPAIR csomag használata. A dbms_repair segítségével felismerheti és javíthatja a sérült blokkokat a táblákban és indexekben. Ezzel a megközelítéssel lehetőség szerint kezelheti a korrupciót, és folytathatja az objektumok használatát, miközben megpróbálja újjáépíteni vagy javítani őket. A dbms_repair a következő megközelítést használja a korrupciók kezelésére:
- 1. lépés: a korrupciók észlelése és jelentése
- 2. lépés: értékelje a Dbms_repair
- 3. lépés: az objektumok használhatóvá tétele
- 4. lépés: javítsa meg a korrupciót és újraépítse az elveszett adatokat
Megjegyzés:
minden adatvesztéssel járó sérülés megköveteli annak elemzését és megértését, hogy ezek az adatok hogyan illeszkednek a teljes adatbázisrendszerbe. Ezért a DBMS_REPAIR nem varázspálca-továbbra is meg kell határoznia, hogy a csomag által biztosított javítási megközelítés a megfelelő eszköz-e minden egyes korrupciós problémához. A javítás jellegétől függően elveszítheti az adatokat és logikai következetlenségeket vezethet be; ezért mérlegelnie kell a dbms_repair használatával kapcsolatos nyereségeket és veszteségeket.
DBMS_REPAIR csomag tartalma
a 19-1.táblázat a DBMS_REPAIR csomagot alkotó eljárásokat ismerteti.
táblázat 19-1 DBMS_JAVÍTÁSI eljárások
| eljárás neve | leírás |
|---|---|
|
|
egy táblázatban vagy indexben lévő korrupciót észlel és jelent. |
|
|
a blokkokat (amelyeket korábban a |
|
|
jelentések index bejegyzéseket, hogy pont a sorok sérült adatblokkok. |
|
|
újjáépíti egy objektum freelists. |
|
|
használat esetén figyelmen kívül hagyja a tábla-és indexvizsgálatok során korruptnak jelölt blokkokat. Ha nem használja, akkor az ORA-1578 hibát kapja, amikor sérült blokkokkal találkozik. |
|
|
adminisztrációs funkciókat (create, drop, purge) biztosít a DBMS_REPAIR javítási és árva kulcstáblákhoz. Megjegyzés: Ezek a táblák mindig a SYS sémában jönnek létre. |
1. lépés: Detect and reporting Corruptions
a DBMS_REPAIR használata előtt az első feladat a korrupciók észlelése és jelentése. A jelentés nem csak azt jelzi, hogy mi a baj egy blokkkal, hanem azonosítja a kapcsolódó javítási irányelvet is. A dbms_repair mellett számos lehetősége van a korrupciók felderítésére. A 19-2. táblázat ismerteti a különböző kimutatási módszereket.
19-2. táblázat korrupció észlelési módszerek összehasonlítása
| kimutatási módszer | leírás |
|---|---|
|
DBMS_REPAIR |
Blokkellenőrzést végez egy megadott tábla, partíció vagy index esetében. feltölti a javítási táblázatot az eredményekkel. |
|
DB_VERIFY |
külső parancssori segédprogram, amely blokkellenőrzést végez egy offline adatbázisban. |
|
elemzés |
a szerkezet érvényesítése beállítással ellenőrizhető egy index, tábla vagy fürt szerkezetének integritása; ellenőrzi vagy ellenőrzi, hogy a táblák és indexek szinkronban vannak-e. |
|
DB_BLOCK_CHECKING |
azonosítja a sérült blokkokat, mielőtt ténylegesen korruptnak lennének jelölve. Az ellenőrzéseket akkor hajtják végre, amikor egy blokkot módosítanak. |
DBMS_REPAIR: a check_object és admin_tables eljárások használata
a check_object eljárás ellenőrzések és jelentések blokk korrupciók egy adott objektumhoz. Hasonló az elemzéshez…VALIDATE STRUCTURE utasítás indexekhez és táblázatokhoz, blokk ellenőrzés az index és az adatblokkok esetében történik. A
nem csak a check_object jelenti a korrupciót, hanem azonosítja azokat a javításokat is, amelyek akkor fordulnak elő, ha a fix_corrupt_blocks később fut az objektumon. Ez az információ egy javítási táblázat feltöltésével érhető el, amelyet először a admin_tables eljárással kell létrehozni.
a check_object eljárás futtatása után a javítási táblázatban egy egyszerű lekérdezés mutatja az objektum sérüléseit és javítási irányelveit. Ezzel az információval felmérheti, hogyan lehet a legjobban kezelni a jelentett problémákat.
DB_VERIFY: Offline adatbázis-ellenőrzés végrehajtása
általában a DB_VERIFY-t offline diagnosztikai segédprogramként használja adatsérülési problémák esetén.
Lásd Még: További információ a DB_VERIFY, lásd Oracle8i Utilities.
elemzés: korrupciós jelentés
az elemzési táblázat…VALIDATE STRUCTURE utasítás érvényesíti az elemzett objektum szerkezetét. Ha az Oracle sikeresen érvényesíti a struktúrát, egy üzenet, amely megerősíti annak érvényesítését, visszatér Önnek. Ha az Oracle sérülést észlel az objektum szerkezetében, hibaüzenet jelenik meg. Ebben az esetben eldobja és újra létrehozza az objektumot.
Lásd még: az ANALYZE utasítással kapcsolatos további információkért lásd az Oracle8i SQL hivatkozást.
DB_BLOCK_CHECKING (Blokkellenőrzés inicializálási paraméter)
a blokkok blokkellenőrzését a db_block_checking paraméterrel állíthatja be (az alapértelmezett érték TRUE); Ez ellenőrzi az adatokat és az index blokkokat, amikor módosítják őket. A DB_BLOCK_CHECKING egy dinamikus paraméter, amelyet az ALTER SYSTEM SET utasítás módosíthat.
2. lépés: értékelje a Dbms_repair használatának költségeit és előnyeit
a DBMS_REPAIR használata előtt mérlegelnie kell a használat előnyeit a kötelezettségekhez viszonyítva; meg kell vizsgálnia a sérült objektumok kezelésére rendelkezésre álló egyéb lehetőségeket is.
az első lépés a következő kérdések megválaszolása:
- milyen mértékű a korrupció?
annak megállapításához, hogy vannak-e Korrupciós és javítási műveletek, hajtsa végre a
check_objecteljárást, és kérdezze meg a javítási táblázatot. - milyen egyéb lehetőségek állnak rendelkezésre a blokkkorrupciók kezelésére?
feltételezve, hogy az adatok más forrásból érhetők el, dobja el, hozza létre újra és töltse fel újra az objektumot. Egy másik lehetőség a CREATE tábla kiadása…Mint SELECT nyilatkozatot a korrupt tábla, hogy hozzon létre egy újat.
a korrupciót figyelmen kívül hagyhatja, ha kizárja a sérült sorokat a select utasításokból.
végezze el a Média helyreállítását.
- milyen logikai korrupciók vagy mellékhatások kerülnek bevezetésre, amikor a dbms_repair segítségével használhatóvá tesz egy objektumot? Lehet ezeket kezelni? Milyen erőfeszítésre van szükség ehhez?
lehet, hogy nincs hozzáférése a korrupt jelölésű blokkok soraihoz. Előfordulhat azonban, hogy egy blokk sérült, annak ellenére, hogy még mindig vannak olyan sorok, amelyekhez érvényesen hozzáférhet.
a hivatkozási integritási korlátozások megszakadhatnak, ha a blokkok sérültek. Ha ez megtörténik, tiltsa le és engedélyezze újra a korlátozást; az esetleges következetlenségeket jelenteni kell. Az összes probléma kijavítása után képesnek kell lennie a kényszer sikeres újbóli engedélyezésére.
logikai sérülés fordulhat elő, ha vannak triggerek az asztalon. Például, ha a sorokat újra beillesztik, be kell-e illeszteni a triggereket, vagy sem? Ezeket a problémákat csak akkor kezelheti, ha megérti a kiváltó okokat és azok használatát a telepítésben.
a Freelist blokkok nem érhetők el. Ha egy korrupt blokk van a freelist fején vagy farkán, az űrkezelés újra inicializálja a freelist. Lehet, hogy vannak olyan blokkok, amelyeknek szabadúszónak kell lenniük, de nem. ezt a
rebuild_freelistseljárás futtatásával kezelheti.az indexek és táblák nem lehetnek szinkronban. Ezt úgy oldhatja meg, hogy először végrehajtja a
dump_orphan_keyseljárást (hogy információkat szerezzen a kulcsokból, amelyek hasznosak lehetnek a sérült adatok újjáépítésében). Ezután adja ki az ALTER INDEX REBUILD online utasítást, hogy a táblázat és indexei szinkronban legyenek. - ha a javítás adatvesztéssel jár, visszakereshetők ezek az adatok?
adatokat lehet letölteni az indexből, ha egy adatblokk korruptnak van jelölve. Az
dump_orphan_keyseljárások segíthetnek ezen információk lekérésében. Természetesen az adatok ilyen módon történő lekérése az indexek és a táblázat közötti redundancia mértékétől függ.
3. lépés: objektumok használhatóvá tétele
ebben a lépésben a DBMS_REPAIR használhatóvá teszi az objektumot azáltal, hogy figyelmen kívül hagyja a tábla-és indexvizsgálatok során bekövetkező korrupciót.
Korrupciós Javítás: A fix_corrupt_blocks és skip_corrupt_blocks eljárásokkal
egy sérült objektumot használhatóvá tesz egy olyan környezet létrehozásával, amely kihagyja a dbms_repair javítási képességein kívül eső korrupciót.
ha a korrupciók adatvesztéssel járnak, például egy adatblokk rossz sora, akkor az összes ilyen blokkot a fix_corrupt_blocks eljárás korruptnak jelöli. Ezután futtathatja a skip_corrupt_blocks eljárást, amely kihagyja az objektum korrupt jelölésű blokkjait. Ha az átugrás be van állítva, a táblázat-és indexvizsgálatok átugorják az összes korrupt jelölésű blokkot. Ez vonatkozik mind a média, mind a Szoftver sérült blokkjaira.
következmények a sérült blokkok Kihagyásakor
ha egy index és egy tábla nincs szinkronban, akkor a SET tranzakció csak olvasható tranzakció inkonzisztens lehet olyan helyzetekben, amikor egy lekérdezés csak az indexet vizsgálja, majd egy következő lekérdezés mind az indexet, mind a táblát vizsgálja. Ha a tábla blokkja sérült, akkor a két lekérdezés eltérő eredményeket ad vissza, ezáltal megsérti a csak olvasható tranzakció szabályait. Ennek egyik módja az, hogy ne hagyja ki a korrupciót, ha egy meghatározott tranzakcióban csak olvasható tranzakció van.
hasonló probléma lép fel a láncolt sorok kiválasztásakor. Lényegében ugyanannak a sornak a lekérdezése elérheti vagy nem érheti el a korrupciót-ezáltal eltérő eredményeket ad.
4.lépés: a sérült adatok javítása és az elveszett adatok újraépítése
miután egy objektumot használhatóvá tett, a következő javítási tevékenységeket hajthatja végre.
adatok helyreállítása a dump_orphan_keys eljárások segítségével
a dump_orphan_keys eljárás jelentések a sérült adatblokkok soraira mutató indexbejegyzésekről. Az összes ilyen indexbejegyzés egy árva kulcstáblába kerül, amely a korrupció kulcsát és rowid-ját tárolja.
az indexbejegyzési információk beolvasása után újraépítheti az indexet az Alter INDEX REBUILD ONLINE utasítás segítségével.
javítás Freelists segítségével rebuild_freelists eljárás
ha egy blokk jelölt “korrupt” található a fej vagy farok egy freelist, a freelist újra inicializáljuk, és egy hiba kerül vissza. Bár ez elveszi a jogsértő blokkot a freelistától, elveszíti a freelist hozzáférést az összes blokkhoz, amely a korrupt blokkot követte.
használhatja a rebuild_freelists eljárást a freelisták újraindításához. Az objektum beolvasásra kerül, és ha helyénvaló, hogy egy blokk a freelist-en legyen, akkor hozzáadódik a master freelist-hez. Freelist csoportok kezelik meting ki a blokkokat méltányos módon-egy blokk egy időben. Az objektumban “korrupt” jelzéssel ellátott blokkokat az újjáépítés során figyelmen kívül hagyják.
korlátozások és korlátozások
DBMS_REPAIR eljárások a következő korlátozásokkal rendelkeznek:
- a LOB-okat, beágyazott táblákat és VARRÁKAT tartalmazó táblák támogatottak, de a soron kívüli oszlopokat figyelmen kívül hagyják. A
- fürtöket a
skip_corrupt_blocksésrebuild_freelisteljárások támogatják, de acheck_objecteljárás nem. - Index-szervezett táblák és LOB indexek nem támogatottak.
- a
dump_orphan_keyseljárás nem működik bittérképes indexeken vagy függvényalapú indexeken. - az
dump_orphan_keyseljárás legfeljebb 3950 bájt hosszú kulcsokat dolgoz fel.
DBMS_REPAIR eljárások
ez a szakasz a DBMS_REPAIR eljárások részletes leírását tartalmazza.
check_object
a check_object eljárás ellenőrzi a megadott objektumokat, és feltölti a javítási táblázatot a korrupcióval és a javítási irányelvekkel kapcsolatos információkkal. Az érvényesítés Az objektum összes blokkjának blokkellenőrzéséből áll. Opcionálisan megadhat egy tartományt, partíció nevét vagy alrész nevét, amikor ellenőrizni szeretné az objektum egy részét.
procedure check_object(schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT TABLE_OBJECT, repair_table_name IN varchar2 DEFAULT 'REPAIR_TABLE', flags IN binary_integer DEFAULT NULL, relative_fno IN binary_integer DEFAULT NULL, block_start IN binary_integer DEFAULT NULL, block_end IN binary_integer DEFAULT NULL, corrupt_count OUT binary_integer)
19-3. táblázat a check_object eljárás
| argumentum | leírás |
|---|---|
|
|
az ellenőrizendő objektum Sémaneve. |
|
|
az ellenőrizendő táblázat vagy index neve. |
|
|
ellenőrizni kell a partíció vagy alrész nevét. Ha ez egy particionált objektum, és a |
|
|
a feldolgozandó objektum típusa. Legyen TABLE_OBJECT vagy INDEX_OBJECT. Az alapértelmezett a TABLE_OBJECT. |
|
|
a kitöltendő javítási táblázat neve. A táblának léteznie kell a SYS sémában. Használja a |
|
|
későbbi felhasználásra fenntartva. |
|
|
relatív fájlszám. Blokk tartomány megadásakor használatos. |
|
|
az első feldolgozandó blokk, ha blokktartományt ad meg. Csak akkor adható meg, ha az objektum egyetlen tábla, partíció vagy alrész. |
|
|
az utolsó blokk, amelyet feldolgozni kell, ha blokktartományt ad meg. Csak akkor adható meg, ha az objektum egyetlen tábla, partíció vagy alrész. ha csak az egyik block_start vagy block_end van megadva, akkor a másik alapértelmezés szerint az első vagy az utolsó blokk a fájlban. |
|
|
a bejelentett korrupciók száma. |
fix_corrupt_blocks
ezzel az eljárással javíthatja a sérült blokkokat a megadott objektumokban a javítási táblázatban szereplő információk alapján, amelyeket korábban a check_object eljárás generált. Mielőtt bármilyen változtatást végrehajtana egy blokkban, a blokkot ellenőrzik, hogy a blokk továbbra is sérült-e. A sérült blokkokat a blokk szoftver hibás megjelölésével javítják. Javítás végrehajtásakor a javítási táblázat társított sora fix időbélyeggel frissül.
procedure fix_corrupt_blocks( schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT TABLE_OBJECT, repair_table_name IN varchar2 DEFAULT 'REPAIR_TABLE', flags IN boolean DEFAULT NULL, fix_count OUT binary_integer)
19-4. táblázat a fix_corrupt_blocks eljárás
| argumentum | leírás |
|---|---|
|
|
séma neve. |
|
|
az objektum neve sérült blokkokat kell rögzíteni. |
|
|
a feldolgozandó partíció vagy alrész neve. Ha ez egy particionált objektum, és a |
|
|
a feldolgozandó objektum típusa. Legyen TABLE_OBJECT vagy INDEX_OBJECT. Az alapértelmezett a TABLE_OBJECT. |
|
|
a javítási táblázat neve a javítási irányelvekkel. Léteznie kell a SYS sémában. |
|
|
későbbi felhasználásra fenntartva. |
|
|
a rögzített blokkok száma. |
dump_orphan_keys
jelentések az indexbejegyzésekről, amelyek sérült adatblokkok soraira mutatnak. Minden ilyen indexbejegyzésnél egy sor kerül beillesztésre a megadott árva táblába.
ha a javítási táblázat meg van adva, akkor az alaptáblához társított sérült blokkokat a Szoftver sérült jelöléssel ellátott összes adatblokk mellett kezeli. Ellenkező esetben csak azokat a blokkokat kezelik, amelyek korruptnak vannak jelölve.
ez az információ hasznos lehet A táblázat Elveszett sorainak újjáépítéséhez és diagnosztikai célokra.
procedure dump_orphan_keys( schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT INDEX_OBJECT, repair_table_name IN varchar2 DEFAULT 'REPAIR_TABLE', orphan_table_name IN varchar2 DEFAULT 'ORPHAN_KEY_TABLE', key_count OUT binary_integer)
19-5. táblázat a dump_orphan_keys eljárás
| argumentum | leírás |
|---|---|
|
|
séma neve. |
|
|
objektum neve. |
|
|
a feldolgozandó partíció vagy alrész neve. Ha ez egy particionált objektum, és a |
|
|
a feldolgozandó objektum típusa. Az alapértelmezett INDEX_OBJECT. |
|
|
az alaptábla sérült blokkjaival kapcsolatos információkat tartalmazó javítási táblázat neve. A megadott táblának léteznie kell a SYS sémában. A |
|
|
az árva kulcstábla neve, amely minden olyan indexbejegyzéssel kapcsolatos információt tartalmaz, amely egy sérült adatblokk sorára utal. A megadott táblának léteznie kell a SYS sémában. A |
|
|
a feldolgozott indexbejegyzések száma. |
rebuild_freelists
újraépíti a freelists a megadott objektum. Minden szabad blokk kerül a mester freelist. Az összes többi szabadúszó nullázott. Ha az objektumnak több freelist csoportja van, akkor a szabad blokkokat elosztják az összes freelist között, körmérkőzéses módon elosztva a különböző csoportokhoz.
procedure rebuild_freelists( schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT TABLE_OBJECT);
19-6. táblázat a rebuild_freelists eljárás
| argumentum | leírás |
|---|---|
|
|
séma neve. |
|
|
az objektum neve, amelynek freelists kell újjáépíteni. |
|
|
partíció vagy alrész neve, amelynek freelistáit át kell építeni. Ha ez egy particionált objektum, és a |
|
|
a feldolgozandó objektum típusa. Legyen TABLE_OBJECT vagy INDEX_OBJECT. Az alapértelmezett a TABLE_OBJECT. |
skip_corrupt_blocks
engedélyezi vagy letiltja a sérült blokkok kihagyását a megadott objektum index-és táblázatvizsgálata során. Ha az objektum tábla, akkor a skip a táblára és annak indexeire vonatkozik. Ha az objektum fürt, akkor a fürt összes táblájára és a hozzájuk tartozó indexekre vonatkozik.
procedure skip_corrupt_blocks( schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT TABLE_OBJECT, flags IN boolean DEFAULT SKIP_FLAG);
19-7. táblázat a skip_corrupt_blocks eljárás
| argumentum | leírás |
|---|---|
|
|
a feldolgozandó objektum Sémaneve. |
|
|
az objektum neve. |
|
|
a feldolgozandó partíció vagy alrész neve. Ha ez egy particionált objektum, és a |
|
|
a feldolgozandó objektum típusa. Legyen TABLE_OBJECT vagy CLUSTER_OBJECT. Az alapértelmezett a TABLE_OBJECT. |
|
|
ha a SKIP_FLAG meg van adva, bekapcsolja az objektum szoftveres sérült blokkjainak kihagyását az index-és táblázatvizsgálatok során. Ha a NOSKIP_FLAG meg van adva, akkor a szoftveres sérült blokkokat érintő vizsgálatok ora-1578-at adnak vissza. |
admin_tables
felügyeleti funkciókat biztosít javítási és árva kulcstáblákhoz.
procedure admin_tables( table_name IN varchar2, table_type IN binary_integer, action IN binary_integer, tablespace IN varchar2 DEFAULT NULL);
19-8. táblázat az admin_tables eljárás
| argumentum | leírás |
|---|---|
|
|
a feldolgozandó táblázat neve. Alapértelmezés szerint ‘ ORPHAN_KEY_TABLE ‘vagy’ REPAIR_TABLE ‘ a megadott table_type alapján. Ha meg van adva, a tábla nevének rendelkeznie kell a megfelelő előtaggal, ‘ORPHAN_’ vagy ‘REPAIR_’. |
|
|
a táblázat típusa, az ORPHAN_TABLE vagy a REPAIR_TABLE egyikének kell lennie. |
|
|
jelzi, hogy milyen adminisztratív műveletet kell végrehajtani. Kell CREATE_ACTION, PURGE_ACTION, vagy DROP_ACTION. Ha a tábla már létezik, és a CREATE_ACTION meg van adva, akkor a rendszer hibát ad vissza. A PURGE_ACTION azt jelzi, hogy törli a táblázat összes olyan sorát, amely nem létező objektumokhoz van társítva. Ha a táblázat nem létezik, és a DROP_ACTION meg van adva, akkor a rendszer hibát ad vissza. amikor a CREATE_ACTION és a DROP_ACTION meg van adva, egy dba_< table_name> nevű társított nézet jön létre, illetve csökken. A nézet úgy van meghatározva, hogy a nem létező objektumokhoz társított sorok megszűnjenek. létrehozva a SYS sémában. |
|
|
a táblázat létrehozásakor használandó táblaterületet jelzi. Alapértelmezés szerint a SYS alapértelmezett táblaterületét használja. Hiba jelenik meg, ha a táblaterület meg van adva, és a művelet nem CREATE_ACTION. |
Dbms_repair kivételek
| 942 | a javítási táblázat nem létezik |
| 1418 | a megadott index nem létezik |
| 24120 | érvénytelen paraméter |
| 24121 | nem adható meg a CASCADE_FLAG és a blokktartomány |
| 24122 | érvénytelen blokktartomány |
| 24124 | érvénytelen műveletparaméter megadva |
| 24126 | CASCADE_FLAG a megadott és az objektum nem tábla |
| 24127 | tablespace megadott és action nem CREATE_ACTION |
| 24128 | nem particionált objektumhoz megadott partíció |
| 24129 | érvénytelen árva kulcstábla neve – ‘ORPHAN_’ előtaggal kell rendelkeznie |
| 24129 | a megadott javítási táblázat nem a ‘REPAIR_’ előtaggal kezdődik |
| 24131 | a javítási táblázat hibás oszlopokat tartalmaz |
| 24132 | a javítási táblázat neve túl hosszú |