L’optimisation est un processus intelligent complexe qui vise à améliorer les performances du système application / réseau / OS / SGBD (système lui-même complexe…).
Les gains peuvent être soit en terme de temps de réponse utilisateur, soit en  consommation de ressources.
Un système optimisé doit pouvoir supporter de manière linéaire une montée en charge, soit en terme de volume, soit en terme de nombre d’utilisateurs. En d’autres termes la consommation de ressources CPU, mémoire, E/S doit être proportionnelle à la montée en charge, le système est alors dit ‘SCALABLE’.
Dans la pratique un système non optimisé va consommer de manière inflationiste et s’effondrer.

Il existe 2 approches d’optimisation  complémentaires  :

• préventive
  qui couvre tous les cycles de dévelopement du S.I ( conception, developpement, production, maintenance)
• curative
  qui  intervient principalement en maintenance du système en production

Il va donc falloir ORGANISER l’optimisation à ces différents niveaux.

Rappel : Principe valable dans toutes les phases du S.I :  ‘LESS IS MORE’ ou KISS : Keep It Simple Stupid !

Optimisation de l’architecture technique

• privilégier les architectures 3 tier
• simplifier les couches logicielles
  Attention aux couches d’abstraction (PDO, jdbc, odbc), aux pilotes génériques plutôt que natifs, aux machines virtuelles, aux clients lourds, aux applets java, …
• utiliser  SSO et plus généralement d’annuaire pour les users, mais aussi les bases, les machines, les services réseau, …

Optimisation du modèle : tables

• NORMALISATION RAISONNABLE
  pas de table ‘universelle’ unique comme dans les systèmes de gestion de fichiers d’antan (trop de colonnes, trop de redondance de données)

• DENORMALISATION INTELLIGENTE
  à l’inverse pas de modèle ultra normalisé, qui donnerait une pléthore de tables non redondantes mais nécessitera de nombreuses jointures pour ramener une info pertinente. mise en place de  intelligente
• REDONDANCE CALCULEE
  Il est plus efficace parfois de stocker les résultats de calculs complexes dans les tables, lors des mises à jour, plutôt que de les calculer ‘à la volée’ lors des consultations.

Optimisation du modèle : index

• CHOISIR LE BON TYPE D’INDEX (voir mon article : les différents types d’index Oracle )
• NE PAS OUBLIER LES CLES  primaires et étrangères 1clé = 1 index) !!!!
• TROP D’INDEX TUE L’INDEX
  1) en terme  de volume : si on indexe toutes le colonnes on double le volume de la base !!!
  2) parce que lors des mises à jour de la table tous les index doivent être maintenus et cela coute desressources
• CHOISIR LES BONNES COLONNES à indexer
  en général les colonnes qui vont servir de critères de recherches fréquents (qui apparaissent dans le clause WHERE du SELECT)
• INDEXER LES FONCTIONS
  corrolaire du précédent si une fonction apparait dans la clause WHERE …on peut l’indexer aussi
• ELARGIR LES INDEX… pour en faire des données
  si Oracle trouve dans l’index toutes les données de la SELECT LIST…il ne prend pas la peine de consulter les tables !

Conseils généraux d’optimisation du développement Oracle

• utiliser les types de données appropriés et les fonctions associées ( par exemple ne pas réinventer le format DATE…), utiliser des VARCHAR plutôt que des CHAR, se méfier des LOBs
• implémenter un maximum de contraintes d’intégrité au niveau table (factorise le code et évite le traitement de données non fiabilisées)
• utiliser des curseurs : evite de re interpréter totalement les ordres SQL (dissocie la phase de parsing de la phase d’execution qui est seule rejouée )
• utiliser des règles de casse dans les ordres SQL (évite le SQL rewriting ou reparsing)
• utiliser des VRAIS ordres SQL paramétrés (sql_prepare + sql_bind)
• vérifier les migrations dev -> test , test -> prod (pertes d’index possibles)
• éviter les vues de vuesjointes à des vues. Simplifie le codage, mais masque totalement la complexité sous jacente des requêtes. Solution : créer des vues directement sur les tables !
• encapsuler les ordres SQL dans du PLSQL (traitement par bloc et précompilation)

Conseils généraux de paramétrage de l’instance

L’instance de la base de données possède un certain nombre de paramètres d’initialisation , dont certains ont un impact fort sur les performances. Nous allons citer les principaux :

• COMPATIBLE = <no_version_oracle>
  permet de fonctionner dans un mode antérieur, notamment si des spécifités de l’optimiseur avaient été utilisés. A l’inverse peut dégrader les performances dans le cas contraire.
• SGA_TARGET = <montant_memoire_max>
  laisse Oracle organiser les sous-zones de cache de son cache principal (la SGA). Il faut bien sûr donner une valeur compatible avec votre RAM et prenant en compte le fait que Oracle n’est pas tout seul…
• UNDO_MANAGEMENT = AUTO
  gestion des espace de Rollback. Ne pas changer cette valeur !

Dimensionnement des fichiers et espaces logiques

• REDOLOG files
  de 100MO a qq GO, devarient switcher toutes les 1/2 heures en gros
• TABLESPACES applicatifs
  chaque application devrait avoir (au moins) son tbs spécifique, avec une volumétrie estimée
• TABLESPACE temporaire
• UNDO : gérer la taille des transactions

doit être dimensionné en fonction des besoins de la zone de tri :