Optimisation d'un algo [PL/SQL] - SQL/NoSQL - Programmation
MarshPosté le 04-03-2011 à 17:26:56
B'jour,
J'ai deux questions sur l'optimisation d'un algorithme PL/SQL (sous Oracle donc).
1. L'algo doit effectuer une requete légèrement complexe (5 jointures, 4 se faisant sur clés uniquement, et 1 un peu moins performante (incluant une manipulation de varchar)).
La requete va ramener des lignes avec des IDs venant de différentes tables (appelons-les ID1, ID2 et ID3, venant respectivement de table1, table2 et table3). Pour chaque ligne, l'algo doit insérer la paire ID1, ID2 dans une table T4, puis updater un flag pour ID1 dans table1, puis updater un flag pour ID3 dans table3 (j'espère que c'est clair...).
Donc ma question est: d'un point de vue de performance, vaut-il mieux utiliser un cursor avec la requete initiale, puis boucler sur chaque ligne du cursor en faisant insert/update/update pour chaque, ou vaut-il mieux enchainer directement 3 fois la requete (une fois pour tous les inserts d'un coup, puis tous les update table1 d'un coup, puis tous les update table3 d'un coup)? Sachant que la solution 2 permet d'"alléger" la requete, certaines jointures étant nécessaires seulement pour l'insert par exemple. Théoriquement les différents caches de Oracle devraient maximiser la réutilisation des résultats communs entre les 3 requetes, mais n'y a-t-il pas une limite à cela dans le sens où si les requetes sont longues à exécuter et la base fortement sollicitée par ailleurs, les résultats intermédiaires seront vidés du cache et hop DTC?
2. J'ai un algo déjà fait sous la main, qui a opté pour la solution 1. Pour les updates, l'algo se sert des rowids au lieu des IDs - bien que les IDs soient des clés primaires simples. Si on oublie les problèmes de fiabilité liés à l'utilisation de rowid (normalement les lignes de table1 et table3 ne sont jamais deletées), quel est l'avantage à utiliser rowid? Performance? (évidemment, je demande parce que je n'ai pas le gars qui a écrit ca sous la main...)
Merci pour vos lumières!
--------------- C'était vraiment très intéressant.
Marsh Posté le 04-03-2011 à 17:26:56
B'jour,
J'ai deux questions sur l'optimisation d'un algorithme PL/SQL (sous Oracle donc).
1. L'algo doit effectuer une requete légèrement complexe (5 jointures, 4 se faisant sur clés uniquement, et 1 un peu moins performante (incluant une manipulation de varchar)).
La requete va ramener des lignes avec des IDs venant de différentes tables (appelons-les ID1, ID2 et ID3, venant respectivement de table1, table2 et table3).
Pour chaque ligne, l'algo doit insérer la paire ID1, ID2 dans une table T4, puis updater un flag pour ID1 dans table1, puis updater un flag pour ID3 dans table3 (j'espère que c'est clair...).
Donc ma question est: d'un point de vue de performance, vaut-il mieux utiliser un cursor avec la requete initiale, puis boucler sur chaque ligne du cursor en faisant insert/update/update pour chaque, ou vaut-il mieux enchainer directement 3 fois la requete (une fois pour tous les inserts d'un coup, puis tous les update table1 d'un coup, puis tous les update table3 d'un coup)? Sachant que la solution 2 permet d'"alléger" la requete, certaines jointures étant nécessaires seulement pour l'insert par exemple. Théoriquement les différents caches de Oracle devraient maximiser la réutilisation des résultats communs entre les 3 requetes, mais n'y a-t-il pas une limite à cela dans le sens où si les requetes sont longues à exécuter et la base fortement sollicitée par ailleurs, les résultats intermédiaires seront vidés du cache et hop DTC?
2. J'ai un algo déjà fait sous la main, qui a opté pour la solution 1. Pour les updates, l'algo se sert des rowids au lieu des IDs - bien que les IDs soient des clés primaires simples. Si on oublie les problèmes de fiabilité liés à l'utilisation de rowid (normalement les lignes de table1 et table3 ne sont jamais deletées), quel est l'avantage à utiliser rowid? Performance? (évidemment, je demande parce que je n'ai pas le gars qui a écrit ca sous la main...)
Merci pour vos lumières!
---------------
C'était vraiment très intéressant.