Restaurați fișierul de control

Restaurați fișierul de control

Pierderea sau coruperea fișierului de control este prima problemă pe care o puteți aștepta când încercați să porniți o instanță de bază de date Oracle. Acesta este detectat imediat când încercați să montați sistemul: ca răspuns la instalarea de pornire în svrmgrl sau sqlplus, primiți un mesaj ca







ORA-00205: eroare în identificarea fileului de control, verificați jurnalul de alertă pentru mai multe informații

Pentru a înțelege de ce se întâmplă acest lucru și pentru a se orienta puțin în acțiunile viitoare, este suficient să ne reamintim rolul său. Fișierul de control (fișierul de control, puteți spune în continuare „corectitudinea fișierului de control de stat bază de date“, este mai corect, dar ceva mai lung) - un fișier cu o „bază de date“ specială, informațiile privind starea actuală a unei astfel de baze de date ca obiecte spații de tabelă, fișiere - cu date și jurnal. Unul dintre cei mai importanți parametri monitorizați de fișierul de control este "numărul de schimbare a sistemului" (SCN). Numărul SCN a emis fiecare sistem începe o tranzacție, iar când modificările vin în fișierul de date, acest număr este stocat în antetul fișierului și fișierul de control în același timp (desigur, dar acest lucru devine SCN și fișierele jurnal). Când sistemul DBMS este pornit, sistemul compară SCN din antetul fișierului cu SCN înregistrat pentru acest fișier în sine. Dacă numărul fișierului este mai vechi decât cel din fișier, trebuie să restaurați fișierul de date. Dacă înlocuiți fișierul de control cu ​​o versiune mai veche în această situație, puteți primi un mesaj de eroare "fișierul de control este depășit". Aceasta este ceea ce privește sincronizarea fișierelor de sistem. Dar fișierul de control stochează, de asemenea, alte informații despre DBMS - de exemplu, numărul maxim de fișiere din grupul de jurnal și așa mai departe.

O neplăcere cu fișierul de control poate apărea în cazul în care sistemul de fișiere este defectat sau utilizat în mod necorespunzător sau dacă copia de rezervă a bazei de date este inexactă. Dar, deoarece pentru Oracle funcționează fișierul de control este vital, răsfățându-l sau dispărând face ca lucrul cu DB să fie imposibil. Pentru a proteja utilizatorii de astfel de situații, există un mecanism în Oracle oglindirea fișierele de control, permite plantei la câteva copii ale unui fișier, pentru identitate semnificativă pe care sistemul însuși monitorizează. Dar, totuși, în ciuda "avertismente repetate ale Ministerului Sănătății" fișierul de control de la administratorul "podzasletel", ce să fac. Depinde mult de circumstanțele specifice ale problemei. Următoarea este o posibila succesiune de acțiuni.

Deci, ce să facă în cazul în care probleme cu fișierul de control face imposibilă montarea sistemului (amintiți-vă că acesta este actul de citire a fișierului de control diferă de pornire de procesare de montare nomount de pornire).

Pasul 1. În primul rând, trebuie să determinați prezența fișierelor de control și ce fișier a provocat problema. Având în vedere că sistemul este în jos, va trebui să se aplice fișierul init.ora sau CONFIG.ORA și pentru a găsi o ofertă control_files = (...) cu o listă de copii în oglindă ale unui fișier, sau o indicație atunci când nu există nici o oglindire.

Apoi trebuie să mergeți la "jurnalul pentru înregistrarea semnalelor primite de pe site" (jurnal alertă). Acesta este de obicei localizat în directorul ORACLE_BASE / ORACLE_SID / admin / bdumb. dar poate fi într-un loc diferit, de exemplu, indicat în parametrul background_dump_dest în init.ora sau CONFIG.ORA (în versiunile 8.0 și versiunile anterioare pe Windows NT, acesta nu poate fi nici aici, nici acolo, dar este ușor de găsit) - alert_ORACLE_SID în fișierul. log. Va exista un mesaj ca acesta:

ORA-00202: fișier de control: 'E: \ Oracle \ oradata \ db1 \ control01.ctl'

ORA-27041: nu poate deschide fișierul

OSD-04002: nu poate deschide fișierul

Eroare O / S: (OS 2) Sistemul nu poate găsi fișierul specificat.

Acum trebuie să ne uităm la fișierele reale, să comparăm dimensiunile și datele schimbărilor și să determinăm situația și acțiunile ulterioare.

Fișierul, care păcatele Oracle, lipsește, dar există cel puțin o copie a acestuia.

Mergeți la pasul 2.

Fișierul pe care Oracle îl jură este disponibil, dar este corupt.

Dacă corupția fișierului nu este evidentă, concluzia despre aceasta devine subiectivă, adică alegerea (intuiția, experiența) a DBA. Verificați momentul potrivit pentru a ajuta la „jocul de substituție“ de copii ale fișierului de control, așa cum este descris în pasul 2. Din acest punct înainte de a trece, se recomandă insistent să facă copii ale tuturor fișierelor de control disponibile.







Dacă toate operaționale (on-line) redo fișierele jurnal de pe site-ul, acesta este, probabil, cel mai simplu scenariu de acțiune - asigurați-vă că aveți toate fișierele de date și fișierele jurnal (pașii 3 și 4) și re-crea fișierul de control comanda de creare a controlfile (pașii 5 și 6) .

Fișierele de control lipsesc complet sau toate au mărimi și date diferite de modificări.

Se poate concluziona că toate fișierele de control sunt corupte și că toate trebuie să fie restaurate sau să se restabilească întreaga bază de date dintr-o copie de rezervă. Acesta din urmă este posibilă în cazul în care (sperăm) atunci când backup-ul nu vă uitați să efectuați fișierul de control de rezervă pentru a urmări (această comandă creează o secvență SQL pentru fișierul de control de regenerare). Dacă nu ați făcut acest lucru, trebuie să treceți la pasul 7 și, dacă da, ați făcut backup, apoi la acțiunile 3 până la 6).

Pasul 2. Încercăm să înlocuim un fișier de control valid. Deci, Oracle se plânge de dosar de control lipsă sau de rău. Încă o dată, verificăm dacă sistemul de fișiere a făcut copii ale tuturor fișierelor de control disponibile.

Dacă începeți Oracle, este bine; dacă nu - treceți la pașii 3 - 6 pentru a crea din nou un fișier de control.

Pasul 3. Încercăm să determinăm dacă toate fișierele de date și fișierele jurnal online sunt în regulă. Trebuie să știți acest lucru, deoarece fără aceasta nu puteți rula scriptul pentru crearea unui fișier de control (pasul 6). Dacă accidentul cu fișierul de control a avut loc după o restaurare nereușită a copiei de siguranță și se pare că fișierele de date sunt mai vechi decât este necesar, este posibil să nu fie înfricoșător și fixabil cu ajutorul recuperării media de recuperare. Cu toate acestea, pentru a elabora acțiunea 6 este necesar ca fișierele jurnal online să fie intacte și să corespundă stării actuale a sistemului.

Acest lucru se datorează faptului că atunci când se creează un fișier de control, sistemul va analiza fiecare fișier de date și va verifica SCN-ul său. Dacă se constată că SCN din fișier este mai târziu decât toate numerele SCN care apar în fișierele jurnal, procesul de creare va fi întrerupt.

Dacă ați ajuns la opinia fermă că unul dintre fișierele de date sau jurnalul online nu este bun de utilizat, trebuie să treceți la pasul următor. În caz contrar, puteți merge la pasul 5.

Pasul 4. Recuperați datele sau fișierele jurnal care s-au dovedit a fi inutilizabile. Încă o dată: dacă nu sunteți sigur dacă oricare dintre fișierele devin inutile, și că este probabil că totul este în regulă fișier, puteți, dacă se dorește, treceți la pasul 5, iar în cazul în care nu reușește să se întoarcă din nou aici. Problemele de la acest lucru nu se vor întâmpla.

Mai întâi, să definim prezența fișierelor. Lista de fișiere care trebuie să fie disponibile, pot fi obținute prin introducerea svrmgrl sau SQLPlus (în acest ultim caz, se recomandă să emită sqlplus / nolog), care emite un intern de conectare, și apoi secvențial

selectați numele din v $ datafile;

selectați grupul #, membru din v $ logfile;

(Amintiți-vă că v $ - „de masă“ nu sunt stocate fizic în fișiere și în SGA, și DB, prin urmare, accesibilă și nedescoperite).

Mai întâi ar trebui să te uiți la fișierele de date. Dacă oricare dintre ele lipsește în sistemul de fișiere sau are o lungime de zero sau are o dată de modificare ulterioară celui mai recent fișier jurnal online, acestea vor trebui să fie restaurate din copia de rezervă.

Situația cu dosarele revistei este puțin diferită. Este necesar să verificați aceeași lungime și dată de modificare a tuturor fișierelor dintr-un grup. Bineînțeles, lungimile trebuie să fie diferite de zero, iar datele ar trebui să fie semnificative. Problemele pot avea două culori diferite:

În fiecare grup există cel puțin un jurnal normal.

Cel puțin un grup este deteriorat în întregime.

Aceasta este o situație proastă, deoarece crearea unui fișier de control (pasul 5) necesită prezența tuturor jurnalelor operaționale. Este necesar să restabiliți complet baza de date și să efectuați alte modificări în baza de date, deoarece vor exista conversații separate.

Pasul 5. Căutăm un script pentru a crea un fișier de control - ar fi bine dacă era deja gata. Acesta poate exista dacă emiteți fișierul de modificare al bazei de date de rezervă pentru a urmări comanda, când totul a funcționat. Prin urmare, este o idee bună să executați această comandă regulat și automat, de exemplu, utilizând cron pe Unix.

Scriptul creat de această comandă intră în fișierul de urmărire. NT (versiunea 8.1 Oracle), acest fișier este stocat în mod implicit în ORACLE_BASE \ Admin \ ORACLE_SID \ udump, și o altă locație de stocare poate fi specificat parametrul user_dump_dest în fișierul bazei de date de inițializare. urme de fișiere (de obicei, acestea sunt o TRC extensie) poate fi câteva, și apoi printre ei pentru a găsi cel cu cea mai recenta comanda de a crea controlfile (într-un sistem de operare diferit pentru acest lucru, există posibilități diferite, în NT, de exemplu, o mulțime va trebui să lucreze prin ochii, si Unix - mâinile și capul) și treceți la pasul 6. Dacă fișierele de urmărire cu comanda pentru a crea fișierul de control nu sunt disponibile, mergeți la pasul 7.

Dacă totul a funcționat, considerați că ați coborât cu o ușoară frică și odihnă. În caz contrar (de exemplu, sa dovedit că fișierele jurnal online sunt corupte) - continuăm cu pasul următor.

Pasul 7. Încercăm să restaurăm fișierul de control din copia de rezervă, să pregătim pentru restaurarea bazei de date și să încercăm să o restaurăm. Faptul că am ajuns la acest pas este, cu siguranță, o consecință a cataclismului. Judecător: am pierdut toate copiile controlate ale fișierului de control, un scenariu de recuperare (dacă a fost generat vreodată!) Și toate copiile întregi în cel puțin unul din grupurile de jurnale operaționale.

Alegerea nu este grozavă. Acum puteți să vă întoarceți la n ore, zile, săptămâni în urmă pe o copie rece sau să încercați să restaurați ultimul fișier de control valid dintr-unul din copiile de rezervă și, utilizând-l, să restaurați baza de date. Dar aceasta necesită o conversație separată.







Articole similare

Pagina anterioară

Pagina următoare

Trimiteți-le prietenilor: