Oracle giver forskellige metoder til at opdage og korrigere data blok korruption. En metode er at droppe og genskabe et objekt, efter at korruptionen er opdaget; dette er dog ikke altid muligt eller ønskeligt. Hvis datablokkorruption er begrænset til en delmængde af rækker, er en anden mulighed at genopbygge tabellen ved at vælge alle data undtagen de korrupte rækker.
endnu en måde at styre data blok korruption er at bruge dbms_repair pakke. Du kan bruge dbms_repair til at registrere og reparere korrupte blokke i tabeller og indekser. Ved hjælp af denne tilgang kan du adressere korruption, hvor det er muligt, og også fortsætte med at bruge objekter, mens du forsøger at genopbygge eller reparere dem. DBMS_REPAIR bruger følgende tilgang til at løse korruption:
- Trin 1: Opdag og rapporter Korruptioner
- Trin 2: Evaluer omkostningerne og fordelene ved at bruge DBMS_REPAIR
- Trin 3: Gør objekter brugbare
- Trin 4: Reparer Korruptioner og genopbyg mistede Data
Bemærk:
enhver korruption, der involverer tab af data, kræver analyse og forståelse af, hvordan disse data passer ind i det overordnede databasesystem. Derfor er DBMS_REPAIR ikke en tryllestav-du skal stadig afgøre, om reparationsmetoden, der leveres af denne pakke, er det passende værktøj til hvert specifikt korruptionsproblem. Afhængigt af arten af reparationen, kan du miste data og logiske uoverensstemmelser kan indføres; derfor er du nødt til at afveje gevinster og tab forbundet med at bruge dbms_repair.
Dbms_repair Pakkeindhold
tabel 19-1 beskriver de procedurer, der udgør dbms_repair-pakken.
tabel 19-1 Dbms_reparationsprocedurer
| Procedurenavn | beskrivelse |
|---|---|
|
|
registrerer og rapporterer korruption i en tabel eller et indeks. |
|
|
markerer blokke (som tidligere blev identificeret ved |
|
|
rapporter indeks poster, der peger på rækker i korrupte datablokke. |
|
|
genopbygger et objekts freelister. |
|
|
når det bruges, ignorerer blokke markeret korrupt under tabel og indeks scanninger. Hvis det ikke bruges, får du fejl ORA-1578, når du støder på blokke markeret korrupt. |
|
|
giver administrative funktioner (Opret, drop, purge) til dbms_repair reparation og forældreløse nøgletabeller. Bemærk: Disse tabeller oprettes altid i SYS-skemaet. |
Trin 1: opdage og rapportere korruption
din første opgave, før du bruger DBMS_REPAIR, bør være påvisning og rapportering af korruption. Rapportering angiver ikke kun, hvad der er galt med en blok, men identificerer også det tilknyttede reparationsdirektiv. Du har flere muligheder, ud over DBMS_REPAIR, til at opdage korruption. Tabel 19-2 beskriver de forskellige detektionsmetoder.
tabel 19-2 sammenligning af metoder til påvisning af korruption
| påvisningsmetode | beskrivelse |
|---|---|
|
DBMS_REPAIR |
udfører blok kontrol for en bestemt tabel, partition eller indeks. udfylder en reparationstabel med resultater. |
|
DB_VERIFY |
ekstern kommando-line værktøj, der udfører blok kontrol på en offline database. |
|
analyser |
bruges med indstillingen valider struktur, verificerer integriteten af strukturen i et indeks, tabel eller klynge; kontrollerer eller verificerer, at dine tabeller og indekser er synkroniseret. |
|
DB_BLOCK_CHECKING |
identificerer korrupte blokke, før de rent faktisk er markeret korrupte. Kontroller udføres, når der foretages ændringer i en blok. |
Dbms_repair: ved hjælp af Check_object og admin_tables procedurer
den check_object procedure kontrol og rapporter blokere korrumperinger for et bestemt objekt. Svarende til analysen…Valider struktur erklæring for indekser og tabeller, blok kontrol udføres for indeks og data blokke henholdsvis.
ikke kun rapporterer check_object korruptioner, men det identificerer også eventuelle rettelser, der ville opstå, hvis fix_corrupt_blocks efterfølgende køres på objektet. Disse oplysninger stilles til rådighed ved at udfylde en reparationstabel, som først skal oprettes ved admin_tables – proceduren.
når du har kørt check_object – proceduren, viser en simpel forespørgsel på reparationstabellen korruptions-og reparationsdirektiverne for objektet. Med disse oplysninger kan du vurdere, hvordan du bedst kan løse de rapporterede problemer.
DB_VERIFY: udførelse af en offline Databasekontrol
typisk bruger du DB_VERIFY som et offline diagnostisk værktøj, når du støder på datakorruptionsproblemer.
Se Også: For mere information om DB_VERIFY, se Oracle8i Utilities.
analyser: Korruptionsrapportering
ANALYSETABELLEN…Validering struktur erklæring validerer strukturen af det analyserede objekt. Hvis Oracle validerer strukturen, returneres en meddelelse, der bekræfter dens Validering, til dig. Hvis Oracle støder på korruption i objektets struktur, returneres en fejlmeddelelse til dig. I dette tilfælde vil du droppe og genskabe objektet.
Se også: For mere information om ANALYSEERKLÆRINGEN, se Oracle8i-referencen.
DB_BLOCK_CHECKING (blok kontrol initialisering Parameter)
du kan indstille blok kontrol for forekomster via db_block_checking parameter (standardværdien er sand); dette kontrollerer data og indeks blokke, når de ændres. DB_BLOCK_CHECKING er en dynamisk parameter, modificerbar af alter SYSTEM SET-sætningen.
Trin 2: Evaluer omkostningerne og fordelene ved at bruge DBMS_REPAIR
før du bruger DBMS_REPAIR, skal du afveje fordelene ved brugen i forhold til forpligtelserne; du bør også undersøge andre muligheder for adressering korrupte objekter.
et første skridt er at besvare følgende spørgsmål:
- hvad er omfanget af korruptionen?
hvis du vil afgøre, om der er fejl og reparationshandlinger, skal du udføre proceduren
check_objectog forespørge på reparationstabellen. - hvilke andre muligheder er tilgængelige for adressering blok korruption?
hvis du antager, at dataene er tilgængelige fra en anden kilde, skal du droppe, genskabe og genfylde objektet. En anden mulighed er at udstede OPRETTABELLEN…Som Vælg sætning fra den korrupte tabel for at oprette en ny.
du kan ignorere korruptionen ved at ekskludere korrupte rækker fra udvalgte udsagn.
Udfør mediegendannelse.
- hvilke logiske korruptioner eller bivirkninger vil blive introduceret, når du bruger DBMS_REPAIR til at gøre et objekt brugbart? Kan disse behandles? Hvad er den indsats, der kræves for at gøre det?
du har muligvis ikke adgang til rækker i blokke markeret korrupt. En blok kan dog være markeret korrupt, selvom der stadig er rækker, som du gyldigt kan få adgang til.
referentielle integritetsbegrænsninger kan blive brudt, når blokke er markeret som korrupte. Hvis dette sker, skal du deaktivere og genaktivere begrænsningen; eventuelle uoverensstemmelser vil blive rapporteret. Når du har løst alle problemer, skal du være i stand til at genaktivere begrænsningen.
logisk korruption kan forekomme, når der er udløsere defineret på bordet. For eksempel, hvis rækker indsættes igen, skal indsæt udløsere fyres eller ej? Du kan kun løse disse problemer, hvis du forstår udløsere og deres anvendelse i din installation.
Freelist blokke kan være utilgængelige. Hvis en korrupt blok er i spidsen eller halen af en freelist, space management reinitialiserer freelist. Der kan så være blokke, der skal være på en freelist, det er det ikke. du kan løse dette ved at køre
rebuild_freelists– proceduren.indekser og tabeller kan være ude af sync. Du kan løse dette ved først at udføre
dump_orphan_keys– proceduren (for at få oplysninger fra de nøgler, der kan være nyttige til genopbygning af beskadigede data). Derefter udstede alter indeks genopbygge ONLINE erklæring for at få tabellen og dens indekser tilbage i sync. - hvis reparation indebærer tab af data, kan disse data hentes?
du kan hente data fra indekset, når en datablok er markeret korrupt. Procedurerne
dump_orphan_keyskan hjælpe dig med at hente disse oplysninger. Selvfølgelig, hente data på denne måde afhænger af mængden af redundans mellem indekserne og tabellen.
Trin 3: Gør objekter brugbare
i dette trin gør dbms_repair objektet brugbart ved at ignorere korruption under tabel-og indeksscanninger.
Reparation Af Korruption: Ved hjælp af procedurerne for rett_corrupt_blocks og skip_corrupt_blocks
gør du et korrupt objekt brugbart ved at etablere et miljø, der springer over korruptioner, der forbliver uden for omfanget af dbms_repairs reparationsmuligheder.
hvis korruption indebærer tab af data, f.eks. en dårlig række i en datablok, markeres alle sådanne blokke korrupt af fix_corrupt_blocks – proceduren. Derefter kan du køre skip_corrupt_blocks – proceduren, som vil springe over blokke markeret korrupt for objektet. Når skip er indstillet, tabel og indeks scanninger springe alle blokke markeret korrupt. Dette gælder både medier og programmer korrupte blokke.
implikationer, når du springer over korrupte blokke
hvis et indeks og en tabel ikke er synkroniseret, kan en indstillet transaktion skrivebeskyttet transaktion være inkonsekvent i situationer, hvor en forespørgsel kun undersøger indekset, og derefter undersøger en efterfølgende forespørgsel både indekset og tabellen. Hvis tabelblokken er markeret korrupt, returnerer de to forespørgsler forskellige resultater og bryder dermed reglerne for en skrivebeskyttet transaktion. En måde at nærme sig dette på er ikke at springe over korruption, når du er i en bestemt transaktion, der kun er læselig transaktion.
et lignende problem opstår, når du vælger rækker, der er kædet. I det væsentlige kan en forespørgsel i samme række muligvis ikke få adgang til korruptionen-hvilket giver forskellige resultater.
Trin 4: Reparer Korruptioner og genopbyg mistede Data
når du har gjort et objekt brugbart, kan du udføre følgende reparationsaktiviteter.
Gendan Data ved hjælp af dump_orphan_keys-procedurerne
proceduren dump_orphan_keys rapporter om indeksposter, der peger på rækker i korrupte datablokke. Alle sådanne indeksindgange indsættes i en forældreløs nøgletabel, der gemmer korruptionens nøgle og række.
når indeksindtastningsoplysningerne er hentet, kan du genopbygge indekset ved hjælp af erklæringen alter indeks REBUILD online.
Reparer Freelister ved hjælp af rebuild_freelists-proceduren
når en blok mærket “korrupt” findes i hovedet eller halen på en freelist, geninitialiseres freelisten, og en fejl returneres. Selvom dette fjerner den fornærmende blok fra freelisten, får det dig til at miste freelistadgang til alle blokke, der fulgte den korrupte blok.
du kan bruge rebuild_freelists – proceduren til at geninitialisere freelisterne. Objektet scannes, og hvis det er hensigtsmæssigt, at en blok er på freelisten, tilføjes den til master freelisten. Freelistgrupper håndteres ved at udmåle blokkene på en retfærdig måde-en blok ad gangen. Eventuelle blokke mærket” korrupt ” i objektet ignoreres under genopbygningen.
begrænsninger og begrænsninger
DBMS_REPARATIONSPROCEDURER har følgende begrænsninger:
- tabeller med LOBS, indlejrede tabeller og VARRAYS understøttes, men kolonnerne uden for linjen ignoreres.
- klynger understøttes i procedurerne
skip_corrupt_blocksogrebuild_freelist, men ikke i procedurencheck_object. - indeks-organiserede tabeller og LOB-indekser understøttes ikke.
-
dump_orphan_keys-proceduren fungerer ikke på bitmapindekser eller funktionsbaserede indekser. - proceduren
dump_orphan_keysbehandler nøgler, der højst er 3.950 bytes lange.
Dbms_repair procedurer
dette afsnit indeholder detaljerede beskrivelser af dbms_repair procedurer.
check_object
proceduren check_object kontrollerer de angivne objekter og udfylder reparationstabellen med oplysninger om korruption og reparationsdirektiver. Validering består af blok kontrol af alle blokke i objektet. Du kan eventuelt angive et område, partitionsnavn eller subpart-navn, når du vil kontrollere en del af et 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)
tabel 19-3 check_object-proceduren
| Argument | beskrivelse |
|---|---|
|
|
Skemanavn på det objekt, der skal kontrolleres. |
|
|
navn på den tabel eller det indeks, der skal kontrolleres. |
|
|
partitions-eller subpartitionsnavn, der skal kontrolleres. Hvis dette er et partitioneret objekt, og |
|
|
type af det objekt, der skal behandles. Skal være enten TABLE_OBJECT eller INDEKS_OBJECT. Standard er TABLE_OBJECT. |
|
|
navn på reparationstabellen, der skal udfyldes. Tabellen skal findes i SYS-skemaet. Brug proceduren |
|
|
reserveret til fremtidig brug. |
|
|
relativ filnummer. Bruges, når du angiver et blokområde. |
|
|
den første blok, der skal behandles, hvis der angives et blokområde. Kan kun angives, hvis objektet er en enkelt tabel, partition eller subpart. |
|
|
den sidste blok, der skal behandles, hvis du angiver et blokområde. Kan kun angives, hvis objektet er en enkelt tabel, partition eller subpart. hvis kun en af block_start eller block_end er angivet, er den anden standard til henholdsvis den første eller sidste blok i filen. |
|
|
antallet af korruptioner rapporteret. |
brug denne procedure til at rette de korrupte blokke i bestemte objekter baseret på oplysninger i reparationstabellen, der tidligere blev genereret af check_object – proceduren. Før der foretages ændringer i en blok, kontrolleres blokken for at sikre, at blokken stadig er korrupt. Korrupte blokke repareres ved at markere blokprogrammet korrupt. Når en reparation udføres, opdateres den tilknyttede række i reparationstabellen med et tidsstempel for rettelse.
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)
tabel 19-4 proceduren for rettelse af corrupt_blocks
| Argument | beskrivelse |
|---|---|
|
|
Skema navn. |
|
|
navn på objektet med korrupte blokke, der skal fastsættes. |
|
|
partitions-eller subpartitionsnavn, der skal behandles. Hvis dette er et partitioneret objekt, og |
|
|
type af det objekt, der skal behandles. Skal være enten TABLE_OBJECT eller INDEKS_OBJECT. Standard er TABLE_OBJECT. |
|
|
navn på reparationstabellen med reparationsdirektiverne. Skal eksistere i SYS-skemaet. |
|
|
reserveret til fremtidig brug. |
|
|
antallet af faste blokke. |
dump_orphan_keys
rapporter om indeksposter, der peger på rækker i korrupte datablokke. For hver sådan indeksindgang, der opstår, indsættes en række i den angivne forældreløse tabel.
hvis reparationstabellen er angivet, håndteres eventuelle korrupte blokke, der er knyttet til basistabellen, ud over alle datablokke, der er markeret som korrupte. Ellers håndteres kun blokke, der er markeret korrupte.
disse oplysninger kan være nyttige til genopbygning af tabte rækker i tabellen og til diagnostiske formå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)
tabel 19-5 dump_orphan_keys-proceduren
| Argument | beskrivelse |
|---|---|
|
|
Skema navn. |
|
|
objekt navn. |
|
|
partitions-eller subpartitionsnavn, der skal behandles. Hvis dette er et partitioneret objekt, og |
|
|
type af det objekt, der skal behandles. Standard er INDEKS_OBJECT. |
|
|
navn på reparationstabellen, der indeholder oplysninger om korrupte blokke i basistabellen. Den angivne tabel skal findes i SYS-skemaet. Proceduren |
|
|
navn på den forældreløse nøgletabel, der skal udfyldes med oplysninger om hver indekspost, der refererer til en række i en korrupt datablok. Den angivne tabel skal findes i SYS-skemaet. Proceduren |
|
|
antal behandlede indeksposter. |
rebuild_freelists
genopbygger freelisterne for det angivne objekt. Alle gratis blokke er placeret på master freelist. Alle andre freelister nulstilles. Hvis Objektet har flere freelistgrupper, fordeles de frie blokke blandt alle freelister og tildeles de forskellige grupper på round-robin-måde.
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);
tabel 19-6 proceduren rebuild_freelists
| Argument | beskrivelse |
|---|---|
|
|
Skema navn. |
|
|
navn på det objekt, hvis freelister skal genopbygges. |
|
|
partitions-eller subpartitionsnavn, hvis freelister skal genopbygges. Hvis dette er et partitioneret objekt, og |
|
|
type af det objekt, der skal behandles. Skal være enten TABLE_OBJECT eller INDEKS_OBJECT. Standard er TABLE_OBJECT. |
skip_corrupt_blocks
Aktiverer eller deaktiverer springning af korrupte blokke under indeks-og tabelscanninger af det angivne objekt. Når objektet er en tabel, gælder skip for tabellen og dens indekser. Når objektet er en klynge, gælder det for alle tabellerne i klyngen og deres respektive indekser.
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);
tabel 19-7 skip_corrupt_blocks-proceduren
| Argument | beskrivelse |
|---|---|
|
|
Skemanavn på det objekt, der skal behandles. |
|
|
navn på objektet. |
|
|
partitions-eller subpartitionsnavn, der skal behandles. Hvis dette er et partitioneret objekt, og |
|
|
type af det objekt, der skal behandles. Skal være enten TABLE_OBJECT eller CLUSTER_OBJECT. Standard er TABLE_OBJECT. |
|
|
hvis SKIP_FLAG er angivet, tænder springet over korrupte blokke for objektet under indeks-og tabelscanninger. Hvis NOSKIP_FLAG er angivet, scanninger, der støder på programmer korrupte blokke returnere en ORA-1578. |
admin_tables
indeholder administrative funktioner til reparation og forældreløse nøgletabeller.
procedure admin_tables( table_name IN varchar2, table_type IN binary_integer, action IN binary_integer, tablespace IN varchar2 DEFAULT NULL);
tabel 19-8 proceduren admin_tables
| Argument | beskrivelse |
|---|---|
|
|
navn på den tabel, der skal behandles. Standard ‘ORPHAN_KEY_TABLE’ eller ‘REPAIR_TABLE’ baseret på den angivne table_type. Når det er angivet, skal tabelnavnet have det relevante præfiks, ‘ORPHAN_’ eller ‘REPAIR_’. |
|
|
tabeltype, skal være en af ORPHAN_TABLE eller REPAIR_TABLE. |
|
|
angiver, hvilken administrativ handling der skal udføres. Skal være CREATE_ACTION, PURGE_ACTION eller DROP_ACTION. Hvis tabellen allerede findes, og CREATE_ACTION er angivet, returneres en fejl. PURGE_ACTION angiver at slette alle rækker i tabellen, der er knyttet til ikke-eksisterende objekter. Hvis tabellen ikke findes, og DROP_ACTION er angivet, returneres en fejl. når CREATE_ACTION og DROP_ACTION er angivet, oprettes og slettes en tilknyttet visning med navnet DBA_<Tabelnavn>. Visningen er defineret således, at rækker, der er knyttet til ikke-eksisterende objekter, elimineres. oprettet i SYS-skemaet. |
|
|
angiver det tablespace, der skal bruges, når du opretter en tabel. Som standard bruges SYS ‘ s standard tablespace. En fejl returneres, hvis tablespace er angivet, og handlingen er ikke CREATE_ACTION. |
Dbms_repair undtagelser
| 942 | reparation tabel findes ikke |
| 1418 | angivet indeks findes ikke |
| 24120 | Ugyldig parameter |
| 24121 | kan ikke angive CASCADE_FLAG og et blokområde |
| 24122 | ugyldigt blokområde |
| 24124 | ugyldig handling parameter angivet |
| 24126 | CASCADE_FLAG specificeret og objekt er ikke en tabel |
| 24127 | tablespace specificeret og handling er ikke CREATE_ACTION |
| 24128 | partition angivet for ikke-partitioneret objekt |
| 24129 | ugyldig orphan key table name – skal have’ ORPHAN_ ‘præfiks |
| 24129 | specificeret reparationstabel starter ikke med’ REPAIR_ ‘ præfiks |
| 24131 | reparation tabel har forkerte kolonner |
| 24132 | reparation tabel navn er for lang |