Oracle biedt verschillende methoden voor het detecteren en corrigeren van corruptie van gegevensblokken. Een methode is om een object te laten vallen en opnieuw te maken nadat de corruptie is gedetecteerd; dit is echter niet altijd mogelijk of wenselijk. Als de corruptie van gegevensblokken beperkt is tot een subset van Rijen, is een andere optie om de tabel opnieuw op te bouwen door alle gegevens te selecteren, behalve de corrupte rijen.
nog een andere manier om corruptie van gegevensblokken te beheren is door het dbms_repair-pakket te gebruiken. U kunt dbms_repair gebruiken om corrupte blokken in tabellen en indexen te detecteren en te repareren. Met behulp van deze aanpak, kunt u corrupties waar mogelijk aan te pakken, en ook doorgaan met het gebruik van objecten terwijl u probeert om ze te herbouwen of te repareren. DBMS_REPAIR gebruikt de volgende aanpak om corrupties aan te pakken:
- Stap 1: Detecteer en rapporteer corrupties
- Stap 2: Evalueer de kosten en baten van het gebruik van DBMS_REPAIR
- Stap 3: Maak objecten bruikbaar
- Stap 4: Herstel corrupties en herbouw verloren gegevens
opmerking:
elke corruptie waarbij gegevens verloren gaan, vereist analyse en inzicht in de manier waarop die gegevens in het algemene databasesysteem passen. Vandaar, DBMS_REPAIR is niet een toverstaf-je moet nog steeds bepalen of de reparatie aanpak die door dit pakket is het juiste instrument voor elk specifiek corruptie probleem. Afhankelijk van de aard van de reparatie, kunt u gegevens verliezen en logische inconsistenties kunnen worden ingevoerd; daarom moet u de winsten en verliezen in verband met het gebruik van dbms_repair wegen.
Dbms_repair pakketinhoud
tabel 19-1 beschrijft de procedures waaruit het dbms_repair pakket bestaat.
tabel 19-1 DBMS_REPARATIEPROCEDURES
| naam van de Procedure | beschrijving |
|---|---|
|
|
detecteert en rapporteert corruptie in een tabel of index. |
|
|
markeert blokken (die eerder geïdentificeerd werden met de |
|
|
rapporteert indexvermeldingen die verwijzen naar rijen in corrupte gegevensblokken. |
|
|
herbouwt de freelisten van een object. |
|
|
wanneer gebruikt, negeert blokken gemarkeerd beschadigd tijdens tabel en index scans. Indien niet gebruikt, krijg je fout ORA-1578 bij het ontmoeten van blokken gemarkeerd corrupt. |
|
|
biedt administratieve functies (create, drop, purge) voor DBMS_REPAIR repair en orphan key tables. Opmerking: Deze tabellen worden altijd gemaakt in het SYS-schema. |
Stap 1: corrupties detecteren en rapporteren
uw eerste taak, voordat u DBMS_REPAIR gebruikt, zou het detecteren en rapporteren van corrupties moeten zijn. Rapportage geeft niet alleen aan wat er mis is met een blok, maar identificeert ook de bijbehorende reparatierichtlijn. Je hebt verschillende opties, naast DBMS_REPAIR, voor het opsporen van corruptie. Tabel 19-2 beschrijft de verschillende detectiemethoden.
tabel 19-2 vergelijking van Corruptiedetectiemethoden
| Detectiemethode | beschrijving |
|---|---|
|
DBMS_REPAIR |
voert blokcontrole uit voor een opgegeven tabel, partitie of index. vult een reparatietabel aan met resultaten. |
|
DB_VERIFY |
extern opdrachtregelhulpprogramma waarmee blokcontrole wordt uitgevoerd in een offline database. |
|
analyseren |
gebruikt met de optie structuur valideren controleert u de integriteit van de structuur van een index, tabel of cluster; controleert of controleert u of uw tabellen en indexen synchroon zijn. |
|
DB_BLOCK_CHECKINGCOMMENT |
identificeert corrupte blokken voordat ze daadwerkelijk zijn gemarkeerd corrupt. Controles worden uitgevoerd wanneer wijzigingen worden aangebracht in een blok. |
DBMS_REPAIR: met behulp van de check_object en admin_tables Procedures
de check_object procedure controleert en rapporteert corrupties voor een bepaald object. Vergelijkbaar met de analyse…Valideer structuur statement voor indexen en tabellen, blok controle wordt uitgevoerd voor index en data blokken respectievelijk.
rapporteert niet alleen corrupties met check_object, maar identificeert ook eventuele fixes die zouden optreden als fix_corrupt_blocks later op het object wordt uitgevoerd. Deze informatie wordt beschikbaar gemaakt door een reparatietabel te vullen, die eerst moet worden aangemaakt met de admin_tables procedure.
nadat u de check_object procedure hebt uitgevoerd, toont een eenvoudige query in de repair table de corrupties en repair directives voor het object. Met deze informatie kunt u beoordelen hoe u de gerapporteerde problemen het beste kunt aanpakken.
DB_VERIFY: het uitvoeren van een Offline Database Check
normaal gesproken gebruikt u DB_VERIFY als een offline diagnostisch hulpprogramma wanneer u problemen ondervindt met gegevenscorruptie.
Zie Ook: Zie Oracle8i Utilities voor meer informatie over DB_VERIFY.
analyseren: Corruptierapportage
de ANALYSETABEL…Validate STRUCTURE statement valideert de structuur van het geanalyseerde object. Als Oracle de structuur met succes valideert, ontvangt u een bericht dat de validatie ervan bevestigt. Als Oracle corruptie tegenkomt in de structuur van het object, krijgt u een foutmelding. In dit geval zou je het object laten vallen en opnieuw maken.
zie ook: voor meer informatie over het ANALYZE statement, zie de Oracle8i SQL referentie.
DB_BLOCK_CHECKING (Block Checking Initialization Parameter)
u kunt blokcontrole instellen voor instanties via de parameter DB_BLOCK_CHECKING (de standaardwaarde is waar); dit controleert gegevens en indexblokken wanneer ze worden gewijzigd. DB_BLOCK_CHECKING is een dynamische parameter, aanpasbaar door het alter SYSTEM SET statement.
Stap 2: Evalueer de kosten en baten van het gebruik van DBMS_REPAIR
voordat u DBMS_REPAIR gebruikt, moet u de voordelen van het gebruik ervan afwegen in verhouding tot de verplichtingen.; u moet ook andere opties die beschikbaar zijn voor het aanpakken van corrupte objecten te onderzoeken.
een eerste stap is het beantwoorden van de volgende vragen:
- Wat is de omvang van de corruptie?
om te bepalen of er corrumpties en herstelacties zijn, voert u de
check_object– procedure uit en bevraagt u de hersteltabel. - welke andere opties zijn beschikbaar voor het aanpakken van blokcorrupties?
ervan uitgaande dat de gegevens uit een andere bron beschikbaar zijn, drop, re-create en re-bevolk het object. Een andere optie is om de CREATE TABLE uit te geven…Als Selecteer statement uit de corrupte tabel om een nieuwe te maken.
u kunt de corruptie negeren door corrupte rijen uit te sluiten van geselecteerde statements.
herstel van media.
- welke logische corrupties of bijwerkingen zullen worden geïntroduceerd wanneer u DBMS_REPAIR gebruikt om een object bruikbaar te maken? Kunnen deze worden aangepakt? Wat is de inspanning die daarvoor nodig is?
u heeft mogelijk geen toegang tot rijen in blokken die als beschadigd zijn gemarkeerd. Een blok kan echter beschadigd zijn gemarkeerd, ook al zijn er nog rijen die u geldig kunt openen.
referentiële integriteitsbeperkingen kunnen worden verbroken wanneer blokken als corrupt zijn gemarkeerd. Als dit gebeurt, de beperking uitschakelen en opnieuw inschakelen; eventuele inconsistenties worden gerapporteerd. Nadat alle problemen zijn opgelost, moet u in staat zijn om de beperking met succes opnieuw in te schakelen.
logische corruptie kan optreden wanneer er triggers zijn gedefinieerd op de tabel. Als bijvoorbeeld rijen opnieuw worden ingevoegd, moeten triggers worden ingevoegd of niet? U kunt deze problemen alleen aanpakken als u triggers en het gebruik ervan in uw installatie begrijpt.
Freelist blokken kunnen ontoegankelijk zijn. Als een corrupte blok aan het hoofd of staart van een freelist, space management herinitialiseert de freelist. Er kunnen dan blokken zijn die op een freelist zouden moeten staan, maar die dat niet Zijn. u kunt dit oplossen door de
rebuild_freelistsprocedure uit te voeren.indexen en tabellen zijn mogelijk niet gesynchroniseerd. U kunt dit aanpakken door eerst de
dump_orphan_keysprocedure uit te voeren (om informatie te verkrijgen van de sleutels die nuttig kunnen zijn bij het opnieuw opbouwen van beschadigde gegevens). Geef dan het alter INDEX REBUILD ONLINE statement uit om de tabel en de indexen weer synchroon te krijgen. - indien herstel gepaard gaat met verlies van gegevens, kunnen deze gegevens worden opgevraagd?
u kunt gegevens uit de index ophalen wanneer een gegevensblok beschadigd is gemarkeerd. De
dump_orphan_keysprocedures kunnen u helpen deze informatie op te halen. Natuurlijk, het ophalen van gegevens op deze manier afhankelijk van de hoeveelheid redundantie tussen de indexen en de tabel.
Stap 3: Maak objecten bruikbaar
In deze stap maakt DBMS_REPAIR het object bruikbaar door corrupties te negeren tijdens het scannen van tabellen en indexen.
Reparatie Van Corruptie: Met behulp van de fix_corrupt_blocks en skip_corrupt_blocks procedures
maakt u een corrupt object bruikbaar door een omgeving te creëren die corrupties overslaat die buiten het bereik van de reparatiemogelijkheden van DBMS_REPAIR blijven.
als corrupties gepaard gaan met verlies van gegevens, zoals een slechte rij in een gegevensblok, worden alle dergelijke blokken gemarkeerd als corrupt met de fix_corrupt_blocks – procedure. Vervolgens kunt u de skip_corrupt_blocks procedure uitvoeren, die blokken die beschadigd zijn gemarkeerd voor het object zal overslaan. Wanneer skip is ingesteld, slaan tabel-en indexscans alle blokken over die beschadigd zijn gemarkeerd. Dit geldt voor zowel media als software corrupte blokken.
implicaties bij het overslaan van corrupte blokken
als een index en tabel niet gesynchroniseerd zijn, dan kan een SET-transactie alleen-lezen transactie inconsistent zijn in situaties waarin één query alleen de index onderzoekt, en vervolgens een volgende query zowel de index als de tabel. Als het tabelblok beschadigd is gemarkeerd, zullen de twee query ‘ s verschillende resultaten opleveren, waardoor de regels van een alleen-lezen transactie worden overtreden. Een manier om dit te benaderen is om corruptie niet overslaan wanneer in een SET transactie alleen-lezen transactie.
een soortgelijk probleem doet zich voor bij het selecteren van rijen met een ketting. In wezen kan een query van dezelfde rij al dan niet toegang hebben tot de corruptie-waardoor verschillende resultaten worden gegeven.
Stap 4: Herstel corrupties en herbouw verloren gegevens
nadat u een object bruikbaar hebt gemaakt, kunt u de volgende reparatieactiviteiten uitvoeren.
gegevens herstellen met behulp van de dump_orphan_keys Procedures
de dump_orphan_keys procedure rapporteert over indexingangen die verwijzen naar rijen in corrupte gegevensblokken. Al deze indexvermeldingen worden ingevoegd in een weesknopentabel die de sleutel en rowid van de corruptie opslaat.
nadat de indexinganginformatie is opgehaald, kunt u de index opnieuw opbouwen met behulp van het alter INDEX REBUILD ONLINE statement.
Rebuild_freelists-Procedure
wanneer een blok met “corrupt” wordt gevonden aan het hoofd of de staart van een freelist, wordt de freelist opnieuw geïnitialiseerd en wordt een fout geretourneerd. Hoewel dit neemt de beledigende blok uit de freelist, het zorgt ervoor dat u freelist toegang tot alle blokken die de corrupte blok gevolgd verliezen.
u kunt de procedure rebuild_freelists gebruiken om de freelisten opnieuw te initialiseren. Het object wordt gescand, en als het geschikt is voor een blok op de freelist, wordt het toegevoegd aan de meester freelist. Freelistische groepen worden behandeld door de blokken op een billijke manier uit te meten-een blok per keer. Alle blokken gemarkeerd als “corrupt” in het object worden genegeerd tijdens het opnieuw opbouwen.
beperkingen en beperkingen
DBMS_REPAIR procedures hebben de volgende beperkingen:
- tabellen met LOBS, geneste tabellen en VARRAYS worden ondersteund, maar de kolommen buiten de regel worden genegeerd.
- Clusters worden ondersteund in de
skip_corrupt_blocksenrebuild_freelistprocedures, maar niet in decheck_objectprocedure. - Index-georganiseerde tabellen en LOB-indexen worden niet ondersteund.
- de
dump_orphan_keysprocedure werkt niet op bitmap indexen of functie-gebaseerde indexen. - de
dump_orphan_keysprocedure verwerkt sleutels die ten hoogste 3.950 bytes lang zijn.
Dbms_repair Procedures
deze secties bevatten gedetailleerde beschrijvingen van de DBMS_REPAIR procedures.
check_object
de check_object procedure controleert de gespecificeerde objecten en vult de hersteltabel met informatie over corrupties en reparatierichtlijnen. Validatie bestaat uit het controleren van alle blokken in het object. U kunt optioneel een bereik, partitienaam of subdeelnaam opgeven wanneer u een gedeelte van een object wilt controleren.
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 de check_object-Procedure
| Argument | beschrijving |
|---|---|
|
|
schemanaam van het te controleren object. |
|
|
naam van de te controleren tabel of index. |
|
|
partitie of subdeelnaam die moet worden gecontroleerd. Als dit een gepartitioneerd object is, en |
|
|
Type van het te verwerken object. Moet ofwel TABLE_OBJECT of INDEX_OBJECT zijn. De standaard is TABLE_OBJECT. |
|
|
naam van de in te vullen reparatietabel. De tabel moet in het SYS-schema staan. Gebruik de |
|
|
gereserveerd voor toekomstig gebruik. |
|
|
relatief dossiernummer. Gebruikt bij het opgeven van een blokbereik. |
|
|
het eerste blok dat moet worden verwerkt als een blokbereik wordt opgegeven. Mag alleen worden opgegeven als het object een enkele tabel, partitie of subdeel is. |
|
|
het laatste blok dat moet worden verwerkt als een blokbereik wordt opgegeven. Mag alleen worden opgegeven als het object een enkele tabel, partitie of subdeel is. als slechts één van block_start of block_end is opgegeven, dan wordt de andere standaard ingesteld op respectievelijk het eerste of laatste blok in het bestand. |
|
|
het aantal gerapporteerde corrupties. |
fix_corrupt_blocks
Gebruik deze procedure om de corrupte blokken in gespecificeerde objecten te repareren op basis van informatie in de reparatietabel die eerder werd gegenereerd door de check_object – procedure. Voordat een blok wordt gewijzigd, wordt het blok gecontroleerd om er zeker van te zijn dat het blok nog steeds corrupt is. Corrupte blokken worden gerepareerd door het markeren van het blok Software corrupt. Wanneer een reparatie wordt uitgevoerd, wordt de bijbehorende rij in de reparatietabel bijgewerkt met een vaste tijdstempel.
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 procedure fix_corrupt_blocks
| Argument | beschrijving |
|---|---|
|
|
schemanaam. |
|
|
naam van het object met corrupte blokken die moeten worden opgelost. |
|
|
partitie of subdeelnaam die moet worden verwerkt. Als dit een gepartitioneerd object is, en |
|
|
Type van het te verwerken object. Moet ofwel TABLE_OBJECT of INDEX_OBJECT zijn. De standaard is TABLE_OBJECT. |
|
|
naam van de reparatielijst met de reparatierichtlijnen. Moet bestaan in het SYS-schema. |
|
|
gereserveerd voor toekomstig gebruik. |
|
|
het aantal vaste blokken. |
dump_orphan_keys
rapporteert over indexvermeldingen die verwijzen naar rijen in corrupte gegevensblokken. Voor elke dergelijke indexingang die wordt aangetroffen, wordt een rij ingevoegd in de opgegeven weeftabel.
als de reparatietabel is opgegeven, worden alle corrupte blokken geassocieerd met de basistabel behandeld naast alle gegevensblokken die als software corrupt zijn gemarkeerd. Anders, alleen blokken die zijn gemarkeerd corrupt worden behandeld.
deze informatie kan nuttig zijn voor het opnieuw samenstellen van verloren rijen in de tabel en voor diagnostische doeleinden.
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 de procedure dump_orphan_keys
| Argument | beschrijving |
|---|---|
|
|
schemanaam. |
|
|
objectnaam. |
|
|
partitie of subdeelnaam die moet worden verwerkt. Als dit een gepartitioneerd object is, en |
|
|
Type van het te verwerken object. De standaard is INDEX_OBJECT. |
|
|
naam van de reparatietabel die informatie heeft over corrupte blokken in de basistabel. De opgegeven tabel moet in het SYS-schema staan. De |
|
|
naam van de verweesde sleuteltabel die moet worden gevuld met informatie over elke indexingang die verwijst naar een rij in een corrupt gegevensblok. De opgegeven tabel moet in het SYS-schema staan. De |
|
|
aantal verwerkte indexgegevens. |
rebuild_freelists
herbouwt de freelists voor het opgegeven object. Alle vrije blokken worden geplaatst op de master freelist. Alle andere freelisten staan op nul. Als het object meerdere freelist groepen heeft, dan worden de vrije blokken verdeeld over alle freelisten, toewijzen aan de verschillende groepen in round-robin Mode.
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 de procedure rebuild_freelists
| Argument | beschrijving |
|---|---|
|
|
schemanaam. |
|
|
naam van het object waarvan de freelisten moeten worden herbouwd. |
|
|
partitie of subdeelnaam waarvan de freelisten opnieuw moeten worden opgebouwd. Als dit een gepartitioneerd object is, en |
|
|
Type van het te verwerken object. Moet ofwel TABLE_OBJECT of INDEX_OBJECT zijn. De standaard is TABLE_OBJECT. |
skip_corrupt_blocks
schakelt het overslaan van corrupte blokken in of uit tijdens index-en tabelscans van het opgegeven object. Wanneer het object een tabel is, wordt skip toegepast op de tabel en zijn indexen. Wanneer het object een cluster is, is dit van toepassing op alle tabellen in het cluster en hun respectieve indexen.
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 de procedure van de “skip_corrupt_blocks”
| Argument | beschrijving |
|---|---|
|
|
schemanaam van het te verwerken object. |
|
|
naam van het object. |
|
|
partitie of subdeelnaam die moet worden verwerkt. Als dit een gepartitioneerd object is, en |
|
|
Type van het te verwerken object. Moet ofwel TABLE_OBJECT of CLUSTER_OBJECT zijn. De standaard is TABLE_OBJECT. |
|
|
als SKIP_FLAG is opgegeven, schakelt u het overslaan van software corrupte blokken voor het object tijdens index en tabel scans. Als NOSKIP_FLAG is opgegeven, geven scans die software corrupte blokken tegenkomen een ORA-1578 terug. |
admin_tables
biedt administratieve functies voor repair en orphan key tables.
procedure admin_tables( table_name IN varchar2, table_type IN binary_integer, action IN binary_integer, tablespace IN varchar2 DEFAULT NULL);
tabel 19-8 de procedure admin_tables
| Argument | beschrijving |
|---|---|
|
|
naam van de te verwerken tabel. Standaard ‘ ORPHAN_KEY_TABLE ‘of’ REPAIR_TABLE ‘ op basis van het opgegeven table_type. Indien gespecificeerd, moet de tabelnaam het juiste voorvoegsel hebben, “ORPHAN_” of “REPAIR_”. |
|
|
type tabel, moet een van ORPHAN_TABLE of REPAIR_TABLE zijn. |
|
|
geeft aan welke administratieve actie moet worden uitgevoerd. Moet CREATE_ACTION, PURGE_ACTION of DROP_ACTION zijn. Als de tabel al bestaat en CREATE_ACTION is opgegeven, wordt een fout geretourneerd. PURGE_ACTION geeft aan dat alle rijen in de tabel die geassocieerd zijn met niet-bestaande objecten moeten worden verwijderd. Als de tabel niet bestaat en DROP_ACTION is opgegeven, wordt een fout geretourneerd. wanneer CREATE_ACTION en DROP_ACTION zijn opgegeven, wordt een bijbehorende weergave met de naam dba_<table_name> aangemaakt en verwijderd. De weergave is zo gedefinieerd dat rijen die geassocieerd zijn met niet-bestaande objecten worden geëlimineerd. gemaakt in het SYS-schema. |
|
|
geeft de te gebruiken tablespace aan bij het maken van een tabel. Standaard wordt de standaard tablespace van SYS gebruikt. Een fout wordt geretourneerd als de tablespace is opgegeven en de actie niet CREATE_ACTION is. |
DBMS_REPAIR Uitzonderingen
| 942 | reparatie tabel bestaat niet |
| 1418 | opgegeven index bestaat niet |
| 24120 | ongeldige parameter |
| 24121 | niet opgeven CASCADE_FLAG en een blok bereik |
| 24122 | ongeldige blok bereik |
| 24124 | ongeldige actie parameter opgegeven |
| 24126 | CASCADE_FLAG opgegeven object is niet een tabel |
| 24127 | tablespace opgegeven en actie is niet CREATE_ACTION |
| 24128 | partitie opgegeven voor niet-gepartitioneerde object |
| 24129 | ongeldig wees toets naam van de tabel, moet ‘ORPHAN_’ prefix |
| 24129 | opgegeven reparatie-tabel niet beginnen met ‘REPAIR_’ prefix |
| 24131 | reparatie tafel heeft een onjuiste kolommen |
| 24132 | reparatie naam van de tabel is te lang |