oracle real application testing solution test oracle db before moving production
Hem arribat a la part final del sèrie de proves d'Oracle Database.
Fins ara hem tractat mètodes de prova de la base de dades Oracle. Continuant aquest enfocament, ens endinsarem en més detalls respecte a les proves d'aplicacions reals d'Oracle.
Avui coneixerem l'Oracle Real Application Testing: un sistema eficaç d'assegurament del canvi que avalua el canvi del sistema en el propi entorn de prova abans d'introduir-lo a la producció.
Aquesta és la solució líder d'Oracle per capturar la càrrega de treball de l'entorn de producció real i substituir-la a t és medi ambient .
Com s'ha indicat en nombroses ocasions, sempre hem d'assegurar-nos que provem la base de dades en totes les dimensions possibles per eradicar les inestabilitats i assegurar-nos que no trobem cap problema imprevist a la nostra instància de producció.
Podem categoritzar Proves d'aplicacions reals d'Oracle en dues grans seccions:
- Analitzador de rendiment SQL
- Repetició de la base de dades
Abans d’anar més enllà, tingueu en compte que SQL Performance Analyzer i Database Replay requereixen llicències addicionals, és a dir, estan disponibles per un cost addicional i una opció Enterprise Edition.
Què aprendreu:
Analitzador de rendiment SQL
La interfície gràfica d’usuari que s’utilitza per accedir a SQL Performance Analyzer i Database Replay és Enterprise Manager, que es mostra a continuació:
Per accedir a SQL Performance Analyzer, feu clic a l'enllaç 'SQL Performance Analyzer'
(Feu clic a la imatge per veure la imatge ampliada)
SQL Performance Analyzer ens permet avaluar l'impacte sobre el rendiment de qualsevol canvi al sistema que pugui tenir un impacte en l'execució i el rendiment de SQL.
Són extremadament útils en casos com:
- Actualització de la base de dades, Patching
- Canvis de configuració del sistema operatiu: programari o maquinari
- Canvis a les estadístiques d'Oracle Optimizer
- Canvis d’usuari / esquema
Sempre es recomana executar SQL Performance Analyze en una prova o un UAT (Prova d'aplicacions d'usuari) més que en un sistema de producció. Ja que, mentre provàvem els efectes del canvi en termes de rendiment, podríem afectar sense voler els usuaris que s’executen a la instància de producció. A més, executar-lo en una prova ens assegurarà que no manipulem els processos de producció actuals.
A A continuació es mostra una visió general bàsica d’un flux de treball de SQL Performance Analyzer:
L’anàlisi del rendiment SQL comporta els passos següents.
Pas 1)Captura de càrrega de treball SQL
Determineu les sentències SQL que formarien part de la vostra càrrega de treball SQL des de la vostra instància de producció que voleu analitzar. Aquesta càrrega de treball hauria de representar idealment la càrrega de treball que podríeu tenir a la producció.
Capturem aquestes afirmacions en un conjunt de sintonització SQL i alimentem aquest conjunt de sintonització SQL a SQL Performance Analyzer.
Com que l'Analyzer consumeix molts recursos al vostre sistema, sempre us recomanem que s'executin en una prova o en un sistema UAT. Per executar-lo en un sistema de prova hauríem d'exportar el conjunt de sintonització SQL que ja hem creat en producció al sistema de prova.
Pas 2)Creació d’una tasca SQL Performance Analyzer
Per executar Analyzer, primer heu de crear una tasca SQL Performance Analyzer. Aquesta tasca no és més que un dipòsit que consolida totes les dades sobre l’anàlisi que executa SQL Performance Analyzer. Com s'ha indicat anteriorment, el conjunt de sintonització SQL s'alimenta com a estimulant a l'analitzador.
el millor netejador de registre gratuït de Windows 7
Pas 3)Prova de rendiment SQL del canvi previ
Després d’haver creat la tasca SQL Performance Analyzer i el conjunt de sintonització SQL, hem de construir la infraestructura al sistema de prova.
Tingueu en compte que quan pensem utilitzar un sistema per provar-los, hem d’assegurar-nos que sigui molt similar al sistema de producció en termes de maquinari, programari i emmagatzematge, de manera que puguem replicar un entorn similar.
Un cop el sistema de prova estigui configurat adequadament, podem construir la versió prèvia al canvi de les dades mitjançant SQL Performance Analyzer.
Això es pot aconseguir utilitzant Enterprise Manager o API (procediments incorporats).
Pas 4)Prova de rendiment SQL després del canvi
La prova posterior al canvi es realitza al sistema de prova després de fer alguns canvis al sistema.
Un cop acabat, tindríem dues proves SQL: una prova prèvia i posterior al canvi per comparar.
De manera similar a la prova de rendiment SQL de pre-canvi, podem crear una prova de rendiment SQL després de canviar mitjançant Enterprise Manager o API (procediments integrats).
Pas 5)Generació d’un informe
Després d’executar les proves de pre-canvi i post-canvi, les dades de rendiment recollides en elles es poden comparar mitjançant una anàlisi de comparació mitjançant SQL Performance Analyzer.
Un cop finalitzada aquesta tasca de comparació, podem generar un informe per identificar el rendiment de la sentència SQL que formava part de la càrrega de treball que preteníem provar.
En revisar l'informe, podem jutjar i treure conclusions sobre el rendiment de l'SQL
Declaracions i després desplegueu els canvis del sistema a la producció.
De la mateixa manera, podem provar diverses càrregues de treball amb diversos canvis del sistema i assegurar-nos que provem cadascuna d’elles abans d’implementar-les a la producció.
El flux de treball il·lustrat anteriorment es pot representar gràficament com es mostra a continuació.
Repetició de la base de dades
Per executar l'eina mitjançant Enterprise Manager:
(Feu clic a la imatge per veure la imatge ampliada)
La reproducció de bases de dades permet fer proves realistes dels canvis del sistema, essencialment replicant el vostre entorn de producció en un sistema de prova. Ho fa capturant la càrrega de treball desitjada al sistema de producció i reproduint-la en un sistema de prova amb les característiques de recursos exactes de la càrrega de treball original, com ara execució SQL, transaccions, extractes i procediments.
Això es realitza per assegurar-nos que considerem tots els possibles impactes de qualsevol canvi, inclosos els resultats no desitjats, com ara errors de producte, resultats inadequats o regressió del rendiment.
Una àmplia anàlisi i informe generat també ajuda a identificar possibles problemes, com ara circumstàncies errònies i divergències de rendiment.
Com a resultat, les organitzacions poden estar segures a l’hora d’afrontar el canvi i ser lucratives en avaluar l’èxit global del canvi de sistema. Això reduirà significativament qualsevol risc quan vulguem implementar els canvis en la producció. El canvi és inevitable i assegurar-nos que provem tots els aspectes d’aquest canvi des de tots els graus farà que la producció sigui més robusta i robusta.
A continuació es mostra un flux de treball bàsic de la reproducció de la base de dades:
Els canvis admesos per Database Replay són:
- Actualitzacions de bases de dades Oracle, pegat de programari
- Usuari / esquema, instància de base de dades Paràmetres com ara memòria, E / S
- Canvis de maquinari / programari als nodes RAC (Real Application Cluster)
- Canvis en el sistema operatiu, pegat del sistema operatiu
- CPU, memòria, emmagatzematge
La reproducció de la base de dades ens permet provar diversos efectes de possibles canvis al sistema reproduint la càrrega pràctica d’un sistema de producció real en un sistema de prova abans que s’exposi al primer. La càrrega de treball de la producció es controla, s’analitza i es registra durant un període fix de temps quantitatiu. Aquestes dades es registren al llarg del temps i s’utilitzen per reproduir la càrrega de treball en sistemes de prova.
En realitzar-ho, podem provar amb èxit les implicacions de la càrrega de treball abans d’implementar qualsevol canvi que pugui afectar negativament la producció.
El flux de treball és el següent:
Pas 1) Captura de càrrega de treball
Registrem totes les sol·licituds realitzades pels clients en fitxers anomenats 'Captura fitxers' al sistema de fitxers (emmagatzematge). Aquests fitxers contenen tota la informació vital relativa a les sol·licituds del client, com ara SQL, vinculacions, procediments i informació de transaccions. Aquests fitxers es poden exportar a qualsevol sistema per si volem reproduir-los en un altre sistema.
Pas 2)Preprocessament de càrrega de treball
Després d’haver capturat la informació dels “Captura de fitxers”, hem de processar-los prèviament. En aquest pas, creem metadades que proporcionen una descripció de totes les dades necessàries per reproduir la càrrega de treball.
Com que aquest pas utilitza una gran quantitat de recursos del sistema, es recomana executar-lo en un altre sistema, a part de la producció on es pugui reproduir la càrrega. En cas que no tingueu un altre sistema per provar i que vulgueu executar-los en producció, assegureu-vos d’executar-los durant les hores no punta perquè els usuaris i els processos que s’executen en producció no es vegin afectats.
Pas 3)Reproducció de càrrega de treball
Ara podem reproduir-los al sistema de prova. En aquest moment, reproduïm totes les transaccions, context, procediments i SQL capturats inicialment durant la fase de captura acumulant dades a mesura que cada procés passa per aquesta transició.
Pas 4)Generació d'informes
De manera similar al Performance Analyzer, també podeu generar i visualitzar informes per comparar cadascuna de les proves que heu executat.
Per concloure, oferim un parell de consells ràpids mentre provem la reproducció de bases de dades:
- Utilitzeu un sistema de prova idèntic a i quan sigui possible
- Proveu un canvi a la vegada per comprendre’n l’impacte
- Assegureu-vos de començar amb les opcions de reproducció predeterminades i, a continuació, feu canvis si cal segons el vostre requisit.
- Abans de realitzar la segona reproducció, assegureu-vos d'entendre tots els aspectes de la prova
- Assegureu-vos de desar els resultats de la prova i documentar els canvis / accions de prova necessaris
- Assegureu-vos que cap altra càrrega de treball ni cap usuari utilitzi el sistema durant cap de les proves de prova
Conclusió:
Amb diversos aspectes i diversos mètodes de proves de bases de dades i d'aplicacions d'Oracle, assegureu-vos sempre de provar el més freqüentment i el més complet possible; entendre l’aplicació i l’entorn de l’usuari abans de desplegar qualsevol alteració o introduir qualsevol paràmetre nou a Production.
Lectura recomanada
- Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
- Diferència entre la prova d'escriptori, el servidor de clients i la prova web
- Com provar la base de dades Oracle
- Guia de proves de seguretat d'aplicacions web
- Proves d'aplicacions: els conceptes bàsics de la prova de programari.
- Instal·lació de l'aplicació al dispositiu i inici de proves des d'Eclipse
- Prova de descàrrega de llibres electrònics
- Tutorial de proves destructives i proves no destructives