Discussion :

[Ikebukuro]

OK, ben à part faire une trace 10046, je ne vois plus rien.

Il faut lancer les commandes suivantes :

Code :

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

1
2
3
4
ALTER SESSION SET timed_statistics = TRUE;
ALTER SESSION SET max_dump_file_size = unlimited;
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'zztest_insert.trc';
ALTER SESSION SET events '10046 trace name context forever, level 4';

L'ordre SQL à tracer.

Code :

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

INSERT...

Ne pas oublier de désactiver la trace une fois l'ordre SQL exécuté.

Code :

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

ALTER SESSION SET events '10046 trace name context off';

Interroger v$diag_info pour trouver le fichier de trace : vous noterez que je l'ai appelé zztest_insert.trc mais Oracle peut le préfixer avec un autre libellé.

Code :

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

SELECT value FROM   v$diag_info WHERE  name = 'Default Trace File';

L'utilitaire TKPROF permet de rendre le fichier de trace brut plus lisible; attention, il y a un prix à payer, on perd les valeurs des bind variables dans le fichier généré.
Sous Unix, lancer avec fichier.trc le nom retournée par le précédent SELECT et fichier.txt le fichier de sortie.

Code :

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

tkprof fichier.trc fichier.txt

[Ikebukuro]

Un autre autre truc qu'il faudrait faire c'est une boucle de 10000 INSERT pour avoir une valeur moyenne du temps pris par ta commande.

La commande ressemble à ça de mémoire :
set timing on;
BEGIN
FOR i IN 1..10000 LOOP
INSERT
END LOOP;
END;
/
set timing off;

Puis tu divises le temps total par 10000.

[scary02820]

Bonjour,

Je n'ai pas encore eu le temps de tester vos proposition.

Par contre j'ai fais un petit test.

J'ai inséré une première ligne => Ecoulé : 00:00:00.812
Puis une seconde ligne => Ecoulé : 00:00:00.007

Via SQLDevelopper.

Par contre depuis le code c++ le temps est toujours a chaque INSERT supérieur a 500ms.

[Ikebukuro]

Dans ce cas, fait la boucle sous SQL Developer pour voir le temps moyen. Ensuite tu fais un rollback puis la même chose en C++ si possible, histoire de voir si c'est pas le code en C++ qui pose pb.

[scary02820]

Bonjour,

Je ne comprend pas le comporte de Oracle..
J'ai effectué votre boucle ... 3 x voici les résultats :

Procédure PL/SQL terminée.

Ecoulé : 00:03:46.757


Procédure PL/SQL terminée.

Ecoulé : 00:01:22.130


Procédure PL/SQL terminée.

Ecoulé : 00:09:33.809



A chaque test de 10.000 insert j'ai un résultat complètement différent.


Merci...

[Ikebukuro]

Et les 10 000 INSERT faits 3 fois l'ont été avec SQL Developer ou ton programme en C++?

Visiblement il y a une forte activité sur ta base qui pollue les tests; es-tu seul sur cette base ou bien d'autres personnes sont connectées?

De mon expérience, j'écarterai Oracle comme source du problème. Soit ta base est surchargée par les autres users soit c'est ton programme en C++ qui foire (oui, c'est facile à dire ).

[scary02820]

Bonjour,

C'est 3 tests ont été effectués via SQLDevelopper et non en c++. Ensuite je suis le seul à utiliser cette base de données... est elle est complètement vide.

[skuatamad]

Faîtes une trace 10046 level 12 pour voir les temps d'attente.

[Ikebukuro]

Bonjour,

C'est 3 tests ont été effectués via SQLDevelopper et non en c++. Ensuite je suis le seul à utiliser cette base de données... est elle est complètement vide.

Aïe, ça sent mauvais...
Comme dit skuatamad, il faut faire une trace 10046 maintenant pour y voir plus clair.