Temps de traitement 8i et 10g

[jlm22]

Bonjour à tous,
je suis face à un soucis sur ma base de donnée Oracle, j'exécute en ce moment des tests de Select, insert, et update pour une future migration vers 10G. Et le même code, et même donnée je me retrouve avec des temps de traitement de 2 à 3 fois plus long. Sur Oracle 8i le traitement dure environ 6 min pour 100000 ligne et 15 min pour la 10g (10.2.0.5). J'ai essayé les différents patchs de la 10G et même problème.

J'ai réussi à gagner 4 min en mettant le cursor_sharing = FORCE, même je suis encore loin du temps de traitement de la 8i sachant que je doit effectuer des traitements qui mettaient environ 3h sur la 8i

Avez vous déjà rencontrer ce problème ? Si oui quel est le moyen de le régler ? des paramètres à changer dans l'ouverture de la base? la 11g règle t'elle ce soucis ? Bref une solution ^^

Merci à tous.

Ps : Je ne joins pas le code puisqu'il s'agit du même pour la 8i et la 10g, il n'a donc pas d'influence sur le temps de traitement

[Mohamed.Houri]

Bonjour,

Avez vous essayé de faire ceci dans votre nouvelle base de données(10g)

Code :

1
2
 
ALTER session SET optimizer_features_enable='8.1.7';

Et de voir les nouveaux temps de réponse de vos requêtes?

Beaucoup de choses ont changé entre la version 8 et 10g si bien que, dans un premier temps, je pense c'est ce qu'il y a de mieux à faire.

Jonathan Lewis dans son livre "Cost Based Oracle Fundamentals" consacre un annexe intitulé "Upgrade Headaches" où il a résumé la majeur partie des problèmes qu'une migration de 8i vers 10g peut produire en partant du calcul des statistiques (dbms_stats au lieu de analyze), le nouvel algorithme du group by, etc...



Par ailleurs, vous dites que vous avez mis la valeur du cursor_sharing à FORCE ce qui vous a permis de gagner 4 minutes. Pourriez vous nous donner plus de détails sur les traitements que vous faites afin que l'on puisse vous expliquer pourquoi il va falloir éviter de forcer le cursor_sharing

Bien respectueusement

Mohamed Houri

[Vlad59]

• Les bases sont sur un serveur comparable ?
• Les statistiques sont à jour des deux côtés ?

[jlm22]

Bonjour,

En faite je ne fait que poursuivre le travail d'un collègue et c'est lui qui avait pris l'initiative de mettre le = FORCE, je ne peut pas vraiment vous en dire plus.

Concernant les serveurs se sont tous les 2 des VM avec windows 2k3 dessus, avec les mêmes ressources bien entendu

J'ai une autre précision, j'utilise actuellement le logiciel spotlight pour superviser ma base de donnée 10G et je remarque qu'au lancement de ma procédure j'ai un problème au niveau du parse qui ralentit le nombre de requête traité je passe de 300 à 120/150 environ ...

voici l'algo de ma procédure (il s'agit d'un programme VB.NET) :

la base 1 est une base progress
la base 2 est soit la base en 8i soit la base en 10G

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
Début du programme
	Connexion à la base 1
	Récupération de données base 1
 
	Connexion à la base 2
	Début de la transaction
		Essayer
                                      suppression des données base 2 TABLE 1
                                      Insertion des données base 1 dans base 2 TABLE 1
			Validation
		Sinon
			Annulation
	Fin de la transaction
Fin du programme

Je vais tester ta proposition Mohamed ... si vous souhaitez plus de précision

[Rams7s]

Bonjour,

Vu que vous faites deux traitements differents dans les bases Oracles (8/10), vous pourriez regarder le temps que ca prend pour chacune des operations?

Le temps passe a supprimer dans 8i, et pareil pour 10g. Et la meme chose pour l'insertion des donnees.
Ca peut eventuellement montrer que le probleme ne vient que de l'insertion ou que de la suppression, ou a defaut que c'est plus lent partout.

[jlm22]

Autant pour moi je n'ai pas précisé, j'ai des fichiers de logs :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
 
Sur 10G
18/07/2011 15:10:59: #################### Début intégration #################### : 
18/07/2011 15:10:59: Connexion BASE1 OK : 
18/07/2011 15:10:59: Connexion BASE2 OK : 
18/07/2011 15:10:59: Début récupération ZARTFAB : 
18/07/2011 15:10:59: Fin récupération ZARTFAB : 
18/07/2011 15:10:59: Début suppression ZARTFAB dans BASE2 : 
18/07/2011 15:11:02: Fin suppression ZARTFAB dans BASE2 : 
18/07/2011 15:11:02: Début insertion ZARTFAB dans BASE2 : 
18/07/2011 15:21:49: Fin insertion ZARTFAB dans BASE2 : 
18/07/2011 15:21:49: #################### Fin intégration #################### :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
 
Sur 8i
Intégration dans ZARTFAB2 de BOAC5 PROD oracle 8i (5min 48)
18/07/2011 10:33:19: #################### Début intégration #################### : 
18/07/2011 10:33:19: Connexion BASE1 OK : 
18/07/2011 10:33:19: Connexion BASE2 OK : 
18/07/2011 10:33:19: Début récupération ZARTFAB : 
18/07/2011 10:33:19: Fin récupération ZARTFAB : 
18/07/2011 10:33:19: Début suppression ZARTFAB dans BASE2 : 
18/07/2011 10:33:38: Fin suppression ZARTFAB dans BASE2 : 
18/07/2011 10:33:38: Début insertion ZARTFAB dans BASE2 : 
18/07/2011 10:39:26: Fin insertion ZARTFAB dans BASE2 : 
18/07/2011 10:39:26: #################### Fin intégration #################### :

Donc a priori cela vient de l'insertion ...

[Vlad59]

Ton tablespace de rollback est configuré pareil ?

[jlm22]

quel est le rapport ?

De toute façon c'est un import/export donc les 2 bases de données sont sensé être exactement les mêmes.

J'ai remarqué grâce à spotlight que pendant 1 minutes environ tout se passe bien, 300 SQL exec/s et 600 parse req/s au niveau du shared pool puis au bout d'un certains temps le CPU s'enflamme 70 % au lieu de 40 % et le parse descend à 400 et le SQL exec arrive à 100/150 , je soupçonne le sharedpool plein cependant il ne m'affiche que 50% d'utilisations ...

[Mohamed.Houri]

Envoyé par jlm22

quel est le rapport ?
je soupçonne le sharedpool plein cependant il ne m'affiche que 50% d'utilisations ...

C'est pourquoi lorsque le cursor_sharing a été mis à FORCE vous avez gagné un peu de temps. C'est la non utilisation des "bind variables" qui consomme beaucoup de cpu et rempli le "shared pool".

Que donne la requête suivante

Code :

1
2
3
4
 
SELECT count(1)
FROM v$sql
WHERE executions <=2;

Il y a certainement beaucoup d'instructions sql qui ne sont pas partagées (re-executés)

Bien à vous

Mohamed Houri

[skuatamad]

Pour de bonne performance il faut évidemment utiliser des binds variables comme l'a diagnostiqué Mohamed.Houri.
Cependant "300 SQL exec/s et 600 parse req/s", laisse supposer qu'en plus de l'absence de binds variables, l'insertion se fait ligne à ligne, ce qui est également contre performant.

L'idéal est d'utiliser uniquement du SQL via un dblink par exemple, mais en VB.NET il faudrait que tu fasses des recherches sur le BULK INSERT qui dépendront probablement du driver utilisé, le gain en performance sera très conséquent quelque soit la version d'oracle 8i ou 10g.
Je ne connais pas .NET mais ça semble possible :

vb.net oracle bulk insert - Recherche Google

vb.net oracle bulk insert - Recherche Google

[jlm22]

Le "300 SQL exec/s et 600 parse req/s" me convient amplement au niveau des performance, j'aimerais juste pouvoir réalisé c'est même performance en 10G.

C'est pourquoi lorsque le cursor_sharing a été mis à FORCE vous avez gagné un peu de temps. C'est la non utilisation des "bind variables" qui consomme beaucoup de cpu et rempli le "shared pool".

si j'ai bien compris je dois donc baisser la tailler du shared pool pour de meilleur performance, non ? de quel taille doit être le shared pool ?

voici le résultat de la requête :

Code :

1
2
3
4
5
6
7
8
 
SQL> SELECT count(1)
  2  FROM v$sql
  3  WHERE executions<=2;
 
  COUNT(1)
----------
       968

[Mohamed.Houri]

Bonjour,

Non, je n'ai pas suggéré un changement du shared pool si tant est que ce changement vous apportera quelque chose. En effet, lorsque vous n'utilisez pas les "bind variables" les mêmes instructions sql ne sont pas reutilisées (968 instructions sql sont exécutées au maximum 2 fois), ceci a comme effet de remplir le shared pool et de générer une consommation excessive de CPU et de "Physical I/O".

Je pense, comme je vous l'ai suggéré la première fois, la meilleure chose à faire dans votre cas, c'est de changer l'optimisateur à sa version '8.1.7' et de voir si vous retrouvez en 10g les temps de performance de la 8i.

Dans une deuxième étape, vous devez améliorer la performance de votre programme en utilisant des bind variables et du SQL(si c'est possible) au lieu du PL/SQL. Par exemple, préferez ceci

Code :

1
2
3
4
5
6
7
8
 
BEGIN
  INSERT INTO t1
  SELECT FROM t2
  WHERE ..;
 
  COMMIT;
END;

à ceci

Code :

1
2
3
4
5
6
7
8
9
10
11
 
BEGIN
FOR x IN (SELECT * FROM t2)
LOOP
  INSERT INTO t1()
  VALUES (x., x.);
 
END LOOP;
COMMIT;
 
END;

En ce qui concerne l'utilisation des bind variables, je vous conseille de rassembler toutes vos intructions SQL dans une procédure stockée et d'appeler celle-ci via votre client (.Net ou VB).

Le PL/SQL static (procédure stockée) a comme avantage que tout ce que vous mettez dedans est "auto-bindé"; c'est à dire que lorsque vous utilisez les procédures stockées vous êtes sûr d'avoir utilisé les bind variables à une seule et importante condition : lorsque vous appelez cette procédure via votre client .Net veuillez à bien l'appeler avec des "bind variables"

Bien respectueusement

Mohamed Houri

[jlm22]

Merci pour votre intérêt à mon problème, mais comment expliquez-vous la fait que les bind variables ai plus d'influence pour la 10G que pour la 8i ? Car il s'agit du même programme qui est exécuté sur la 8i .... J'avoue être étonner que cela vienne de l'algorithme.

Le "ALTER session SET optimizer_features_enable='8.1.7';" n'a rien changé.

Cordialement,

[Mohamed.Houri]

Si les "bind variables" n'étaient pas utilisées en 8i, elles ne seront pas utilisées également en 10g (sans un changement de votre part).

Puisque le retour à l'ancien optimisateur n'a rien donné, pourriez vous alors activer les traces (10046 level 12) afin de voir comment votre temps de traitement est consommé.

Bien cordialement

Mohamed Houri

[jlm22]

Bon j'ai décidé de modifier mon programme, an ajoutant des requêtes paramétrées dans VB grâce à OracleParameter.

Le résultat est assez impressionnant seulement 2 min pour tous insérer

Bref, merci pour votre aide

[laurentschneider]

Envoyé par jlm22

Concernant les serveurs se sont tous les 2 des VM avec windows 2k3 dessus, avec les mêmes ressources bien entendu

Bon, le noyeau Oracle grandit à chaque version, ainsi que les besoins de mémoire en général.

ce qui pouvait tourner avec 500 még en 8i risque d'être insuffisant en 10g.

Aussi, quelle drôle d'idée de migrer d'une version complètement obsolète (du siècle passé) en une version qui n'est déjà plus en support premium depuis 2010 !

11gR2 s'impose!

[jlm22]

Arf fausse alerte le problème n'est qu'à moitié régler ! Y'a t-il des paramètres a ajouter pour avoir les mêmes performance d'une 8i à une 10g ?

[Heaven93]

Bonjour,

il n'y a évidemment pas de paramètre magique. en 11g non plus
elle marchait comment la base en 8? en mode rule?
le CBO est un énorme changement dans le traitement des requêtes. l'essentiel est d'avoir des stats très à jour sur les objets afin qu'oracle choisisse le bon chemin pour exécuter les requêtes le plus efficacement possible.
pouvez-vous nous poster un comparatif des events sur la base en 8i et sur la base en 10g au moment du traitement? un awr sur la période de test et un awrsqrpt sur la requête seraient très instructifs

[laurentschneider]

je suis assez pas d'accord... en 10g , 11g il y a beaucoup de parametre magique qui font tout pour toi (style SGA_TARGET et PGA_AGGREGATE_TARGET) ainsi que l'UNDO tablespace, le locally managed, l'automatic segment space management et beaucoup d'amelioration interne.

Pour cost based, revois tes stats

Le OPTIMIZER_MODE=rule existe toujours mais n'est plus supporte

A+

[Heaven93]

mouais, magique pour le dba qui a moins de taf ?
la meilleure des optimisations passe par une revue du schema et/ou réécriture des requêtes d'après ce que je constate au quotidien. oui, l'administration n'aurait presque plus besoin de dba mais le code reste le point névralgique