Pourquoi utiliser ActiveBase |
La productivité de développement des applications
PB provient principalement du fait que les outils de développement
pour PB prennent en charge la génération automatique
des ordres SQL d’accès à la base et soulagent
le développeur de ces tâches. Or avec le temps,
les temps d’exécution peuvent se dégrader
pour plusieurs raisons :
- Les stratégies d’exécution de l’optimiseur
d’Oracle évoluent avec les versions d’Oracle,
et les ordres générés peuvent être
traités selon des plans d’exécution
différents
- Les volumes de données augmentent et il est parfois
nécessaire de « forcer » l’usage
de certains paramètres de l’optimiseur pour
tenir compte de ces nouveaux volumes ou de la répartition
des valeurs dans les index, etc…
- Des opérations sur la base ont été
effectuées par les DBA qui auraient nécessité
de revoir la génération des ordres SQL opérés
dans les divers programmes PB, mais qui va « modifier
un programme qui marche » uniquement pour le faire
marcher mieux ? Avec le temps, cela entraîne des dégradations
de performances importantes.
- De nombreux ordres SQL sont générés
dynamiquement à partir des écrans de saisie
(fonction QBE), avec des champs non toujours renseignés,
des conversions automatiques dues à des types de
données différentes, des fonctions sur des
colonnes inhibant l’usage des index etc… rendant
l’optimisation de ces ordres dans le code impossible.
- Etc…
 |
Avec ActiveBase,
divisez les temps d’exécution
par 5, 10 ou plus !
- Pour toutes les applications ou progiciels
utilisant une base de données Oracle.
- Sans modifier la base de données
- Sans aucune modification
du code de l’application |
|
|
Principe simple et rapide |
La phase d’optimisation se passe en deux temps : une
phase « off-line » et une phase « on-line
».
En mode off-line, les outils d’ActiveBase
(ActiveBase Expert™ et ActiveBase Tuning Robot™)
vont automatiser les processus suivants:
1. Aider à « identifier » les ordres
SQL candidats à optimisation.
Par exemple un ordre qui dure 2 heures et qui pénalise
la génération d’un rapport, ou bien
des ordres de 30 secondes, mais qui sont exécutés
fréquemment dans des contextes d’utilisation
interactive.
2. Pour chacun de ces ordres, ils vont rechercher la combinaison
de paramètres de l’optimiseur produisant le
meilleur temps d’exécution.
Ces paramètres tiendront compte de la manière
dont l’ordre SQL est construit et de la version d’Oracle
cible. Cette combinaison de paramètres peut-être
ajoutée sous forme de ‘Hint’ à
l’ordre SQL original. Elle ne change pas la logique
de l’ordre lui-même et ne fait qu’indiquer
à l’optimiseur de prendre en compte les paramètres
fournis.
Exemple :
Si une table contient plusieurs colonnes avec des Index,
elle peut forcer l’usage d’un Index particulier,
ou inhiber l’usage d’un Index,…
Cette recherche du meilleur Hint peut se faire en tâche
de fond en périodes creuses sur l’environnement
de production avec les données réelles actuelles,
ou sur un environnement de pré-production.
En mode on-line, ActiveBase fournit ActiveBase
Performance™ serveur :
1. ActiveBase Performance™ serveur s’installe
entre les applications PB et les serveurs Oracle. Il intercepte
les ordres SQL émis par les applications PB.
2. Son moteur de règles identifie les ordres SQL
ayant fait l’objet d’une optimisation par les
outils Expert ou le Tuning Robot.
3. Il ajoute à l’ordre SQL, à la volée,
le « meilleur Hint » trouvé et envoie
l’ordre SQL ainsi modifié à Oracle pour
une exécution optimisée.
Les outils d’analyse SQL peuvent mettre en évidence
certaines constructions d’ordres nécessitant
d’être modifiées pour optimisation. Si
ces ordres SQL sont codés en dur, il est possible de
les modifier en intervenant dans le code des applications,
mais souvent, ils sont générés dynamiquement.
ActiveBase Base offre la possibilité de créer
des règles « génériques »
qui analyseront les requêtes SQL en transit vers la
base, et identifieront celles qui doivent être changées.
Il leur appliquera les changements requis et les enverra ensuite
vers la base pour exécution optimisée.
Une seule règle pourra ainsi traiter des centaines
voire des milliers de requêtes.
Exemple :
Des requêtes SQL permettant de filtrer des informations
sur un mois donné pourra être écrite de
la manière suivante :
Select…. From fact_t where month_num = 12 ;
Dans ce cas, si la donnée est stockée dans
un format de type date, l’index ne sera pas utilisé
et les performances d’exécution de la requête
s’en trouveront dégradées.
Une règle générique peut être
écrite avec ActiveBase pour détecter l’ensemble
des requêtes composées sous cette forme afin
de les réécrire dans une syntaxe optimisée
:
Select … From fact_t where date between 1.12 and
31.12
|
Bénéfices |
- La logique de l’ordre SQL est préservée,
étant donné que le Hint consiste uniquement
à modifier le comportement de l’optimiseur
Oracle.
- L’automatisation de la phase de recherche permet
de gagner un temps considérable car il permet de
traiter de nombreux ordres SQL, parfois très longs
et complexes et ne nécessite aucune expertise ni
une connaissance approfondie des internes d’Oracle.
- Les Hints peuvent être régulièrement
revus pour tenir compte de l’évolution de la
volumétrie des données, du nombre ou du profil
d’utilisateurs, des changements effectués par
les DBA sur la base, etc..
- Les améliorations sont immédiatement applicables
aux applications.
- Pas d’upgrade des serveurs ni du nombre de licences
Oracle.
- Prolonge la durée de vie des applications PowerBuilder
en conservant ou améliorant la qualité de
service
|
