oracle real application testing solution test oracle db before moving production
Vi er kommet til den sidste del af programmet serie af Oracle Database Testing.
Indtil videre har vi behandlet det metoder til test af Oracle-databasen. Fortsat dette fokus vil vi dykke ned i yderligere detaljer med hensyn til Oracle Real Application Testing.
I dag lærer vi Oracle Real Application Testing - et effektivt ændringssikringssystem, der vurderer systemændringen i selve testmiljøet, før det introduceres til produktion.
Dette er den førende løsning fra Oracle til at fange det virkelige produktionsmiljø DB arbejdsbelastning og erstatte det på t er miljø .
Som nævnt ved flere lejligheder er vi altid nødt til at sikre os, at vi tester databasen i enhver mulig dimension for at udrydde ustabiliteter og for at sikre, at vi ikke støder på uforudsete problemer i vores produktionsinstans.
Vi kan kategorisere Oracle Real Application Testing i to brede sektioner:
- SQL Performance Analyzer
- Afspilning af database igen
Inden vi går videre, skal du være opmærksom på, at SQL Performance Analyzer og Database Replay kræver yderligere licens, dvs. det er tilgængeligt mod et ekstra gebyr og en Enterprise Edition-mulighed.
Hvad du vil lære:
SQL Performance Analyzer
GUI'en, der bruges til at få adgang til SQL Performance Analyzer og Database Replay, er Enterprise Manager, som er som vist nedenfor:
For at få adgang til SQL Performance Analyzer skal du blot klikke på 'SQL Performance Analyzer' -linket
(Klik på billedet for at se det forstørrede)
SQL Performance Analyzer giver os mulighed for at måle ydeevneeffekten af enhver ændring i systemet, der kan have en indvirkning på SQL-udførelse og ydeevne.
De er yderst nyttige i tilfælde som:
- Databaseopgradering, patching
- Konfigurationsændringer til operativsystemet - Software eller hardware
- Oracle Optimizer-statistikændringer
- Ændringer af bruger / skema
Det tilrådes altid at køre SQL Performance Analyze på en test eller a UAT (test af brugerapplikationer) system snarere end på et produktionssystem. Da vi under testning af virkningerne af ændringen med hensyn til ydeevne kunne utilsigtet påvirke de brugere, der kører i produktionsinstansen. At køre det på en test vil også sikre, at vi ikke manipulerer med nuværende kørende processer under produktion.
TIL grundlæggende oversigt over en SQL Performance Analyzer-arbejdsgang er vist nedenfor:
SQL Performance-analyse involverer følgende trin.
Trin 1)Optagelse af SQL-arbejdsbelastning
Bestem de SQL-sætninger, der ville være en del af din SQL-arbejdsbyrde fra din produktionsinstans, som du gerne vil analysere. Denne arbejdsbyrde skal ideelt set repræsentere den arbejdsbyrde, du måtte have i din produktion.
Vi indfanger disse udsagn i et SQL-tuning-sæt og føder dette SQL-tuning-sæt til SQL Performance Analyzer.
Da Analyzer bruger mange ressourcer på dit system, anbefaler vi altid at lade dem køre på en test eller et UAT-system. For at køre det på et testsystem skulle vi eksportere det SQL Tuning-sæt, som vi allerede har oprettet i produktionen, til testsystemet.
Trin 2)Oprettelse af en SQL Performance Analyzer-opgave
For at køre Analyzer skal du først oprette en SQL Performance Analyzer-opgave. Denne opgave er intet andet end et lager, der konsoliderer alle data om analysen, der udføres af SQL Performance Analyzer. Som tidligere angivet tilføres SQL Tuning Set som et stimulerende middel til analysatoren.
Trin # 3)Pre-Change SQL Performance Trial
Efter at have oprettet SQL Performance Analyzer-opgaven og SQL Tuning Set, er vi nødt til at bygge infrastrukturen på testsystemet.
Bemærk, at når vi planlægger at bruge et system til at teste, er vi nødt til at sikre, at det ligner meget produktionssystemet med hensyn til hardware, software og opbevaring, så vi kan replikere et lignende miljø.
Når testsystemet er konfigureret korrekt, kan vi oprette den forudskiftede version af dataene ved hjælp af SQL Performance Analyzer.
Dette kan opnås ved hjælp af enten Enterprise Manager eller API'er (indbyggede procedurer).
Trin # 4)Prøveversion af SQL-præstation efter ændring
Prøven efter ændring udføres på testsystemet efter at have foretaget nogle ændringer i systemet.
Når dette er afsluttet, vil vi have to SQL-forsøg - en prøve før ændring og efter ændring at sammenligne.
Svarende til Pre-Change SQL performance Trial, kan vi oprette SQL Performance-prøveversion efter ændring ved hjælp af enten Enterprise Manager eller API'er (indbyggede procedurer).
Trin # 5)Generering af en rapport
Efter udførelsen af forsøgene før ændring og efter ændring kan præstationsdataene, der er indsamlet i dem, sammenlignes ved at køre en sammenligningsanalyse ved hjælp af SQL Performance Analyzer.
Når denne sammenligningsopgave er afsluttet, kan vi generere en rapport for at identificere SQL-sætningens ydeevne, som var en del af den arbejdsbyrde, vi havde til hensigt at teste.
Ved at gennemgå rapporten kan vi bedømme og drage konklusioner om udførelsen af SQL
Erklæringer og derefter implementere systemændringerne i produktionen.
På samme måde kan vi teste forskellige arbejdsbelastninger med forskellige systemændringer og sørge for, at vi tester hver enkelt af dem, inden de implementeres i produktionen.
Workflowet illustreret ovenfor kan vises grafisk som vist nedenfor.
Afspilning af database igen
Sådan køres værktøjet gennem Enterprise Manager:
(Klik på billedet for at se det forstørrede)
bedste gratis sikkerhedskopieringssoftware til Windows 7 64 bit
Database Replay tillader realistisk test af systemændringer ved i det væsentlige at replikere dit produktionsmiljø på et testsystem. Det gør det ved at indfange en ønsket arbejdsbyrde på produktionssystemet og afspille det igen på et testsystem med de nøjagtige ressourceegenskaber for den oprindelige arbejdsbyrde, såsom SQL-udførelse, transaktioner, uddrag og procedurer.
Dette udføres for at sikre, at vi overvejer alle mulige virkninger af enhver ændring inklusive uønskede resultater såsom produktfejl, upassende resultater eller præstationsregression.
Omfattende analyse og rapportering genereret hjælper også med at identificere eventuelle problemer, såsom fejlagtige omstændigheder, der er stødt på og præstationsforskelle.
Som et resultat kan organisationer være sikre på, når de beskæftiger sig med ændringer, og være lukrative i vurderingen af systemændringens samlede succes. Dette reducerer enhver risiko markant, når vi ønsker at gennemføre ændringer i produktionen. Ændring er uundgåelig, og det at gøre produktionen mere robust og robust at sikre, at vi tester alle aspekter af denne ændring fra alle grader.
En grundlæggende arbejdsgang i databasens gentagelse er som vist nedenfor:
Ændringer, der understøttes af Database Replay er:
- Oracle Database Opgraderinger, Software Patching
- Bruger / skema, databaseforekomst Parametre som hukommelse, I / O
- Hardware- / softwareændringer i RAC-noder (Real Application Cluster)
- Operativsystemændringer, Patching af operativsystem
- CPU, hukommelse, opbevaring
Database Replay giver os mulighed for at teste forskellige effekter af mulige ændringer i systemet ved at afspille den praktiske belastning af et faktisk produktionssystem på et testsystem, før det udsættes for det tidligere. Arbejdsbelastningen ved produktion overvåges, analyseres og registreres over en kvantitativ fast periode. Disse data registreres over tid og bruges til at afspille arbejdsbyrden på testsystemer.
Ved at udføre dette kan vi med succes teste konsekvenserne af arbejdsbyrden inden implementering af ændringer, der kan påvirke produktionen negativt.
Workflowet er som følger:
Trin 1) Registrering af arbejdsbyrde
Vi registrerer alle anmodninger fra klienter i filer kaldet 'Capture files' på filsystemet (lagring). Disse filer indeholder alle vigtige oplysninger om klientanmodninger såsom SQL, bindinger, procedurer og transaktionsoplysninger. Disse filer kan derefter eksporteres til ethvert system, hvis vi vil afspille dem igen på et andet system.
Trin 2)Forarbejdning af arbejdsbyrde
Efter at have fanget informationen i “Capture files” skal vi forbehandle dem. I dette trin opretter vi metadata, der giver en beskrivelse af alle data, der kræves til genafspilning af arbejdsbyrden.
Da dette trin bruger en enorm mængde ressourcer fra systemet, tilrådes det at køre på et andet system bortset fra produktion, hvor belastningen kan afspilles igen. I tilfælde af at du ikke har et andet system til at teste og gerne vil køre dem i produktion, skal du sørge for at køre dem i ikke-spidsbelastningstimer, så brugerne og processer, der kører på produktionen, ikke påvirkes.
Trin # 3)Afspilning af arbejdsbelastning
Nu kan vi afspille dem igen på testsystemet. På dette tidspunkt afspiller vi alle de transaktioner, kontekst, procedurer og SQL, der oprindeligt blev fanget under opsamlingsfasen, og akkumulerede data, da hver proces gennemgår denne overgang.
Trin # 4)Genererer rapporter
I lighed med Performance Analyzer kan du også generere og se rapporter for at sammenligne hver af de test, du har udført.
Afslutningsvis tilbyder vi et par hurtige tip, mens du tester databasegenopspilning:
- Brug identisk testsystem, når og når det er muligt
- Test en ændring ad gangen for at forstå dens indvirkning
- Sørg for at starte med standardindstillingerne for gentagelse, og foretag derefter ændringer, hvis det er nødvendigt, baseret på dit krav.
- Før du udfører den anden gentagelse, skal du sørge for at forstå alle testaspekterne
- Sørg for at gemme dine testresultater og dokumentere eventuelle ændringer / testhandlinger, der kræves
- Sørg for, at ingen anden arbejdsbyrde eller brugere bruger systemet under nogen af testkørslerne
Konklusion:
Med forskellige aspekter og forskellige metoder til Oracle Database og Application Testing skal du altid sørge for at teste så ofte og så grundigt som muligt; forstå applikationen og brugermiljøet inden implementering af ændringer eller introduktion af nye parametre i produktionen.
Anbefalet læsning
- Bedste softwaretestværktøjer 2021 [QA Test Automation Tools]
- Forskel mellem Desktop, Client Server Testing og Web Testing
- Sådan testes Oracle Database
- Vejledning til test af webapplikationssikkerhed
- Applikationstest - ind i det grundlæggende ved softwaretest!
- Installation af din applikation på enheden og start test fra Eclipse
- Test af Primer eBook Download
- Destruktiv test og ikke-destruktiv testvejledning