Este deja cunoscut faptul că utilizarea a aproape oricărui program software Oracle necesită o licență. Dar cum funcționează asta atunci când instalați software-ul Oracle doar în scopuri de recuperare in caz de dezastru (DR)? Nu utilizați software-ul, deci probabil că nu trebuie să îl licențiați, nu? Sau dacă utilizați software-ul Oracle instalat pe serverul DR, atunci credeți că puteți re-aloca licențele de la serverul de producție, pe serverul DR secundar, deoarece utilizați doar software-ul pe serverul DR. Oracle clasifică diferite scenarii de DR drept „cold-standby”, „warm-standby” sau „hot-standby”. Ei bine, am întâlnit diferite scenarii în practica noastră de zi cu zi, care arătau că utilizatorii finali nu au o viziune clară asupra modului de funcționare a licențelor software Oracle într-un mediu DR. Prin urmare, obiectivul acestei cărți este de a aduce claritate asupra diferitelor scenarii de licență aplicabile atunci când programele software Oracle sunt implementate în medii de recuperare în cazul dezastrelor.
Metode de recuperare a datelor
Recuperarea datelor reprezintă procesul de recuperare a informațiilor inaccesibile, pierdute, corupte, deteriorate sau formatate din stocarea secundară, din suporturile sau fișierele media, când datele stocate în ele nu pot fi accesate în mod normal. Cel mai frecvent scenariu de recuperare a datelor implică o defecțiune a sistemului de operare. Un aspect nefericit al fiecărui sistem de baze de date este posibilitatea unei defecțiuni a sistemului sau a hardware-ului. Principalele tipuri de eșec sunt:
- Eroare server
- Eroare utilizator sau aplicație
- Eroare media (disc)
- Dezastre
Cele mai frecvente metode de recuperare a datelor sunt:
- backup
- standby
- remote mirroring
- failover
Toate sunt descrise în politica Oracle pentru “Licențierea în medii de recuperare a datelor”, disponibile aici.
Backup
Prin backup, se face o copie a structurii bazei de date fizice. Când datele originale sunt pierdute, fișierele de rezervă pot fi folosite pentru a reconstrui informațiile pierdute, care constituie baza de date Oracle. Această copie de rezervă include principalele părți ale structurii fizice, cum ar fi: control files, redo logs si data files. Aceste fișiere fizice pot fi stocate pe un server, storage array, unități de disc sau Compact Disc (uri). Soluții precum Recovery Manager / RMAN (incluse în Oracle Database Enterprise Edition sau Standard Edition) și Oracle Secure Backup sau utilitățile sistemului de operare sunt utilizate pentru a crea copii ale fișierului fizic.
Oracle permite utilizatorilor finali să stocheze o copie de rezervă a bazei de date pe dispozitivele de stocare, cum ar fi disc-uri, fără a achiziționa licențe suplimentare. În caz de eșec, când datele Oracle sunt restaurate de pe disk sau suport, utilizatorii finali pot consulta următoarele scenarii pentru a licenția baza de date de recuperare:
Scenariul 1:
- Baza de date de producție: Baza de date Oracle este instalată și / sau rulează
- Baza de date de recuperare: Baza de date Oracle este instalată și / sau rulează. Disk-urile sunt utilizate pentru a actualiza site-ul de recuperare
Politica de licențiere:
- Atât bazele de date de producție, cât și recuperarea trebuie să fie licențiate.
Scenariul 2:
- Baza de date de producție: Baza de date Oracle instalată și / sau rulare
- Baza de date de recuperare: Serverul este oprit Oracle Database este instalat, dar nu funcționează. Disk-urile sunt utilizate pentru a actualiza site-ul de recuperare
Politica de licențiere:
- Atât bazele de date de producție, cât și recuperarea trebuie să fie licențiate.
Scenariul 3:
- Baza de date de producție: Baza de date Oracle instalată și / sau rulată
- Baza de date de recuperare: Serverul este oprit. Baza de date Oracle nu este instalată.
În timpul recuperării, baza de date Oracle este instalată pentru a recupera informațiile din disk-urile de rezervă.
Politica de licențiere:
- Baza de date de producție trebuie să fie licențiată.
- Baza de date de recuperare: o Atunci când serverul este oprit și baza de date Oracle nu este instalată, baza de date Oracle nu trebuie să fie licențiată.
o În timpul recuperării, când Baza de date Oracle este instalată pentru a recupera informațiile din disk-urile de rezervă, Baza de date de recuperare trebuie să fie licențiata.
Scenariul 4:
- Baza de date de producție: Baza de date Oracle este complet indisponibilă din cauza distrugerii hardware-ului
- Baza de date de recuperare: În timpul recuperării, baza de date Oracle este instalată pentru a recupera informațiile din disk-urile de rezervă.
Politica de licențiere:
- Baza de date de producție: Licențiată și complet indisponibilă, în afara reparației.
- Baza de date de recuperare: În această situație, clientului îi este permis să transfere setul de licențe al bazei de date Producție, cu condiția ca baza de date primară să fie complet indisponibilă și inaccesibilă.
Standby
Prin standby, una sau mai multe copii ale unei baze de date primare sunt păstrate pe unul sau mai multe server(e) de așteptare. Pe măsură ce baza de date primară este modificată, informațiile generate de modificări sunt trimise bazelor de date de standby și ulterior sunt aplicate la baza de date de așteptare(standby). Dacă eșuează baza de date primară, o bază de date de așteptare poate fi activată pentru a fi noua bază de date primară. Pot fi utilizate soluții precum Oracle Data Guard (inclus în Oracle Database EE) sau scripturi generate de clienți.
În acest mediu de disaster recovery, atât bazele de date primare, cât și cele de așteptare trebuie să fie licențiate.
În plus, aceeași măsură trebuie utilizată pentru a licența ambele baze de date.
- Când licențiați opțiunile Baza de date Oracle într-un mediu de așteptare, opțiunile trebuie să corespundă numărului de licențe / utilizatori ai bazei de date asociate unde este instalată și / sau rulează opțiunea.
- Utilizatorii finali care au licențiat deja baza de date Oracle pentru mediul principal utilizând un
metric vechi (cum ar fi: Concurrent Device, Named User Single Server, Named User Multi Server,
Universal Power Unit, Power Unit etc.) pot cumpăra licențe suplimentare pentru mediul lor de așteptare, fără a migra neapărat. Se aplică următoarele reguli:
o În cazul în care mediul primar este licențiat cu un metric multi-server, cum ar fi Concurrent Device, Named User, Named User Multi-server și clientul nu a îndeplinit minimul de licențe pentru toate discurile, care includ serverul Standby, clientul își poate licența mediul de standby cu Named User Plus, fără a-și migra licența de la celelalte multi-server metric. Dacă mediul de așteptare este licențiat de
Numit User Plus, atunci trebuie să se îndeplinească minimul pe serverul de așteptare.
o Dacă mediul primar este licențiat cu o metrică bazată pe hardware cum ar fi UPU, Power
Unit, Power Unit – RISC, Power Unit – Intel, atunci clientul își poate licenția mediul de standby-ul cu metric Procesor, fără a migra licențele sale existente care sunt atribuite mediului său primar. Dacă am licențiat cu Procesor metric, toate procesoarele în care Baza de date de standby este instalată și / sau rulează, trebuie numărate.
Remote Mirroring
Remote Mirroring implică oglindirea unității de stocare sau a discurilor partajate. Oglindite de la distanță, unitățile de stocare pot fi dispersate geografic și nu în aceeași locație cu unitatea primară, dar ele împart aceleași shared disk array. Pentru a configura un mediu de oglindire la distanță, fișierele de date Oracle, executabile, binarele și DLL-urile sunt replicate la unitatea de stocare oglindită. Soluții precum Veritas Volume Replicator, EMCSRDF, Legato Replistor și EMS StoreEdgeare utilizate pentru oglindirea datelor stocate pe disk.
În acest mediu, atât bazele de date cu oglindire primară, cât și cele de la distanță trebuie să fie complet licențiate. În plus, aceeași măsură trebuie utilizată pentru a licenția ambele baze de date.
- Dacă baza de date Oracle accesează datele din tabloul principal de discuri și nu accesează tablou de disc oglindit, dar este instalat pe unitatea de stocare a rețelei oglindită, atunci ambele baze de date trebuie licențiate complet și trebuie utilizată același metric.
- Dacă apare un eșec în unitatea de stocare primară și Oracle Database nu mai poate accesa datele din tabloul principal de discuri, dar acestea sunt încă instalate pe unitatea primară și datele pot fi doar accesate din tabloul de discuri oglindit de la distanță, atunci ambele baze de date trebuie să fie în continuare licențiate complet și trebuie utilizată același metric.
Excepție de la această regulă: Dacă eșecul din tabloul de discuri primare face ca baza de date Oracle să nu mai fie instalat, de exemplu în cazul unei explozii, atunci licențele din baza de date primară pot fi alocate la baza de date care accesează unitatea oglindită la distanță.
Failover
În această metodă de recuperare a dezastrelor, nodurile sunt configurate în „clustere”. Un grup de failover este un grup de sisteme, legate împreună într-un grup comun de resurse. În acest tip de metodă de recuperare, nodul Producție acționează ca nod primar. Dacă nodul primar se pierde, unul dintre nodurile “supraviețuitoare” din cluster acționează ca nod primar. Soluții precum Oracle Failsafe (incluse în Oracle Database EE sau SE, SE1) sau soluții pentru furnizori oferite de terțe părți (de exemplu, Veritas, HP Service Guard, HACMP, Linux HA – Heartbeat) sunt utilizate pentru a gestiona mediile Failover.
Restricții și condiții:
- Un singur nod de failover pentru fiecare mediu înglobat este gratuit timp de până la 10 zile – chiar dacă mai multe noduri sunt configurate ca failover.
- Regula de potrivire a metricilor se aplică tuturor serverelor dintr-o configurație în grup(clustered).
- Zece zile sunt contabilizate ca zece zile separate de functionare in failover. De exemplu: dacă nodul este in failover timp de două ore marți și trei ore vineri, acest timp este contorizat ca două zile.
- Când licențierea se face pe Named User Plus, minimele sunt scutite doar pe un singur nod de reîncărcare.
- Revenirea la nodul de producție este obligatorie. Când nodul de producție nu reușește, failover nodul acționează ca nodul primar. Odată ce nodul de producție este reparat, este necesară trecerea la acesta. Dacă perioada de reîncărcare a depășit zece zile, nodul de reîncărcare va trebui să fie licențiat. Clientul nu trebuie să treaca peste numărul de licențe acordate sau cumpărate.
- Timpul de oprire în scop de întreținere se contorizează/adaugă la cele zece zile.
- Când licențiem opțiunile într-un mediu failover, opțiunile trebuie să corespundă cu numărul de licențe alocate bazei de date.
- Politica de failover nu se aplică edițiilor Oracle Database Lite și Personal.
Concluzii
Unul dintre cele mai bune moduri de a reduce timpul de oprire este încorporarea celor mai bune practici operaționale. De multe ori puteți preveni problemele și perioadele de oprire înainte să apară prin testarea riguroasă a modificărilor din mediul dvs. de testare, după politici stricte de control al modificărilor pentru a vă proteja baza de date principală de daune și a avea o strategie de reparație bine structurata pentru fiecare tip de întrerupere.
O infrastructură de monitorizare precum Grid Control este esențială pentru a detecta rapid problemele. Pus in fața unei întreruperi, dar cu o strategie de decizii pentru reparații împreună cu un serviciu de reparații automat, puteți reduce timpul de oprire eliminând sau reducând orele de reparații.
Unele recomandări pentru prevenirea unor astfel de probleme și întreruperi includ:
- Creați medii de testare: este util un mediu de testare care imită mediul de producție pentru testarea modificărilor și prevenirea problemelor precum întreruperile de curent, eșecurile sistemului de operare, ștergerea fișierelor, eșecuri ale instanței Oracle, atacuri teroriste sau rău intenționate etc.
- Implementați procedurile de control și securitate a modificărilor pentru a vă asigura că nu sunt încorporate modificări ale bazei de date primară, cu excepția cazului în care au fost evaluate riguros pe sistemele de testare.
- Creați și urmați cele mai bune practici de securitate: o politică de securitate bine definită vă poate ajuta să vă protejați sistemele de acces nedorit și protejează informațiile sensibile împotriva sabotajului. O protecție a datelor adecvata, reduce șansele de întrerupere din cauza încălcărilor de Securitate.
- Utilizați Grid Control sau o altă infrastructură de monitorizare pentru a detecta și reacționa la eventualele defecțiuni și probleme înainte să apară.
