Comme je l'ai déjà expliqué dans mon précédent topic, je dois insérer un grand nombre d'enregistrement dans une base de données Oracle via les ADO. Après moult tests, la méthode la plus rapide est d'appeller n fois une procedure stockée (qui fait un seul insert) dans un bloc d'execution BEGIN ... END . Le problème, c'est que le nombre d'instructions dans un bloc PL/SQL est limité et que je ne connais pas la méthode pour calculer cette limite.
 
Tout ce que j'ai trouvé c'est ça:

http://www.orafaq.com/faqplsql.htm#BLKSIZE
 
J'ai lancé la requete dans TOAD mais je ne sais pas quoi faire des données qu'il me renvoit, ça reste assez flou (de plus cette requête ne fonctionne que pour un user avec des droits d'administrateur).
 
Si quelqu'un peut m'aider, je crois que je vais craquer
 
Merci d'avance  

Sous Oracle 7, PL/SQL 2.0, la limite était de 64 Ko pour une procédure stockée ou un package. Mais attention :
- cette limite dépend du client. Ces 64 Ko sont valables pour un client Windows, pour Linux je sais pas
- cette limite de 64 Ko comprend le source + la représentation  de la compilation de ce source. Ce qui fait qu'un source de 10 Ko peut très bien dépasser cette limite

Merci  
Comment je fais pour calculer la taille de la représentation de la compilation de mon source ?
 
EDIT: t'aurais un lien à ce sujet ?
ça a évolué dans Oracle 8i ou 9i ?

Peu importe sa taille (c'est ce qu'ils appellent le "parse tree" dans ton article), la requête qu'ils te donnent te permet de calculer la taille totale du paquet, source + représentation comprise. Il te reste qu'à vérifier que ça ne dépasse pas 64 Ko

La requête me renvoit 3 valeurs: SOURCE_SIZE, PARSED_SIZE et CODE_SIZE C'est lequel qui ne doit pas dépasser 64Ko ?
 
 
P.S. tu pourrais répondre à mon précédent edit stp ?

à mon avis, ce lien devrait répondre à toutes tes questions
 
http://members.fortunecity.com/dpa [...] ons_8i.htm

Merci , je sais ce qu'il me reste à faire maintenant:
 

j'aimerais bien connaitre la limite de taille sous SQL Server tiens

Perso, je m'en fous un peu, je n'ai pas besoin d'avoir recours à de tels bricolages pour avoir des perfs décentes sous SQL Server.

c'est clair... au niveau perfs y'a pas photo entre Oracle et SQL Server

/me se demande vraiment comment il va faire ...

j'y arrives pas

t'aurais pas la même page pour Oracle 9i, j'ai l'impression que les limitations ne sont plus les mêmes
 
EDIT: D'après mes tests, la taille limite de mon bloc d'execution (qui lance n fois ma procedure stockée de test) semble aux alentours de 100Ko, ce qui me ferait penser que la taille maximale d'un programme est de 128Ko.

Bon, je m'en suis sorti en limitant la taille (le nombre de caractères en fait) de mon bloc BEGIN ... END; à 50Ko. J'espère que ça marchera sur les bases des clients

Hélas, je n'ai pas l'équivalent pour Oracle 9i, et je te parle même pas de 10g
Mais c'est pas impossible que la taille maximale ait augmenté, dans mon ex boite on avait reçu un commercial de chez Oracle, et on pestait justement contre la limitation des procédures à 64 Ko (on travaillait sur 7 et 8i), et à l'époque, il nous avait assuré, plaquettes à l'appui, que cette taille serait augmentée dans 9i, donc tous les espoirs  sont permis

Sinon je suppose qu'écrire un fichier texte et lancer un bon gros sql loader est complètement hors de propos...?

Vu que la plupart des clients ont 8i (ici on a 9i), je crois que je vais baisser ma limite de taille .
Au fait, c'est une limitation du client ou du Serveur ?

ben j'aurais toujours cette limite à la con

Euh j'en sais rien, ça dépend comment sqlloader fait ça, mais je suppose qu'il sait se démerder pour la contourner tout seul comme un grand!

Du client, en fait sur la 7 (et probablement sur 8i), ça vient du fait que Windows est incapable de gérer des blocs de plus de 64 Ko (explication made in Oracle à l'époque)

Ils ne savent vraiment pas quoi inventer pour avoir des excuses les commerciaux d'Oracle

Je vois pas pourquoi SQL loader contournerait cette limitation alors que les autres n'y arrivent pas
Ou alors il execute les instructions une par une ce que je ne veux pas car c'est trop lent.

http://www.orafaq.com/faqloadr.htm
 

Ca peut être sympa ça non?

Le truc de bourrin
 
Bon, je garde ça sous le coude au cas où

Ah ben toi qui voulais de la perf, ça devrait pas être trop mauvais ça...

+1

Heureusement que les petits jeunes sont là pour te montrer les choses avant que tu embauches, toi!

j'ai jamais utilisé SQL*Loader, au boulot on codait directement par SQL*NET

...et après on vient gueuler que ça marche pas...
 
 
 
 
 
 
 
Bon ok j'ai rien dit, j'ai découvert ça ya 2 semaines...:lol:

Le problème, c'est que si tu as une merde dans tes fichiers, tu bousilles ta base en moins de 2

ah ben oui...mieux vaut être sûr du contenu de tes fichiers, là...
 
Ici on utilise sql*loader pour charger un fichier dans un table temporaire, et ensuite on a un traitement qui teste la cohérence et insère dans la bonne table, et surtout nous sort les erreurs éventuelles.

Et malgré tout ce traitement, c'est quand même plus rapide qune insertion classique ?

Aucune idée, je peux pas bencher, j'ai pas le code de ce qui se passe après avoir lancé le sql*loader.
Mais comme je te disais j'insère sans trop de problèmes 20/30000 enregistrements d'un coup sans que cela pose de problème...

ça prend combien de temps ? c'est quoi comme serveur ?

Le tout (sql*loader + traitements qui suivent) prend à vue de nez (très difficile à contrôler dans le contexte dans lequel je l'utilise) 3 à 4 minutes, sur une base en prod avec des traitements assez lourds régulièrement lancés dessus...
Bref, je peux pas vraiment te filer de chiffres fiables, je contrôle trop peu de ce qui se passe.

et pour le serveur c'est une machine assez costaud...un HP DS25, si mes souvenirs sont bons.

OK, merci quand même
 
(tiens, j'ai aussi envie de cracher sur Transact-SQL maintenant )

t'aurais pas été emmerdé comme ça avec SQL Server

Je ne crache pas sur les SGBD sans raison, ce con de transact-SQL n'accepte pas qu'une fonction (un Convert par ex.) soit passée en paramètre d'une procedure stockée. Vachement pratique pour passer des dates à une procedure stockée