oracle real application testing solution test oracle db before moving production
Vi har kommet til den siste delen av serie av Oracle Database Testing.
Så langt har vi taklet metoder for å teste Oracle-databasen. Fortsetter dette fokuset, vil vi dykke ned i ytterligere detaljer med hensyn til Oracle Real Application Testing.
I dag vil vi lære Oracle Real Application Testing - et effektivt endringssikringssystem som vurderer systemendringen i selve testmiljøet før vi introduserer det for produksjon.
Dette er den ledende løsningen fra Oracle for å fange opp det virkelige produksjonsmiljøet DB arbeidsmengde og erstatte det på t er miljø .
Som nevnt ved flere anledninger, må vi alltid sørge for at vi tester databasen i alle mulige dimensjoner for å utrydde ustabilitet og for å sikre at vi ikke støter på uforutsette problemer i vår produksjonsinstans.
Vi kan kategorisere Oracle Real Application Testing i to brede seksjoner:
- SQL Performance Analyzer
- Databaseavspilling
Før vi går videre, vær oppmerksom på at SQL Performance Analyzer og Database Replay krever ekstra lisensiering, det vil si at den er tilgjengelig mot en ekstra kostnad og et Enterprise Edition-alternativ.
Hva du vil lære:
SQL Performance Analyzer
GUI-en som brukes for å få tilgang til SQL Performance Analyzer og Database Replay er Enterprise Manager, som er som vist nedenfor:
For å få tilgang til SQL Performance Analyzer klikker du bare på 'SQL Performance Analyzer' -linken
(Klikk på bildet for å se forstørret)
SQL Performance Analyzer gjør det mulig for oss å måle ytelseseffekten av endringer i systemet som kan ha innvirkning på SQL-utførelse og ytelse.
De er ekstremt nyttige i tilfeller som:
- Databaseoppgradering, patching
- Konfigurasjonsendringer i operativsystemet - Programvare eller maskinvare
- Oracle Optimizer-statistikk endres
- Endringer av bruker / skjema
Det anbefales alltid å kjøre SQL Performance Analyze på en test eller a UAT (testing av brukerapplikasjoner) systemet i stedet for på et produksjonssystem. Siden vi testet effekten av endringen når det gjelder ytelse, kan vi utilsiktet påvirke brukerne som kjører i produksjonsinstansen. Å kjøre den på en test vil også sikre at vi ikke tukler med nåværende prosesser som kjører på produksjonen.
TIL grunnleggende oversikt over en arbeidsflyt for SQL Performance Analyzer er vist nedenfor:
SQL ytelsesanalyse innebærer følgende trinn.
Trinn 1)Fange SQL-arbeidsbelastning
Bestem SQL-setningene som vil være en del av SQL-arbeidsbelastningen fra produksjonsforekomsten din som du vil analysere. Denne arbeidsmengden skal ideelt sett representere arbeidsmengden du måtte ha i produksjonen din.
Vi fanger opp disse setningene i et SQL-innstillingssett og mater dette SQL-innstillingssettet til SQL Performance Analyzer.
Siden analysatoren bruker mye ressurser på systemet ditt, anbefaler vi alltid å kjøre dem på en test eller et UAT-system. For å kjøre det på et testsystem måtte vi eksportere SQL Tuning-settet som vi allerede har opprettet i produksjonen til testsystemet.
Steg 2)Opprette en SQL Performance Analyzer Task
For å kjøre Analyzer, må du først opprette en SQL Performance Analyzer-oppgave. Denne oppgaven er ingenting annet enn et arkiv som konsoliderer alle data om analysen som blir utført av SQL Performance Analyzer. Som tidligere angitt, mates SQL Tuning Set som et stimulerende middel til analysatoren.
youtube til mp3 converter app gratis nedlasting
Trinn 3)Pre-Change SQL Performance Trial
Etter å ha opprettet SQL Performance Analyzer-oppgaven og SQL Tuning Set, må vi bygge infrastrukturen på testsystemet.
Vær oppmerksom på at når vi planlegger å bruke et system til å teste, må vi sørge for at det er veldig likt produksjonssystemet når det gjelder maskinvare, programvare og lagring, slik at vi kan replikere et lignende miljø.
Når testsystemet er riktig konfigurert, kan vi bygge forhåndsendringsversjonen av dataene ved hjelp av SQL Performance Analyzer.
Dette kan oppnås ved å bruke enten Enterprise Manager eller API-er (innebygde prosedyrer).
Trinn 4)Etterprestasjon for SQL-ytelse
Testen etter endring utføres på testsystemet etter å ha gjort noen endringer i systemet.
Når dette er fullført, vil vi ha to SQL-prøver - en prøve før endring og etter endring å sammenligne.
I likhet med Pre-Change SQL performance Trial, kan vi opprette SQL Performance-prøveversjon etter endring ved hjelp av enten Enterprise Manager eller API-er (innebygde prosedyrer).
Trinn 5)Genererer en rapport
Etter å ha utført forsøkene etter endring og etter endring, kan ytelsesdataene som er samlet inn i dem, sammenlignes ved å kjøre en sammenligningsanalyse ved hjelp av SQL Performance Analyzer.
Når denne sammenligningsoppgaven er fullført, kan vi generere en rapport for å identifisere ytelsen til SQL-setningen som var en del av arbeidsmengden vi hadde til hensikt å teste.
Ved å gjennomgå rapporten kan vi bedømme og trekke konklusjoner om ytelsen til SQL
Uttalelser og deretter distribuere systemendringene i produksjonen.
På samme måte kan vi teste forskjellige arbeidsbelastninger med forskjellige systemendringer og sørge for at vi tester hver enkelt av dem før vi implementerer dem i produksjonen.
Arbeidsflyten illustrert ovenfor kan vises grafisk som vist nedenfor.
Databaseavspilling
Slik kjører du verktøyet gjennom Enterprise Manager:
(Klikk på bildet for å se forstørret)
Database Replay tillater realistisk testing av systemendringer ved å replikere produksjonsmiljøet ditt på et testsystem. Den gjør dette ved å fange opp ønsket arbeidsbelastning på produksjonssystemet og spille den på et testsystem med de nøyaktige ressurskarakteristikkene til den opprinnelige arbeidsmengden, for eksempel SQL-kjøring, transaksjoner, utdrag og prosedyrer.
Dette utføres for å sikre at vi vurderer alle mulige konsekvenser av endringer, inkludert uønskede resultater som produktfeil, upassende resultater eller ytelsesregresjon.
Omfattende analyse og rapportering generert hjelper også til å identifisere potensielle problemer, for eksempel feilaktige omstendigheter og ytelsesforskjeller.
Som et resultat kan organisasjoner være trygg når de takler endring og være lukrative i å vurdere den generelle suksessen til systemendringen. Dette vil redusere risikoen betydelig når vi ønsker å implementere endringene i produksjonen. Endring er uunngåelig, og å sørge for at vi tester alle aspekter av denne endringen fra alle grader, vil gjøre produksjonen mer robust og solid.
En grunnleggende arbeidsflyt for databaseavspillingen er som vist nedenfor:
Endringer som støttes av Database Replay er:
- Oracle Database-oppgraderinger, programvareoppdatering
- Bruker / skjema, databaseforekomst Parametere som minne, I / U
- Maskinvare- / programvareendringer i RAC-noder (Real Application Cluster)
- Operativsystemendringer, oppdatering av operativsystem
- CPU, minne, lagring
Database Replay lar oss teste forskjellige effekter av mulige endringer i systemet ved å spille den praktiske belastningen til et faktisk produksjonssystem på et testsystem før det blir utsatt for det tidligere. Arbeidsbelastningen på produksjonen overvåkes, analyseres og registreres over en kvantitativ fast periode. Disse dataene registreres over tid og brukes til å spille arbeidsmengden på testsystemer på nytt.
Ved å utføre dette kan vi teste konsekvensene av arbeidsmengden før vi implementerer endringer som kan påvirke produksjonen negativt.
Arbeidsflyten er som følger:
Trinn 1) Fange arbeidsmengde
Vi registrerer alle forespørsler fra klienter om filer kalt 'Capture files' på filsystemet (lagring). Disse filene inneholder all viktig informasjon om klientforespørsler som SQL, bindinger, prosedyrer og transaksjonsinformasjon. Disse filene kan deretter eksporteres til hvilket som helst system i tilfelle vi vil spille dem på et annet system.
Steg 2)Forbehandling av arbeidsmengde
Etter å ha fanget informasjonen i 'Capture files' må vi behandle dem på forhånd. I dette trinnet lager vi metadata som gir en beskrivelse av alle data som kreves for å spille av arbeidsmengden på nytt.
Siden dette trinnet bruker enorme mengder ressurser fra systemet, anbefales det å kjøre på et annet system bortsett fra produksjon der lasten kan spilles på nytt. I tilfelle du ikke har et annet system å teste, og du vil kjøre dem i produksjon, må du sørge for å kjøre dem i løpet av ikke-peak timer, slik at brukerne og prosessene som kjører på produksjonen ikke påvirkes.
Trinn 3)Arbeidsbelastning på nytt
Nå kan vi spille dem på nytt på testsystemet. På dette tidspunktet spiller vi av alle transaksjonene, konteksten, prosedyrene og SQL som ble fanget i utgangspunktet i fangstfasen, og samlet data, ettersom hver prosess gjennomgår denne overgangen.
Trinn 4)Genererer rapporter
I likhet med Performance Analyzer kan du også generere og vise rapporter for å sammenligne hver av testene du har utført.
For å avslutte tilbyr vi et par raske tips mens du tester Database Replay:
- Bruk identisk testsystem når det er mulig
- Test en endring av gangen for å forstå dens innvirkning
- Forsikre deg om å starte med standard omspillingsalternativer og deretter gjøre endringer om nødvendig basert på dine krav.
- Før du utfører andre omspillingen, må du forstå alle testaspektene
- Sørg for å lagre testresultatene og dokumentere eventuelle endringer / testhandlinger som kreves
- Forsikre deg om at ingen andre arbeidsmengder eller brukere bruker systemet under noen av testkjøringene
Konklusjon:
Med forskjellige aspekter og forskjellige metoder for Oracle Database og Application Testing, må du alltid sørge for å teste så ofte og så grundig som mulig; forstå applikasjonen og brukermiljøet før du implementerer endringer eller introduserer nye parametere i produksjonen.
Anbefalt lesing
- Beste verktøy for testing av programvare 2021 [QA Test Automation Tools]
- Forskjellen mellom Desktop, Client Server Testing og Web Testing
- Hvordan teste Oracle Database
- Veiledning for testing av webapplikasjoner
- Søknadstesting - inn i det grunnleggende om programvaretesting!
- Installere applikasjonen din på enheten og start testing fra Eclipse
- Testing Primer eBook Download
- Destruktiv testing og ikke-destruktiv testing