oracle real application testing solution test oracle db before moving production
Přišli jsme k závěrečné části série testování databáze Oracle.
Zatím jsme se zabývali metody testování databáze Oracle. V tomto zaměření se ponoříme do dalších podrobností týkajících se Oracle Real Application Testing.
Dnes se naučíme Oracle Real Application Testing - efektivní systém zabezpečování změn, který před zavedením do výroby vyhodnotí samotnou změnu systému v testovacím prostředí.
Toto je přední řešení společnosti Oracle k zachycení zátěže reálného produkčního prostředí DB a jeho nahrazení na t je prostředí .
Jak již bylo uvedeno při mnoha příležitostech, vždy se musíme ujistit, že testujeme databázi v každé možné dimenzi, abychom odstranili nestability, a abychom se ujistili, že v naší produkční instanci nenarazíme na žádné nepředvídané problémy.
Můžeme kategorizovat Testování aplikací Oracle Real do dvou širokých sekcí:
- Analyzátor výkonu SQL
- Replay databáze
Než půjdeme dále, vezměte prosím na vědomí, že SQL Performance Analyzer a Database Replay vyžaduje další licencování, tj. Je k dispozici za příplatek a možnost Enterprise Edition.
Co se naučíte:
Analyzátor výkonu SQL
GUI používaným pro přístup k SQL Performance Analyzer a Database Replay je Enterprise Manager, který je zobrazen níže:
Chcete-li získat přístup k nástroji SQL Performance Analyzer, klikněte na odkaz „SQL Performance Analyzer“
(Klikněte na obrázek pro zvětšení)
SQL Performance Analyzer nám umožňuje měřit dopad na výkon jakékoli změny v systému, která by mohla mít dopad na provádění a výkon SQL.
Jsou velmi užitečné v případech, jako jsou:
- Upgrade databáze, oprava
- Změny konfigurace operačního systému - software nebo hardware
- Změny statistik Oracle Optimizer
- Změny uživatele / schématu
Vždy se doporučuje spustit analýzu výkonu SQL na testu nebo UAT (Testování uživatelských aplikací) spíše než na produkčním systému. Protože při testování účinků změny z hlediska výkonu bychom mohli nechtěně ovlivnit uživatele běžící v produkční instanci. Spuštění na test také zajistí, že nebudeme manipulovat s žádnými aktuálně spuštěnými procesy ve výrobě.
NA základní přehled pracovního postupu nástroje SQL Performance Analyzer je uveden níže:
Analýza výkonu SQL zahrnuje následující kroky.
Krok 1)Zachycení pracovní zátěže SQL
Určete příkazy SQL, které by byly součástí vašeho pracovního vytížení SQL z vaší produkční instance, které byste chtěli analyzovat. Toto pracovní vytížení by mělo ideálně představovat pracovní vytížení, které byste mohli mít ve své produkci.
Zachycujeme tyto příkazy v sadě ladění SQL a dodáváme tuto sadu ladění SQL do analyzátoru výkonu SQL.
Vzhledem k tomu, že analyzátor ve vašem systému spotřebovává velké množství prostředků, vždy doporučujeme nechat je běžet v testovacím systému nebo v systému UAT. Abychom jej mohli spustit na testovacím systému, museli bychom do testovacího systému exportovat sadu SQL Tuning, kterou jsme již vytvořili ve výrobě.
Krok 2)Vytvoření úlohy analyzátoru výkonu SQL
Chcete-li spustit analyzátor, musíte nejprve vytvořit úlohu analyzátoru výkonu SQL. Tento úkol není nic jiného než úložiště, které konsoliduje všechna data o analýze prováděné analyzátorem výkonu SQL. Jak bylo uvedeno výše, sada pro ladění SQL se přivádí jako stimulant do analyzátoru.
k čemu se dnes používá java
Krok č. 3)Předběžná zkušební verze výkonu SQL
Po vytvoření úlohy SQL Performance Analyzer a sady pro ladění SQL musíme vybudovat infrastrukturu v testovacím systému.
Vezměte prosím na vědomí, že když plánujeme k testování použít systém, musíme se ujistit, že je velmi podobný produkčnímu systému z hlediska hardwaru, softwaru a úložiště, abychom mohli replikovat podobné prostředí.
Jakmile je testovací systém správně nakonfigurován, můžeme sestavit verzi před změnou dat pomocí nástroje SQL Performance Analyzer.
Toho lze dosáhnout pomocí Enterprise Manager nebo API (vestavěné procedury).
Krok č. 4)Zkouška výkonu SQL po změně
Po provedení některých změn v systému se zkušební verze po změně provádí na testovacím systému.
Jakmile je to dokončeno, měli bychom dvě SQL zkoušky - jednu před změnou a po změně zkoušku k porovnání.
Podobně jako u předběžné změny výkonu SQL, můžeme vytvořit zkušební verzi výkonu po změně pomocí Enterprise Manager nebo API (vestavěné procedury).
Krok č. 5)Generování zprávy
Po provedení zkoušek před změnou a po změně lze údaje o výkonu shromážděné v nich porovnat spuštěním srovnávací analýzy pomocí nástroje SQL Performance Analyzer.
Po dokončení této srovnávací úlohy můžeme vygenerovat zprávu, která identifikuje výkon příkazu SQL, který byl součástí úlohy, kterou jsme chtěli otestovat.
Zkontrolováním zprávy můžeme posoudit a učinit závěry o výkonu SQL
Příkazy a poté nasadit změny systému v produkčním prostředí.
Podobně můžeme testovat různá pracovní zatížení s různými změnami systému a ujistit se, že testujeme každou z nich před jejich implementací do výroby.
Pracovní postup znázorněný výše lze graficky znázornit, jak je znázorněno níže.
Replay databáze
Spuštění nástroje prostřednictvím Enterprise Manager:
(Klikněte na obrázek pro zvětšení)
Database Replay umožňuje realistické testování systémových změn zásadní replikací vašeho produkčního prostředí na testovacím systému. Dělá to zachycením požadovaného pracovního vytížení v produkčním systému a jeho přehráním v testovacím systému s přesnými charakteristikami zdrojů původního pracovního vytížení, jako je provádění SQL, transakce, extrakty a procedury.
To se provádí, abychom se ujistili, že bereme v úvahu všechny možné dopady jakékoli změny, včetně nežádoucích výsledků, jako jsou chyby produktu, nevhodné výsledky nebo regrese výkonu.
Rozsáhlé generované analýzy a zprávy také pomáhají identifikovat potenciální problémy, jako jsou chybné okolnosti a rozdíly v výkonu.
Výsledkem je, že si organizace mohou být jisti, že se budou zabývat změnami, a budou lukrativní při hodnocení celkového úspěchu změny systému. To výrazně sníží jakékoli riziko, když chceme implementovat změny ve výrobě. Změna je nevyhnutelná a díky tomu, že otestujeme všechny aspekty této změny ze všech stupňů, bude výroba robustnější a robustnější.
Základní pracovní postup přehrání databáze je uveden níže:
Změny podporované přehráním databáze jsou:
- Upgrady databáze Oracle, oprava softwaru
- Uživatel / Schéma, Parametry instance databáze, jako je paměť, I / O
- Změny hardwaru / softwaru v uzlech RAC (Real Application Cluster)
- Změny operačního systému, oprava operačního systému
- CPU, paměť, úložiště
Přehrávání databáze nám umožňuje otestovat různé účinky možných změn systému přehráním praktického zatížení skutečného produkčního systému na testovacím systému, než bude vystaven předchozímu. Pracovní zátěž výroby je sledována, analyzována a zaznamenávána po kvantitativně pevně stanovenou dobu. Tato data se zaznamenávají v průběhu času a používají se k přehrání pracovní zátěže na testovacích systémech.
Provedením tohoto můžeme úspěšně otestovat důsledky pracovního vytížení před implementací jakýchkoli změn, které by mohly nepříznivě ovlivnit produkci.
Pracovní postup je následující:
Krok 1) Zachycení pracovní zátěže
Zaznamenáváme všechny požadavky klientů do souborů označovaných jako „Zachytit soubory“ v systému souborů (úložiště). Tyto soubory obsahují všechny důležité informace týkající se požadavků klienta, jako jsou SQL, vazby, procedury a informace o transakcích. Tyto soubory lze poté exportovat do libovolného systému pro případ, že je chceme přehrát v jiném systému.
Krok 2)Předzpracování pracovní zátěže
Poté, co jsme zachytili informace v „Capture files“, musíme je předzpracovat. V tomto kroku vytvoříme metadata, která poskytují popis všech dat požadovaných pro přehrání pracovního vytížení.
Vzhledem k tomu, že tento krok využívá obrovské množství zdrojů ze systému, je doporučeno jej provozovat v jiném systému kromě produkce, kde lze zatížení přehrát. V případě, že nemáte k testování jiný systém a chtěli byste je spustit ve výrobě, nezapomeňte je spustit mimo špičku, aby to neovlivnilo uživatele a procesy běžící ve výrobě.
Krok č. 3)Přehrávání pracovního vytížení
Nyní je můžeme přehrát na testovacím systému. V tuto chvíli přehráváme všechny transakce, kontext, procedury a SQL, které byly původně zachyceny během fáze zachycení a shromažďují data, protože každý proces prochází tímto přechodem.
Krok č. 4)Generování zpráv
Podobně jako u analyzátoru výkonu můžete také generovat a prohlížet sestavy pro porovnání každého z testů, které jste provedli.
Na závěr nabízíme několik rychlých tipů při testování přehrávání databáze:
- Pokud je to možné, používejte identický testovací systém
- Otestujte jednu změnu najednou, abyste pochopili její dopad
- Nezapomeňte začít s výchozími možnostmi přehrávání a poté podle potřeby provést změny podle vašeho požadavku.
- Před provedením druhého přehrání nezapomeňte porozumět všem aspektům testování
- Nezapomeňte uložit výsledky testu a zdokumentovat všechny požadované změny / akce testování
- Ujistěte se, že během jakéhokoli testovacího běhu systém nepoužívá žádná jiná pracovní zátěž ani uživatelé
Závěr:
Díky různým aspektům a různým metodám testování databáze a aplikací Oracle se vždy snažte testovat co nejčastěji a nejdůkladněji; porozumět aplikaci a uživatelskému prostředí před nasazením jakýchkoli změn nebo zavedením nových parametrů v produkci.
Doporučené čtení
- Nejlepší nástroje pro testování softwaru 2021 (QA Test Automation Tools)
- Rozdíl mezi desktopem, klientským serverem a webovým testováním
- Jak testovat databázi Oracle
- Průvodce testováním zabezpečení webových aplikací
- Testování aplikací - do základů testování softwaru!
- Instalace aplikace na zařízení a zahájení testování z Eclipse
- Testování stahování e-knih Primer
- Výukový program pro destruktivní testování a nedestruktivní testování