[Uukrul]

а не проходит where r_file is null ?

не пробовал... но тут похоже если так пройдет, то надо будет все запросы по этому полю по всей программе менять на r_file is null or r_file = 0, что уже не кошерно, так что проще таки новое поле принудительно присвоить в space или в ноль, если возможно и потом уже не париться.

[Uukrul]

как по мне так правильно выбирать .... хотя сам помню когда-то сидел пытался выбрать по условию что поле типа дата пустое ..... самое интересное, сюда не написал .... а теперь не помню ....
кажись писал WHERE docdate = '' ....

Не с датой там фишка другая, там точно известно что поле дата будет '00000000'.

[Паганель]

ну может быть, я же не знаю твоих условий .....

как по мне закладыватся на то что ты обновил, источник ошибок .... вдруг забудеш обновить и выборка пойдет ....

[Паганель]

Не с датой там фишка другая, там точно известно что поле дата будет '00000000'.

буду на работе поищу, там ксати у меня так не прошло ..... не помню точно

[Uukrul]

как по мне закладыватся на то что ты обновил, источник ошибок .... вдруг забудеш обновить и выборка пойдет ....

Условие я написал какое... а обновить, так это надо в любом случае первый раз сделать для всех записей которые существовали до внесения нового поля, для записей, который будут вставлены после добавления нового поля, уже корректно работает выборка на space или ноль. Так что тут именно грабли в том что поле не конвертировано. Возможно что IS NULL пройдет, но если у меня запросов уже три десятка по программе, то добавлять лишнее сравнение на то что пока обработаются все старые записи, да и вообще лишнее сравнение, которое через месяц точно уже будет лишним, короче апдейтик будет самое оно.

[Uukrul]

В общем из этого поста: http://sapforum.biz/index.php/topic,510.0.html

Есть выборка и есть обработка/модификация данных внутренней таблицы в LOOP AT / ENDLOOP. Само собой есть два варианта, через MODIFY и используя FIELD-SYMBOLS, в общем во втором случае производительность просто в разы больше, что видно из теста! Так что считайте, что это рекомендации лучших собаководов при обновлении внутренних таблиц данных.

Однако подтверждаю, и так провел небольшой тест, есть табличка MSEG, система тестовая записей  123 226, сделана программка следующего вида:

Код: [Выделить]

REPORT  yuuk_test_select.

DATA: lt_mseg LIKE mseg OCCURS 1 WITH HEADER LINE,
      runtime_1 TYPE i,
      runtime_2 TYPE i,
      time_diff TYPE i.

FIELD-SYMBOLS: <fs> LIKE LINE OF lt_mseg.

SELECT * INTO TABLE lt_mseg
FROM mseg.

GET RUN TIME FIELD runtime_1.
LOOP AT lt_mseg.
  lt_mseg-bwart = '000'.
  MODIFY lt_mseg.
ENDLOOP.
GET RUN TIME FIELD runtime_2.
time_diff = runtime_2 - runtime_1.
WRITE: / time_diff.

GET RUN TIME FIELD runtime_1.
LOOP AT lt_mseg ASSIGNING <fs>.
  <fs>-bwart = '000'.
ENDLOOP.
GET RUN TIME FIELD runtime_2.
time_diff = runtime_2 - runtime_1.
WRITE: / time_diff.
Результат на экране, комментарии я так думаю излишние, разница в производительности даже не на лице  в надцать раз практически, т.е.  192 580 миллисекунд против  12 172, кажется закрывают данный вопрос как нужно делать обновления внутренних таблиц.

[NachDenken]

Спасибо партии администрации за возвращения ника
есть вопрос скорее по оптимизации выполнения select
задачка выполнить 2-3 тяжелых селекта в паралельном фоновом режиме,
есть 2 (у меня) варианта
1) call function селект ...new task и потом их ловить в процедурке on end task
2) запустить  job_open submit селект

как лучше ?

селект к одной и тойже таблице в 2 разных фоновых заданиях будет быстрее чем 2 селекта последовательно ?

[Uukrul]

1) call function селект ...new task и потом их ловить в процедурке on end task
2) запустить  job_open submit селект

Я не тестировал оба варианта, делал по второму пункту.

селект к одной и тойже таблице в 2 разных фоновых заданиях будет быстрее чем 2 селекта последовательно ?

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

Тут есть правда такая вещь как кеширование, если данные обоих запросов очень близкие по теме, то... я бы замерил время выполнения обоих вариантов на твоих данных и тода уже принимал бы решение. (Как измерять время выполнения тут уже написано)

[Паганель]

Можно и мои 5 коп?

По поводу "LOOP AT + INTO" vs "LOOP AT + ASSIGNING", тут как раз занимаюсь оптимизацией одной гениальной програмульки, написанной неким месье Паганелем (дизайн и все ..... лапочка, только быстродействие).....Ннндда, .....

 вот пару замерчиков, выводы очевидны:
1. LOOP AT gt_alvtab INTO ls_alvtab.
2. LOOP AT gt_alvtab ASSIGNING <fs_alvtab>.

[NachDenken]

ого какая существенная разница в тормозах ,
для LOOP AT gt_alvtab ASSIGNING <fs_alvtab>.

[Паганель]

ого какая существенная разница в тормозах ,
для LOOP AT gt_alvtab ASSIGNING <fs_alvtab>.

Ссори, привел полные логи, но реально изменения касались только последней строки
calc_data 14.457.162 и calc_data 11.666.928

P.S. В пред. посте рисунки поменял :-)

[Паганель]

Еще пару заметок и мыслей-вопросов

1. Странно SAP выбирает какие индексы использовать, раньше я думал что порядок
полей в условии WHERE, как раз и определяет, какой индекс юзается, как оказалось -  не так.
На выбор индекса, как я понял, влияют только количество параметров в условии WHERE.

2. ! Как оказалось, если параметр (selopt) не заполнен, он все равно влияет на выбор индекса.
Т.е.:
Первый вариант:
  

Код: [Выделить]

WHERE
          matnr IN  so_matnr     AND
          werks IN  so_werks     AND
          sobkz = 'K'            AND          
          lifnr IN  so_lifnr     AND " даже если пустой so_lifnr, он все равно влияет на выбор индекса
У меня из-за него подтягивался какой-то "неправильный" :-) индекс.

Второй вариант:
 

Код: [Выделить]

WHERE
          matnr IN  so_matnr     AND
          werks IN  so_werks     AND
          sobkz = 'K'            AND          
          "!!!!! lifnr IN  so_lifnr     AND " закомментировал, теперь выбирается нужный индекс...
уфффф.... сссори, что сумбурно, радость переполняет ...

[Uukrul]

На выбор индекса, как я понял, влияют только количество параметров в условии WHERE.

Ну ты же сам написал... порядок полей в условии WHERE!!!, а какая разница есть справа значение для сравнения или нет?!

[Паганель]

Ну ты же сам написал... порядок полей в условии WHERE!!!, а какая разница есть справа значение для сравнения или нет?!

Ну вот, хотя если реально в данный момент времени, данные не передаются, оптимизатор должен бы отбросить несипользуемые  условия ....

[Uukrul]

Ну вот, хотя если реально в данный момент времени, данные не передаются, оптимизатор должен бы отбросить несипользуемые  условия ....

Ну я бы про отбросить так не говорил, так как я как раз иногда использую такую конструкцию чтобы выбирался нужный мне индекс при выборке, а вообще у тебя оракловая база? Прибей индекс гвоздями и буде тебе счастье...

[Паганель]

Ну я бы про отбросить так не говорил, так как я как раз иногда использую такую конструкцию чтобы выбирался нужный мне индекс при выборке, а вообще у тебя оракловая база? Прибей индекс гвоздями и буде тебе счастье...

да нет "ДИБИ Цвай" ....  :-), это как "гвоздями"?

[Uukrul]

да нет "ДИБИ Цвай" ....  :-), это как "гвоздями"?

Ну под DB2 не знаю надо документацию смотреть, опять же может Дмитрий знает, там типа хинт использования индекса можно указывать... но админы БД обычно это сильно не любят... т.е. мы жестко говорим какой индекс должна использовать система.

[Dmitriy]

уфффф.... сссори, что сумбурно, радость переполняет ...

По праву передавшего эстафетную палочку месье Паганелю.
2 Паганель: как-то внятно писать сразу нужно писать, задача, результат, выводы, стройность текста сообщения должна быть на уровне. А то как же месье Паганель, вы модератором тематики в скором времени будете: начинающий не поймет о чем это он, куда плыть?

P.S. Это так, оффтоп, просто контент должен быть четким.

[Dmitriy]

Ну под DB2 не знаю надо документацию смотреть, опять же может Дмитрий знает, там типа хинт использования индекса можно указывать... но админы БД обычно это сильно не любят... т.е. мы жестко говорим какой индекс должна использовать система.

Хинт иногда нужно указывать, однозначно.

[Паганель]

По праву передавшего эстафетную палочку месье Паганелю.
2 Паганель: как-то внятно писать сразу нужно писать, задача, результат, выводы, стройность текста сообщения должна быть на уровне. А то как же месье Паганель, вы модератором тематики в скором времени будете: начинающий не поймет о чем это он, куда плыть?

Все правильно Вы написали, мой уважаемый друг Дима, только не учли одного: природы человека по имени Паганель ......  который и получил сие прозвище еще в школе, за сию рассеянность и непоследовательность ...  ссори ... стараюсь.... буду исправляется ..

[Паганель]

Хинт иногда нужно указывать, однозначно.

Слышал, вроде бы видел, тока не помню как пишется ....  ;-)

[Паганель]

По праву передавшего эстафетную палочку месье Паганелю.
P.S. Это так, оффтоп, просто контент должен быть четким.

Поддежрживаю, "должен быть четким".

..... вы модератором тематики в скором времени будете:.....

Ну это бабка на двое сказала, как говортся "ры...м еще не дорос"

[Uukrul]

Хинт иногда нужно указывать, однозначно.

Синтаксис не подскажешь сразу, а то я что-то найти не могу..

[Паганель]

Синтаксис не подскажешь сразу, а то я что-то найти не могу..

ага, а то видел, кажись в mb5b... сижу, ищу ...  :-(

[Паганель]

Поддежрживаю, "должен быть четким".
Ну это бабка на двое сказала, как говортся "ры...м еще не дорос"

Еще раз поддерживаю, "дурак, это тот кого никто не понимает"