Oracle gir ulike metoder for å oppdage og korrigere data blokk korrupsjon. En metode er å slippe og gjenskape et objekt etter at korrupsjonen er oppdaget; dette er imidlertid ikke alltid mulig eller ønskelig. Hvis data blokk korrupsjon er begrenset til et delsett av rader, er et annet alternativ å bygge tabellen ved å velge alle data bortsett fra de ødelagte radene.
Enda En måte å håndtere data blokk korrupsjon er å bruke dbms_repair pakken. Du kan bruke DBMS_REPAIR til å oppdage og reparere korrupte blokker i tabeller og indekser. Ved hjelp av denne tilnærmingen, kan du løse korrupsjon der det er mulig, og også fortsette å bruke objekter mens du prøver å gjenoppbygge eller reparere dem. DBMS_REPAIR bruker følgende tilnærming til å løse korrupsjon:
- Trinn 1: Oppdag Og Rapporter Korrupsjon
- Trinn 2: Evaluer Kostnadene og Fordelene Ved Å Bruke DBMS_REPAIR
- Trinn 3: Gjør Objekter Brukbare
- Trinn 4: Reparer Korrupsjon Og Gjenoppbygg Tapte Data
:
enhver korrupsjon som innebærer tap av data krever analyse og forståelse av hvordan dataene passer inn i det samlede databasesystemet. Derfor ER DBMS_REPAIR ikke en tryllestav-du må fortsatt avgjøre om reparasjonsmetoden som tilbys av denne pakken, er det riktige verktøyet for hvert enkelt korrupsjonsproblem. Avhengig av arten av reparasjonen, kan du miste data og logiske uoverensstemmelser kan innføres; derfor må du veie gevinster og tap forbundet med å bruke DBMS_REPAIR.
Dbms_repair Pakkeinnhold
Tabell 19-1 beskriver prosedyrene SOM utgjør dbms_repair-pakken.
Tabell 19-1 Dbms_repair Prosedyrer
| Prosedyrenavn | Beskrivelse |
|---|---|
|
|
Oppdager og rapporterer korrupsjon i en tabell eller indeks. |
|
|
Merker blokker (som tidligere ble identifisert av prosedyren |
|
|
Rapporter indeksoppføringer som peker til rader i korrupte datablokker. |
|
|
Gjenoppbygger et objekts freelists. |
|
|
når den brukes, ignorerer blokker merket skadet under tabell-og indeksskanninger. Hvis ikke brukt, får du feil ORA-1578 når du møter blokker merket korrupt. |
|
|
Gir administrative funksjoner (opprett, slipp, rense) FOR dbms_repair reparasjon og foreldreløse nøkkel tabeller. Obs! : disse tabellene opprettes alltid i SYS-skjemaet. |
Trinn 1: Oppdag Og Rapporter Korrupsjon
Din første oppgave, før du bruker DBMS_REPAIR, bør være deteksjon og rapportering av korrupsjon. Rapportering indikerer ikke bare hva som er galt med en blokk, men identifiserer også det tilknyttede reparasjonsdirektivet. Du har flere alternativer, i TILLEGG TIL DBMS_REPAIR, for å oppdage korrupsjon. Tabell 19-2 beskriver de ulike deteksjonsmetodene.
Tabell 19-2 Sammenligning Av Korrupsjonsdeteksjonsmetoder
| Deteksjonsmetode | Beskrivelse |
|---|---|
|
DBMS_REPAIR |
Utfører blokksjekking for en spesifisert tabell, partisjon eller indeks. Fyller ut en reparasjonstabell med resultater. |
|
DB_VERIFY |
Eksternt kommandolinjeverktøy som utfører blokkkontroll på en frakoblet database. |
|
ANALYSER |
Brukes MED VALIDER STRUKTUR alternativet, bekrefter integriteten til strukturen i en indeks, tabell eller klynge; sjekker eller bekrefter at tabeller og indekser er synkronisert. |
|
DB_BLOCK_CHECKING |
Identifiserer korrupte blokker før de faktisk er merket korrupte. Kontroller utføres når endringer gjøres i en blokk. |
Dbms_repair: ved hjelp av check_object Og admin_tables Prosedyrer
check_object prosedyre sjekker og rapporter blokkere korrupsjon for et angitt objekt. Ligner PÅ ANALYSEN…VALIDERE STRUKTUR setning for indekser og tabeller, blokk kontroll utføres for indeks og datablokker henholdsvis.
ikke bare rapporterer korrupsjon, men det identifiserer også eventuelle feilrettinger som ville oppstå hvis fix_corrupt_blocks senere kjøres på objektet. Denne informasjonen gjøres tilgjengelig ved å fylle ut en reparasjonstabell, som først må opprettes av prosedyren admin_tables.
når du har kjørt prosedyren check_object , viser en enkel spørring i reparasjonstabellen korrupsjoner og reparasjonsdirektiver for objektet. Med denne informasjonen kan du vurdere hvordan du best kan løse de rapporterte problemene.
DB_VERIFY: Utfører En Frakoblet Databasekontroll
VANLIGVIS bruker DU DB_VERIFY som et frakoblet diagnoseverktøy når det oppstår problemer med dataødeleggelse.
Se Også: Hvis Du vil ha mer informasjon Om DB_VERIFY, kan Du se Oracle8i Utilities.
ANALYSER: Korrupsjonsrapportering
ANALYSER TABELLEN…VALIDER STRUCTURE-setningen validerer strukturen til det analyserte objektet. Hvis Oracle validerer strukturen, returneres en melding som bekrefter valideringen til deg. Hvis Oracle støter på korrupsjon i objektets struktur, returneres en feilmelding til deg. I dette tilfellet vil du slippe og gjenopprette objektet.
Se Også: HVIS Du vil ha mer informasjon OM ANALYSER-setningen, kan Du se Oracle8i SQL-Referansen.
DB_BLOCK_CHECKING (Blokkkontroll Initialiseringsparameter)
du kan angi blokkkontroll for forekomster via parameteren DB_BLOCK_CHECKING (standardverdien ER SANN) ; dette kontrollerer data og indeksblokker når de endres. DB_BLOCK_CHECKING er en dynamisk parameter, modifiserbar AV ALTER SYSTEM SET-setningen.
Trinn 2: Evaluer Kostnadene og Fordelene VED Å Bruke DBMS_REPAIR
før DU bruker DBMS_REPAIR må du veie fordelene ved bruken i forhold til forpliktelsene; du bør også undersøke andre alternativer som er tilgjengelige for å adressere korrupte objekter.
et første skritt er å svare på følgende spørsmål:
- Hva er omfanget av korrupsjonen?
hvis du vil finne ut om det finnes korrupsjoner og reparasjonshandlinger, utfører du prosedyren
check_objectog spør etter reparasjonstabellen. - Hvilke andre alternativer er tilgjengelige for å adressere blokkkorrupsjoner?
Forutsatt at dataene er tilgjengelige fra en annen kilde, slipp, opprett og fyll ut objektet på nytt. Et annet alternativ er å utstede OPPRETT TABELL…SOM VELG setning fra det korrupte bordet for å opprette en ny.
du kan ignorere korrupsjonen ved å ekskludere korrupte rader fra utvalgte setninger.
Utfør mediegjenoppretting.
- hvilke logiske korrupsjoner eller bivirkninger vil bli introdusert når DU bruker DBMS_REPAIR for å gjøre et objekt brukbart? Kan disse adresseres? Hva er innsatsen som kreves for å gjøre det?
du har kanskje ikke tilgang til rader i blokker merket korrupte. En blokk kan imidlertid være merket korrupt selv om det fortsatt er rader som du har gyldig tilgang til.
Referanseintegritetsbegrensninger kan brytes når blokker er merket skadet. Hvis dette skjer, deaktiver og aktiver begrensningen på nytt; eventuelle inkonsekvenser vil bli rapportert. Etter å ha løst alle problemer, bør du kunne aktivere begrensningen på nytt.
Logisk korrupsjon kan oppstå når det er utløsere definert i tabellen. For eksempel, hvis rader er satt inn igjen, skal sett utlosere bli sparket eller ikke? Du kan løse disse problemene bare hvis du forstår utløsere og deres bruk i installasjonen.
Frilansblokker kan være utilgjengelige. Hvis en korrupt blokk er på hodet eller halen av en freelist, space management reinitializes freelist. Det kan da være blokker som skal være på en freelist, det er det ikke. Du kan løse dette ved å kjøre
rebuild_freelists– prosedyren.Indekser og tabeller kan være ute av sync. Du kan løse dette ved først å utføre
dump_orphan_keys– prosedyren (for å få informasjon fra nøklene som kan være nyttige for å gjenoppbygge ødelagte data). Deretter utsteder DU ALTER INDEX REBUILD online-setningen for å få tabellen og dens indekser tilbake i synkronisering. - hvis reparasjon innebærer tap av data, kan disse dataene hentes?
du kan hente data fra indeksen når en datablokk er merket skadet. Prosedyrene
dump_orphan_keyskan hjelpe deg med å hente denne informasjonen. Selvfølgelig avhenger henting av data på denne måten av mengden redundans mellom indeksene og tabellen.
Trinn 3: Gjør Objekter Brukbare
I dette trinnet gjør dbms_repair objektet brukbart ved å ignorere korrupsjon under tabell-og indeksskanninger.
Korrupsjonsreparasjon: Ved hjelp av prosedyrene fix_corrupt_blocks Og skip_corrupt_blocks
gjør du et skadet objekt brukbart ved å etablere et miljø som hopper over korrupsjon som forblir utenfor omfanget AV dbms_repairs reparasjonsfunksjoner.
hvis korrupsjon innebærer tap av data, for eksempel en ugyldig rad i en datablokk, merkes alle slike blokker som korrupte av prosedyren fix_corrupt_blocks. Deretter kan du kjøre skip_corrupt_blocks – prosedyren, som vil hoppe over blokker merket skadet for objektet. Når skip er satt, hopper tabell-og indeksskanninger over alle blokker merket korrupte. Dette gjelder både media og programvare korrupte blokker.
Implikasjoner Når Du Hopper Over Korrupte Blokker
hvis en indeks Og tabell ikke er synkronisert, kan EN ANGITT TRANSAKSJON SKRIVEBESKYTTET transaksjon være inkonsekvent i situasjoner der en spørring sonder bare indeksen, og deretter en påfølgende spørring sonder både indeksen og tabellen. Hvis tabellblokken er merket korrupt, vil de to spørringene returnere forskjellige resultater, og dermed bryte reglene for en skrivebeskyttet transaksjon. En måte å nærme seg dette på er å ikke hoppe over korrupsjon når du ER I EN ANGITT TRANSAKSJON, LES bare transaksjon.
det oppstår et lignende problem når du velger rader som er lenket. I hovedsak kan en spørring av samme rad eller ikke få tilgang til korrupsjonen-og dermed gi forskjellige resultater.
Trinn 4: Reparer Korrupsjoner Og Gjenoppbygg Tapte Data
etter at et objekt er brukbart, kan du utføre følgende reparasjonsaktiviteter.
Gjenopprett Data Ved Hjelp av dump_orphan_keys-Prosedyrene
prosedyrerapportene dump_orphan_keys på indeksoppføringer som peker på rader i korrupte datablokker. Alle slike indeksoppføringer settes inn i en foreldreløs nøkkeltabell som lagrer nøkkelen og rowid for korrupsjonen.
når indeksoppføringsinformasjonen er hentet, kan du bygge indeksen på nytt ved HJELP AV ALTER INDEX REBUILD online-setningen.
Reparere Freelists Bruker rebuild_freelists Prosedyre
når en blokk merket «korrupt» er funnet på hodet eller halen av en freelist, freelist er initialisert og en feil returneres. Selv om dette tar den fornærmende blokken av freelisten, får det deg til å miste freelist tilgang til alle blokkene som fulgte den korrupte blokken.
du kan bruke prosedyren rebuild_freelists til å initialisere freelists. Objektet skannes, og hvis det er hensiktsmessig for en blokk å være på freelist, legges den til master freelist. Freelistgrupper håndteres ved å måle ut blokkene på en rettferdig måte-en blokk om gangen. Eventuelle blokker merket «korrupt» i objektet ignoreres under gjenoppbyggingen.
Begrensninger og Begrensninger
dbms_repair prosedyrer har følgende begrensninger:
- Tabeller med LOBS, nestede tabeller og VARRAYS støttes, men ut av linjen kolonner ignoreres.
- Klynger støttes i prosedyrene
skip_corrupt_blocksogrebuild_freelist, men ikke i prosedyrencheck_object. - indeksorganiserte tabeller og LOB-indekser støttes ikke.
- prosedyren
dump_orphan_keysfungerer ikke på punktgrafikkindekser eller funksjonsbaserte indekser. - prosedyren behandler nøkler som maksimalt er 3950 byte lange.
Dbms_repair Prosedyrer
denne delen inneholder detaljerte beskrivelser AV dbms_repair prosedyrer.
check_object
prosedyren check_object kontrollerer de angitte objektene, og fyller ut reparasjonstabellen med informasjon om korrupsjoner og reparasjonsdirektiver. Validering består av blokkkontroll av alle blokker i objektet. Du kan eventuelt angi et område, partisjonsnavn eller delpartisjonsnavn når du ønsker å sjekke en del av 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)
Tabell 19-3 check_object-Prosedyren
| Argument | Beskrivelse |
|---|---|
|
|
Skjemanavn for objektet som skal kontrolleres. |
|
|
Navnet på tabellen eller indeksen som skal kontrolleres. |
|
|
Partisjon eller delnavn som skal kontrolleres. Hvis dette er et partisjonert objekt, og |
|
|
type av objektet som skal behandles. MÅ være ENTEN TABLE_OBJECT eller INDEX_OBJECT. Standard ER TABLE_OBJECT. |
|
|
navnet på reparasjonstabellen som skal fylles ut. Tabellen må finnes i SYS-skjemaet. Bruk prosedyren |
|
|
Reservert for fremtidig bruk. |
|
|
Relativ filnummer. Brukes når du angir et blokkområde. |
|
|
den første blokken å behandle hvis du angir et blokkområde. Kan bare angis hvis objektet er en enkelt tabell, partisjon eller delpartisjon. |
|
|
den siste blokken å behandle hvis du angir et blokkområde. Kan bare angis hvis objektet er en enkelt tabell, partisjon eller delpartisjon. hvis bare en av block_start eller block_end er angitt, er den andre standard til henholdsvis den første eller siste blokken i filen. |
|
|
antall korrupsjoner rapportert. |
fix_corrupt_blocks
Bruk denne prosedyren til å løse korrupte blokker i angitte objekter basert på informasjon i reparasjonstabellen som tidligere ble generert av prosedyren check_object. Før du foretar endringer i en blokk, kontrolleres blokken for å sikre at blokken fortsatt er skadet. Korrupte blokker repareres ved å markere blokkprogramvaren korrupt. Når en reparasjon utføres, oppdateres den tilknyttede raden i reparasjonstabellen med et tidsstempel for reparasjon.
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 prosedyren fix_corrupt_blocks
| Argument | Beskrivelse |
|---|---|
|
|
Skjema navn. |
|
|
navn på objektet med korrupte blokker som skal løses. |
|
|
Partisjon eller delnavn som skal behandles. Hvis dette er et partisjonert objekt, og |
|
|
type av objektet som skal behandles. MÅ være ENTEN TABLE_OBJECT eller INDEX_OBJECT. Standard ER TABLE_OBJECT. |
|
|
navn på reparasjonstabellen med reparasjonsdirektivene. Må eksistere i SYS-skjemaet. |
|
|
Reservert for fremtidig bruk. |
|
|
antall blokker fast. |
dump_orphan_keys
Rapporter om indeksoppføringer som peker på rader i korrupte datablokker. For hver slik indeksoppføring som oppstår, settes en rad inn i den angitte foreldreløse tabellen.
hvis reparasjonstabellen er angitt, håndteres eventuelle korrupte blokker som er knyttet til grunntabellen, i tillegg til alle datablokker som er merket skadet av programvare. Ellers håndteres bare blokker som er merket korrupte.
denne informasjonen kan være nyttig for å gjenoppbygge tapte rader i tabellen og for 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)
Tabell 19-5 dump_orphan_keys-Prosedyren
| Argument | Beskrivelse |
|---|---|
|
|
Skjema navn. |
|
|
Objektnavn. |
|
|
Partisjon eller delnavn som skal behandles. Hvis dette er et partisjonert objekt, og |
|
|
type av objektet som skal behandles. Standard ER INDEX_OBJECT. |
|
|
navn på reparasjonstabellen som har informasjon om korrupte blokker i grunntabellen. Den angitte tabellen må finnes i SYS-skjemaet. Prosedyren |
|
|
navnet på tabellen for foreldreløs nøkkel for å fylle ut med informasjon om hver indeksoppføring som refererer til en rad i en skadet datablokk. Den angitte tabellen må finnes i SYS-skjemaet. Prosedyren |
|
|
Antall indeksoppføringer behandlet. |
rebuild_freelists
Bygger freelists for det angitte objektet. Alle gratis blokker er plassert på master freelist. Alle andre freelists er nullet. Hvis objektet har flere freelistgrupper, blir de frie blokkene fordelt blant alle freelists, allokering til de forskjellige gruppene i round-robin-mote.
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 rebuild_freelists-Prosedyren
| Argument | Beskrivelse |
|---|---|
|
|
Skjema navn. |
|
|
Navn på objektet hvis freelists skal gjenoppbygges. |
|
|
Partition eller subpartition navn som freelists skal gjenoppbygges. Hvis dette er et partisjonert objekt, og |
|
|
type av objektet som skal behandles. MÅ være ENTEN TABLE_OBJECT eller INDEX_OBJECT. Standard ER TABLE_OBJECT. |
skip_corrupt_blocks
Aktiverer Eller deaktiverer hopp over korrupte blokker under indeks-og tabellskanninger av det angitte objektet. Når objektet er en tabell, gjelder skip for tabellen og dens indekser. Når objektet er en klynge, gjelder det for alle tabellene 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);
Tabell 19-7 prosedyren skip_corrupt_blocks
| Argument | Beskrivelse |
|---|---|
|
|
Skjemanavn for objektet som skal behandles. |
|
|
navnet på objektet. |
|
|
Partisjon eller delnavn som skal behandles. Hvis dette er et partisjonert objekt, og |
|
|
type av objektet som skal behandles. MÅ være ENTEN TABLE_OBJECT eller CLUSTER_OBJECT. Standard ER TABLE_OBJECT. |
|
|
HVIS SKIP_FLAG er angitt, slår på hopp over programvare korrupte blokker for objektet under indeks og tabell skanner. HVIS NOSKIP_FLAG er angitt, returnerer skanninger som støter på programvarekorrupte blokker EN ORA-1578. |
admin_tables
gir administrative funksjoner for reparasjon og foreldreløse nøkkel tabeller.
procedure admin_tables( table_name IN varchar2, table_type IN binary_integer, action IN binary_integer, tablespace IN varchar2 DEFAULT NULL);
Tabell 19-8 admin_tables-Prosedyren
| Argument | Beskrivelse |
|---|---|
|
|
Navnet på tabellen som skal behandles. Standard er ‘ORPHAN_KEY_TABLE ‘ eller’ REPAIR_TABLE ‘ basert på den angitte table_type. Når angitt, må tabellnavnet ha riktig prefiks, ‘ORPHAN_’ eller ‘REPAIR_’. |
|
|
type tabell, må være EN AV ORPHAN_TABLE eller REPAIR_TABLE. |
|
|
Angir hvilken administrativ handling som skal utføres. MÅ VÆRE CREATE_ACTION, PURGE_ACTION eller DROP_ACTION. Hvis tabellen allerede finnes, OG CREATE_ACTION er angitt, returneres en feil. PURGE_ACTION angir for å slette alle rader i tabellen som er knyttet til ikke-eksisterende objekter. Hvis tabellen ikke eksisterer, og DROP_ACTION er angitt, returneres en feil. NÅR CREATE_ACTION og DROP_ACTION er angitt, opprettes henholdsvis en tilknyttet visning KALT DBA_<table_name>. Visningen er definert slik at rader knyttet til ikke-eksisterende objekter elimineres. Opprettet i SYS-skjemaet. |
|
|
Angir tabellområdet som skal brukes når du oppretter en tabell. SOM standard BRUKES SYS standard tabellplass. En feil returneres hvis tabellområdet er angitt, og handlingen ER IKKE CREATE_ACTION. |
Dbms_repair Unntak
| 942 | reparasjonstabellen finnes ikke |
| 1418 | angitt indeks finnes ikke |
| 24120 | ugyldig parameter |
| 24121 | kan ikke angi CASCADE_FLAG og et blokkområde |
| 24122 | ugyldig blokkområde |
| 24124 | ugyldig handlingsparameter angitt |
| 24126 | CASCADE_FLAG angitt og objekt er ikke en tabell |
| 24127 | tabellplass angitt og handlingen ER IKKE CREATE_ACTION |
| 24128 | partisjon angitt for ikke-partisjonert objekt |
| 24129 | ugyldig orphan key table name – må ha ‘ORPHAN_’ prefiks |
| 24129 | angitt reparasjonstabell starter ikke med’ REPAIR_ ‘ prefiks |
| 24131 | reparasjonstabellen har feil kolonner |
| 24132 | reparasjonstabellnavnet er for langt |