oracle real application testing solution test oracle db before moving production
Siamo giunti alla parte finale del serie di Oracle Database Testing.
Finora, abbiamo affrontato metodi per testare il database Oracle. Continuando questo focus ci immergeremo in ulteriori dettagli rispetto a Oracle Real Application Testing.
Oggi impareremo Oracle Real Application Testing, un sistema efficace di change assurance che valuta il cambiamento di sistema nell'ambiente di test stesso prima di introdurlo in produzione.
Questa è la soluzione leader di Oracle per acquisire il carico di lavoro del DB dell'ambiente di produzione reale e sostituirlo su t è l'ambiente .
Come affermato in numerose occasioni, dobbiamo sempre assicurarci di testare il database in ogni possibile dimensione per eliminare le instabilità e per assicurarci di non incontrare problemi imprevisti nella nostra istanza di produzione.
Possiamo classificare Oracle Real Application Testing in due ampie sezioni:
- SQL Performance Analyzer
- Replay del database
Prima di procedere, tieni presente che SQL Performance Analyzer e Database Replay richiedono licenze aggiuntive, ovvero sono disponibili a un costo aggiuntivo e un'opzione Enterprise Edition.
Cosa imparerai:
SQL Performance Analyzer
La GUI utilizzata per accedere a SQL Performance Analyzer e Database Replay è Enterprise Manager, come mostrato di seguito:
Per accedere a SQL Performance Analyzer è sufficiente fare clic sul collegamento 'SQL Performance Analyzer'
(Clicca sull'immagine per visualizzarla ingrandita)
SQL Performance Analyzer ci consente di valutare l'impatto sulle prestazioni di qualsiasi modifica al sistema che potrebbe avere un impatto sull'esecuzione e sulle prestazioni di SQL.
Sono estremamente utili in casi come:
- Aggiornamento del database, patch
- Modifiche alla configurazione del sistema operativo: software o hardware
- Modifiche alle statistiche di Oracle Optimizer
- Modifiche utente / schema
Si consiglia sempre di eseguire l'analisi delle prestazioni SQL su un test o un file UAT (User Application Testing) sistema piuttosto che su un sistema di produzione. Poiché, durante il test degli effetti del cambiamento in termini di prestazioni, potremmo inavvertitamente influenzare gli utenti in esecuzione nell'istanza di produzione. Inoltre, eseguirlo su un test assicurerà di non manomettere alcun processo attualmente in esecuzione in produzione.
PER La panoramica di base di un flusso di lavoro di SQL Performance Analyzer è mostrata di seguito:
SQL Performance Analysis prevede i seguenti passaggi.
Passo 1)Acquisizione del carico di lavoro SQL
Determina le istruzioni SQL che faranno parte del tuo carico di lavoro SQL dall'istanza di produzione che desideri analizzare. Questo carico di lavoro dovrebbe idealmente rappresentare il carico di lavoro che potresti avere nella tua produzione.
Catturiamo queste istruzioni in un set di ottimizzazione SQL e forniamo questo set di ottimizzazione SQL all'analizzatore delle prestazioni SQL.
Poiché Analyzer consuma molte risorse sul sistema, consigliamo sempre di eseguirle su un sistema di test o UAT. Per eseguirlo su un sistema di test dovremmo esportare il set SQL Tuning che abbiamo già creato in produzione nel sistema di test.
Passo 2)Creazione di un'attività SQL Performance Analyzer
Per eseguire Analyzer, è necessario prima creare un'attività di SQL Performance Analyzer. Questa attività non è altro che un repository che consolida tutti i dati sull'analisi eseguita da SQL Performance Analyzer. Come indicato in precedenza, l'SQL Tuning Set viene alimentato come stimolante all'analizzatore.
elimina un elemento da un array java
Passaggio 3)Prova delle prestazioni SQL pre-modifica
Dopo aver creato l'attività di SQL Performance Analyzer e il set di ottimizzazione SQL, è necessario creare l'infrastruttura sul sistema di test.
Tieni presente che quando pianifichiamo di utilizzare un sistema per testare, dobbiamo assicurarci che sia molto simile al sistema di produzione in termini di hardware, software e archiviazione in modo da poter replicare un ambiente simile.
Una volta configurato il sistema di test, è possibile creare la versione precedente alla modifica dei dati utilizzando SQL Performance Analyzer.
Ciò può essere ottenuto utilizzando Enterprise Manager o API (procedure integrate).
Passaggio 4)Prova delle prestazioni SQL post-modifica
La prova Post-Change viene eseguita sul sistema di test dopo aver apportato alcune modifiche al sistema.
Una volta completato, avremmo due prove SQL: una prima della modifica e una dopo la modifica da confrontare.
Simile alla versione di prova delle prestazioni SQL precedente alla modifica, possiamo creare una versione di prova delle prestazioni SQL successiva alla modifica utilizzando Enterprise Manager o API (procedure integrate).
Passaggio 5)Generazione di un report
Dopo aver eseguito le prove di pre-modifica e post-modifica, i dati sulle prestazioni raccolti in essi possono essere confrontati eseguendo un'analisi di confronto utilizzando SQL Performance Analyzer.
Una volta completata questa attività di confronto, possiamo generare un rapporto per identificare le prestazioni dell'istruzione SQL che faceva parte del carico di lavoro che intendevamo testare.
Esaminando il rapporto, possiamo giudicare e trarre conclusioni sulle prestazioni dell'SQL
Dichiarazioni e quindi distribuire le modifiche di sistema in produzione.
Allo stesso modo, possiamo testare vari carichi di lavoro con varie modifiche al sistema e assicurarci di testare ciascuno di essi prima di implementarli in produzione.
Il flusso di lavoro illustrato sopra può essere rappresentato graficamente come mostrato di seguito.
Replay del database
Per eseguire lo strumento tramite Enterprise Manager:
(Clicca sull'immagine per visualizzarla ingrandita)
Database Replay consente di eseguire test realistici delle modifiche al sistema replicando essenzialmente l'ambiente di produzione su un sistema di test. Lo fa catturando un carico di lavoro desiderato sul sistema di produzione e riproducendolo su un sistema di test con le esatte caratteristiche delle risorse del carico di lavoro originale come l'esecuzione SQL, le transazioni, le estrazioni e le procedure.
Ciò viene eseguito per assicurarsi di considerare tutti i possibili impatti di qualsiasi modifica, inclusi risultati indesiderati come bug del prodotto, risultati inappropriati o regressione delle prestazioni.
Analisi approfondite e rapporti generati aiutano anche a identificare potenziali problemi, come circostanze errate incontrate e divergenze di prestazioni.
Di conseguenza, le organizzazioni possono stare tranquille quando si occupano del cambiamento ed essere redditizie nel valutare il successo complessivo del cambiamento del sistema. Ciò ridurrà in modo significativo qualsiasi rischio quando vogliamo implementare i cambiamenti nella produzione. Il cambiamento è inevitabile e assicurandosi di testare ogni aspetto di questo cambiamento a tutti i livelli renderà la produzione più robusta e robusta.
Di seguito è illustrato un flusso di lavoro di base della riproduzione del database:
Le modifiche supportate da Database Replay sono:
- Aggiornamenti del database Oracle, patch del software
- Utente / schema, istanza di database Parametri come memoria, I / O
- Modifiche hardware / software ai nodi RAC (Real Application Cluster)
- Modifiche al sistema operativo, patch del sistema operativo
- CPU, memoria, archiviazione
Database Replay ci consente di testare vari effetti di possibili modifiche al sistema riproducendo il carico pratico di un sistema di produzione effettivo su un sistema di test prima che sia esposto al primo. Il carico di lavoro sulla produzione viene monitorato, analizzato e registrato su un periodo di tempo fisso quantitativo. Questi dati vengono registrati nel tempo e vengono utilizzati per riprodurre il carico di lavoro sui sistemi di test.
In questo modo, possiamo testare con successo le implicazioni del carico di lavoro prima di implementare eventuali modifiche che potrebbero influire negativamente sulla produzione.
Il flusso di lavoro è il seguente:
Passo 1) Acquisizione del carico di lavoro
Registriamo tutte le richieste effettuate dai client in file denominati 'Capture files' sul file system (archiviazione). Questi file contengono tutte le informazioni vitali riguardanti le richieste del client come SQL, binding, procedure e informazioni sulle transazioni. Questi file possono quindi essere esportati su qualsiasi sistema nel caso in cui desideriamo riprodurli su un altro sistema.
Passo 2)Pre-elaborazione del carico di lavoro
Dopo aver catturato le informazioni nei 'File di cattura' dobbiamo preelaborarle. In questo passaggio, creiamo metadati che forniscono una descrizione di tutti i dati necessari per riprodurre il carico di lavoro.
Poiché questo passaggio utilizza un'enorme quantità di risorse dal sistema, si consiglia di eseguire su un altro sistema diverso dalla produzione in cui il carico può essere riprodotto. Nel caso in cui non disponi di un altro sistema da testare e desideri eseguirli in produzione, assicurati di eseguirli durante le ore non di punta in modo che gli utenti e i processi in esecuzione in produzione non siano interessati.
Passaggio 3)Riproduzione del carico di lavoro
Ora possiamo riprodurli sul sistema di test. A questo punto, riproduciamo tutte le transazioni, il contesto, le procedure e l'SQL che sono stati acquisiti inizialmente durante la fase di acquisizione, accumulando dati mentre ogni processo subisce questa transizione.
Passaggio 4)Generazione di rapporti
Simile all'analizzatore delle prestazioni, puoi anche generare e visualizzare report per confrontare ciascuno dei test che hai eseguito.
Per concludere, offriamo un paio di suggerimenti rapidi durante il test di Database Replay:
- Utilizzare lo stesso sistema di test come e quando possibile
- Prova una modifica alla volta per comprenderne l'impatto
- Assicurati di iniziare con le opzioni di riproduzione predefinite e quindi apportare le modifiche se necessario in base alle tue esigenze.
- Prima di eseguire il secondo replay, assicurati di aver compreso tutti gli aspetti del test
- Assicurati di salvare i risultati del test e documenta eventuali modifiche / azioni di test richieste
- Assicurarsi che nessun altro carico di lavoro o utenti stiano utilizzando il sistema durante le esecuzioni di test
Conclusione:
Con vari aspetti e vari metodi di Oracle Database e Application Testing, assicurati sempre di testare il più frequentemente e nel modo più accurato possibile; comprendere l'applicazione e l'ambiente utente prima di implementare qualsiasi modifica o introdurre nuovi parametri in produzione.
Lettura consigliata
- Migliori strumenti di test del software 2021 [Strumenti di automazione del test QA]
- Differenza tra desktop, test server client e test Web
- Come testare il database Oracle
- Guida al test di sicurezza delle applicazioni Web
- Test delle applicazioni: le basi del test del software!
- Installazione dell'applicazione sul dispositivo e avvio del test da Eclipse
- Download dell'eBook Testing Primer
- Tutorial sui test distruttivi e non distruttivi