Développement d'une procédure lancée quotidiennement pour prévenir les "explosions" des tables. Le principe est de calculer la quantité d'espace libre jour après jour et, en fonction de ce calcul, il est possible de savoir approximativement l'augmentation du nombre d'enregistrement encore possible aujourd'hui ...

De plus, l'analyse quotidienne des tables sur une longue durée permet d'avoir un aperçu du nombre moyen d'enregistrements créés chaque jour par table. Donc, en se basant sur cette moyenne et sur l'espace disponible, il est possible de prévoir ( de manière assez précise ) dans combien de temps la table sera arrivée à saturation.

Ceci est globalement nommée de l'administration prédictive ou prévisionnelle.

Cette partie a été développée en PL-SQL et a été programmée chaque nuit sur plusieurs serveurs de productions et de developpement pendant plusieurs mois sans avoir à être retouché.

Développement d'une procédure qui, depuis un schéma Siebel ( plus de 600 tables ), génère un schéma simplifié, plus facile à comprendre pour les utilisateurs ( une trentaine de tables environ ).

Cela permet quotidiennement à des centaines d'utilisateurs de requéter sur des données de production sans écrouler les performances des serveurs de productions possédant les données de la veille au soir, ce qui, généralement est bien suffisant pour le reporting classique.

Ce script une fois éxécuté produit un rapport qui donne le nombre d'enregistrements par table, et le nombre total d'enregistrements recréés, etc.

Cette partie a été développée en PL-SQL et a été programmée quotidiennement et peut meme être relancé en journée en cas de demande utilisateur. La recontruction de la base mirroir est autonome maintenant

Analyse des requêtes occupant le plus de ressources lors de leur éxécution. Il existe un principe simple selon lequel : plus une requête dure longtemps, plus elle a de chance de ne jamais se terminer. C'est à dire, qu'un requête, qui après une journée pleine d'éxécution n'a toujours pas terminé son calcul ne se terminera peut être jamais. Cela est trés souvent dû à une mauvais écriture de la requête.

En se basant sur cette observation, il apparait que les requêtes les plus longues à éxécuter sont celles sur lesquelles on peut le plus gagner de temps et de ressources. Il faut savoir que dans plus de 70% des cas, des requêtes mal écrites sont à l'origine des temps de réponse les plus lents. Dans environ 15% des cas, les lenteurs sont dûes à un manque de tables intermédiaires ou, tout au moins, d'étapes intermédiaires dans les requêtes qui ont de plus en plus besoin de mémoire ou de ressources processeur. Dans le reste des cas seulement, c'est à dire 15% environ, les ressources matérielles sont réellement insuffisante.

Cette partie est appelée Tuning SQL.

Dans un environnement de production, il n'est pas rare de voir une même requête s'éxécuter plusieurs centaines de fois. Cela impose au serveur de ré-effectuer le même calcul plusieurs fois. Par exemple, une requête prenant 1 seconde avant d'être éxécutée peut être éxécuté 1000 fois, cela veut dire que cette requête, sur l'ensemble de la journée de travail ( environ 8 heures ) aura pris 1000 secondes soit 16 minutes soit 1/32ème du temps. Si 10 requêtes sont dans ce cas, c'est 1/8ème du temps qui est passé pour 10 requêtes.

Ce genre de problème peut être simplement réglé en lançant ces requêtes pendant la nuit et en stockant le résultat dans une table temporaire. Cette table sera simplement lue et contiendra le résultat direct, ce qui fait tomber le temps de requête de 1 seconde à environ 1/100~1/10 ème de seconde. Ce gain est trés important dans des modèles contenant leur référentiel et leurs données dans des tables Oracle.

Cette partie doit être faite chaque soir ou à intervalle régulier.