Reprise du message précédent :

Tu change la valeur d'un champ dans une autre table quand tu commences et tu le reset quand tu as finis.
Avant de commencer ta procedure tu check la valeur du champ.
Si c'est occupé tu fais un WAITFOR 00:05 (5sec) et tu reesayes.
Penses a mettre un timeout apres X tentatives pour que ca ne boucle pas a l'infini si un truc deconne.
 
C'est pas super propre mais c'est pas prévu pour a l'origine

Sinon je pensais stocker dans une table "d'attente" toutes les demandes utilisateurs et checker en fin de proc s'il y a encore des demandes en cours dans la table d'attente et si c'est le cas, on ré-exécute.
(Enfin, faut que j'y réfléchisse.)

Oui ca marche aussi ca, c'est mieux que d'utiliser des lock
Tu peux aussi donner l'option a l'utilisateur de recevoir son rapport plus tard (par email par exemple) en utilisant une solution similaire.

Pour continuer sur cette idée, comment faire pour démarrer une proc à partir d'une appli web (C#), sans que la page web attende la fin de la proc ?

Tu ne le fait pas !
Un serveur Web n'est pas faite pour ça !
Sauf si ton serveur de base de données est capable d'enregister une demande de job.
Sinon, tu demande à un autre process serveur (de ta création par exemple) d'enregister ta demande.
Ce dernier l'éxécutera quand il aura le temps ou par exemple en lançant un thread pour le faire.

Ben si, c'est faisable. Une async job en xmlhttprequest par exemple.

Je suppose qu'il voulait dire que tu le fais pas si tu veux que ton appli reste correcte
 
Soit on connecte directement le web server au sql server et c'est plus simple mais on a beaucoup moins de flexibilité et on risque de se faire avoir comme un bleu par une sql injection.
Soit on passe par une appli en plusieurs couche avec un application server (ou un service sur la meme machine hein) qui est plus compliqué a réaliser mais beaucoup plus flexible (on peut avoir de l'online et de l'offline), ca suit mieux les best practice et le SQL server est protégé par une couche en plus.

Salut

J'ai un pb sur une appli, je pense que c'est un truc assez commun mais je trouve pas de solution satisfaisante.
En gros c'est une appli web Java utilisant Oracle (JDBC toussa).
Certains écrans lancent des requètes assez "lourdes", càd qu'elles peuvent ramener pas mal de résultats (plusieurs centaines de milliers de lignes, voire plusieurs millions pour les pires). Souvent dans les requètes ya des jointures dans tous les sens; la table principale c'est du 166 champs avec 1 milliard d'enregistrements (partitioné à coup de 50/60 millions).
Bref c'est assez lourd.

Les écrans présentent les résultats sous forme de page, donc ca ca passe sans problème - la requete a beau etre lourde, Oracle fait bien le boulot quand tu demandes que les 20 premiers résultats.

Le problème c'est qu'on a un affichage du genre "894635 enregistrements trouvés, affichage page 1 sur 44732".
Et pour faire ca, notre super programme de la mort qui tue wrappe la requete dans un "select count(*)", ce qui évidemment prend des plombes. Sur certains écrans, j'ai vu ce count prendre 40 minutes... Et c'était meme pas pour une des requetes qui retourne plus d'un million de lignes.

Bref, c'est évidemment pas acceptable, et de plus, les utilisateurs étant ce qu'ils sont, une fois qu'il en ont lancé une et que ca revient pas sous 1 ou 2 minutes (ce qui est déjà pas mal, d'habitude les utilisateurs sont moins patients!), ben ils rafraichissent l'écran pour voir si ca marche mieux, donc ils relancent la meme alors que la première tourne toujours. Quelques utilisateurs qui font ca en meme temps et boum la base commence à prendre cher (c'est plus du aux DD qu'aux processeurs, mais bref ca dégrade les perfs).

Bon maintenant la question c'est: on fait quoi? J'ai pensé à quelques trucs mais rien n'est vraiment satisfaisant:
1 - limiter le nombre de résultats (en prévenant l'utilisateur si ca dépasse). Le probleme c'est que meme en mettant ROWNUM<1000 (limite acceptée par le client) certains écrans mettent encore dans les 30 secondes. Le second probleme est que le ROWNUM garantit pas que les memes résultats seront retournés à chaque fois. Et tenter de le garantir en faisant un ORDER BY ben ca nique tout le concept voyez-vous, on repart sur des temps de 40+ minutes.

2 - une solution qui a été proposée sur le produit dans une version ultérieure, c'est de désactiver complètement le count et ne laisser que des liens "page précédente"/"page suivante". Bien pour les perfs mais moins pour l'utilisateur (ie tout écran avec plus de 20 résultats, il n'aura aucune idée du nombre de résultats total).

3 - un truc auquel j'ai pensé, mais ca s'avère moins pratique à mettre en place que prévu et je doute que le client soit OK, c'est de poser une limite de temps (ex: 5s) pour la requete qui compte. Si ca revient dans les temps, on affiche le compte et le nombre de pages, sinon on affiche juste "précédent"/"suivant". Mais visiblement Oracle ne sait pas faire ca directement (avec une clause ou autre). Faut passer par mettre en place un user spécifique avec un profil spécifique qui a une limite de temps sur l'exécution de requetes. Ca implique aussi de créer un autre pool JDBC pour ce nouvel user. Pas sur que le client soit trop chaud. Et derrière faut qu'on demande aux devs de modifier le code (bon ca sera pas ultime), et qu'on reteste intensivement donc ca prendra du temps.

Voilà où j'en suis. Tous les avis/idées sont les bienvenus, spécialement pour la 3 si ya un moyen plus facile de le mettre en place.

Merci
A+

Edit: j'me rends compte que c'est pas trop SQL en fait, si ca gene je fais un topic dédié

Quand on commence a faire joujou avec des tables volumineuse on a plus trop le choix de ce qu'on peut faire.
Dans ton cas les requetes doivent toutes utiliser un index et etre les plus simple possible.
C'est donc surtout un probleme d'optimisation des query et du design des tables/indexes.
 
Si les indexes sont correct et bien utilisé par une query potable un count devrai etre pratiquement instantané.
Il faudrai aussi revoir l'utilité de faire tourner des queries qui retournent potentiellement des centaine de milliers voir millions de lignes. Jamais personne ne va tout utiliser.
Peut etre donner l'option aux utilisateurs d'avoir un count 'dynamic' qui est estimé en fonction des parametres utilisé dans la recherche (en gros tu simules les statistiques sur la table).
 
Quand une query destinée a etre affichée prends plus que quelques secondes la premiere chose a faire est de l'optimiser, aucune query destiné a de l'online ne devrai prendre plus que 2-3 secs (et encore, ca devrai prendre 0 sec), donc si ca prends 40 mins ya un tres tres gros soucil au niveau design de l'appli

La question que je me pose :
 
L'utilisateur patient a qui on répond : "894635 enregistrements trouvés, affichage page 1 sur 44732", il fait quoi ?

• Il se tape les 44732 pages pour trouver ce qu'il cherche ?
• Il se contente de 2 ou 3 premières pages ?
• Autre ?

Bref tout ça pour dire qu'il manque un critère quelque-part, mais bon, çà tu le sais déjà.
Je vois mal 1 milliard d'enregistrements de 166 champs sans un champs DATE qui permettrait de dire : "Je veux ceux d'aout 1996".
 
Après sans avoir une idée du contenu, des mises à jour et de la structure global, il est difficile de répondre.
 
Par exemple, peut-être qu'il y a moyen de créer une table (ou vue matérialisée) avec le contenu de la (les) grosse(s) requête(s) méchante(s), ou au moins des champs servant de critères, ce qui permet de faire un "count" plus rapide.
 
Limiter les requêtes sur leur durée d'exécution n'a qu'un seul avantage, éviter de tout planter.
Mais même si je ne sais pas comment faire, c'est un peut le même genre que le "max execution time" de php.
La requête qui s'arrête au bout de 20 secondes, c'est juste 20 secondes de perdu : Tu n'as aucun résultat à fournir à l'utilisateur.

Wesh ca fait des mois que je "galère" avec ces requetes et j'vous raconte pas comment ca fait plaisir c'que vous dites... J'suis 100% d'accord avec vous, mais juste que je peux rien y faire.
 
Complètement d'accord quant à l'utilité nulle de ramener autant de lignes au front-end. Le "truc" c'est que dans 99.5% des cas ca retourne que quelques lignes, ca prend effectivement 2 secondes, l'info est utile et tout le monde est content. Ya juste une "poignée" de cas (quelques centaines) ou ca part en couilles, et effectivement quand ca arrive, personne ira regarder plus loin que les deux premières pages - mais malheureusement ces quelques cas posent problème car causent de temps en temps des grosses dégradations quand les utilisateurs insistent un peu dessus (bon maintenant que c'est arrivé quelque fois, ils sont conscients du truc et ca arrive moins souvent).
Malheureusement (bis) le business ils sont un peu et ya déjà fallu se battre pour qu'ils acceptent de limiter à 1000 résultats. C'est du bon business pur souche: t'as les utilisateurs qui disent que des dizaines de pages ils s'en serviront jamais, que au pire 2/3 pages de résultats ca leur fait un échantillon utilisable, mais non le business il veut quand meme qu'on ramène tout, et évidemment il vient faire un caca nerveux quand l'appli rame à cause de ca. Ils ont pas non plus voulu qu'on mette les cas "à risque" sur une liste noire pour laquelle on désactive la requete.
 
Et donc en plus oui, le modèle de données il est plutot mal foutu (meme sans etre un cador dans ce domaine je m'en rends compte) mais c'est le produit "de base" qui est comme ca et je peux pas y faire grand-chose.
 
Niveau index/requetes j'ai fait ce que j'ai pu (et j'peux vous dire que j'ai amélioré le truc!) mais sans pouvoir changer les tables (et c'est pas envisageable) je pourrai probablement pas faire mieux. Donc j'en suis, comme Mara's dad dit, à essayer de limiter la casse - le pire étant que je m'en tamponne un peu, si le business est con tant pis pour lui, sauf que quand à chaque fois que l'appli tombe c'est pour ma gueule et ca me soule un peu.
 
Bref. En fait je suis en train de me dire que meme l'user Oracle utilisé par l'application devrait avoir une limite de temps, vu qu'il y a un timeout sur l'appli de toute facon, l'utilisateur Oracle devrait au moins avoir la meme limite pour éviter que des trucs tournent "à l'infini" dessus.

Perso, les cas du "on sais pas y faire grand chose" a cause d'une appli ou rien ne peut etre changé, je les remontes vers le business en leur expliquant simplement que le maximum est atteint au niveau technique et que dans l'etat actuel de l'application il n'est pas possible de réparer le probleme.
 
Je ne donne pas plus de détails ni d'explications. En general le business assume et se retourne sur le provider ou laisse pisser si c'est sans espoir. Dans le cas ou le business continue a se plaindre je leur rebalance la meme chose avec 1-2 preuves en plus et je leur remet le probleme sur le dos, si ca continue a raler je leur demande une solution (qu'ils n'auront pas).
 
Jusqu'ici ca a toujours fonctionné, je suis partisant de mettre le nez du business dans leur caca sans tourner autour du pot si c'est sans espoir, ca fait gagner du temps a tout le monde et ils se rendent compte qu'une seule query mal ecrite peut foutre tout un server par terre independement des skills technique de l'IT.

Question sur Oracle.
J'ai une requette d'insertion de cette forme :

Ca marche bien...

Sauf que j'ai mis des contraintes d'unicité sur certains champs.
Et donc si certaines lignes "existent" déjà, l'insert ne passe pas DU TOUT.

Comment lui dire d'insérer celles qu'il peut, et de pas faire chier ?

 
En faisant une jointure à gauche sur table1 dans ton select pour virer celles qui y sont déjà?

Ouais mais la table d'où viennent les données n'a même pas de clé primaire ; alors certes je pourrais faire ce que tu dis en testant tous les valeurs de chaque champs mais bon c'est chiant
 
Ya pas une solution simple pour flemmard, comme INSERT IGNORE ou INSERT IF NOT EXISTS, mais qui fonctionnerait sous Oracle ?  

Merge au lieu d'insert, peut-être?

(mais ça risque de pas simplifier des masses. )

euh ouais, merci ( ), mais effectivement ça rallonge encore + que de tester chaque champs

Sinon tu écris une procédure stockée, mais ça va réduire que l'écriture de l'appel.

Les valeurs que je veux insérer, je les obtiens déjà en faisait 4-5 jointures...
 
Donc s'il faut les refaire dans un premier temps pour tester que l'insertion est possible (que ce soit avec un merge ou un not exist...)
Ca fait une requete de barbare au final. Ou bien procédure stockée et je stock les valeurs dans des variables temporaires. Super propre...  
 
C'est quand meme incroyable qu'il y ait pas un mot clé prévu de base pour continuer.

 
Merge permet de faire bien plus compliqué que ce que tu cherches à faire, a priori. Ils n'ont probablement pas pensé qu'un mot clé spécifique à ce besoin était nécessaire...

Enfin bref, Oracle c'est comme Java ; pour faire un truc tout con il te faut 20 lignes.    
 

 
Comme quoi ils ont bien fait de racheter sun!

Je suis presque sûr d'avoir lu il y a de nombreux mois qu'il était possible en MySQL de copier une ligne X fois sans procédure stockée, en une seule commande SQL.
J'ai rêvé ?

Il manque un mot ?

Sinon via INSERT+SELECT ?

explique mieux le problème.

C'est pas qu'il manquait un mot mais qu'il y en avait un de trop
 
En gros je veux faire un INSERT+SELECT x fois uniquement en sql sans procédure stockée.
 
Je suis quasi sûr que c'est possible et la simplicité de la commande m'avait étonnée.
 

 
mais tu veux exactement la même ligne X fois?

 
Non je veux que l'id change.

Réussi avec UNION ALL. Genre une table avec pour champs : id, field1, field2, je duplique 5 fois la ligne qui a l'id 1  :

INSERT INTO my_table
SELECT NULL, field1, field2 FROM my_table WHERE id=1
UNION ALL
SELECT NULL, field1, field2 FROM my_table WHERE id=1
UNION ALL
SELECT NULL, field1, field2 FROM my_table WHERE id=1
UNION ALL
SELECT NULL, field1, field2 FROM my_table WHERE id=1
UNION ALL
SELECT NULL, field1, field2 FROM my_table WHERE id=1;

Et encore mieux en mettant la table 2 fois, et en utilisant un LIMIT :

INSERT INTO my_table
SELECT NULL, m1.field1, m1.field2 FROM my_table m1, my_table m2 WHERE m1.id=1 LIMIT 0,5;

Le dernier ne marche pas si y'a moins de 5 lignes dans la table

Ah mais fallait pas te casser la tête dessus
Et ce n'est pas ce que je cherchais, mais merci d'avoir essayé

Bon, des experts oracle qui trainent ici?

Mettons que j'ai une procédure qui ressemble à ça dans le schéma "toto" :

CREATE OR REPLACE PROCEDURE toto.maprocedure (param IN table_de_toto.champ%type
         Retour OUT varchar2) IS               
--le reste on s'en tape pour la discussion

On veut déplacer cette procédure dans le schéma du user "titi" (me demandez pas pourquoi. ).
C'est quoi la feinte qui permet à ça de compiler sans nous dire que "table_de_toto" doit être déclaré, sachant que titi voit très bien la table et que mettre "toto.table_de_toto" ne change rien?

Bon, s'il y en a qui ont un problème équivalent, c'est encore une connerie d'oracle : titi voyait les tables de toto via un rôle, hors pour accéder aux tables dans une procédure ou une fonction il faut un grant direct sur la table, les rôles ne sont pas pris en compte...

Sous SQLite, j'ai une table contenant une colonne ayant pour contrainte d'être unique.
Lorsque j'update une ligne de cette table avec le SET sur cette colonne unique, je me tape une erreur de violation de contrainte d'intégrité.
 
Dans le code c'est un peu bourrin mais mon SET set de nouveau toutes mes colonnes, même si celles-ci n'ont pas été modifiée.

Tu veux pas poster un peu de code SQL?

salut,
est ce qu'il y a un ouvrage/site (autre que dev.mysql.org) qui fait reference ? Je voudrais me perfectionner et faire 'du beau code' sous mysql, lire des exemples d'optimisation de requetes etc.
merci