oracle real application testing solution test oracle db before moving production
Nous sommes arrivés à la dernière partie de la série de tests de base de données Oracle.
Jusqu'à présent, nous avons traité méthodes de test de la base de données Oracle. Poursuivant cet objectif, nous approfondirons les détails concernant Oracle Real Application Testing.
Aujourd'hui, nous allons apprendre Oracle Real Application Testing - un système efficace d'assurance des changements qui évalue le changement du système dans l'environnement de test lui-même avant de l'introduire en production.
Il s'agit de la principale solution d'Oracle pour capturer la charge de travail DB de l'environnement de production réel et la remplacer sur t est environment .
Comme indiqué à de nombreuses reprises, nous devons toujours nous assurer que nous testons la base de données dans toutes les dimensions possibles pour éradiquer les instabilités et pour nous assurer que nous ne rencontrons aucun problème imprévu dans notre instance de production.
Nous pouvons catégoriser Test des applications réelles Oracle en deux grandes sections:
- Analyseur de performances SQL
- Relecture de la base de données
Avant d'aller plus loin, veuillez noter que SQL Performance Analyzer et Database Replay nécessitent une licence supplémentaire, c'est-à-dire qu'il est disponible avec un coût supplémentaire et une option Enterprise Edition.
Ce que vous apprendrez:
Analyseur de performances SQL
L'interface graphique utilisée pour accéder à SQL Performance Analyzer et Database Replay est Enterprise Manager, comme illustré ci-dessous:
Pour accéder à SQL Performance Analyzer, cliquez simplement sur le lien «SQL Performance Analyzer»
(Cliquez sur l'image pour l'agrandir)
SQL Performance Analyzer nous permet d'évaluer l'impact sur les performances de toute modification du système susceptible d'avoir un impact sur l'exécution et les performances SQL.
Ils sont extrêmement utiles dans des cas tels que:
- Mise à niveau de la base de données, correction
- Modifications de la configuration du système d'exploitation - Logiciel ou matériel
- Modifications des statistiques d'Oracle Optimizer
- Modifications utilisateur / schéma
Il est toujours conseillé d'exécuter SQL Performance Analyze sur un test ou un UAT (test d'application utilisateur) système plutôt que sur un système de production. Depuis, tout en testant les effets du changement en termes de performances, nous pourrions affecter par inadvertance les utilisateurs exécutés dans l'instance de production. De plus, l'exécuter sur un test garantira que nous n'altérerons aucun processus en cours d'exécution en production.
À La présentation de base d'un flux de travail SQL Performance Analyzer est présentée ci-dessous:
L'analyse des performances SQL implique les étapes suivantes.
Étape 1)Capture de la charge de travail SQL
Déterminez les instructions SQL qui feraient partie de votre charge de travail SQL à partir de votre instance de production que vous souhaitez analyser. Cette charge de travail doit idéalement représenter la charge de travail que vous pourriez avoir dans votre production.
Nous capturons ces instructions dans un ensemble de réglages SQL et transmettons cet ensemble de réglages SQL à SQL Performance Analyzer.
Étant donné que l'analyseur consomme beaucoup de ressources sur votre système, nous vous recommandons toujours de les exécuter sur un test ou un système UAT. Pour l'exécuter sur un système de test, nous devrions exporter l'ensemble de réglage SQL que nous avons déjà créé en production dans le système de test.
Étape 2)Création d'une tâche SQL Performance Analyzer
Pour exécuter l'analyseur, vous devez d'abord créer une tâche SQL Performance Analyzer. Cette tâche n'est rien d'autre qu'un référentiel qui consolide toutes les données relatives à l'analyse exécutée par SQL Performance Analyzer. Comme indiqué précédemment, l'ensemble de réglage SQL est alimenté en tant que stimulant vers l'analyseur.
fonctions friend en c ++
Étape 3)Essai de performances SQL avant le changement
Après avoir créé la tâche SQL Performance Analyzer et l'ensemble de réglages SQL, nous devons construire l'infrastructure sur le système de test.
Veuillez noter que lorsque nous prévoyons d'utiliser un système pour tester, nous devons nous assurer qu'il est très similaire au système de production en termes de matériel, de logiciel et de stockage afin que nous puissions reproduire un environnement similaire.
Une fois que le système de test est correctement configuré, nous pouvons créer la version pré-modification des données à l'aide de SQL Performance Analyzer.
Cela peut être réalisé en utilisant Enterprise Manager ou des API (procédures intégrées).
Étape 4)Essai des performances SQL après modification
L'essai post-changement est effectué sur le système de test après avoir apporté quelques modifications au système.
Une fois cela terminé, nous aurions deux essais SQL - un essai avant et après changement à comparer.
Semblable à l'essai de performance SQL avant modification, nous pouvons créer un essai de performance SQL après modification à l'aide d'Enterprise Manager ou d'API (procédures intégrées).
Étape # 5)Générer un rapport
Après avoir exécuté les essais avant et après modification, les données de performances collectées peuvent être comparées en exécutant une analyse de comparaison à l'aide de SQL Performance Analyzer.
Une fois cette tâche de comparaison terminée, nous pouvons générer un rapport pour identifier les performances de l'instruction SQL qui faisait partie de la charge de travail que nous avions l'intention de tester.
En examinant le rapport, nous pouvons juger et tirer des conclusions sur les performances du SQL
Déclarations puis déployer les modifications du système en production.
De même, nous pouvons tester différentes charges de travail avec diverses modifications du système et nous assurer que nous testons chacune d'entre elles avant de les mettre en œuvre en production.
Le flux de travail illustré ci-dessus peut être représenté graphiquement comme indiqué ci-dessous.
Relecture de la base de données
Pour exécuter l'outil via Enterprise Manager:
(Cliquez sur l'image pour l'agrandir)
Database Replay permet de tester de manière réaliste les modifications du système en répliquant essentiellement votre environnement de production sur un système de test. Pour ce faire, il capture une charge de travail souhaitée sur le système de production et la rejoue sur un système de test avec les caractéristiques exactes des ressources de la charge de travail d'origine, telles que l'exécution SQL, les transactions, les extraits et les procédures.
Ceci est effectué pour nous assurer que nous considérons tous les impacts possibles de tout changement, y compris les résultats indésirables tels que les bogues du produit, les résultats inappropriés ou la régression des performances.
Une analyse approfondie et des rapports générés aident également à identifier les problèmes potentiels, tels que les circonstances erronées rencontrées et les divergences de performances.
En conséquence, les organisations peuvent être assurées de faire face au changement et être lucratives dans l'évaluation du succès global du changement de système. Cela réduira considérablement tout risque lorsque nous voulons mettre en œuvre les changements de production. Le changement est inévitable et s'assurer que nous testons tous les aspects de ce changement à tous les degrés rendra la production plus robuste et plus robuste.
Un flux de travail de base de la réexécution de la base de données est illustré ci-dessous:
Les modifications prises en charge par Database Replay sont:
- Mises à niveau de la base de données Oracle, correctifs logiciels
- Utilisateur / schéma, paramètres d'instance de base de données tels que la mémoire, les E / S
- Modifications matérielles / logicielles des nœuds RAC (Real Application Cluster)
- Modifications du système d'exploitation, correctifs du système d'exploitation
- CPU, mémoire, stockage
Database Replay nous permet de tester divers effets d'éventuelles modifications du système en rejouant la charge pratique d'un système de production réel sur un système de test avant qu'il ne soit exposé au premier. La charge de travail sur la production est surveillée, analysée et enregistrée sur une période de temps fixe quantitative. Ces données sont enregistrées au fil du temps et sont utilisées pour rejouer la charge de travail sur les systèmes de test.
En effectuant cette opération, nous pouvons tester avec succès les implications de la charge de travail avant d'implémenter toute modification susceptible d'affecter la production.
Le flux de travail est le suivant:
Étape 1) Capture de la charge de travail
Nous enregistrons toutes les demandes faites par les clients dans des fichiers appelés «fichiers de capture» sur le système de fichiers (stockage). Ces fichiers contiennent toutes les informations vitales concernant les demandes des clients telles que SQL, les liaisons, les procédures et les informations de transaction. Ces fichiers peuvent ensuite être exportés vers n'importe quel système au cas où nous souhaiterions les rejouer sur un autre système.
Étape 2)Prétraitement de la charge de travail
Après avoir capturé les informations dans les «Fichiers de capture», nous devons les prétraiter. Dans cette étape, nous créons des métadonnées qui fournissent une description de toutes les données requises pour relire la charge de travail.
Étant donné que cette étape utilise une énorme quantité de ressources du système, il est conseillé de s'exécuter sur un autre système en dehors de la production où la charge peut être rejouée. Si vous n'avez pas d'autre système à tester et que vous souhaitez les exécuter en production, assurez-vous de les exécuter pendant les heures creuses afin que les utilisateurs et les processus exécutés en production ne soient pas affectés.
Étape 3)Relecture de la charge de travail
Maintenant, nous pouvons les rejouer sur le système de test. À ce stade, nous rejouons toutes les transactions, le contexte, les procédures et le SQL qui ont été capturés initialement pendant la phase de capture, en accumulant des données à mesure que chaque processus subit cette transition.
Étape 4)Générer des rapports
À l'instar de l'Analyseur de performances, vous pouvez également générer et afficher des rapports pour comparer chacun des tests que vous avez exécutés.
Pour conclure, nous proposons quelques conseils rapides lors du test de Database Replay:
- Utilisez un système de test identique lorsque cela est possible
- Testez un changement à la fois pour comprendre son impact
- Assurez-vous de commencer avec les options de relecture par défaut, puis apportez des modifications si nécessaire en fonction de vos besoins.
- Avant d'effectuer la deuxième relecture, assurez-vous de comprendre tous les aspects du test
- Assurez-vous de sauvegarder vos résultats de test et de documenter les modifications / actions de test requises
- Assurez-vous qu'aucune autre charge de travail ou utilisateur n'utilise le système pendant les exécutions de test
Conclusion:
Avec divers aspects et diverses méthodes de test de base de données Oracle et d'application, veuillez toujours vous assurer de tester aussi fréquemment et aussi minutieusement que possible; comprendre l'application et l'environnement utilisateur avant de déployer des modifications ou d'introduire de nouveaux paramètres dans la production.
lecture recommandée
- Meilleurs outils de test de logiciels 2021 (Outils d'automatisation des tests QA)
- Différence entre les tests de bureau, client-serveur et Web
- Comment tester Oracle Database
- Guide de test de sécurité des applications Web
- Test d'applications - Dans les bases du test de logiciels!
- Installation de votre application sur l'appareil et démarrage des tests à partir d'Eclipse
- Téléchargement du livre électronique sur les tests
- Tutoriel sur les tests destructifs et les tests non destructifs