În acest articol, vom examina principalele probleme legate de utilizarea bazei de date de rezervă Oracle. Mai întâi de toate, să răspundem la întrebarea - de ce avem nevoie de o bază de date de rezervă? Scopul său principal este de a restabili rapid baza de date primară, numită și primară, cu pierderi minime de informații. Comutarea bazei de date de rezervă în modul principal este o chestiune de câteva minute cu organizarea corespunzătoare a proceselor de administrare a bazelor de date.
Pentru fiabilitatea serverului și a dispozitivului de stocare, bazele de date primare și de rezervă ar trebui eliminate în spațiile izolate fizic ale companiei și chiar în clădiri la fel de mult precum permite rețeaua companiei. În acest caz, vom putea evita pierderile ireparabile chiar și în cazurile de evenimente fatale, cum ar fi incendiile și atacurile teroriste.
Crearea unei baze de date de rezervă are sens pentru o bază de date dinamică localizată în modul ARCHIVELOG și pentru instanța căror procese de arhivare a fișierelor de redo log sunt inițiate sau create, dacă este necesar. Adică atât baza de date, cât și instanța sunt în modul ARCHIVELOG.
Acesta este cel mai simplu mod de a crea o bază de date fizică de rezervă. Puteți crea, de asemenea, o bază de date logică de rezervă, inclusiv cross-platform. Dar procesul de restabilire a unei baze de date logice este mult mai consumator de timp, deoarece modificările din baza de date sunt efectuate nu prin actualizarea blocurilor de date, ci prin transformarea modificărilor în interogări SQL și executarea acestor interogări.
Așadar, am dezvoltat arhitectura serverului de rezervă și am instalat software-ul necesar, inclusiv prin transferarea pur și simplu a fișierelor. Acum, pentru a crea o bază de date de rezervă, trebuie să efectuați o procedură simplă. Oprim instanța Oracle utilizând comanda imediată de închidere sau închidere SQL * Plus. Pentru o scurtă perioadă de timp, ridicăm instanța și creăm un fișier de control de rezervă.
> modificați baza de date;
> modificați baza de date a crea fișierul de control de așteptare ca "c: \ control.stb";
Acum, să ne ocupăm de problemele legate de gestionarea bazei de date de rezervă.
Baza de date de rezervă trebuie să fie activată. Pentru a face acest lucru, scoateți fișierele de control din copiile bazei de date principale, plasați fișierul de control de rezervă creat în locul lor și efectuați modificările corespunzătoare din fișierul parametrilor de inițializare. Vom edita alți parametri dacă este necesar.
Lansați ascultătorul Oracle. Utilizând utilitarul oradim.exe, dacă este necesar, creați un serviciu și executați acest serviciu folosind același utilitar. Rețineți că parametrii utilitării specificate pentru diferite versiuni ale Oracle sunt diferite, deci mai întâi este logic să o rulați cu întrebarea - oradim.exe /.
Rulați shell shell-ul SQL * Plus folosind comanda sqlplus.exe / nolog. În funcție de sistemul de operare, este posibil sau nu să avem nevoie de comanda nomlast de pornire SQL * Plus. În acest caz, shell-ul SQL * Plus vă va informa că instanța este deja executată. Apoi, montați baza de date de rezervă, cu următoarele directive:
SQL> CONNECT sys / sys_pwd @ standby1 AS SYSDBA
SQL> STARTUP NOMOUNT pfile = / oracle / admin / pfile / initSTBY.ora
SQL> ALTER DATABASE MOUNT STANDBY DATABASE;
Dacă totul se face corect, atunci baza noastră de date de rezervă este gata de utilizare. Acesta poate funcționa în 3 moduri de bază (mod):
- Gestionat modul de recuperare
- Modul de recuperare manuală
- Mod numai pentru citire
În modul managed (modul de recuperare administrat), care este numit mai corect un sistem automat, serverul principal trimite serverul de backup printr-un ascultător arhivate fișierele redo log la serverul de backup în directoarele corespunzătoare, și serverul de backup le aplică în mod automat. În versiunea Oracle9i, această procedură a fost numită cu mândrie Data Guar. Puteți citi tehnologia corespunzătoare cu ea la următorul link. Cu toate acestea, nu recomand utilizarea acestei tehnologii. Poate că procedura de transfer automat de fișiere este cu siguranță utilă, dar cum pe procedurile eficiente de transfer de fișiere, cum ar fi cp sau rcp pe sistemele UNIX? Dar pentru a utiliza acest mod există mai multe obstacole tangibile.
Următorul argument este că backup-ul bazei de date ar trebui să fie monitorizat pentru operabilitate. Pentru a face acest lucru, trebuie tradus în modul read-only. În acest mod, recuperarea nu este posibilă, prin urmare, în acest timp există lacune în secvența fișierelor jurnal de arhivă, iar pentru a restabili secvența și, în consecință, posibilitatea unui mod automat, este necesar să se aplice modul manual. Dacă baza de date este dinamică, fișierele jurnal sunt scurte, atunci va fi dificil să restabiliți modul automat.
Prin urmare, alegem modul manual și îl completăm cu instrumente de automatizare. În modul manual, trebuie să restaurați baza de date pentru a copia un alt lot de fișiere redo log arhivate în directorul specificat de variabila LOG_ARCHIVE_DEST_n (n un număr întreg de 1 la 5), sau o LOG_ARCHIVE_DEST variabilă, și să inițieze opțiunea de recuperare AUTOMAT
SQL> RECUPERĂ DATABASE AUTOMAT DE STANDBY
După aplicarea unui fișier adecvat, Oracle va afișa numele jurnalului care nu se află în director, de exemplu, puteți vedea următoarele mesaje SQL * Plus:
ORA-00308: nu se poate deschide jurnalul arhivat '/oracle/standby/standby_logs/arcr_1_540.arc'
ORA-27037: nu poate obține statutul fișierului
SVR4 Eroare: 2: Nici un astfel de fișier sau director
Informații suplimentare: 3
Selectați opțiunea CANCEL și finalizați procesul de restaurare.
Recuperarea media a fost anulată.
Dacă am plasat fișierele într-un alt director, puteți utiliza RECUPERAREA AUTOMAT STANDBY bază de date cu opțiunea din naprmer „put_k_katalogu_s_faylami_zhurnala“
SQL> RECUPERAȚI DIN '/ logs' STANDBY DATABASE;
În modul citire din baza de date de rezervă pentru multe interogări, este posibil să fie nevoie să sortați, ceea ce va necesita operații pe disc. Prin urmare, poate fi necesar să creați un spațiu de tabelă temporar cu un fișier temporar
SQL> ALTER DATABASE MOUNT STANDBY DATABASE;
SQL> ALTER DATABASE OPEN CITIȚI DOAR;
SQL> CREATE TABLESPACE TEMPORARĂ tbs_1 TEMPFILE 'file_1.f' MANAGEMENTUL EXTENT LOCAL UNIFORM DIMENSIUNE 2048M;
La traducerea bazei de date în modul de așteptare în conformitate cu Oracle 9.2, a apărut următoarea eroare enervantă
SGA inițializare / DB deschis nu este completă, chiar și după 5 minute, QMN0exiting
eroare 604 detectată în procesul de fundal
OPIRIP: Eroare necorespunzătoare 447. Stack eroare:
ORA-00447: eroare fatală în procesul de fundal
ORA-00604: a apărut o eroare la nivel SQL recursiv 1
ORA-01219: baza de date nu se deschide: interogări permise numai pe mesele fixe / vizualizări
Fisa de fisiere f: \ database \ bdump \ bv_qmn0_xxxx.trc
Nu a afectat funcționalitatea. Baza de date de rezervă a aplicat corect jurnalele de arhivă. Dar s-au născut dosarele de gunoi și nu au lăsat sentimentul de nemulțumire față de munca făcută. Motivul a fost ușor de eliminat. Parametrul instanței aq_tm_process nu a fost egal cu 0 și instanța a încercat fără succes să inițieze procesele qmno corespunzătoare care necesită deschiderea bazei de date. A fost foarte simplu de rezolvat problema, aproximativ după cum urmează
modificați setul de sistem aq_tm_processes = 0 scope = ambele;
Dar trebuie să înțelegem că până atunci suntem departe de copia de lucru. Iar când baza de date de rezervă este activată, trebuie să returnați valoarea inițială tuturor parametrilor modificați.
Articole similare
Trimiteți-le prietenilor: