Ограничение на кол-во записей в ranges

Egal

Подскажите пожалуйста,

в SELECT используется конструкция, ну например

Code:

... WHERE belnr IN rng_belnr ...

, где rng_belnr объявлен как RANGES для BSEG-BELNR, размер этого rng_belnr[] ограничен по числу записей?

10х

Пономарев Артем: пожалуйста, создавайте темы с осмысленными названиями (п.п. 6.1).

Rokhay

Ограничен не размер Range, а общая длина sql запроса. Очевидно, что для каждого запроса максимальный размер range будет свой.
Если есть большой список со значениями, можно воспользоваться конструкцией FOR ALL ENTRIES IN.

ArmAnn

Rokhay написал:

Ограничен не размер Range, а общая длина sql запроса. Очевидно, что для каждого запроса максимальный размер range будет свой.
Если есть большой список со значениями, можно воспользоваться конструкцией FOR ALL ENTRIES IN.

С FOR ALL ENTRIES IN будет выполнено столько запросов, сколько записей во внутренней табличке, что не есть хорошо с точки зрения производительности.
Лучше прикинуть безопасный размер RANGE и выбирать данные порциями

Удав

ArmAnn написал:

С FOR ALL ENTRIES IN будет выполнено столько запросов, сколько записей во внутренней табличке, что не есть хорошо с точки зрения производительности.
Лучше прикинуть безопасный размер RANGE и выбирать данные порциями

Не совсем так. При FOR ALL ENTRIES IN запросов будет меньше, чем количество записей.
Другое дело, что интерфейс к БД объединяет записи по OR

Code:

SELECT                                                                        
  "MATNR" , "BWKEY" "WERKS" , "BWTAR" , "BWTTY" , "BKLAS"                     
FROM                                                                          
  "MBEW"                                                                      
WHERE                                                                         
  "MANDT" = :A0 AND "MATNR" = :A1 AND "BWKEY" = :A2 OR 
  "MANDT" = :A3 AND "MATNR" = :A4 AND "BWKEY" = :A5 OR 
  "MANDT" = :A6 AND "MATNR" = :A7 AND "BWKEY" = :A8 OR
  "MANDT" = :A9 AND "MATNR" = :A10 AND "BWKEY" = :A11 OR     
  "MANDT" = :A12 AND "MATNR" = :A13 AND "BWKEY" = :A14 OR 
  "MANDT" = :A15 AND "MATNR" = :A16 AND "BWKEY" = :A17 OR
  "MANDT" = :A18 AND "MATNR" = :A19 AND "BWKEY" = :A20 OR 
  "MANDT" = :A21 AND "MATNR" = :A22 AND "BWKEY" = :A23 OR   
  "MANDT" = :A24 AND "MATNR" = :A25 AND "BWKEY" = :A26 OR 
  "MANDT" = :A27 AND "MATNR" = :A28 AND "BWKEY" = :A29 OR
  "MANDT" = :A30 AND "MATNR" = :A31 AND "BWKEY" = :A32 OR 
  "MANDT" = :A33 AND "MATNR" = :A34 AND "BWKEY" = :A35 OR   
  "MANDT" = :A36 AND "MATNR" = :A37 AND "BWKEY" = :A38 OR 
  "MANDT" = :A39 AND "MATNR" = :A40 AND "BWKEY" = :A41 OR 
  "MANDT" = :A42 AND "MATNR" = :A43 AND "BWKEY" = :A44                                                              

А по поводу быстродействия FOR ALL ENTRIES - лучше применять его, если ключом для выборки является первичный ключ таблицы (ну или поля, входящие в индексы)

Пономарев Артем

Ну и отбрасывание дубликатов на стороне application server'а тоже сбрасывать со счетов не стоит, в случае с FOR ALL ENTRIES.

Впрочем я бы скорее подумал над изменением логики программы. Т.к. сам по себе код

Code:

WHERE belnr IN rng_belnr

лично у меня вызывает вопросы.

Удав

Пономарев Артем написал:

Т.к. сам по себе код

Code:

WHERE belnr IN rng_belnr

лично у меня вызывает вопросы.

См. транзакцию FB03, там есть критерий выбора "Номер документа"

Пономарев Артем

Имел в виду не само по себе, а в контексте боязни упереться в ограничение по записям. Тут явно что-то нечисто.

Egal

Rokhay написал:

Ограничен не размер Range, а общая длина sql запроса. Очевидно, что для каждого запроса максимальный размер range будет свой.

Мысль интересная... чет я не подумал об этом, сейчас я это проверю. А разве это не string? Он, поидее, условно ничем не ограничен.

Egal

Пономарев Артем написал:

Впрочем я бы скорее подумал над изменением логики программы. Т.к. сам по себе код

Code:

WHERE belnr IN rng_belnr

лично у меня вызывает вопросы.

какие?

PS: это естественно не весь код, тоесть WHERE работает не только по BELNR. Это просто для примера, показать о чем идет речь.

ArmAnn

Удав написал(а):

ArmAnn написал:

С FOR ALL ENTRIES IN будет выполнено столько запросов, сколько записей во внутренней табличке, что не есть хорошо с точки зрения производительности.
Лучше прикинуть безопасный размер RANGE и выбирать данные порциями

Не совсем так. При FOR ALL ENTRIES IN запросов будет меньше, чем количество записей.
Другое дело, что интерфейс к БД объединяет записи по OR

упс... был не прав, понял сап хелп по своему

спасибо

Stenj_90

1. В FOR ALL ENTRIES IN кол-во выполняемых за один блок селектов можно регулировать через %_HINTS ORACLE '&max_blocking_factor nn&', где nn - целое число. Как и всякое нестандартное решение, этот хинт может принести ощутимое ускорение, но может привести к неработоспособности программы

Так что все на совести программиста.
2. Отбрасывание дубликатов борется путем указания после select всех ключевых полей или '*', а для получения необходимых 'into corresponding fields'.

Egal

Всё, сенька ю вери мух. Штото я протупил поповоду длинны строки запроса - проблема была именно в этом.

Пономарев Артем

Stenj_90, rsdb/max_blocking_factor - это не хинт. Оракл не в курсе

Это настройка связи САП - СУБД. Есть еще rsdb/prefer_in_itab_opt, тогда запрос будет выглядеть как WHERE ... IN ( ... , ... , ... ).
Так что пример Удава - не всегда верен. Кроме OR'ов и IN может быть еще и UNION ALL.

Egal, не так давно уже было обсуждение рэйнджей. Там же и точный макс. размер запроса выкладывали в КБ. Можете поискать.

Удав

Пономарев Артем написал:

Есть еще rsdb/prefer_in_itab_opt, тогда запрос будет выглядеть как WHERE ... IN ( ... , ... , ... ).
Так что пример Удава - не всегда верен. Кроме OR'ов и IN может быть еще и UNION ALL.

Ну скажем при выборке по нескольким полям внутренней таблицы (как в моем примере) IN не будет :wink:

За исключением случая, когда в одном из полей мало уникальных значений, да и то это зависит от конкретной СУБД и настройки интерфейса с БД

Пономарев Артем

Так и я о том. Уточнил просто, что FOR ALL ENTRIES - это не только OR. Возможны варианты

Сам предпочитаю JOIN. По логике вещей должно быть быстрее, чем сабж.

Правила форума

Ограничение на кол-во записей в ranges

Кто сейчас на конференции