Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
La DEV est-elle représentative de la PROD (copie exacte et même requête) ?
De toute façon ça change rien au problème, avoir un process de qualification qui ne tient pas compte des problèmes rencontrés j'vois pas l'intérêt. La seule réponse (si tu ne veux vraiment pas toucher aux stats) est la suivante : "cette version d'Oracle posera un problème sur cette requête au moins"
Oui la DEV est iso-prod, mais bonne nouvelle, il semblerait qu'en production il vont devoir installer la version 9.2.0.8 car se serait la seule disponible en ligne pour une install sur les machines, j'attends la confirmation et je patch mes serveurs de DEV.
En attendant, nous venons de voir que si on ne recalcule pas les stats sur la machine et que l'import se fait avec la paramètre avec analyze=N, alors l'ensemble des instances fonctionnent correctement, donc en attendant de patcher les instances en 9.2.0.8, nous allons faire le montage ainsi.
Je vais monter une autre machine en Solaris8 et Ora 9.2.0.8 et nous allons tester si il y a du mieux.
MErci pour tout, le mieux est de marquer le sujet comme corrigé même si ce n'est pas encore totalement le cas.
donc vous faites le choix du mode RULE... bah vous êtes pas au bout de vos peines quand vous allez passé le 9.2.0.8 et repasser les stats
et pourquoi ?
Quels sont les problèmes que l'on risquent d'avoir en passant en 9.2.0.8 et donc en remodifiant en CHOOSE et en passant le DBMS_STATS ?
Non le choix définitif n'est pas encore fixé je pousse en effet dans la voie de la 9.2.0.8, je suis juste en train de chercher les bons leviers pour faire basculer l'ensemble dans la bonne direction
bah tout simplement que pas mal de plan d'exécution risquent de changer. Un exemple tout bête, tu as 3 colonnes a, b et c et un index sur a,b et un autre sur b,c... selon les stats sur chaque index, le plan peut être différent qu'en mode RULE. Et la solution sera peut-être de remplacer ces indexes par un index sur (b,a,c)
quand l'optimiseur se plante c'est pas par hasard... s'obliger à passer par un index quelque soit le contexte c'est pas forcément une bonne idée, d'où la création du CBO qui est contraignant mais bien plus performant
Ok je voit. Merci pour le temps pris à me répondre.
Récemment je suis intervenu chez un client qui effectue plusieurs insert en allant chercher les data dans quelques tables volumineuses (plusieurs 10aines de millions de lignes). Plan d'exec : hash, hash, hash, toutes les grosses tables doivent être intégralement lues. Au vu des statspack : grosse conso de temp. Confirmé par les plan d'exec.Envoyé par orafrance
Je lui ai fait considérablement augmenter sa PGA => quasiment plus d'io, tout se fait en mémoire.
Il y a d'autres pistes pour ce cas précis mais déjà ses traitements ont été boostés.
Voila pourquoi j'avais évoqué la piste PGA.
ouais, enfin le problème c'est les I/O ou les hashs... parce que des requêtes qui font du FTS et donc du hash, ça peut peut-être se régler à coup d'indexes. Sinon tu peux aussi mettre toutes les tables en KEEP et faire un cache buffer = taille de la base comme ça t'as plus d'I/O
ouais, enfin le problème c'est les I/O ou les hashs... parce que des requêtes qui font du FTS et donc du hash, ça peut peut-être se régler à coup d'indexes. Sinon tu peux aussi mettre toutes les tables en KEEP et faire un cache buffer = taille de la base comme ça t'as plus d'I/O
Les FTS étaient inévitables car besoin de tout lire pour générer des indicateurs (base plutôt décisionnelle).
En plus, partitions (range) sur une clé non utilisée dans les requêtes.
J'ai changé ça en splittant leur traitement en n requêtes (n=nb de partitions) et en ajoutant un critère sur la clé de partitionnement : 2h30 de traitement au lieu de 24h (et il y a encore davantage à gagner).
Grosse table en cache : déjà fait mais solution peu viable car il s'agissait d'une table qui croissait. Temps de réponse béton mais...c'est une autre histoire, on s'éloigne du sujet de Knonix.
Dans le datawarehouse en principe tu fais le contraire de ce que tu as choisi, on privilégie la lecture disque parce que de toute façon c'est pas possible de tout monter en mémoire. En revanche tu fais des gros blocs, tu récupères le maximum de bloc par accès, etc...
Et c'était pas mieux de faire du parallélisme qui aurait splitté tout seul ? Et quid des indexes globaux ?
Tu m'étonnes
D'accord mais je ne suis sollicité que sur le schéma qui réceptionne les datas. Je dois faire avec les contraintes d'un existant difficile à modifier :un seul volume raid5 pour tous les datafiles, une partie des pk de certaines tables non partitionnées (alors que les tables oui), partitionnement par range alors que list aurait été préférable, el pctfree laissé à 10 alors qu'il n'y a pas d'update etc. Je le notifierai mais les préco demandées portent sur le schéma qui réceptionne des valeurs calculées.En revanche tu fais des gros blocs, tu récupères le maximum de bloc par accès, etc...
Malgré les 16 proc (vus par oracle), à partir d'un dop de 8, plus de gain. Avec 4 je gagnais trés peu.
De plus, parallélisme et raid5 (1 seul volume) ne me semblent pas faire bon ménage.
Index globaux ? Sur le schéma concerné par les pb de perf, il n'y en a pas.
Au final, une sérialisation des traitements est plus bénéfique qu'un traitement massif.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager