tout à fait d'accord. Je tune toujours apres coup. Mais l'exemple initial, on etait sur de l'unicité de id, donc le distinct avait un sens, même s'il apportait pas grand chose vu la simplicité de la requête. mais quand on est sur de quelques choses, autant l'écrire de suite. En general, le mec qui tune n'est pas celui qui a développé. Et donner des infos à l'optimiseur par l'écriture plus propre de la requête et mettre un hint sont deux choses différentes
Fred Brouard - SQLpro a écrit :
je connais bien tout cela, mais le contraire est aussi vrai.
A force de forcer un plan de requête ce dernier peut s'avérer mauvais à la montée en charge.
L'optimisation est donc plutôt à faire après montée en charge et en récrivant la requête sans tag si possible. Si tout cela échoue alors taguer pour obliger certains verrous.
Mais donner de but en blanc une requête aussi tordue et spécifique n'est franchement pas une bonne chose !
A +
Hugues a écrit:
Non, il est tres bon. Mais je part du principe que tout info donnée à l'optimiseur va lui simplifier la vie, donc lui faire gagner du temps. Peut etre a tu déjà écrit des compilateurs ou des moteurs de recherche. Dans ce cas, tu comprendras plus facilement ma pensée.
Mais en prenant un cas simple : select * from t1 where id in (select id from t2 where ...)
l'optimiseur va travailler correctement et faire un select * from t1, t2 where t1.id = t2.id and ...
mais ça, ce n'est pas un travail d'optimiseur mais plutot au développeur de le faire. Et puis, pour faire cette transformation, le noyau a du bosser, donc ça prend du temps.
La, c'était un cas très simple. Mais tu dois savoir qu'il y a fréquemment des requêtes avec des dizaines de tables, dans des traitements batch, que le temps est limité (car la sauvegarde démarre à 3h du mat et qu'il faut avoir fini avant)...
D'autres cas encore nécessite de l'intelligence coté développeur. par exemple, utiliser des variables de bind pour que le plan d'execution soit la pour la fois suivante (select * from t1 where id = :v) mais quand on fait un (select * from t1 where nom like :v), l'optimiseur a de forte chance de faire un full table scan car il n'a aucune idée de ce que contient la variable. Encore du travail pour le -bon- développeur (soit pas de bind, soit mettre un hint pour guider l'optimiseur). Mais en général, le -mauvais- développeur, il n'en a rien à faire et demande à l'administrateur d'ajouter des cpu ou de la ram.
Fred Brouard - SQLpro a écrit :
L'otpimiseur d'Oracle est si mauvais que cela qu'il n'est pas capable de lui même de trouver un bon plan d'exécution et de tirer partie de ses propres structures internes ???
;-)
A +
Hugues a écrit:
Yves Calvet a écrit :
Bruno Jargot a écrit :
Tu veux dire que le moteur Oracle n'est pas capable de s'arrêter tout seul à la première occurence trouvée ? À ce niveau, je suppose qu'il s'agit d'un bug.
fais un rapport de bug: le gens d'Oracle ont aussi le droit de se marrer :-)
Plus on fournit d'info au moteur de base de données, moins il a de chose à déduire par lui même et meilleures sont les perfs. Effectivement, il y a bcp de développeurs qui n'ont aucune idée de comment ça marche derrière (analyse sémantique, compilation, fonctionnement des différents niveaux de caches, etc...) et écrive n'importe comment, et ne comprennent pas ensuite que les perfs soit mauvaises. C'est sur que sur une bête requête à 1 ou 2 tables, le noyau fait plein de choses tout seul. Quand tu atteindras les 30 ou 50 tables avec différents niveaux d'agrégats... dans tes requêtes, tu comprendras que tout petit peu aide et sera moins ironique.
tout à fait d'accord. Je tune toujours apres coup. Mais l'exemple
initial, on etait sur de l'unicité de id, donc le distinct avait un
sens, même s'il apportait pas grand chose vu la simplicité de la requête.
mais quand on est sur de quelques choses, autant l'écrire de suite. En
general, le mec qui tune n'est pas celui qui a développé.
Et donner des infos à l'optimiseur par l'écriture plus propre de la
requête et mettre un hint sont deux choses différentes
Fred Brouard - SQLpro a écrit :
je connais bien tout cela, mais le contraire est aussi vrai.
A force de forcer un plan de requête ce dernier peut s'avérer mauvais à
la montée en charge.
L'optimisation est donc plutôt à faire après montée en charge et en
récrivant la requête sans tag si possible. Si tout cela échoue alors
taguer pour obliger certains verrous.
Mais donner de but en blanc une requête aussi tordue et spécifique n'est
franchement pas une bonne chose !
A +
Hugues a écrit:
Non, il est tres bon. Mais je part du principe que tout info donnée à
l'optimiseur va lui simplifier la vie, donc lui faire gagner du temps.
Peut etre a tu déjà écrit des compilateurs ou des moteurs de
recherche. Dans ce cas, tu comprendras plus facilement ma pensée.
Mais en prenant un cas simple :
select * from t1 where id in (select id from t2 where ...)
l'optimiseur va travailler correctement et faire un
select * from t1, t2 where t1.id = t2.id and ...
mais ça, ce n'est pas un travail d'optimiseur mais plutot au
développeur de le faire. Et puis, pour faire cette transformation, le
noyau a du bosser, donc ça prend du temps.
La, c'était un cas très simple. Mais tu dois savoir qu'il y a
fréquemment des requêtes avec des dizaines de tables, dans des
traitements batch, que le temps est limité (car la sauvegarde démarre
à 3h du mat et qu'il faut avoir fini avant)...
D'autres cas encore nécessite de l'intelligence coté développeur.
par exemple, utiliser des variables de bind pour que le plan
d'execution soit la pour la fois suivante (select * from t1 where id =
:v)
mais quand on fait un (select * from t1 where nom like :v),
l'optimiseur a de forte chance de faire un full table scan car il n'a
aucune idée de ce que contient la variable. Encore du travail pour le
-bon- développeur (soit pas de bind, soit mettre un hint pour guider
l'optimiseur). Mais en général, le -mauvais- développeur, il n'en a
rien à faire et demande à l'administrateur d'ajouter des cpu ou de la
ram.
Fred Brouard - SQLpro a écrit :
L'otpimiseur d'Oracle est si mauvais que cela qu'il n'est pas capable
de lui même de trouver un bon plan d'exécution et de tirer partie de
ses propres structures internes ???
;-)
A +
Hugues a écrit:
Yves Calvet a écrit :
Bruno Jargot a écrit :
Tu veux dire que le moteur Oracle n'est pas capable de s'arrêter tout
seul à la première occurence trouvée ?
À ce niveau, je suppose qu'il s'agit d'un bug.
fais un rapport de bug: le gens d'Oracle ont aussi le droit de se
marrer :-)
Plus on fournit d'info au moteur de base de données, moins il a de
chose à déduire par lui même et meilleures sont les perfs.
Effectivement, il y a bcp de développeurs qui n'ont aucune idée de
comment ça marche derrière (analyse sémantique, compilation,
fonctionnement des différents niveaux de caches, etc...) et écrive
n'importe comment, et ne comprennent pas ensuite que les perfs soit
mauvaises.
C'est sur que sur une bête requête à 1 ou 2 tables, le noyau fait
plein de choses tout seul. Quand tu atteindras les 30 ou 50 tables
avec différents niveaux d'agrégats... dans tes requêtes, tu
comprendras que tout petit peu aide et sera moins ironique.
tout à fait d'accord. Je tune toujours apres coup. Mais l'exemple initial, on etait sur de l'unicité de id, donc le distinct avait un sens, même s'il apportait pas grand chose vu la simplicité de la requête. mais quand on est sur de quelques choses, autant l'écrire de suite. En general, le mec qui tune n'est pas celui qui a développé. Et donner des infos à l'optimiseur par l'écriture plus propre de la requête et mettre un hint sont deux choses différentes
Fred Brouard - SQLpro a écrit :
je connais bien tout cela, mais le contraire est aussi vrai.
A force de forcer un plan de requête ce dernier peut s'avérer mauvais à la montée en charge.
L'optimisation est donc plutôt à faire après montée en charge et en récrivant la requête sans tag si possible. Si tout cela échoue alors taguer pour obliger certains verrous.
Mais donner de but en blanc une requête aussi tordue et spécifique n'est franchement pas une bonne chose !
A +
Hugues a écrit:
Non, il est tres bon. Mais je part du principe que tout info donnée à l'optimiseur va lui simplifier la vie, donc lui faire gagner du temps. Peut etre a tu déjà écrit des compilateurs ou des moteurs de recherche. Dans ce cas, tu comprendras plus facilement ma pensée.
Mais en prenant un cas simple : select * from t1 where id in (select id from t2 where ...)
l'optimiseur va travailler correctement et faire un select * from t1, t2 where t1.id = t2.id and ...
mais ça, ce n'est pas un travail d'optimiseur mais plutot au développeur de le faire. Et puis, pour faire cette transformation, le noyau a du bosser, donc ça prend du temps.
La, c'était un cas très simple. Mais tu dois savoir qu'il y a fréquemment des requêtes avec des dizaines de tables, dans des traitements batch, que le temps est limité (car la sauvegarde démarre à 3h du mat et qu'il faut avoir fini avant)...
D'autres cas encore nécessite de l'intelligence coté développeur. par exemple, utiliser des variables de bind pour que le plan d'execution soit la pour la fois suivante (select * from t1 where id = :v) mais quand on fait un (select * from t1 where nom like :v), l'optimiseur a de forte chance de faire un full table scan car il n'a aucune idée de ce que contient la variable. Encore du travail pour le -bon- développeur (soit pas de bind, soit mettre un hint pour guider l'optimiseur). Mais en général, le -mauvais- développeur, il n'en a rien à faire et demande à l'administrateur d'ajouter des cpu ou de la ram.
Fred Brouard - SQLpro a écrit :
L'otpimiseur d'Oracle est si mauvais que cela qu'il n'est pas capable de lui même de trouver un bon plan d'exécution et de tirer partie de ses propres structures internes ???
;-)
A +
Hugues a écrit:
Yves Calvet a écrit :
Bruno Jargot a écrit :
Tu veux dire que le moteur Oracle n'est pas capable de s'arrêter tout seul à la première occurence trouvée ? À ce niveau, je suppose qu'il s'agit d'un bug.
fais un rapport de bug: le gens d'Oracle ont aussi le droit de se marrer :-)
Plus on fournit d'info au moteur de base de données, moins il a de chose à déduire par lui même et meilleures sont les perfs. Effectivement, il y a bcp de développeurs qui n'ont aucune idée de comment ça marche derrière (analyse sémantique, compilation, fonctionnement des différents niveaux de caches, etc...) et écrive n'importe comment, et ne comprennent pas ensuite que les perfs soit mauvaises. C'est sur que sur une bête requête à 1 ou 2 tables, le noyau fait plein de choses tout seul. Quand tu atteindras les 30 ou 50 tables avec différents niveaux d'agrégats... dans tes requêtes, tu comprendras que tout petit peu aide et sera moins ironique.
Hugues
(¯`·..Yttrium ...·´¯) a écrit :
"Hugues" a écrit dans le message de news: 42a430e9$0$25834$
[...] Encore du travail pour le -bon- développeur [...] [...] le -mauvais- développeur, il n'en a rien à faire et demande [...]
Bonjour,
De l'art de distinguer le *bon* développeur du *mauvais* développeur....
Salutations.
Effectivement... les mauvais, y se prennent pas le chou et quand ça merde, c'est pas la faute de leur code mais des autres couches du système (sgbd, dba, machine ou autre)
(¯`·..Yttrium ...·´¯) a écrit :
"Hugues" <hugues_2003_fr@yahoo.fr> a écrit dans le message de news:
42a430e9$0$25834$626a14ce@news.free.fr...
[...] Encore du travail pour le -bon- développeur [...]
[...] le -mauvais- développeur, il n'en a rien à faire et demande [...]
Bonjour,
De l'art de distinguer le *bon* développeur du *mauvais* développeur....
Salutations.
Effectivement... les mauvais, y se prennent pas le chou et quand ça
merde, c'est pas la faute de leur code mais des autres couches du
système (sgbd, dba, machine ou autre)
"Hugues" a écrit dans le message de news: 42a430e9$0$25834$
[...] Encore du travail pour le -bon- développeur [...] [...] le -mauvais- développeur, il n'en a rien à faire et demande [...]
Bonjour,
De l'art de distinguer le *bon* développeur du *mauvais* développeur....
Salutations.
Effectivement... les mauvais, y se prennent pas le chou et quand ça merde, c'est pas la faute de leur code mais des autres couches du système (sgbd, dba, machine ou autre)
Yves Calvet
Hugues a écrit :
C'est sur que sur une bête requête à 1 ou 2 tables, le noyau fait plein de choses tout seul. Quand tu atteindras les 30 ou 50 tables avec différents niveaux d'agrégats... dans tes requêtes, tu comprendras que tout petit peu aide et sera moins ironique.
Pour ton info, j'ai longtemps bossé dans le noyau d'Oracle comme programmeur chez Oracle Corp ainsi que sur le DLM avec Oracle Nederland. bien, le bonjour chez toi.
C'est sur que sur une bête requête à 1 ou 2 tables, le noyau fait plein
de choses tout seul. Quand tu atteindras les 30 ou 50 tables avec
différents niveaux d'agrégats... dans tes requêtes, tu comprendras que
tout petit peu aide et sera moins ironique.
Pour ton info, j'ai longtemps bossé dans le noyau d'Oracle comme
programmeur chez Oracle Corp ainsi que sur le DLM avec Oracle Nederland.
bien, le bonjour chez toi.
C'est sur que sur une bête requête à 1 ou 2 tables, le noyau fait plein de choses tout seul. Quand tu atteindras les 30 ou 50 tables avec différents niveaux d'agrégats... dans tes requêtes, tu comprendras que tout petit peu aide et sera moins ironique.
Pour ton info, j'ai longtemps bossé dans le noyau d'Oracle comme programmeur chez Oracle Corp ainsi que sur le DLM avec Oracle Nederland. bien, le bonjour chez toi.
"Yves Calvet" a écrit dans le message de news: 42a44e52$0$23466$
Pour ton info, j'ai longtemps bossé dans le noyau d'Oracle comme programmeur chez Oracle Corp ainsi que sur le DLM avec Oracle Nederland. bien, le bonjour chez toi.
Frimeur... ;-)
"Yves Calvet" <ycalvet3@hotmail.com> a écrit dans le message de news:
42a44e52$0$23466$626a14ce@news.free.fr...
Pour ton info, j'ai longtemps bossé dans le noyau d'Oracle comme
programmeur chez Oracle Corp ainsi que sur le DLM avec Oracle Nederland.
bien, le bonjour chez toi.
"Yves Calvet" a écrit dans le message de news: 42a44e52$0$23466$
Pour ton info, j'ai longtemps bossé dans le noyau d'Oracle comme programmeur chez Oracle Corp ainsi que sur le DLM avec Oracle Nederland. bien, le bonjour chez toi.
Frimeur... ;-)
see
Yves Calvet wrote:
Bruno Jargot a écrit : > > Tu veux dire que le moteur Oracle n'est pas capable de s'arrêter tout > seul à la première occurence trouvée ? > À ce niveau, je suppose qu'il s'agit d'un bug.
fais un rapport de bug: le gens d'Oracle ont aussi le droit de se marrer :-)
ça t'arrive souvent de faire des réponses aussi méprisantes ?
-- Bruno http://errance.lirano.net (photographies)
Yves Calvet <ycalvet3@hotmail.com> wrote:
Bruno Jargot a écrit :
>
> Tu veux dire que le moteur Oracle n'est pas capable de s'arrêter tout
> seul à la première occurence trouvée ?
> À ce niveau, je suppose qu'il s'agit d'un bug.
fais un rapport de bug: le gens d'Oracle ont aussi le droit de se marrer
:-)
ça t'arrive souvent de faire des réponses aussi méprisantes ?
--
Bruno
http://errance.lirano.net (photographies)
Bruno Jargot a écrit : > > Tu veux dire que le moteur Oracle n'est pas capable de s'arrêter tout > seul à la première occurence trouvée ? > À ce niveau, je suppose qu'il s'agit d'un bug.
fais un rapport de bug: le gens d'Oracle ont aussi le droit de se marrer :-)
ça t'arrive souvent de faire des réponses aussi méprisantes ?
-- Bruno http://errance.lirano.net (photographies)
Antoun
Etienne SOBOLE wrote:
c'est possible de faire un insert dans une table sous condition?
j'ai un table qui relie un contact a une société et je voudrai faire l'insertion dans cette table que si l'entrée n'existe pas deja !
à noter qu'avec MySQL il y a l'ordre REPLACE qui est un INSERT si l'entrée n'existe pas et ressemble à un UPDATE sinon...
Fred, btw, qu'est-ce que ton nouveau bouquin par rapport à l'ancien ? une mise à jour avec changement d'éditeur et refonte de la maquette, ou il y a + de différence que ça ?
Fred, btw, qu'est-ce que ton nouveau bouquin par rapport à l'ancien ?
une mise à jour avec changement d'éditeur et refonte de la maquette, ou
il y a + de différence que ça ?
Fred, btw, qu'est-ce que ton nouveau bouquin par rapport à l'ancien ? une mise à jour avec changement d'éditeur et refonte de la maquette, ou il y a + de différence que ça ?
