Oracle tillhandahåller olika metoder för att upptäcka och korrigera datablock korruption. En metod är att släppa och återskapa ett objekt efter att korruptionen upptäckts; detta är dock inte alltid möjligt eller önskvärt. Om korruption av datablock är begränsad till en delmängd av rader, är ett annat alternativ att bygga om tabellen genom att välja Alla data utom de korrupta raderna.
ännu ett sätt att hantera datablockkorruption är att använda dbms_repair-paketet. Du kan använda DBMS_REPAIR för att upptäcka och reparera korrupta block i tabeller och index. Med hjälp av detta tillvägagångssätt kan du ta itu med korruptioner där det är möjligt och även fortsätta använda objekt medan du försöker bygga om eller reparera dem. DBMS_REPAIR använder följande tillvägagångssätt för att hantera korruption:
- Steg 1: upptäcka och rapportera korruption
- steg 2: utvärdera kostnader och fördelar med att använda DBMS_REPAIR
- steg 3: Gör objekt Användbara
- steg 4: Reparera korruption och bygga förlorade Data
Obs:
varje korruption som innebär förlust av data kräver analys och förståelse för hur dessa data passar in i det övergripande databassystemet. Därför är DBMS_REPAIR inte en trollstav-du måste fortfarande avgöra om reparationsmetoden som tillhandahålls av detta paket är lämpligt verktyg för varje specifikt korruptionsproblem. Beroende på vilken typ av reparation, kan du förlora data och logiska inkonsekvenser kan införas; därför måste du väga vinster och förluster i samband med att använda DBMS_REPAIR.
Dbms_repair Paketets innehåll
tabell 19-1 beskriver de procedurer som utgör dbms_repair paketet.
tabell 19-1 DBMS_REPARATIONSPROCEDURER
| Procedurnamn | beskrivning |
|---|---|
|
|
upptäcker och rapporterar korruption i en tabell eller ett index. |
|
|
markerar block (som tidigare identifierades av |
|
|
rapporter indexposter som pekar på rader i korrupta datablock. |
|
|
återuppbygger ett objekts freelister. |
|
|
när den används, ignorerar block markerade korrupta under tabell-och indexskanningar. Om det inte används får du fel ORA-1578 när du stöter på block markerade korrupta. |
|
|
ger administrativa funktioner (Skapa, släppa, Rensa) för dbms_repair reparation och föräldralösa nyckeltabeller. OBS!: Dessa tabeller skapas alltid i SYS-schemat. |
Steg 1: Upptäck och rapportera korruption
din första uppgift, innan du använder DBMS_REPAIR, bör vara upptäckt och rapportering av korruption. Rapportering indikerar inte bara vad som är fel med ett block utan identifierar också det tillhörande reparationsdirektivet. Du har flera alternativ, förutom DBMS_REPAIR, för att upptäcka korruption. Tabell 19-2 beskriver de olika detekteringsmetoderna.
tabell 19-2 jämförelse av Korruptionsdetekteringsmetoder
| detekteringsmetod | beskrivning |
|---|---|
|
DBMS_REPAIR |
utför blockkontroll för en viss tabell, partition eller index. fyller en reparationstabell med resultat. |
|
DB_VERIFY |
externt kommandoradsverktyg som utför blockkontroll på en offline-databas. |
|
analysera |
används med alternativet validera struktur, verifierar integriteten för strukturen i ett index, en tabell eller ett kluster; kontrollerar eller verifierar att dina tabeller och index är synkroniserade. |
|
DB_BLOCK_KONTROLLERA |
identifierar korrupta block innan de faktiskt markeras korrupta. Kontroller utförs när ändringar görs i ett block. |
DBMS_REPAIR: använda procedurerna check_object och admin_tables
check_object procedurkontroller och rapporter blockerar korruption för ett angivet objekt. Liknar analysen…Validera struktur uttalande för index och tabeller, är block kontroll utförs för index och datablock respektive.
inte bara rapporterar check_object korruption, men det identifierar också eventuella korrigeringar som skulle uppstå om fix_corrupt_blocks senare körs på objektet. Denna information görs tillgänglig genom att fylla i en reparationstabell, som först måste skapas med admin_tables – proceduren.
när du har kört proceduren check_object visar en enkel fråga i reparationstabellen korruptions-och reparationsdirektiven för objektet. Med denna information kan du bedöma hur du bäst kan hantera de rapporterade problemen.
DB_VERIFY: utför en offline-Databaskontroll
vanligtvis använder du DB_VERIFY som ett diagnostiskt verktyg offline när du stöter på problem med datakorruption.
Se Även: Mer information om Db_verify finns i Oracle8i Utilities.
analysera: Korruptionsrapportering
ANALYSTABELLEN…Validera struktur uttalande validerar strukturen för det analyserade objektet. Om Oracle framgångsrikt validerar strukturen returneras ett meddelande som bekräftar dess validering till dig. Om Oracle stöter på korruption i objektets struktur returneras ett felmeddelande till dig. I det här fallet skulle du släppa och återskapa objektet.
Se även: för mer information om ANALYZE-satsen, se Oracle8i SQL-referensen.
DB_BLOCK_CHECKING (Blockkontroll Initialiseringsparameter)
du kan ställa in blockkontroll för instanser via db_block_checking-parametern (Standardvärdet är sant); detta kontrollerar data och indexblock när de ändras. DB_BLOCK_CHECKING är en dynamisk parameter, modifieras av Alter system SET uttalande.
steg 2: utvärdera kostnader och fördelar med att använda DBMS_REPAIR
innan du använder DBMS_REPAIR måste du väga fördelarna med dess användning i förhållande till skulderna; du bör också undersöka andra tillgängliga alternativ för att hantera korrupta objekt.
ett första steg är att svara på följande frågor:
- vad är omfattningen av korruptionen?
för att avgöra om det finns korruptioner och reparationsåtgärder, kör proceduren
check_objectoch fråga reparationstabellen. - vilka andra alternativ finns tillgängliga för att hantera blockförstöringar?
förutsatt att data är tillgängliga från en annan källa, släpp, återskapa och fylla i objektet igen. Ett annat alternativ är att utfärda tabellen skapa…Som välj uttalande från den korrupta tabellen för att skapa en ny.
du kan ignorera korruptionen genom att utesluta korrupta rader från select-satser.
utför mediaåterställning.
- vilka logiska skador eller biverkningar kommer att introduceras när du använder DBMS_REPAIR för att göra ett objekt användbart? Kan dessa åtgärdas? Vad är den ansträngning som krävs för att göra det?
du kanske inte har tillgång till rader i block markerade korrupta. Ett block kan dock markeras korrupt även om det fortfarande finns rader som du kan få åtkomst till.
referensintegritetsbegränsningar kan brytas när Block markeras korrupta. Om detta inträffar, inaktivera och återaktivera begränsningen; eventuella inkonsekvenser kommer att rapporteras. När du har åtgärdat alla problem bör du kunna aktivera begränsningen igen.
logisk korruption kan uppstå när det finns triggers definierade på bordet. Till exempel, om rader sätts in igen, bör infoga triggers avfyras eller inte? Du kan bara lösa dessa problem om du förstår utlösare och deras användning i din installation.
Freelist block kan vara otillgängliga. Om ett korrupt block är i huvudet eller svansen på en freelist, rymdhantering initierar freelisten igen. Det kan då finnas block som borde vara på en freelist, det är det inte.du kan ta itu med detta genom att köra
rebuild_freelists– proceduren.index och tabeller kan vara synkroniserade. Du kan åtgärda detta genom att först utföra proceduren
dump_orphan_keys(för att få information från nycklarna som kan vara användbara för att återuppbygga skadade data). Utfärda sedan Alter INDEX REBUILD online-uttalandet för att få tabellen och dess index tillbaka synkroniserade. - om reparation innebär förlust av data, kan dessa data hämtas?
du kan hämta data från indexet när ett datablock är markerat korrupt. Procedurerna
dump_orphan_keyskan hjälpa dig att hämta den här informationen. Naturligtvis beror hämtning av data på detta sätt på mängden redundans mellan indexen och tabellen.
steg 3: Gör objekt Användbara
i detta steg gör dbms_repair objektet användbart genom att ignorera korruption under tabell-och indexskanningar.
Reparation Av Korruption: Med hjälp av procedurerna fix_corrupt_blocks och skip_corrupt_blocks
gör du ett korrupt objekt användbart genom att skapa en miljö som hoppar över korruption som förblir utanför omfattningen av dbms_repairs reparationsfunktioner.
om korruption innebär förlust av data, till exempel en dålig rad i ett datablock, markeras alla sådana block med proceduren fix_corrupt_blocks. Sedan kan du köra skip_corrupt_blocks – proceduren, som hoppar över block markerade korrupta för objektet. När skip är inställt hoppar tabell-och indexskanningar över alla block markerade korrupta. Detta gäller både media och programvara korrupta block.
implikationer när du hoppar över korrupta Block
om ett index och en tabell är synkroniserade, kan en uppsättning TRANSAKTIONSLÄSNINGSTRANSAKTION vara inkonsekvent i situationer där en fråga endast sonderar indexet och sedan en efterföljande fråga sonderar både indexet och tabellen. Om tabellblocket är markerat korrupt, kommer de två frågorna att returnera olika resultat och därmed bryta reglerna för en skrivskyddad transaktion. Ett sätt att närma sig detta är att inte hoppa över korruption när du är i en uppsättning TRANSAKTIONSLÄSNINGSTRANSAKTION.
ett liknande problem uppstår när du väljer rader som är kedjade. I huvudsak kan en fråga av samma rad eller inte komma åt korruptionen-vilket ger olika resultat.
steg 4: reparera skador och återuppbygga förlorade Data
när du har gjort ett objekt användbart kan du utföra följande reparationsaktiviteter.
Återställ Data med dump_orphan_keys-procedurerna
dump_orphan_keys – proceduren rapporterar om indexposter som pekar på rader i korrupta datablock. Alla sådana indexposter infogas i en föräldralös nyckeltabell som lagrar korruptionens nyckel och rowid.
när indexpostinformationen har hämtats kan du bygga om indexet med hjälp av Alter INDEX REBUILD online-uttalandet.
reparera Freelists med hjälp av rebuild_freelists förfarande
när ett block märkt” korrupt ” hittas i huvudet eller svansen på en freelist, freelist återinitieras och ett fel returneras. Även om detta tar det kränkande blocket från freelisten, får det dig att förlora freeliståtkomst till alla block som följde det korrupta blocket.
du kan använda proceduren rebuild_freelists för att initiera freelisterna igen. Objektet skannas, och om det är lämpligt för ett block att vara på freelisten, läggs det till master freelisten. Freelistgrupper hanteras genom att mäta ut blocken på ett rättvist sätt-ett block i taget. Alla block markerade ”korrupta” i objektet ignoreras under ombyggnaden.
begränsningar och begränsningar
dbms_repair-procedurer har följande begränsningar:
- tabeller med LOBS, kapslade tabeller och VARRAYS stöds, men kolumnerna utanför raden ignoreras.
- kluster stöds i procedurerna
skip_corrupt_blocksochrebuild_freelist, men inte i procedurencheck_object. - Index – organiserade tabeller och LOB-index stöds inte.
-
dump_orphan_keys-proceduren fungerar inte på bitmappsindex eller funktionsbaserade index. -
dump_orphan_keys– proceduren behandlar nycklar som högst är 3 950 byte långa.
Dbms_repair-procedurer
detta avsnitt innehåller detaljerade beskrivningar av dbms_repair-procedurerna.
check_object
check_object – proceduren kontrollerar de angivna objekten och fyller reparationstabellen med information om korruptioner och reparationsdirektiv. Validering består av att blockera alla block i objektet. Du kan välja att ange ett intervall, partitionsnamn eller underpartitionsnamn när du vill kontrollera en del av ett objekt.
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)
tabell 19-3 proceduren check_object
| Argument | beskrivning |
|---|---|
|
|
schemanamn på objektet som ska kontrolleras. |
|
|
namn på tabellen eller indexet som ska kontrolleras. |
|
|
partitions-eller underpartitionsnamn som ska kontrolleras. Om detta är ett partitionerat objekt och |
|
|
typ av objekt som ska behandlas. Måste vara antingen TABLE_OBJECT eller INDEX_OBJECT. Standardvärdet är TABLE_OBJECT. |
|
|
namn på reparationstabellen som ska fyllas i. Tabellen måste finnas i SYS-schemat. Använd proceduren |
|
|
reserverad för framtida bruk. |
|
|
relativt filnummer. Används när du anger ett blockområde. |
|
|
det första blocket att bearbeta om du anger ett blockområde. Kan anges endast om objektet är en enda tabell, partition eller underpartition. |
|
|
det sista blocket att bearbeta om du anger ett blockområde. Kan anges endast om objektet är en enda tabell, partition eller underpartition. om endast en av block_start eller block_end anges, är den andra standardvärdet det första eller sista blocket i filen. |
|
|
antalet rapporterade korruptioner. |
fix_corrupt_blocks
använd den här proceduren för att åtgärda korrupta block i angivna objekt baserat på information i reparationstabellen som tidigare genererats av check_object – proceduren. Innan du ändrar ett block kontrolleras blocket för att säkerställa att blocket fortfarande är korrupt. Korrupta block repareras genom att markera blockprogramvaran korrupt. När en reparation utförs uppdateras den associerade raden i reparationstabellen med en fix-tidsstämpel.
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)
tabell 19-4 proceduren fix_corrupt_blocks
| Argument | beskrivning |
|---|---|
|
|
Schema namn. |
|
|
namn på objektet med korrupta block som ska åtgärdas. |
|
|
partitions-eller underpartitionsnamn som ska behandlas. Om det här är ett partitionerat objekt och |
|
|
typ av objekt som ska behandlas. Måste vara antingen TABLE_OBJECT eller INDEX_OBJECT. Standardvärdet är TABLE_OBJECT. |
|
|
namn på reparationstabellen med reparationsdirektiven. Måste finnas i SYS-schemat. |
|
|
reserverad för framtida bruk. |
|
|
antalet block fasta. |
dump_orphan_keys
rapporter om indexposter som pekar på rader i korrupta datablock. För varje sådan indexpost som påträffas infogas en rad i den angivna föräldralösa tabellen.
om reparationstabellen anges, hanteras eventuella korrupta block som är associerade med bastabellen utöver alla datablock som är markerade programvara korrupta. Annars hanteras endast block som är markerade korrupta.
denna information kan vara användbar för att återskapa förlorade rader i tabellen och för diagnostiska ändamål.
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)
tabell 19-5 dump_orphan_keys-proceduren
| Argument | beskrivning |
|---|---|
|
|
Schema namn. |
|
|
objektets namn. |
|
|
partitions-eller underpartitionsnamn som ska behandlas. Om det här är ett partitionerat objekt och |
|
|
typ av objekt som ska behandlas. Standardvärdet är INDEX_OBJECT. |
|
|
namn på reparationstabellen som har information om korrupta block i bastabellen. Den angivna tabellen måste finnas i SYS-schemat. Proceduren |
|
|
namn på den anonyma nyckeltabellen för att fylla i information om varje indexpost som refererar till en rad i ett korrupt datablock. Den angivna tabellen måste finnas i SYS-schemat. Proceduren |
|
|
antal indexposter som behandlats. |
rebuild_freelists
bygger om freelisterna för det angivna objektet. Alla fria block placeras på master freelist. Alla andra freelists nollställs. Om objektet har flera freelistgrupper fördelas de fria blocken mellan alla freelister och fördelar sig till de olika grupperna på round-robin-sätt.
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);
tabell 19-6 proceduren rebuild_freelists
| Argument | beskrivning |
|---|---|
|
|
Schema namn. |
|
|
namn på objektet vars freelister ska byggas om. |
|
|
Partition eller underpartition namn vars freelists ska byggas om. Om det här är ett partitionerat objekt och |
|
|
typ av objekt som ska behandlas. Måste vara antingen TABLE_OBJECT eller INDEX_OBJECT. Standardvärdet är TABLE_OBJECT. |
skip_corrupt_blocks
Aktiverar eller inaktiverar hoppning av korrupta block under index-och tabellskanningar av det angivna objektet. När objektet är en tabell gäller skip för tabellen och dess index. När objektet är ett kluster gäller det för alla tabeller i klustret och deras respektive index.
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);
tabell 19-7 proceduren skip_corrupt_blocks
| Argument | beskrivning |
|---|---|
|
|
schemanamn på objektet som ska behandlas. |
|
|
objektets namn. |
|
|
partitions-eller underpartitionsnamn som ska behandlas. Om det här är ett partitionerat objekt och |
|
|
typ av objekt som ska behandlas. Måste vara antingen TABLE_OBJECT eller CLUSTER_OBJECT. Standardvärdet är TABLE_OBJECT. |
|
|
om SKIP_FLAG anges, aktiverar hoppa över programvara korrupta block för objektet under index och tabellskanningar. Om NOSKIP_FLAG anges returnerar skanningar som stöter på korrupta block av programvara en ORA-1578. |
admin_tables
ger administrativa funktioner för reparation och föräldralösa nyckeltabeller.
procedure admin_tables( table_name IN varchar2, table_type IN binary_integer, action IN binary_integer, tablespace IN varchar2 DEFAULT NULL);
tabell 19-8 proceduren admin_tables
| Argument | beskrivning |
|---|---|
|
|
namn på tabellen som ska behandlas. Standardvärdet är ’ORPHAN_KEY_TABLE’ eller ’REPAIR_TABLE’ baserat på den angivna table_type. När det anges måste tabellnamnet ha lämpligt prefix, ’ORPHAN_’ eller ’REPAIR_’. |
|
|
typ av tabell, måste vara en av ORPHAN_TABLE eller REPAIR_TABLE. |
|
|
anger vilken administrativ åtgärd som ska utföras. Måste vara CREATE_ACTION, PURGE_ACTION eller DROP_ACTION. Om tabellen redan finns och CREATE_ACTION anges, returneras ett fel. PURGE_ACTION indikerar att radera alla rader i tabellen som är associerade med obefintliga objekt. Om tabellen inte existerar och DROP_ACTION anges, returneras ett fel. när CREATE_ACTION och DROP_ACTION anges skapas och släpps en associerad vy med namnet DBA_<tabellnamn>. Vyn definieras så att rader associerade med obefintliga objekt elimineras. skapad i SYS-schemat. |
|
|
anger det tabellutrymme som ska användas när du skapar en tabell. Som standard används SYS: s standardbordrum. Ett fel returneras om tabellutrymmet anges och åtgärden inte är CREATE_ACTION. |
Dbms_repair undantag
| 942 | reparationstabell finns inte |
| 1418 | specificerat index finns inte |
| 24120 | Ogiltig parameter |
| 24121 | Det går inte att ange CASCADE_FLAG och ett blockområde |
| 24122 | ogiltigt blockområde |
| 24124 | ogiltig åtgärdsparameter angiven |
| 24126 | CASCADE_FLAG specificerat och objekt är inte en tabell |
| 24127 | tabellutrymme anges och åtgärden är inte CREATE_ACTION |
| 24128 | partition specificerad för icke-partitionerat objekt |
| 24129 | ogiltigt orphan key table name – måste ha’ ORPHAN_ ’prefix |
| 24129 | angiven reparationstabell börjar inte med prefixet’ REPAIR_’ |
| 24131 | reparationstabellen har felaktiga kolumner |
| 24132 | reparationstabellens namn är för långt |