PL/SQLPackagesSchémas
Vérifiez les modifications PL/SQL importantes et comprenez leur impact sur toute l'application.
Une inspection systématique du PL/SQL, avec le contexte nécessaire avant qu'une modification n'arrive en production : dépendances, impact, données d'exécution et suivi des corrections.
L'IA peut accélérer le développement PL/SQL. Les modifications importantes exigent toujours une vérification indépendante.
Inspectez le PL/SQL, qu'il soit écrit par un développeur ou généré par une IA, avec une analyse distincte et reproductible : les mêmes règles à chaque analyse, des résultats conservés dans le temps et une nouvelle analyse pour confirmer chaque correction.
- Vulnérabilités, bugs et problèmes de maintenabilité dans l'ensemble du code PL/SQL analysé.
- Règles de sécurité pour Oracle : injection SQL dans le SQL dynamique, injection de commandes, défaillances cryptographiques, gestion incorrecte des exceptions.
- Nouveaux défauts signalés à chaque analyse, pour voir ce qu'une modification a introduit.
- Inspection continue dans votre chaîne CI/CD, avant le déploiement.
Un défaut ne dit pas tout. Voyez à quoi il est relié.
À partir d'une procédure, d'un package, d'un trigger, d'une table ou d'une colonne, explorez les appelants, les appelés, l'usage des données et les dépendances entre schémas avant de décider comment modifier le code.
- Analyse d'impact au niveau des procédures, fonctions, packages, tables et colonnes.
- Graphes d'appels et graphes d'appels inverses pour les chaînes PL/SQL complexes.
- Matrices CRUD : quel code crée, lit, modifie ou supprime chaque table.
- Objets potentiellement inutilisés listés pour examen. Les références construites uniquement en SQL dynamique ne sont pas visibles par l'analyse statique.
Faites des résultats d'analyse un processus de remédiation piloté
Examinez et hiérarchisez les défauts, appuyez-vous sur le contexte applicatif pour évaluer le risque, attribuez le travail, corrigez le code et laissez l'analyse suivante confirmer la correction.
- Qualifier les résultats : faux positif, risque accepté ou mise en attente. Les décisions et l'historique restent enregistrés.
- Attribuer un défaut crée une tâche, avec un responsable, une priorité et une échéance.
- Mark as fixed : le défaut reste à l'état Pending Validation jusqu'à ce que l'analyse suivante le vérifie.
- Potential Solution (IA) propose une piste de correction lorsque VE AI est activé.
Cycle de vie d'un défaut
Les défauts examinés peuvent aussi être mis de côté. Leur historique est conservé.
Risk AcceptedFalse PositiveOn Hold
Reliez les points chauds de l'exécution au code et aux dépendances qui les expliquent
Quand l'analyse statique ne suffit pas, Visual Expert croise les statistiques d'exécution d'Oracle avec son modèle de l'application : l'optimisation commence là où elle compte.
- Procédures, fonctions et triggers les plus lents, par temps d'exécution moyen.
- Temps d'exécution cumulé : temps moyen multiplié par le nombre d'exécutions.
- Temps d'exécution le long d'une chaîne d'appels, pour trouver l'objet qui ralentit un traitement.
- Statistiques collectées sur votre serveur Oracle, idéalement en production, ou sur une base de test suffisamment utilisée.
Comprendre avant de moderniser ou de migrer
Avant de restructurer le PL/SQL, de déplacer la logique vers une autre architecture ou de quitter Oracle, faites l'inventaire du code, de ses dépendances et de l'usage des données pour cadrer le projet et limiter les surprises.
- Structure de l'application et chaînes de dépendances évaluées avant la transformation.
- Fonctionnalités Oracle obsolètes ou plus prises en charge détectées avant une montée de version, de 18c à 23ai.
- Code potentiellement mort listé, pour exclure du périmètre les composants à faible valeur.
- Documentation générée et tenue à jour, à partager avec les équipes de modernisation.
Suivez les dépendances au-delà d'un seul schéma
Les grandes applications Oracle s'étendent sur plusieurs schémas, parfois sur plusieurs bases. Visual Expert cartographie les références entre eux : la modification d'un objet partagé ne casse pas du code que vous n'avez pas examiné.
Les objets d'autres schémas qui appellent les schémas sélectionnés : ce qu'une modification peut casser ailleurs.
Les objets des schémas sélectionnés qui s'appuient sur d'autres schémas : ce qu'ils utilisent du reste du projet.
Déclarez le schéma ou la base cible de chaque lien pour résoudre les références entre applications.
S'adapte à la façon dont votre code Oracle est stocké
Analysez le PL/SQL directement dans la base ou à partir de fichiers source. Les analyses s'actualisent selon un planning ou depuis Jenkins, et toute l'équipe travaille sur les mêmes résultats dans le navigateur.
Depuis la base ou depuis des fichiers
Connectez-vous à votre base Oracle, y compris Oracle Cloud, ou analysez des fichiers et des dossiers source PL/SQL.
Plusieurs schémas, database links
Suivez les références entre schémas et déclarez les cibles des database links pour résoudre les références entre applications.
Gestion de versions et automatisation
Lisez le code dans Git, SVN ou TFS et actualisez les analyses selon un planning ou depuis Jenkins.
Partagé dans Visual Expert Web
Résultats, documentation, défauts et tâches dans le navigateur, sans installation pour l'équipe.
Pour aller plus loin
La vérification du code à l'ère de l'IA
Pourquoi les modifications assistées par l'IA exigent toujours une vérification indépendante.
Migration Oracle
Préparer un projet de migration.
Utiliser Toad et Visual Expert
Comment les deux outils fonctionnent ensemble.
Tarifs
Éditions et licences.
Mesurez l'impact de votre prochaine modification PL/SQL avant de la faire
Analysez votre propre application Oracle et examinez avec notre équipe les résultats de la vérification, les dépendances, les données d'exécution et les pistes de correction.
Vous préférez une présentation guidée ? Demander une démo
Je ne me souviens pas d'un outil aussi puissant qui permette à un développeur de se familiariser avec une application en seulement quelques heures.
