oracle real application testing solution test oracle db before moving production
Am ajuns la partea finală a serie de teste Oracle Database.
Până acum ne-am descurcat metode de testare a bazei de date Oracle. Continuând această concentrare, vom intra în detalii suplimentare cu privire la testarea aplicațiilor Oracle Real.
Astăzi vom învăța Oracle Real Application Testing - un sistem eficient de asigurare a schimbării care evaluează schimbarea sistemului în mediul de testare înainte de ao introduce în producție.
Aceasta este soluția principală a Oracle pentru a captura volumul de lucru real al mediului de producție DB și a-l înlocui pe t este mediul înconjurător .
După cum sa afirmat în numeroase ocazii, trebuie întotdeauna să ne asigurăm că testăm baza de date în toate dimensiunile posibile pentru a eradica instabilitățile și pentru a ne asigura că nu întâmpinăm probleme neprevăzute în instanța noastră de producție.
Putem clasifica Oracle Real Application Testing în două secțiuni largi:
- Analizator de performanță SQL
- Reluarea bazei de date
Înainte de a merge mai departe, vă rugăm să rețineți că SQL Performance Analyzer și Database Replay necesită licențiere suplimentară, adică este disponibil la un cost suplimentar și o opțiune Enterprise Edition.
Ce veți învăța:
Analizator de performanță SQL
GUI utilizată pentru a accesa SQL Performance Analyzer și Database Replay este Enterprise Manager, care este așa cum se arată mai jos:
Pentru a accesa SQL Performance Analyzer, faceți clic pe linkul „SQL Performance Analyzer”
(Faceți clic pe imagine pentru a vedea mărit)
SQL Performance Analyzer ne permite să evaluăm impactul performanței oricărei modificări a sistemului care ar putea avea un impact asupra execuției și performanței SQL.
Sunt extrem de utile în cazuri precum:
- Actualizarea bazei de date, Patching
- Modificări ale configurației sistemului de operare - Software sau hardware
- Modificările statisticilor Oracle Optimizer
- Modificări utilizator / schemă
Este întotdeauna recomandat să rulați SQL Performance Analyze pe un test sau un UAT (Testare aplicație utilizator) mai degrabă decât pe un sistem de producție. Deoarece, în timp ce testăm efectele schimbării în ceea ce privește performanța, am putea afecta din greșeală utilizatorii care rulează în instanța de producție. De asemenea, rularea acestuia într-un test ne va asigura că nu modificăm niciun proces care rulează în prezent la producție.
LA prezentarea generală de bază a unui flux de lucru SQL Performance Analyzer este prezentată mai jos:
Analiza performanței SQL implică pașii următori.
Pasul 1)Captarea sarcinii de lucru SQL
Determinați instrucțiunile SQL care ar face parte din volumul de lucru SQL din instanța de producție pe care doriți să o analizați. Această sarcină de lucru ar trebui să reprezinte în mod ideal volumul de muncă pe care l-ați putea avea în producție.
Capturăm aceste afirmații într-un set de reglare SQL și îl alimentăm cu acest set de reglare SQL către SQL Performance Analyzer.
Deoarece Analyzer consumă o mulțime de resurse pe sistemul dvs., vă recomandăm întotdeauna să le rulați pe un test sau un sistem UAT. Pentru a-l rula pe un sistem de testare, ar trebui să exportăm setul de reglare SQL pe care l-am creat deja în producție în sistemul de testare.
Pasul 2)Crearea unei activități SQL Performance Analyzer
Pentru a rula Analyzer, trebuie mai întâi să creați o sarcină SQL Performance Analyzer. Această sarcină nu este altceva decât un depozit care consolidează toate datele despre analiza executată de SQL Performance Analyzer. Așa cum s-a indicat mai devreme, setul de reglare SQL este alimentat ca stimulent pentru analizor.
diferența c și c ++
Pasul 3)Înainte de schimbare SQL Performance Trial
După ce am creat sarcina SQL Performance Analyzer și setul de reglare SQL, trebuie să construim infrastructura pe sistemul de testare.
Vă rugăm să rețineți că, atunci când intenționăm să utilizăm un sistem pentru testare, trebuie să ne asigurăm că este foarte similar cu sistemul de producție în ceea ce privește hardware, software și stocare, astfel încât să putem reproduce un mediu similar.
Odată ce sistemul de testare este configurat corespunzător, putem construi versiunea de pre-schimbare a datelor folosind SQL Performance Analyzer.
Acest lucru poate fi realizat utilizând fie Enterprise Manager, fie API-uri (proceduri încorporate).
Pasul 4)Încercare de performanță SQL după schimbare
Încercarea după schimbare se efectuează pe sistemul de testare după efectuarea unor modificări ale sistemului.
Odată ce acest lucru este finalizat, am avea două încercări SQL - o încercare de pre-schimbare și de după schimbare de comparat.
Similar cu încercarea de performanță SQL pre-schimbare, putem crea o încercare de performanță SQL post-schimbare utilizând fie Enterprise Manager, fie API-uri (proceduri încorporate).
Pasul 5)Generarea unui raport
După executarea încercărilor de pre-modificare și post-modificare, datele de performanță colectate în acestea pot fi comparate prin efectuarea unei analize de comparație utilizând SQL Performance Analyzer.
Odată ce această sarcină de comparație este finalizată, putem genera un raport pentru a identifica performanța declarației SQL care a făcut parte din volumul de lucru pe care intenționam să îl testăm.
Prin examinarea raportului, putem judeca și face concluzii cu privire la performanța SQL
Declarații și apoi implementați modificările sistemului în producție.
În mod similar, putem testa diverse sarcini de lucru cu diferite modificări ale sistemului și ne asigurăm că le testăm pe fiecare dintre ele înainte de a le implementa în producție.
Fluxul de lucru ilustrat mai sus poate fi reprezentat grafic așa cum se arată mai jos.
Reluarea bazei de date
Pentru a rula instrumentul prin Enterprise Manager:
(Faceți clic pe imagine pentru a vedea mărit)
Replay-ul bazei de date permite testarea realistă a modificărilor de sistem prin reproducerea esențială a mediului de producție pe un sistem de testare. Face acest lucru prin captarea volumului de lucru dorit pe sistemul de producție și redarea acestuia pe un sistem de testare cu caracteristicile resurse exacte ale volumului de lucru original, cum ar fi execuția SQL, tranzacții, extrase și proceduri.
Acest lucru este realizat pentru a ne asigura că luăm în considerare toate impacturile posibile ale oricărei modificări, inclusiv rezultate nedorite, cum ar fi erori de produs, rezultate inadecvate sau regresie a performanței.
Analiza și raportarea extinse generate, de asemenea, ajută la identificarea oricăror probleme potențiale, cum ar fi circumstanțele eronate întâlnite și divergențele de performanță.
Drept urmare, organizațiile pot fi siguri când se ocupă de schimbare și pot fi profitabile în evaluarea succesului general al schimbării sistemului. Acest lucru va reduce semnificativ orice risc atunci când dorim să implementăm schimbările de producție. Schimbarea este inevitabilă și asigurarea faptului că testăm fiecare aspect al acestei schimbări de la toate gradele va face producția mai robustă și mai robustă.
Un flux de lucru de bază pentru reluarea bazei de date este după cum se arată mai jos:
Modificările acceptate de reluarea bazei de date sunt:
- Actualizări ale bazei de date Oracle, patch-uri software
- Utilizator / Schemă, instanță de bază de date Parametri precum memoria, I / O
- Modificări hardware / software la nodurile RAC (Real Application Cluster)
- Modificări ale sistemului de operare, corecția sistemului de operare
- CPU, memorie, stocare
Replay-ul bazei de date ne permite să testăm diferite efecte ale posibilelor modificări ale sistemului, redând încărcarea practică a unui sistem de producție real pe un sistem de testare înainte ca acesta să fie expus la primul. Volumul de lucru la producție este monitorizat, analizat și înregistrat pe o perioadă de timp fixă cantitativ. Aceste date sunt înregistrate în timp și sunt utilizate pentru a reda volumul de lucru pe sistemele de testare.
Realizând acest lucru, putem testa cu succes implicațiile volumului de muncă înainte de a implementa orice modificări care ar putea afecta negativ producția.
Fluxul de lucru este după cum urmează:
Pasul 1) Captură sarcină de lucru
Înregistrăm toate cererile făcute de clienți în fișiere denumite „Capture files” pe sistemul de fișiere (stocare). Aceste fișiere conțin toate informațiile vitale cu privire la solicitările clientului, cum ar fi SQL, legături, proceduri și informații despre tranzacții. Aceste fișiere pot fi apoi exportate către orice sistem în cazul în care dorim să le redăm pe alt sistem.
Pasul 2)Preprocesare sarcină de lucru
După ce am capturat informațiile din „Capture files”, trebuie să le preprocesăm. În acest pas, creăm metadate care oferă o descriere a tuturor datelor necesare pentru a reda volumul de lucru.
Deoarece acest pas folosește o cantitate imensă de resurse din sistem, se recomandă să rulați pe un alt sistem, în afară de producție, unde sarcina poate fi redată. În cazul în care nu aveți un alt sistem de testat și doriți să le rulați în producție, asigurați-vă că le executați în timpul orelor de vârf, astfel încât utilizatorii și procesele care rulează în producție să nu fie afectate.
Pasul 3)Reîncărcare sarcină de lucru
Acum, le putem reda pe sistemul de testare. În acest moment redăm toate tranzacțiile, contextul, procedurile și SQL care au fost capturate inițial în timpul fazei de captare acumulând date pe măsură ce fiecare proces suferă această tranziție.
Pasul 4)Generarea de rapoarte
Similar cu Analizorul de performanță, puteți genera și vizualiza rapoarte pentru a compara fiecare dintre testele pe care le-ați executat.
În concluzie, oferim câteva sfaturi rapide în timpul testării reluării bazei de date:
- Utilizați un sistem de testare identic ca și când este posibil
- Testați o schimbare pe rând pentru a înțelege impactul acesteia
- Asigurați-vă că începeți cu opțiunile de redare implicite și apoi faceți modificări, dacă este necesar, în funcție de cerința dvs.
- Înainte de a efectua a doua reluare, asigurați-vă că înțelegeți toate aspectele de testare
- Asigurați-vă că salvați rezultatele testelor și documentați orice schimbări / acțiuni de testare necesare
- Asigurați-vă că niciun alt volum de lucru sau utilizatori nu folosesc sistemul în timpul oricărei teste
Concluzie:
Cu diferite aspecte și diverse metode de testare a bazelor de date și aplicații Oracle, vă rugăm să vă asigurați întotdeauna că testați cât mai des și cât mai bine posibil; să înțelegeți aplicația și mediul utilizatorului înainte de a implementa orice modificări sau de a introduce parametri noi în producție.
Lectură recomandată
- Cele mai bune instrumente de testare software 2021 (Instrumente de automatizare a testelor de calitate)
- Diferența dintre Desktop, Client Server Testing și Web Testing
- Cum se testează baza de date Oracle
- Ghid de testare a securității aplicațiilor web
- Testarea aplicațiilor - În noțiunile de bază ale testării software!
- Instalarea aplicației pe dispozitiv și începeți testarea de la Eclipse
- Descărcare eBook Descărcare Primer
- Tutorial de testare distructivă și testare nedistructivă