oracle real application testing solution test oracle db before moving production
Prišli smo do zadnjega dela serija Oracle Database Testing.
Do zdaj smo se ukvarjali metode testiranja baze podatkov Oracle. Nadaljujemo s tem poudarkom, zato se bomo poglobili v nadaljnje podrobnosti v zvezi z Oracle Real Application Test.
Danes se bomo naučili Oracle Real Application Testing - učinkovit sistem za zagotavljanje sprememb, ki oceni sistemsko spremembo v samem testnem okolju, preden ga uvede v proizvodnjo.
To je vodilna rešitev podjetja Oracle, da zajame dejansko delovno obremenitev DB-ja proizvodnega okolja in jo nadomesti na t je okolje .
Kot smo že večkrat navedli, moramo vedno poskrbeti, da bomo bazo podatkov preizkusili v vseh možnih razsežnostih, da bi odpravili nestabilnosti in se prepričali, da v naši proizvodni instanci ne naletimo na nepredvidene težave.
Lahko razvrstimo Oracle Real Application Testiranje v dva široka sklopa:
- Analizator zmogljivosti SQL
- Ponovno predvajanje zbirke podatkov
Preden nadaljujemo, upoštevajte, da SQL Performance Analyzer in Database Replay zahtevata dodatno licenco, tj. Na voljo je z doplačilom in možnost Enterprise Edition.
Kaj se boste naučili:
Analizator zmogljivosti SQL
GUI, ki se uporablja za dostop do SQL Performance Analyzerja in ponovitve baze podatkov, je Enterprise Manager, kot je prikazano spodaj:
Za dostop do SQL Performance Analyzerja kliknite povezavo »SQL Performance Analyzer«
(Kliknite sliko za ogled povečave)
SQL Performance Analyzer nam omogoča, da ocenimo vpliv na zmogljivost vseh sprememb sistema, ki bi lahko vplivale na izvajanje in delovanje SQL.
So izredno koristni v primerih, kot so:
- Nadgradnja baze podatkov, krpanje
- Spremembe konfiguracije operacijskega sistema - programska ali strojna oprema
- Spremembe statistike Oracle Optimizer
- Spremembe uporabnika / sheme
Vedno je priporočljivo zagnati SQL Performance Analyze na testu ali a UAT (testiranje uporabniških aplikacij) namesto na proizvodnem sistemu. Ker bi lahko med preizkušanjem učinkov spremembe v smislu zmogljivosti nehote vplivali na uporabnike, ki se izvajajo v proizvodni instanci. Poleg tega bo izvajanje na preizkusu zagotovilo, da ne bomo posegali v trenutno zagnane procese v proizvodnji.
TO osnovni pregled poteka dela SQL Performance Analyzer je prikazan spodaj:
Analiza učinkovitosti SQL vključuje naslednje korake.
Korak 1)Zajem delovne obremenitve SQL
Določite stavke SQL, ki bi bili del delovne obremenitve SQL iz proizvodne instance, ki jo želite analizirati. Ta delovna obremenitev bi v idealnem primeru morala predstavljati delovno obremenitev, ki bi jo lahko imeli v svoji proizvodnji.
Te stavke zajamemo v naboru za uglasitev SQL in ta nabor za uglaševanje SQL posredujemo v analizator zmogljivosti SQL.
Ker Analyzer porabi veliko virov v vašem sistemu, vedno priporočamo, da jih zaženete na preskusu ali UAT sistemu. Če ga želite zagnati na testnem sistemu, bi morali v testni sistem izvoziti nabor SQL Tuning, ki smo ga že ustvarili v proizvodnji.
2. korak)Ustvarjanje naloge analizatorja zmogljivosti SQL
Če želite zagnati Analyzer, morate najprej ustvariti nalogo SQL Performance Analyzer. Ta naloga ni nič drugega kot repozitorij, ki združuje vse podatke o analizi, ki jo izvede SQL Performance Analyzer. Kot smo že omenili, se SQL Tuning Set kot stimulans dovaja v analizator.
kako predvajati datoteke .bin
3. korak)Preizkusni preizkus zmogljivosti SQL pred spremembo
Potem ko smo ustvarili nalogo SQL Performance Analyzer in SQL Tuning Set, moramo na testnem sistemu zgraditi infrastrukturo.
Ko načrtujemo uporabo sistema za testiranje, se moramo prepričati, da je po strojni, programski in pomnilniški opremi zelo podoben proizvodnemu sistemu, da lahko ponovimo podobno okolje.
Ko je testni sistem ustrezno konfiguriran, lahko z uporabo SQL Performance Analyzerja zgradimo različico podatkov pred spremembo.
To lahko dosežemo z uporabo Enterprise Manager ali API-jev (vgrajeni postopki).
4. korak)Preskus uspešnosti SQL po spremembi
Preskus po spremembi se izvede na testnem sistemu po nekaj spremembah sistema.
Ko bo to končano, bomo imeli dve preizkusni različici SQL - eno pred spremembo in po spremembi za primerjavo.
Podobno kot preizkus zmogljivosti SQL pred spremembo lahko tudi z uporabo upravitelja podjetja ali API-jev (vgrajeni postopki) ustvarimo preizkus zmogljivosti SQL po spremembi.
5. korak)Ustvarjanje poročila
Po izvedbi preskusov pred spremembo in po spremembi je mogoče podatke o zmogljivosti, zbrane v njih, primerjati z izvajanjem primerjalne analize z uporabo SQL Performance Analyzer.
Ko je ta naloga za primerjavo končana, lahko ustvarimo poročilo, ki bo opredelilo uspešnost stavka SQL, ki je bil del delovne obremenitve, ki smo jo nameravali preizkusiti.
S pregledom poročila lahko presodimo in sklepamo o delovanju SQL
Izjave in nato razmestite sistemske spremembe v proizvodnji.
Podobno lahko preizkusimo različne delovne obremenitve z različnimi sistemskimi spremembami in poskrbimo, da preizkusimo vsako od njih, preden jih uvedemo v proizvodnjo.
Zgornji prikaz poteka dela je lahko grafično predstavljen, kot je prikazano spodaj.
Ponovno predvajanje zbirke podatkov
Če želite orodje zagnati prek Enterprise Manager:
(Kliknite sliko za ogled povečave)
Database Replay omogoča realistično testiranje sistemskih sprememb tako, da v bistvu replicira vaše proizvodno okolje na testnem sistemu. To stori tako, da zajame želeno delovno obremenitev v produkcijskem sistemu in jo predvaja v testnem sistemu z natančnimi značilnostmi virov prvotne delovne obremenitve, kot so izvajanje SQL, transakcije, izvlečki in postopki.
To se izvede, da zagotovimo, da upoštevamo vse možne vplive kakršne koli spremembe, vključno z neželenimi rezultati, kot so napake izdelkov, neprimerni rezultati ali regresija učinkovitosti.
Obsežne analize in poročila prav tako pomagajo prepoznati morebitne težave, kot so napačne okoliščine in razlike v delovanju.
Posledično lahko organizacije pri spoprijemanju s spremembami niso prepričane in donosne pri oceni splošnega uspeha sistemskih sprememb. To bo znatno zmanjšalo tveganje, ko želimo uvesti spremembe v proizvodnji. Spremembe so neizogibne in če bomo preizkusili vse vidike te spremembe na vseh stopnjah, bo proizvodnja močnejša in trdnejša.
Osnovni potek ponovitve predvajanja zbirke podatkov je prikazan spodaj:
Spremembe, ki jih podpira predvajanje baze podatkov, so:
- Nadgradnje baze podatkov Oracle, popravljanje programske opreme
- Uporabnik / shema, primer baze podatkov Parametri, kot so pomnilnik, V / I
- Spremembe strojne / programske opreme na vozliščih RAC (Real Application Cluster)
- Spremembe operacijskega sistema, krpanje operacijskega sistema
- CPU, pomnilnik, pomnilnik
Database Replay nam omogoča, da preizkusimo različne učinke morebitnih sprememb sistema s ponovnim prikazovanjem praktične obremenitve dejanskega proizvodnega sistema na testnem sistemu, preden je izpostavljen prvemu. Delovna obremenitev proizvodnje se spremlja, analizira in beleži v količinsko določenem časovnem obdobju. Ti podatki se sčasoma beležijo in se uporabljajo za ponovitev obremenitve na testnih sistemih.
S tem lahko uspešno preizkusimo posledice delovne obremenitve, preden uvedemo kakršne koli spremembe, ki bi lahko negativno vplivale na proizvodnjo.
Potek dela je naslednji:
Korak 1) Zajem delovne obremenitve
Vse zahteve strank zapišemo v datoteke z imenom »Zajemi datoteke« v datotečnem sistemu (pomnilnik). Te datoteke vsebujejo vse ključne informacije o zahtevah odjemalca, kot so SQL, vezave, postopki in informacije o transakcijah. Te datoteke lahko nato izvozite v kateri koli sistem, če jih želimo predvajati v drugem sistemu.
2. korak)Predobdelava delovne obremenitve
Po zajemu informacij v »Zajem datotek« jih moramo predhodno obdelati. V tem koraku ustvarimo metapodatke, ki vsebujejo opis vseh podatkov, potrebnih za predvajanje delovne obremenitve.
Ker ta korak uporablja ogromno virov iz sistema, je priporočljivo, da zaženete v drugem sistemu, razen v produkciji, kjer je obremenitev mogoče predvajati. Če nimate drugega sistema, ki bi ga lahko preizkusili in bi ga radi zagnali v proizvodnji, poskrbite, da ga zaženete v času, ki ni konica, tako da uporabniki in procesi, ki se izvajajo v proizvodnji, ne bodo prizadeti.
3. korak)Ponovno predvajanje delovne obremenitve
Zdaj jih lahko predvajamo na testnem sistemu. Trenutno ponovno predvajamo vse transakcije, kontekst, postopke in SQL, ki so bili prvotno zajeti med fazo zajemanja in zbirajo podatke, ko vsak proces prehaja v ta prehod.
4. korak)Ustvarjanje poročil
Podobno kot Analizator zmogljivosti lahko tudi generirate in si ogledujete poročila, da primerjate vsak preizkus, ki ste ga izvedli.
Za zaključek med preizkušanjem ponovitve zbirke podatkov ponujamo nekaj hitrih nasvetov:
- Uporabite enak testni sistem, kadar koli je to mogoče
- Preizkusite posamezne spremembe, da boste razumeli njihov vpliv
- Ne pozabite začeti s privzetimi možnostmi predvajanja in nato po potrebi spremeniti glede na vaše zahteve.
- Pred izvedbo drugega ponovitve se prepričajte, da ste razumeli vse vidike testiranja
- Shranite rezultate testa in dokumentirajte vse potrebne spremembe / dejanja
- Prepričajte se, da nobena delovna obremenitev ali uporabniki ne uporabljajo sistema med nobenim testnim zagonom
Zaključek:
Z različnimi vidiki in različnimi metodami preskušanja podatkovne baze Oracle in aplikacij vedno poskrbite za čim pogostejše in čim bolj temeljito testiranje; razumeti aplikacijo in uporabniško okolje pred uvedbo kakršnih koli sprememb ali uvedbo novih parametrov v proizvodnji.
Priporočeno branje
- Najboljša orodja za testiranje programske opreme 2021 [QA Test Automation Tools]
- Razlika med testiranjem namizja, odjemalskega strežnika in spletnim preskušanjem
- Kako preizkusiti bazo podatkov Oracle
- Vodič za preizkušanje varnosti spletnih aplikacij
- Testiranje aplikacij - v osnove testiranja programske opreme!
- Namestite svojo aplikacijo v napravo in začnite testirati iz Eclipse
- Preizkus eBook Prenos knjige
- Vadnica za destruktivno testiranje in nedestruktivno testiranje