Blog éclectique & sans sujet précis - Par paquets de 5 - Commentaires<p>Si ça me passe par la tête, si ça n’intéresse que moi, alors c’est peut-être ici. Ou pas.</p>2024-02-13T09:44:49+01:00L'éditeur est le propriétaire du domaineurn:md5:bf83720a7189bba489682d945b972671DotclearPar paquets de 5 - taryckurn:md5:d5730f0886462d54619b59264f31dbc82011-11-16T15:51:53+01:002011-11-16T15:51:53+01:00taryck<p>Le paramètre par défaut de 5 est dans le paramètre base de donnée : rsdb/max_in_blocking_factor & rsdb/max_blocking_factor<br />
modifiable via RZ11, voir note SAP 881083.<br />
On peut ainsi faire monter pour tout les FOR ALL ENTRIES la taille des paquets de 5 à xx. Chez nous 50.<br />
Pour certaines requettes (celle ou on a la clé primaire par exemple) on peux juger que 50 serait alors trop faible, mais que pour ces requêtes là. On utilise alors le %_HINTS ORACLE avec ;<br />
- '&max_blocking_factor 20&'<br />
- ou '&max_in_blocking_factor 20&'<br />
SAP ne peut être plus puissant que la base de donnée qu'il utilise pour des extractions seules.<br />
Donc dans ton cas :</p>
<pre> SELECT * FROM vbap
FOR ALL ENTRIES IN tab_articles
WHERE vbap~matnr = tab_articles-matnr
%_HINTS ORACLE '&max_in_blocking_factor 500&'</pre>
<p>devrait avoir l'efficacité souhaitée.</p>Par paquets de 5 - Le webmestreurn:md5:04cbb750a85d5b27017b33e5888837fd2009-03-12T21:46:03+01:002009-03-12T21:46:03+01:00Le webmestre<p>@taryck : Oui, en gros c’est le problème : le SQL généré par l’ABAP est « basique » et ne tient pas compte de la puissance de la base sous-jacente et la sous-utilise…</p>Par paquets de 5 - taryckurn:md5:e94646a39c8623655cbb41cb66a15c592009-03-12T18:04:26+01:002009-03-12T18:04:26+01:00taryck<p>Je pense que le point qui a été “zappé” est simplement que le code SQL en ABAP est de l’OPEN SQL transcrit en SQL-Natif Oracle, mais pas seulement. Il est donc possible que certaines limites présentes sur les autres BdD supportées par SAP amène à cette limite constatée de 5 clés.<br />
Même si je n’ai aucune idée de la raison…</p>Par paquets de 5 - Le webmestreurn:md5:a72d893d426c79f15a6ed7642adac2722007-09-14T07:39:34+00:002007-09-14T07:39:34+00:00Le webmestre<p>@ECIR : Le SELECT...ENDSELECT, c'est ce que j'utilisais justement... Quant aux jointures, évidemment, comme en SQL il vaut mieux tenter de tout faire en une seule requête. Par contre c'est loin d'être toujours possible, et l'ABAP n'a pas la souplesse du SQL quand il s'agit de faire des « requêtes de feu » (écrire à la main des requêtes SQL de 2 pages avec 5 niveaux de sous-select ne me fait pas peur, donc je suis assez exigeant sur le sujet, mais quand même).</p>Par paquets de 5 - ECIRurn:md5:7ee7bdd172496ab4a1f2db1145a3ce6f2007-09-13T22:03:40+00:002007-09-13T22:03:40+00:00ECIR<p>Bonsoir,<br />
<br />
remarque pertinent du webmestre: le FOR ALL ENTRIES découpe les requêtes par plage de 5 valeur contenues dans la table interne. si la table interne contient 2000 enregistrements, il y a aura donc 400 requêtes SQL exécutées.<br />
<br />
Il y a plusieurs solutions possibles:<br />
- utiliser le select ... endselect, tel que c'est recommandé dans la transaction SE30<br />
- utiliser les possibilités de jointures, de sous-requêtes<br />
<br />
(:))</p>Par paquets de 5 - Le webmestreurn:md5:ec2b362544799e13bd2dd6b69334c9852007-07-22T19:42:49+00:002007-07-22T19:43:18+00:00Le webmestre<p><b>@bob</b> : Et non, il fait 5 fois moins d'accès en base que de WRITE (de lignes ramenées), mais c'est encore beaucoup trop, et c'est bien ce que je lui reproche. <br>Au lieu d’une requête dont chaque ligne est utilisée (bête curseur), il crée une requête <i>différente</i> pour cinq lignes de paramètres !<br>Qu’une table interne permette de contourner/éviter le problème, pourquoi pas (et ce serait après tout la moindre des choses), mais ce n’est pas forcément possible ou souhaitable, et de mon point de vue cela en rajoute encore dans la lourdeur de programmation (alors que le SELECT...ENDSELECT a le bon goût d’exister).Par paquets de 5 - boburn:md5:ae3254c341b086b01de66f2b72638c732007-07-19T15:17:13+00:002007-07-19T15:17:13+00:00bob<p>le prob, c'est que tu fais autant d'accès en base que de write ...<br />
<br />
essaye plutôt ça avant de critiquer un langage que tu ne connais pas !<br />
DATA : matable TYPE TABLE OF vbap WITH HEADER LINE.<br />
<br />
SELECT * FROM vbap<br />
INTO TABLE matable<br />
FOR ALL ENTRIES IN tab_articles<br />
WHERE vbap~matnr = tab_articles-matnr.<br />
<br />
LOOP AT matable.<br />
WRITE :/ matable-matnr, matable-vbeln, matable-posnr .<br />
ENDLOOP.</p>Par paquets de 5 - Le webmestreurn:md5:71f6d6cc5da6a5bc3aac0e897194c67f2006-11-17T09:41:35+00:002006-11-17T09:42:16+00:00Le webmestre<p><i>Balise</i>>Effectivement, mon entretien annuel, ça a donné à peu près ça :o) <br>Et j’en ai tiré les conséquences puisque je pars et du client et de ma SSII trop spécialisée sur SAP dans la région.</p>Par paquets de 5 - Baliseurn:md5:6f8ee6678b545d70311218c1ed2f1f072006-11-16T22:35:48+00:002006-11-16T22:35:48+00:00Balise<p>J'aime. Et après, en entretien : « Y a-t-il des choses que vous ne souhaitez pas faire ? - Du SAP. - Ah, pouquoi ça ? ».</p>