Arjuna Aircraft Ident.: F-MBSD | Salut,
Base de données : Oracle 8i (8.1.7)
OS: Windows 2000 Server
Machine : Bi-Xéon 2.2 GHz avec 2 Go de RAM
Disques en RAID 5
La charge du serveur est largement impactée par d'autres outils (un ERP plus service d'éditique). On a régulièrement des pics à 100% d'utilisation CPU sur les deux processeurs, mais jamais plus de 10 secondes. Le serveur est donc pour le moment correctement dimensionné, et ne nécessite pas d'upgrade.
A côté de ça, on m'a demandé de faire une appli intranet qui vient faire des requêtes plus ou moins lourdes dans la base Oracle. Après quelques bugs et croûtage dans les règles du serveur, c'est maintenant stable, et pour le moment, où on ne fait qu'une période de démonstration de l'appli aux utilisateurs, je peux monitorer un peu la charge induite par ce service supplémentaire (le site est hébergé sur un autre serveur, je n'ai que la charge de la base à gérer).
La base de données est en mode d'omtimisation "RULES". Et d'après les préconisations de l'ERP, impossible de changer pour autrechose.
Sur le site intranet, outre quelques requêtes que je ne vois pas trop comment optimiser, j'ai une requête assez imposante qui fait une recherche "LIKE" dans une vue dont voici le source :
Code :
- CREATE OR REPLACE FORCE VIEW SOC1.WV_PRM
- (CODSOC, CODLAN, CODPRO, NOMPRO, TRADESIG1,
- TRADESIG2, TRADESIG3)
- AS
- select tmp.codsoc, tmp.codlan, tmp.codpro, nvl(prm.nompro, tmp.nompro) nompro, nvl(prm.tradesig1, tmp.design1) tradesig1, nvl(prm.tradesig2, tmp.design2) tradesig2, nvl(prm.tradesig3, tmp.design3) tradesig3
- from prm, (
- select pro.codsoc, pro.codpro, pro.nompro, pro.design1, pro.design2, pro.design3, tbl.cletbl codlan
- from tbl, pro
- where tbl.codsoc = pro.codsoc
- and tbl.codtbl = 'lan'
- ) tmp
- where prm.codsoc(+) = tmp.codsoc
- and prm.codpro(+) = tmp.codpro
- and prm.codlan(+) = tmp.codlan;
|
(211777) lignes, sâchant que j'utilise systématiquement 2 filtres qui font tomber le nombre de lignes sur lesquelles s'exécutent le LIKE à 3224 lignes.
Un LIKE dans ces conditions, malgré la tronche de la requête (vous avez pas vu celle qui utilise la vue) ne pose pas de problème de performance.
Par contre, je cherche à lutter contre les limitations du like, à savoir que si l'utilisateur table "table bleue", je dois pouvoir lui retourner toutes les produits qui contiennent le mot "table", tous ceux qui contienne "bleu" (en virant le E si nécessaire), avec en premiers résultats ceux qui contiennent les deux mots dans cet ordre et l'un à côté de l'autre...
Avec LIKE, vous savez tous que c'est une joyeuse merde à coder, c'est lent, on peut pas tout traiter, ni gérer la pertinance, et du coup le résultat sera loins d'être parfait.
Je pense donc sérieusement à installer Intermedia Textsearch, un module gratuit pour Oracle 8i (le module officiel), qui me permettrait d'interroger un catalogue FullText.
Seulement, j'ai deux problèmes :
1/ Vu que mon LIKE ne bouffe actuellement pas beaucoup de ressources, le passage en FullText, je n'aurai pas de gain de perfs de ce côté
2/ Tout moteur de TextSearch consomme beaucoup de ressources lors de l'indexation. Deplus, un index pollué est flagué comme inutilisable, et fait planter les recherches qui l'interrogent, donc on doit refaire l'indexation régulièrement.
Dans cette optique, et pour se couvrir de toute plainte client, Oracle suit la même politique que Microsoft au niveau du besoin matériel : ils veulent un quadri-pro 2 GHz, 8 Go de RAM et 10 disques en RAID 50 pour la config minimum (sans éxagérer, c'est ça le pire).
Par expérience, je sais que c'est très largement surestimé. Cependant, la surchage est bien réelle. Je n'ai jamais pu la mesurer avec Oracle, car à chaque fois que j'ai pu faire implémenter TextSearch sur Oracle, c'est un DBA en Inde qui s'en est chargé, et surtout à chaque fois c'était sur des très gros datacenter HP très largement surdimensionnés pour la petite base rigicule que j'utilisait (qui faisait quand même 3 Go de données).
Du coup, j'aurais voulu savoir si, en fonction de ces infos, quelqu'un pouvait m'indiquer grossomodo où ça allait pêcher, et si vraiment ça va pêcher. |
