oracle real application testing solution test oracle db before moving production
Vi har kommit till den sista delen av serie Oracle Database Testing.
Hittills har vi hanterat metoder för att testa Oracle-databasen. Fortsatt detta fokus kommer att dyka in i ytterligare detaljer med avseende på Oracle Real Application Testing.
Idag lär vi oss Oracle Real Application Testing - ett effektivt ändringssäkringssystem som utvärderar systemförändringen i testmiljön själv innan den introduceras i produktion.
Detta är den ledande lösningen från Oracle för att fånga den verkliga produktionsmiljön DB arbetsbelastning och ersätta den på t är miljö .
Som nämnts vid flera tillfällen måste vi alltid se till att vi testar databasen i alla möjliga dimensioner för att utrota instabiliteter och se till att vi inte stöter på några oförutsedda problem i vår produktionsinstans.
Vi kan kategorisera Oracle Real Application Testing i två breda sektioner:
- SQL Performance Analyzer
- Databasuppspelning
Innan vi går vidare, Observera att SQL Performance Analyzer och Database Replay kräver ytterligare licensiering, dvs. det är tillgängligt till en extra kostnad och ett Enterprise Edition-alternativ.
Vad du kommer att lära dig:
SQL Performance Analyzer
GUI som används för att komma åt SQL Performance Analyzer och Database Replay är Enterprise Manager, vilket är som visas nedan:
För att komma åt SQL Performance Analyzer klickar du bara på länken 'SQL Performance Analyzer'
(Klicka på bilden för att se förstorad)
SQL Performance Analyzer gör det möjligt för oss att mäta prestandapåverkan av alla ändringar i systemet som kan ha en inverkan på SQL-körning och prestanda.
De är extremt användbara i fall som:
- Databasuppgradering, patchning
- Konfigurationsändringar i operativsystemet - Programvara eller hårdvara
- Oracle Optimizer-statistikändringar
- Ändringar av användare / schema
Det rekommenderas alltid att köra SQL Performance Analyze på ett test eller a UAT (test av användarapplikation) snarare än på ett produktionssystem. Eftersom vi, medan vi testade effekterna av förändringen i termer av prestanda, oavsiktligt kunde påverka de användare som kör i produktionsinstansen. Att köra den på ett test kommer också att säkerställa att vi inte manipulerar med de processer som för närvarande körs vid produktion.
TILL grundläggande översikt över ett SQL Performance Analyzer-arbetsflöde visas nedan:
SQL Performance-analys innefattar följande steg.
Steg 1)Fångar SQL-arbetsbelastning
Bestäm de SQL-uttalanden som skulle vara en del av din SQL-arbetsbelastning från din produktionsinstans som du vill analysera. Denna arbetsbelastning bör helst representera den arbetsbelastning som du kan ha i din produktion.
Vi fångar dessa uttalanden i en SQL Tuning Set och matar denna SQL Tuning Set till SQL Performance Analyzer.
Eftersom Analyzer förbrukar mycket resurser på ditt system, rekommenderar vi alltid att de körs på ett test eller ett UAT-system. För att köra det på ett testsystem måste vi exportera SQL Tuning-uppsättningen som vi redan har skapat i produktionen till testsystemet.
Steg 2)Skapa en SQL Performance Analyzer-uppgift
För att köra analysatorn måste du först skapa en SQL Performance Analyzer-uppgift. Denna uppgift är inget annat än ett arkiv som konsoliderar all data om analysen som utförs av SQL Performance Analyzer. Som anges tidigare matas SQL Tuning Set som en stimulant till analysatorn.
i allmänhet finns de flesta fel (defekter) i vilka två testperioder?
Steg 3)Pre-Change SQL Performance Trial
Efter att ha skapat SQL Performance Analyzer-uppgiften och SQL Tuning Set måste vi bygga infrastrukturen på testsystemet.
Observera att när vi planerar att använda ett system för att testa, måste vi se till att det liknar produktionssystemet när det gäller hårdvara, programvara och lagring så att vi kan replikera en liknande miljö.
När testsystemet har konfigurerats på rätt sätt kan vi bygga den pre-change versionen av data med SQL Performance Analyzer.
Detta kan uppnås genom att använda antingen Enterprise Manager eller API: er (inbyggda procedurer).
Steg 4)SQL-prestandaförsök efter ändring
Försöket efter ändring utförs på testsystemet efter att ha gjort några ändringar i systemet.
När detta är slutfört skulle vi ha två SQL-försök - en pre-change och post-change-test att jämföra.
I likhet med Pre-Change SQL-prestandaförsök kan vi skapa SQL-prestandaförsök efter ändring med antingen Enterprise Manager eller API: er (inbyggda procedurer).
Steg # 5)Skapa en rapport
Efter att ha genomfört försöken före förändring och efter förändring kan prestandadata som samlas in i dem jämföras genom att köra en jämförelsesanalys med SQL Performance Analyzer.
När denna jämförelseuppgift är klar kan vi generera en rapport för att identifiera SQL-uttalandets prestanda som var en del av den arbetsbelastning som vi tänkte testa.
Genom att granska rapporten kan vi bedöma och dra slutsatser om SQL-prestanda
Uttalanden och sedan distribuera systemändringarna i produktionen.
På samma sätt kan vi testa olika arbetsbelastningar med olika systemändringar och se till att vi testar var och en av dem innan de implementeras i produktionen.
Arbetsflödet som illustreras ovan kan visas grafiskt enligt nedan.
Databasuppspelning
Så här kör du verktyget via Enterprise Manager:
(Klicka på bilden för att se förstorad)
Databasuppspelning möjliggör realistisk testning av systemändringar genom att i huvudsak replikera din produktionsmiljö på ett testsystem. Det gör detta genom att fånga en önskad arbetsbelastning på produktionssystemet och spela upp den på ett testsystem med de exakta resursegenskaperna för den ursprungliga arbetsbelastningen som SQL-körning, transaktioner, utdrag och procedurer.
Detta utförs för att säkerställa att vi överväger alla möjliga effekter av förändringar inklusive oönskade resultat som produktfel, olämpliga resultat eller prestationsregression.
Omfattande analys och rapportering som genereras hjälper också till att identifiera eventuella problem, såsom felaktiga omständigheter och prestationsskillnader.
Som ett resultat kan organisationer vara säkra på att hantera förändringar och vara lukrativa när de bedömer systemförändringens totala framgång. Detta minskar all risk avsevärt när vi vill genomföra förändringarna i produktionen. Förändring är oundviklig och att se till att vi testar alla aspekter av denna förändring från alla grader kommer att göra produktionen mer robust och robust.
Ett grundläggande arbetsflöde för databasuppspelningen är som visas nedan:
Ändringar som stöds av databasuppspelning är:
- Oracle-databasuppgraderingar, programvarupatching
- Användare / schema, databasinstans Parametrar som minne, I / O
- Hårdvaru- / programvaruändringar i RAC-noder (Real Application Cluster)
- Ändringar av operativsystem, korrigering av operativsystem
- CPU, minne, lagring
Med Database Replay kan vi testa olika effekter av möjliga ändringar av systemet genom att spela upp den praktiska belastningen för ett verkligt produktionssystem på ett testsystem innan det exponeras för det förra. Arbetsbelastningen vid produktion övervakas, analyseras och registreras under en kvantitativ fast tidsperiod. Dessa data registreras över tiden och används för att spela upp arbetsbelastningen på testsystem.
Genom att utföra detta kan vi framgångsrikt testa konsekvenserna av arbetsbelastningen innan vi implementerar ändringar som kan påverka produktionen negativt.
Arbetsflödet är som följer:
Steg 1) Fångst av arbetsbelastning
Vi registrerar alla förfrågningar från klienter till filer som kallas 'Fånga filer' i filsystemet (lagring). Dessa filer innehåller all viktig information angående klientförfrågningar som SQL, bindningar, procedurer och transaktionsinformation. Dessa filer kan sedan exporteras till vilket system som helst om vi vill spela upp dem på ett annat system.
Steg 2)Förbearbetning av arbetsbelastning
Efter att ha hämtat informationen i ”Fånga filer” måste vi förbehandla dem. I det här steget skapar vi metadata som ger en beskrivning av alla data som krävs för att spela upp arbetsbelastningen.
Eftersom detta steg använder enorma resurser från systemet, rekommenderas det att köras på ett annat system förutom produktion där belastningen kan spelas om. Om du inte har något annat system att testa och vill köra dem i produktion, se till att köra dem under icke-topp timmar så att användare och processer som körs på produktion inte påverkas.
Steg 3)Uppspelning av arbetsbelastning
Nu kan vi spela dem igen i testsystemet. Vid den här tiden spelar vi upp alla transaktioner, sammanhang, procedurer och SQL som ursprungligen registrerades under fångningsfasen och ackumulerade data eftersom varje process genomgår denna övergång.
Steg 4)Skapa rapporter
På samma sätt som Performance Analyzer kan du också skapa och visa rapporter för att jämföra var och en av de tester som du har utfört.
Avslutningsvis erbjuder vi ett par snabba tips när vi testar Database Replay:
- Använd identiskt testsystem när det är möjligt
- Testa en förändring i taget för att förstå dess inverkan
- Se till att börja med standardalternativ för omspelning och gör ändringar om det behövs baserat på ditt krav.
- Innan du utför den andra omspelningen, se till att du förstår alla testaspekter
- Se till att spara dina testresultat och dokumentera eventuella ändringar / teståtgärder som krävs
- Se till att ingen annan arbetsbelastning eller användare använder systemet under någon av testkörningarna
Slutsats:
Med olika aspekter och olika metoder för Oracle Database and Application Testing, se alltid till att testa så ofta och så grundligt som möjligt; förstå applikationen och användarmiljön innan du distribuerar några ändringar eller inför nya parametrar i produktionen.
Rekommenderad läsning
- Bästa verktyg för testning av programvara 2021 (QA Test Automation Tools)
- Skillnad mellan Desktop, Client Server Testing och Web Testing
- Hur man testar Oracle Database
- Handbok för testning av webbapplikation
- Applikationstestning - till grunderna för programvarutestning!
- Installera din applikation på enheten och börja testa från Eclipse
- Testing Primer eBook Download
- Handledning med destruktiv testning och icke-destruktiv testning