Discussion :

[Julien_M]

Bonjour,

J'utilise une base de données avec 50000 tables dans une appli .NET. 99% de ces tables contiennent 2 champs de type BLOB.

Lorsque l'on utilise un OracleDataAdapter avec un CommandBuilder. la commande suivante est exécutée :

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
SELECT c1, c2, c3
FROM (SELECT acc.column_name c1, acc.constraint_name c2,
ac.constraint_type c3
FROM all_cons_columns acc, all_constraints ac
WHERE (ac.constraint_type = 'P' OR ac.constraint_type = 'U')
AND ac.table_name = :b1
AND ac.owner = :b2
AND ac.table_name = acc.table_name
AND ac.owner = acc.owner
AND ac.constraint_name = acc.constraint_name
UNION
SELECT aic.column_name c1, ai.index_name c2, 'U' c3
FROM all_indexes ai, all_ind_columns aic
WHERE ai.uniqueness = 'UNIQUE'
AND ai.table_name = :b1
AND ai.table_owner = :b2
AND ai.table_name = aic.table_name
AND ai.table_owner = aic.table_owner
AND ai.index_name = aic.index_name
AND ai.owner = aic.index_owner)
ORDER BY 3, 2, 1

Cette commande prends 15 secondes à s'éxecuter !! ce qui est très lent ^^

On rempli l'Adapter en utilisant la méthode Fill(Dataset, string).

Est ce que cela ne devrait pas être plus rapide ?
Peut être ne faut il pas utiliser de DataAdapter avec une base de donnée de cette taille ?

Pour Information :

La commande

Code :

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

select count(*) from user_tables

prends 2 minutes à s'executer avec sqlplus. Résultat : 50600

La commande

Code :

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

select count(*) from user_indexes

prends 1 minute 50 avec sqlplus. Résultat : 113000

Merci d'avance

[orafrance]

t'es bien sûr que c'est cette commande qui est longue ? Parce qu'en principe elle lit le dictionnaire et donc en mémoire

[Julien_M]

Si j'exécute cette commande avec sqlplus cela prends bien 15 sec !

Il y a surement un problème avec cette requète, mais je ne vois pas lequel.

Faudrait-il reconstruire des index ?

PS : Si j'exécute cette requète sur un schema avec seulement 200 tables le temps d'exécution est de 200 ms ce qui me fait dire que le nombre de table de mon schema influe grandement sur les performances des OracleDataAdapter !

[orafrance]

ce qui me fait dire que le nombre de table de mon schema influe grandement sur les performances des OracleDataAdapter !

je ne sais pas pour OracleDataAdapter mais il est évident que le nombre de table et index du shema a une influence sur la durée des requêtes que tu montres

[orafrance]

tiens... j'ai trouvé ceci :

BUG FIXES (in 9.2.0.4.01)
=========================
1.1 OracleDataAdapter().Fill leaks memory if table has more than 2 Lobs.
[Bug #3185445]

C'est quelle version que tu as ?

[orafrance]

en passant, ça me parait pour le moins curieux d'avoir 2 LOB par table

[Julien_M]

La version du client est 10.1.0.301.

[orafrance]

c'est la base de données bien sûr qui est intéressante pas le client

[Julien_M]

Oops ! la version de la base est 9.2.0.1.0

[orafrance]

bah voila, c'est un bug corrigé en 9.2.0.4. Je te conseille d'upgrader même en 9.2.0.6

[Julien_M]

Je vais faire des essais en changeant de base.

Mais j'ai quelques doutes sachant que la correction du bug concerne des memory leaks sur le Fill du DataAdapter des tables contenant plus de 2 LOBs (ce qui n'est pas mon cas). Les memory leaks peuvent sans doute entrainer des problèmes de perf mais là c'est apparemment la requête générée pour récupérer les noms de colonne des tables qui prend du temps (celle que j'ai mis en début de post) même lorsque elle est éxécutée dansSQL*Plus donc sans utiliser de DataAdapter.

[orafrance]

comme je te l'ai dit, cette requête lis le dictionnaire qui est en mémoire donc memory leak -> pb de perf sur les accés au dictionnaire... enfin, je pense

[Yorglaa]

Salut à tous...
Comme je comprends ta requête, tu cherche toutes les colonnes de type PK ou Unique d'une table déterminée (c'est dans un loop ?) ainsi que tous les index uniques...
quel est le but ?
si le but est éventuellement de trouver les colonnes uniques non indexées, il faut savoir que Oracle crée automatiquement un index unique lorsque tu crée une clef primaire.
Donc il n'y aurait, à priori, pas besoin de sélectionner les contraintes de type 'P'.
le fait de sélectionner ces contraintes font que les PK appraissent 2 fois, une fois en tant que contrainte et une fois en tant qu'index... est-ce voulu ?
de plus le fait de sélectionner ces contraintes t'a fait mettre un OR dans ta requête, ce peux se révèler assez pénalisant... essaye éventuellement avec un =any ou un IN

[Julien_M]

J'ai fait le test avec une base en 10.1.0.2.0 (c'est la seule version supérieure sur laquelle j'ai pu faire un test) et le problème reste le même .

Cette requête (qui n'est pas générée par moi mais par le commandBuilder) met toujours ses 15 secondes à s'éxécuter.

Salut à tous...
Comme je comprends ta requête, tu cherche toutes les colonnes de type PK ou Unique d'une table déterminée (c'est dans un loop ?) ainsi que tous les index uniques...
quel est le but ?
si le but est éventuellement de trouver les colonnes uniques non indexées, il faut savoir que Oracle crée automatiquement un index unique lorsque tu crée une clef primaire.
Donc il n'y aurait, à priori, pas besoin de sélectionner les contraintes de type 'P'.
le fait de sélectionner ces contraintes font que les PK appraissent 2 fois, une fois en tant que contrainte et une fois en tant qu'index... est-ce voulu ?
de plus le fait de sélectionner ces contraintes t'a fait mettre un OR dans ta requête, ce peux se révèler assez pénalisant... essaye éventuellement avec un =any ou un IN

Comme je viens de le mentionner plus haut ce n'est pas moi qui souhaite faire cette requête mais c'est le CommandBuilder qui la génère et l'éxécute.


PS : Si après avoir lancé la requête sous SLQ*Plus (15 sec) on la réexécute immédiatement le temps d'éxécution reste de 15 secondes. Ce qui m'étonne car je pensais qu'il allait utiliser le câche. Est ce un indice ?

[Yorglaa]

...Comme je viens de le mentionner plus haut ce n'est pas moi qui souhaite faire cette requête mais c'est le CommandBuilder qui la génère et l'éxécute.
...

et bien dans ce cas n'utilise pas le commandbuilder, mais construis-toi un select plus performant et fais-le utiliser par ton appli...
DotNET ne force en aucun cas l'utilisation d'un commandbuilder

[Julien_M]

C'est la méthode GetUpdateCommand() du CommandBuilder qui est mise en défaut dans notre cas (c'est lui qui lance la fameuse requête).

Sur un schéma avec 200 tables, cela ne pose pas de problèmes, mais pas avec 10000 tables.

Le fait de changer tous les CommandBuilder de nôtre application implique un coût non négligeable.

Est t'il clairement déconseillé d'utiliser des CommandBuilder avec des schema comportant un grand nombre de tables ?

[Yorglaa]

CLAIREMENT... je ne dirait pas, non...
mais si dotNET sais faire des requêtes sur Oracle, il n'a par contre aucune idée de tout ce qui touche à l'optimisation...

de même l'utilisation requêtes un peu plus touffues (avec des clauses WITH, des CASE, etc...) toruvent vite leurs limites avec les commandBuilder...
de même, que penserais-tu de faire une procédure stockée dont tu balancerais dans dotNET directement le résultat attendu en fonction de paramètres donnés ?
l'avantage serait que le traitement de la requête resterait du pur Oracle, avec tout ce que ça implique de possibilités...

[orafrance]

PS : Si après avoir lancé la requête sous SLQ*Plus (15 sec) on la réexécute immédiatement le temps d'éxécution reste de 15 secondes. Ce qui m'étonne car je pensais qu'il allait utiliser le câche. Est ce un indice ?

je te répéte que cette requête va TOUJOURS dans le cache où sont les tables du dictionnaire... donc c'est logique, il doit y avoir un problème d'accés mémoire, tu vas devoir contacter le support