Discussion :

[MetalGeek]

Bonjour,
tout d'abord je précise que je ne connais presque rien à Oracle, je suis développeur .NET et mis à part le SQL et les tâches de base l'administration de bases de données n'est pas mon fort...

J'ai une application qui récupère des données depuis une base Oracle sous la version 10g express. Il n'y a que 3 tables, une vue, le tout ne dépasse pas les 200 megas de données, il n'y a aucune relation, pas de trigger bref que du simpliste.
Seulement, un simple "SELECT COUNT(*) FROM [maVue] prend 241,44 secondes sous l'interface web d'Oracle (127.0.0.1/apex etc)... (le résultat arrive bien ensuite => environ 27000 lignes, ce qui n'est pas énorme...)

Donc, ma question est : y-a-t-il un moyen simple de remédier à cela ? des fichiers de log à vider, des paramètres à changer ?

Dites-moi ce qu'il vous faut éventuellement comme infos supplémentaires (en me parlant comme au non connaisseur d'Oracle que je suis!).

[pifor]

D'abord essayer de vérifier que c'est bien la la requête SQL qui est lente en utilisant SQL*Plus pour l'exécuter. Si c'est bien le cas, il faudrait la sortie des scripts référencés dans le message OTN suivant afin d'avoir le plus d'éléments possible pour analyser la requête: http://forums.oracle.com/forums/thre...sageID=3308808

[13thFloor]

Les tables concernées par la vue n'ont t-elles pas été plus grandes auparavant ?
Je m'explique : un select count(*) va induire un parcours complet de la table (appelé FTS full table scan). La lecture va se faire jusqu'au dernier bloc qui a été écrit (le high water mark) même s'il est vide. Il se peut donc que ton select lise plus de blocs que nécessaire.
Pour y remédier simplement (j'ai bien noté que tu ne connais presque rien à oracle), il faudrait
- soit abaisser le high water mark : alter table XXX shrink space compact;
- soit réorganiser la table et reconstruire ses index : alter table XXX move; alter index index_de_XXX rebuild;

PS : vu que tu accèdes à une vue, le plan d'exécution nous serait utile.

[nax71]

Vu que tu accede a une vue ce n'est pas le temps de count(*) que tu mesure mais plus tot le temps de construction de la vue.

Un solution est d'utiliser une vue materialise si ce n'est pas le cas.
Apres tu peux generer les statistiques sur la vue materialisé comme pour une table ce qui aidera beaucoup.

Les tables qui rentre dans la creation de la vue sont mise a jour regulierement ? => Si oui le mise ajour de la vue materialisé ca peut etre couteuse.

Autre piste:
Tu peus essayer aussi de paralleliser la requette (ca ne marche pas toujours si tu as bcp d'access disque: le parallelisme peut augmenter les access I/O).
Tu as combien de CPU et combien de threads pas CPU ? Tu peux essayer de mettre 1,33 * cpu_count dans une premiere estimation

Code :

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

1
2
3
4
5
SQL> show parameter cpu
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
cpu_count                            integer     5
parallel_threads_per_cpu             integer     2

Cdt,

[pifor]

Vu que tu accede a une vue ce n'est pas le temps de count(*) que tu mesure mais plus tot le temps de construction de la vue.

Non. Une vue crééé avec CREATE VIEW n'est que du SQL stocké dans le dictionnaire et que Oracle substitue au nom de la vue lors de la phase de compilation de la requête.

Et Oracle XE n'a pas de fonctionnalités du type DML parallèle , ni de réécriture pour les vues matérialisées et ne peut utiliser qu'un seul processeur quelque soit la machine

[nax71]

Je dois revoir ma copie sur Oracle XE.