ce este corupția bloc și cum putem rezolva corupția bloc
Confidențialitate și cookie-uri
cookie-urile sunt utilizate pe acest site. În continuare, sunteți de acord cu utilizarea lor. Aflați mai multe, inclusiv cum să verificați cookie-urile.
în procesul IT zilnic, există multe cauze posibile ale corupției unui bloc, inclusiv:
– Bad IO hardware / firmware
– probleme OS
– probleme Oracle
– recuperarea prin acțiuni de baze de date „irecuperabile” sau „NOLOGGING” (caz în care ORA-01578& ORA-01110 este de așteptat un comportament)
înainte de a începe să postați, permiteți-mi să vă reamintesc câte corupții avem… Există 2 tipuri de corupții. Corupția datelor se poate manifesta ca o corupție fizică sau logică.
deci, să ne definească toate cele,
corupție fizică a unui bloc se manifestă ca o sumă de control nevalidă sau antet, sau atunci când blocul conține toate zerouri. Când se întâmplă acest lucru, baza de date nu va recunoaște blocul ca un bloc Oracle valid, indiferent de conținutul său. Corupțiile fizice (media corrupt blocks) sunt blocuri care au suferit daune fizice evidente. Când Oracle detectează o inconsecvență între CSN în antetul blocului și CSN în subsolul blocului sau structurile de antet și subsol așteptate nu sunt prezente sau sunt mutilate, atunci sesiunea Oracle ridică o excepție la citirea blocului (ORA-01578: ORACLE data block corupt…). O corupție fizică este numită și corupție media.
corupție logică se întâmplă atunci când un bloc de date are o sumă de control validă, etc., dar conținutul blocului este logic inconsistent. Corupția blocului logic poate apărea și atunci când structura de sub începutul blocului (sub antetul blocului) este coruptă. În acest caz, suma de control a blocului este corectă, dar structurile blocului pot fi corupte. Corupția logică poate rezulta și dintr-o scriere pierdută.
pentru mai multe informații, consultați nota mea de asistență Oracle 840978.1.
deci?? Când puteți primi aceste mesaje de eroare? Este posibil să nu primiți un mesaj de eroare în timpul blocurilor de acces corupte până la blocurile legate de acces
– analizați tabelul .. Validați structura
– Dbverify
– CTA(creați tabelul ca Select)
– Export
– în timpul procesului RMAN
toate aceste utilități de baze de date sunt populează V$DATABASE_BLOCK_CORRUPTION pe detectarea corupției:
comportament în 9i și 10g, vizualizarea v$database_block_corruption folosit pentru a obține populate numai atunci când RMAN backup valida&verificați validarea logică comanda a fost executată.
informațiile populate utilizate pentru a obține odihnit doar o dată corupția a fost reparat (Media recovery/obiect a scăzut) și pe re-run a RMAN backup validate /verificați validare logică comanda pe baza de date sau fișierul de date afectate.
cu 11g acest comportament s-a schimbat.Atunci când orice utilitate bază de date sau proces întâlnește o corupție intrablock, se înregistrează automat în V$DATABASE_BLOCK_CORRUPTION.
repararea elimină metadatele despre blocurile corupte din vizualizare.
puteți identifica obiectele care conțin un bloc corupt folosind o interogare ca aceasta
SELECT DISTINCT owner, segment_name FROM v$database_block_corruption dbc JOIN dba_extents e ON dbc.file# = e.file_id AND dbc.block# BETWEEN e.block_id and e.block_id+e.blocks-1 ORDER BY 1,2;
sau puteți utiliza :
select * from V$DATABASE_BLOCK_CORRUPTION; << get file#&block from here
SELECT segment_type, segment_name
FROM dba_extents
WHERE file_id = 1
AND block_id < 3840
AND block_id + blocks >= 3840;
SEGMENT_TYPE SEGMENT_NAME
—————– —————————————-
INDEX I_SOURCE1
sau utilizați:
SELECT segment_type, segment_name
FROM dba_extents
WHERE file_id = 1
AND 3840 BETWEEN block_id AND block_id + blocks -1;
sau
select 'SELECT tablespace_name, segment_type, owner, segment_name FROM dba_extents WHERE file_id = ' || FILE# || ' and ' || BLOCK# || ' between block_id AND block_id + blocks – 1;' from v$database_block_corruption order by 1;
tehnici de reparare includ:
– block Media recovery,
– restaurarea datafiles,
– recuperarea prin intermediul backup– uri incrementale, și bloc newing,
– Export&import
– crearea tabelului .. Ca selectați comanda.
nu uitați, Block Media recovery poate repara corupții fizice, dar nu corupții logice.
verificarea corupției blocului cu comanda validare
sintaxă pentru comanda validare Rman:-
pentru baza de date :
RMAN > Validate database;
pentru fișierul de date :
RMAN > Validate datafile <file no>,<file no> ;
pentru blocul de date:
RMAN > Validate datafile <file no> block <Block no> ;
Archivelog restabilește pentru Block Media Recovery (BMR) poate fi rulat în paralel pe mai multe canale, dar scanează datafile/backupset și sesiunea de recuperare trebuie să ruleze toate în aceeași sesiune de server.
pentru a permite selectarea copiei de rezervă care va fi utilizată pentru a selecta blocurile dorite,comanda block recover acceptă opțiunile utilizate în comanda restore:
FROM BACKUPSET–> restore blocks from backupsets onlyFROM DATAFILECOPY–> restore blocks from datafile copies onlyFROM TAG–>restore blocks from tagged backupRESTORE UNTIL TIME|SCN|LOGSEQ
Deci, după validarea db nostru decât cum putem recupera corupții legate? Iată câteva exemple:
recuperare folosind fișier/bloc Explicit:
$ RMAN target / log=rman1.log
RMAN> blockrecover datafile 12 block 4207;
recuperare folosind lista de corupție :
$ rman target / log=rman1.log
RMAN> blockrecover corruption list;
abordarea cheie pentru detectarea și prevenirea datelor corupte este de a efectua următoarele cele mai bune practici MAA.
• utilizați Oracle Data Guard
• setați parametrii Oracle Database block corruption detection
• implementați o strategie de backup și recuperare cu Recovery Manager (RMAN)
există prea multe documente disponibile la metalink care sunt acoperă profund explica conceptul cu exemple de corupții. Deci, vă sugerez cu tărie să revizuiți documentele de mai jos în timp ce loviți erori similare pe sistemul dvs: