Discussion :

[JujuM]

Bonjour,

J'ai un problème avec une de mes requetes et je ne sais vraiment pas d'où ça peut venir.
Je cherche à comparer le nom d'un attribut de ma première table avec toutes les lignes de la deuxième table, pour trouver les lignes qui auraient un nom similaire, avec un pourcentage passé en paramètre.
Ensuite, je souhaite remplir une table de résultat qui contiendrait le nom de l'attribut de départ et son numéro, le nom similaire et le numéro associé ainsi que le degré de similitude.

Voila mon code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
CREATE OR REPLACE
PROCEDURE SIM_MISS30(p_similarity NUMBER) AS
TYPE t_Cursor IS REF CURSOR;
C1 t_Cursor;
C2 t_Cursor;
v_b_row T_B%ROWTYPE;
similar_name T_CDQ.GSI_PARTY_NAME%TYPE;
similar_number T_CDQ.GSI_PARTY_NUMBER%TYPE;
BEGIN
  OPEN C1 FOR
  SELECT * FROM T_B;
  LOOP
    EXIT WHEN C1%NOTFOUND;
    FETCH C1 INTO v_b_row;
      OPEN C2 FOR
        SELECT DISTINCT GSI_PARTY_NUMBER,GSI_PARTY_NAME FROM T_CDQ WHERE utl_match.jaro_winkler_similarity(T_CDQ.GSI_PARTY_NAME, v_b_row.PARTY_NAME) > p_similarity;
        LOOP
          EXIT WHEN C2%NOTFOUND;
          FETCH C2 INTO similar_number,similar_name;
            INSERT INTO T_SIM VALUES (v_b_row.PARTY_NUMBER,v_b_row.PARTY_NAME, similar_number, similar_name,utl_match.jaro_winkler_similarity(similar_name,v_b_row.PARTY_NAME));
          COMMIT;
        END LOOP;
      CLOSE C2;
  END LOOP;
  CLOSE C1;
END;

J'ai comme erreur sous sql developer :
Error report:
Il n'y a plus de données à lire dans le socket
et sous sql plus :
ORA-03113: fin de fichier sur canal de communication
Dans les deux cas, ça me déconnecte de la base.

Ma table T_B contient 2550 lignes et ma table T_CDQ en contient 51421.
J'ai pensé que le parcours était trop important et donc j'ai essayé avec une restriction sur la table T_B.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM T_B WHERE ROWNUM < 10;

En dessous de 10, ça fonctionne. De temps en temps ça fonctionne pour 100 mais je n'ai jamais réussi à dépasser 180 lignes...

Je ne sais pas si j'ai été trés claire.. c'est la première fois que je poste ...

Est ce que vous voyez d'où ça peut venir ?

Merci de votre aide.

[Garuda]

Quel version d'ORACLE ?

[JujuM]

Oracle 10g.

[LeoAnderson]

que dit l'alert.log ? les traces dans user_dump_dest ?
le sqlnet.log sur le client ?

[Garuda]

OK.

J'ai eu des erreurs (3113) de ce type lors d'une migration 8.1.7 -> 10 G.
Aprés consultation de METALINK, j'ai vu qu'il y avait pas mal de ORA-3113 dues à l'optimiseur.
Aprés avoir fait tourner les stats (DBMS_STATS Compute) sur ma base (ce qui n'avait jamais été fait), tout est devenu OK.

Renseigne toi également auprés de ton DBA pour savoir s'il a passé les 2 patchs de la 10GR2 (si oui, tu devrais être en 10.2.0.3.0).

Si tu es abonnée (?) à METALINK, je te conseille de poster une SR (service request)

[JujuM]

Alors dans user_dump :
ksedmp: internal or fatal error
ORA-07445: exception trouvée : image mémoire [ACCESS_VIOLATION] [_pi_jaro_winkler_int+338] [PC:0x6308F4C6] [ADDR:0x7FF0000] [UNABLE_TO_READ] []
Current SQL statement for this session:
SELECT DISTINCT GSI_PARTY_NUMBER,GSI_PARTY_NAME FROM T_CDQ WHERE UTL_MATCH.JARO_WINKLER_SIMILARITY(T_CDQ.GSI_PARTY_NAME, :B2 ) > :B1

Même message d'erreur dans le alert.log

Je ne suis pas abonnée à metalink mais je vais demander ses pass à une collegue.
Et non les deux patchs dont tu parles, je ne dois pas les avoir car je suis en 10.2.0.1.0.
Apres j'ai pas trop compris de quoi tu parles à propos de DBMS_STATS Compute.

[Garuda]

En 10G, l'optimiseur de requête ne marche qu'avec des STATISTIQUES (contrairement aux anciennes versions ou il marchait aussi avec des REGLES (rules))
Ces statistiques sont calculées sur la volumétrie des tables et des indexes et permettent à l'optimiseur d'ORACLE de choisir la meilleur stratégie pour executer une requête (utilisation des indexes, table maitresse, etc..)
En 10G, on doit obligatoirement calculer ces statistiques pour optimiser les performances (on doit le faire au moins 1 fois !) : c'est à cela que sert le package DBMS_STAT.