13 Replies Latest reply: Oct 13, 2011 6:05 AM by Laurent Matheo RSS

Remedy v7 : recherche  accent et casse insensible en francais

Victor MIZAN

Bonjour

 

Consultant à Québec, je dirige actuellement un projet de mise en place de Remedy v7 avec Oracle 11g R2 en francais pour un organisme gouvernementale du Québec.

 

Le besoin est de pouvoir faire des recherches dans les modules de Remedy sans tenir compte des caractères accentués ou de la casse (majuscule-minuscule).

 

Exemple : une recherche sur "e" retournerai n'importe quelle combinaison :

"e", "é", "è", "ê", "ë", "E", "É", "È", "Ê", "Ë", ....

 

 

Le support BMC est imprécis et incertain de la réponse.

 

J'aimerai savoir si cela fonctionne Rmwedy v7-Oracle. Quelqu'un peut-il me répondre ?

Si oui, j'aimerai savoir les configurations Remedy et/ou Oracle pour atteindre ce résultat.

 

Actuellement avec Remedy v5 sur SQL, certains modules le font et certains ne le font pas.

 

Merci pour votre réponse.

  • 1. Re: Remedy v7 : recherche  accent et casse insensible en francais
    Matt Laurenceau

    Bonjour Victor.

     

    Je vais vérifier directement avec Engineering.

     

    A bientôt, Matt

  • 2. Re: Remedy v7 : recherche  accent et casse insensible en francais
    Sylvain YVON

    Bonjour Victor,

     

    J'arrive un peu tard, mais l'une des pistes à explorer avec précautions est la configuration d'Oracle lui-même au niveau de la session (paramètres

    NLS_SORT=GENERIC_BASELETTER et NLS_COMP=LINGUISTIC).

     

    C'est radical et effectif dans toute l'application.

    Les inconvénients sont quand même importants :

    - cela nécessite de reconstruire tous les indexes avec les bonnes options sinon ils sont tout simplement ignorés

    - ces options ne pouvant pas être incorporées à l'ardb.conf, cela entraîne un coup de maintenance important

    - même une fois les indexes reconstruits, les recherches même simples sont plus longues

     

    J'ai réalisé des tests sur une VM en injectant quelques dizaines de milliers d'incidents et les écarts en termes de temps de réponses n'étaient pas très importants (quelques millisecondes par requêtes), mais cela ne remplace pas des tests de métrologie.

     

     

    Sylvain

  • 4. Re: Remedy v7 : recherche  accent et casse insensible en francais
    Laurent Matheo

    Salut

    J'ai fait la manip aussi chez un client récemment qui est en 7.6.04 sp1.

    en revanche on a utilisé ça:

    NLS_COMP=LINGUISTIC

    NLS_SORT=BINARY_AI

    (_AI veut dire accent + case insensitive).

     

    Comme l'a dit Sylvain il faut dropper / recréer les index "varchar" (par contre ne pas toucher aux numériques) pour tenir compte du paramètre LINGUISTIC, par exemple:

    drop index ARADMIN.SCHEMA_IND;                                                 

    create unique index ARADMIN.SCHEMA_IND on ARADMIN.ARSCHEMA (                   

    NLSSORT(NAME, 'NLS_SORT=BINARY_AI')) TABLESPACE ARSYSTEM; 

     

     

    Le plus dur est de faire le script qui liste, droppe, crée, recompile les vues et restats uniquement les "bons" indexes (pas les numériques par exemple).

     

    Ne pas oublier non plus de setter les deux variables d'environnement suivantes sur les serveurs ARS:

    NLS_COMP=LINGUISTIC

    NLS_SORT=BINARY_AI

  • 5. Remedy v7 : recherche  accent et casse insensible en francais
    Tarek Benterki

    Bonjour,

     

    Il est effectivement possible de passer la base oracle en case insensitive, mais les indexes ne sont tout simplement plus utilisés par le moteur oracle.

    Lorsque la base est vide, pas trop d'impacte, mais une fois en production, les temps de réponse rende l'application inutilisable.

    J'ai effectué une baterie de test sur Oracle 10GR2 et je pense que c'est pareil sous la 11G. Je déconseille donc la manipulation.

    Vivement que BMC s'occupe de ce point.

     

    Tarek Benterki

  • 6. Re: Remedy v7 : recherche  accent et casse insensible en francais
    Sylvain YVON

    Salut Tarek, content de te recroiser ici

    D'après les tests que j'ai réalisé de mon côté, effectivement si tu ne reconstruis pas tous les indexes, ils sont ignorés. Par contre, si tu les reconstruits, l'execution plan montre qu'ils sont réutilisés :

     

     

    SQL> select incident_number from hpd_help_desk where incident_number = 'INC000000000031';
    
    INCIDENT_NUMBER
    ---------------
    INC000000000031
    
    
    Plan d exécution
    ----------------------------------------------------------
    Plan hash value: 976558547
    
    --------------------------------------------------------------------------------------------------
    | Id  | Operation                    | Name              | Rows  | Bytes | Cost(%CPU)| Time     |
    --------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT             |                   |     1 |    48 |     1   (0)| 00:00:01 |
    |   1 |  NESTED LOOPS OUTER          |                   |     1 |    48 |     1   (0)| 00:00:01 |
    |   2 |   TABLE ACCESS BY INDEX ROWID| T941              |     1 |    32 |     1   (0)| 00:00:01 |
    |*  3 |    INDEX UNIQUE SCAN         | I941_1000000161_1 |     1 |       |     0   (0)| 00:00:01 |
    |*  4 |   INDEX UNIQUE SCAN          | IB941             |    31 |   496 |     0   (0)| 00:00:01 |
    --------------------------------------------------------------------------------------------------
    
    
    
    SQL>  ALTER SESSION SET NLS_COMP=LINGUISTIC;
    
    Session modifiée.
    
    SQL> ALTER SESSION SET NLS_SORT=GENERIC_BASELETTER;
    
    Session modifiée.
    
    SQL>  select incident_number from hpd_help_desk where incident_number = 'INC000000000031';
    
    INCIDENT_NUMBER
    ---------------
    INC000000000031
    
    
    Plan d exécution
    ----------------------------------------------------------
    Plan hash value: 249282356
    
    ----------------------------------------------------------------------------
    | Id  | Operation          | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
    ----------------------------------------------------------------------------
    |   0 | SELECT STATEMENT   |       |     1 |    48 |     4   (0)| 00:00:01 |
    |   1 |  NESTED LOOPS OUTER|       |     1 |    48 |     4   (0)| 00:00:01 |
    |*  2 |   TABLE ACCESS FULL| T941  |     1 |    32 |     3   (0)| 00:00:01 |
    |*  3 |   INDEX FULL SCAN  | IB941 |     1 |    16 |     1   (0)| 00:00:01 |
    ----------------------------------------------------------------------------
    
    SQL> drop index I941_1000000161_1;
    
    Index supprimé.
    
    SQL> create unique index I941_1000000161_1 on T941 (NLSSORT(C1000000161,'NLS_SORT=GENERIC_BASELETTER'));
    
    Index créé.
    
    SQL> select incident_number from hpd_help_desk where incident_number = 'INC000000000031';
    
    INCIDENT_NUMBER
    ---------------
    INC000000000031
    
    
    Plan d exécution
    ----------------------------------------------------------
    Plan hash value: 2463696007
    
    --------------------------------------------------------------------------------------------------
    | Id  | Operation                    | Name              | Rows  | Bytes | Cost(%CPU)| Time     |
    --------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT             |                   |     1 |    48 |     2   (0)| 00:00:01 |
    |   1 |  NESTED LOOPS OUTER          |                   |     1 |    48 |     2   (0)| 00:00:01 |
    |   2 |   TABLE ACCESS BY INDEX ROWID| T941              |     1 |    32 |     1   (0)| 00:00:01 |
    |*  3 |    INDEX UNIQUE SCAN         | I941_1000000161_1 |     1 |       |     0   (0)| 00:00:01 |
    |*  4 |   INDEX FULL SCAN            | IB941             |     1 |    16 |     1   (0)| 00:00:01 |
    --------------------------------------------------------------------------------------------------
    
    

     

    J'ai collé ça de manière un peu barbare, mais en gros ça montre que :

    - un select simple sur l'id utilise l'index unique I941_1000000161_1

    - suite au changement de session, l'index est ignoré et un full scan est réalisé pour la même requête

    - on détruit et recrée l'index I941_1000000161_1 avec l'option NLS_SORT, et on voit un à nouveau un index unique scan

  • 7. Re: Remedy v7 : recherche  accent et casse insensible en francais
    Tarek Benterki

    Bonjour Sylvain,

     

    As tu fais des tests sur un champ caractères dont l'indexe n'est pas unique, comme par exemple le champ "Nom"?

    Je poste mes résultats dès que possible.

     

    Cdt

    Tarek

  • 8. Re: Remedy v7 : recherche  accent et casse insensible en francais
    Sylvain YVON

    Non tu as raison je n'ai fait des tests que sur ce champ à l'époque :/

  • 9. Remedy v7 : recherche  accent et casse insensible en francais
    Laurent Matheo

    Au niveau perfs ou au niveau execution plan?

  • 10. Remedy v7 : recherche  accent et casse insensible en francais
    Victor MIZAN

    Merci à tous pour vos réponses avec tant de détails.

     

    BMC Quebec affirme qu'il n'y a pas de problème de performance....

     

    Le projet ne débutant qu'en février 2012, les essais et mesures de performances seront faits à cette date.

     

    Encore merci.

  • 11. Remedy v7 : recherche  accent et casse insensible en francais
    Sylvain YVON

    Ok Victor, si tu pouvais nous tenir informés des méthodes et résultats de ces mesures ce serait vraiment sympa.

    Merci par avance.

  • 12. Remedy v7 : recherche  accent et casse insensible en francais
    Yann Baumgartner

    Bonjour Victor,

     

    Est-ce qu'il y a une raison spécifique pour que vous n'utilisiez pas le moteur FTS de Remedy?

     

    A mon sens le coût de ces adaptations et de leur maitenance pour atteindre votre objectif va être bien plus important que l'achat de la license FTS.

  • 13. Remedy v7 : recherche  accent et casse insensible en francais
    Laurent Matheo

    Il y a plein de formulaires qui ne sont pas indexés FTS, ça demandrait un gros boulot de les modifier, de plus l'indexation n'est pas immédiate et pour l'instant il est impossible d'avoir du "accent insensitive" via le FTS

    Il y a une bidouille que m'a donnée le support mais qui demande pas mal de taf.