Как такое может быть?! Быстродействие.

Parazit

111 написал(а):

Parazit написал:

111 написал(а):

На самом деле, мне в принципе было интересны причины такого странного поведения.

Ничего странного, всё очевидно. Четко оптимизируюется только условия "=" объединенные "AND". Соответственно, исходя из этого, нужно строить индексы, помещая поля, выбираемые по "=", вверх ключа.

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

Это зависит от оптимизатора СУБД. Например, в Foxpro, могло быть и незаметно больших проблем. А в Sybase, Informix и Oracle - регулярно!

dump

vga написал(а):

В данном эхплайн плане видно, что подцепился не тот индекс. То есть база, использую неверный индекс не имеет информации о сортировке, чтобы выполнить твой group by и поэтому вынуждена сначала создать промежуточную таблицу, отсортировать ее , а потом только по ней обработать запрос.

Короче, если CLIENT SPECIFIED не поможет, используй %_HINTS c явным указанием индекса.

А кстати в Oracle то можно указать индекс в хинте - а вот в DB6 (DB2 )
я не нашел - там только через OPTLEVEL можно как-то влиять на план выполнения или у кого-то есть другая информация ?

111

Parazit написал:

111 написал(а):

Так вот, селектом выбираются... несуществующие записи.
Т.е. ставим точку прерывания сразу за SELECT... , ищем запись с таким ключом в SE16 и... не находим :shock:

.

Select и SE16 - далеко не одно и то же. Ключи, введенные на экране SE16 сначала преобразуются. Могут быть удалены лидирующие нули, или наоборот, добавлены. Или из внешнего представления переведены во внутренее.

Я в курсе

.
От себя добавлю еще одно отличие - SE16 всегда читает, минуя буфер.
Поэтому в случае сбоев, с буферизованными таблицами бывает такой глюк: в SE16 запись есть, а селект в программе его не находит. Лечится с помощью /$SYNC .

Parazit написал:

Modify отличается от Update тем, что Modify добавит запись, если она не существует, а Update может модифицировать только существующие.

Я в курсе

.
Фишка в том, что Modify не отрабатывал вообще совсем никак. Ни добавлял запись, ни модифицировал имеющуюся.
Но выдавал при этом SY-SUBRC = 0 .

dump

111 написал(а):

Parazit написал:

Modify отличается от Update тем, что Modify добавит запись, если она не существует, а Update может модифицировать только существующие.

Я в курсе

.
Фишка в том, что Modify не отрабатывал вообще совсем никак. Ни добавлял запись, ни модифицировал имеющуюся.
Но выдавал при этом SY-SUBRC = 0 .

так если SY-SUBRC = 0 так может COMMIT WORK надо было сделать

- да и вообще MODIFY внутри SELECT - ENDSELECT не очень хорошо
- лучше собрать внутр. таблицу да MODIFY FROM TABLE

vga

dump написал(а):

А кстати в Oracle то можно указать индекс в хинте - а вот в DB6 (DB2 )
я не нашел - там только через OPTLEVEL можно как-то влиять на план выполнения или у кого-то есть другая информация ?

Посмотри ноты
162034
150037

Правильная статейка про хинты http://www.sapbasis.ru/articles/opensqlhints/

111

dump написал(а):

111 написал(а):

Parazit написал:

Modify отличается от Update тем, что Modify добавит запись, если она не существует, а Update может модифицировать только существующие.

Я в курсе

.
Фишка в том, что Modify не отрабатывал вообще совсем никак. Ни добавлял запись, ни модифицировал имеющуюся.
Но выдавал при этом SY-SUBRC = 0 .

так если SY-SUBRC = 0 так может COMMIT WORK надо было сделать

- да и вообще MODIFY внутри SELECT - ENDSELECT не очень хорошо
- лучше собрать внутр. таблицу да MODIFY FROM TABLE

Порядка 60 млн записей => бухнется в дамп из-за нехватки памяти. Поэтому приходится делать именно так.
А COMMIT WORK работает только для LUW, для прямых апдейтов - никакого влияния не оказывает.

John Doe

111 написал(а):

dump написал(а):

так если SY-SUBRC = 0 так может COMMIT WORK надо было сделать

- да и вообще MODIFY внутри SELECT - ENDSELECT не очень хорошо
- лучше собрать внутр. таблицу да MODIFY FROM TABLE

Порядка 60 млн записей => бухнется в дамп из-за нехватки памяти. Поэтому приходится делать именно так.
А COMMIT WORK работает только для LUW, для прямых апдейтов - никакого влияния не оказывает.

Может все таки <я не знать русский языка> как dump предлагал, из таблички БД модифицировать, только побить предварительно на куски по 0,5-1 млн.записей или мельче?

dump

111 написал(а):

dump написал(а):

111 написал(а):

Parazit написал:

Modify отличается от Update тем, что Modify добавит запись, если она не существует, а Update может модифицировать только существующие.

Я в курсе

.
Фишка в том, что Modify не отрабатывал вообще совсем никак. Ни добавлял запись, ни модифицировал имеющуюся.
Но выдавал при этом SY-SUBRC = 0 .

так если SY-SUBRC = 0 так может COMMIT WORK надо было сделать

- да и вообще MODIFY внутри SELECT - ENDSELECT не очень хорошо
- лучше собрать внутр. таблицу да MODIFY FROM TABLE

Порядка 60 млн записей => бухнется в дамп из-за нехватки памяти. Поэтому приходится делать именно так.
А COMMIT WORK работает только для LUW, для прямых апдейтов - никакого влияния не оказывает.

если 60 млн. то все равно надо бить на пачки по 30тыс ( по-моему - могу ошибаться ) есть у сапа рекомендации ) - а по поводу
commit не согласен - из документации по COMMIT WORK

COMMIT WORK also

Calls the subroutines specified by PERFORM ... ON COMMIT
......
Executes a database commit on all database connections
......
а у вас LUW начался или по началу транзакции или если до выполнения вашего оператора был commit или rollback

111

dump написал(а):

а по поводу
commit не согласен - из документации по COMMIT WORK

COMMIT WORK also

Calls the subroutines specified by PERFORM ... ON COMMIT
......
Executes a database commit on all database connections
......
а у вас LUW начался или по началу транзакции или если до выполнения вашего оператора был commit или rollback

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

.
Ни COMMIT WORK, ни ROLLBACK WORK никакого влияния на прямые апдейты не производят. Данные сразу спускаются в БД.

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

vga

не спорьте ;-)

Code:

DATA: l_count TYPE I.
TABLES vbdata.
DATA: it_table TYPE TABLE of bkpf WITH HEADER LINE.
SELECT * FROM BKPF INTO TABLE it_table UP TO 1 ROWS .

SELECT SINGLE COUNT(*) FROM vbdata INTO l_count.
WRITE: / 'Before update',  l_count.

MODIFY BKPF FROM TABLE it_table.

SELECT SINGLE COUNT(*) FROM vbdata INTO l_count.
WRITE: / 'After update before commit',  l_count.

COMMIT WORK.

SELECT SINGLE COUNT(*) FROM vbdata INTO l_count.
WRITE: / 'After update after commit',  l_count.

результат

Цитата:

Before update 8
After update before commit 8
After update after commit 8

Но

Code:

Adding or changing lines with the MODIFY command is only completed after a database commit (see LUW) has been performed. Before the database commit has been performed, any database changes can be reversed with a database rollback (see Programming transactions). 

Database commit and rollback 
Within an LUW, database changes are not made until after a database commit. Prior to this, any database change can be canceled by a database rollback. 

In the R/3 System, a database commit is triggered either automatically or by the ABAP/4 command COMMIT WORK or the appropriate Native SQL command for the database system. 
Similarly, a database rollback is triggered either automatically or by the ABAP/4 command ROLLBACK WORK or the appropriate Native SQL command for the database system. 

dump

vga написал(а):

не спорьте ;-)

Code:

DATA: l_count TYPE I.
TABLES vbdata.
DATA: it_table TYPE TABLE of bkpf WITH HEADER LINE.
SELECT * FROM BKPF INTO TABLE it_table UP TO 1 ROWS .

SELECT SINGLE COUNT(*) FROM vbdata INTO l_count.
WRITE: / 'Before update',  l_count.

MODIFY BKPF FROM it_table.

SELECT SINGLE COUNT(*) FROM vbdata INTO l_count.
WRITE: / 'After update before commit',  l_count.

COMMIT WORK.

SELECT SINGLE COUNT(*) FROM vbdata INTO l_count.
WRITE: / 'After update after commit',  l_count.

результат

Цитата:

Before update 8
After update before commit 8
After update after commit 8

Они то сразу записываются но не в БД а в журнал обновления данных и select их вытаскивает

- но по COMMIT - они записываются именно в БД без возможности отмены - то есть если вместо commit поставить rollback - то мы снова увидим предыдущее значение

vga

Ну короче не то написал. :lol:

vbdata - Таблица запросов, которые должны быть выполнеты в update task. Состояние Rollback segment наверно только через native sql можно прочитать.

dump

vga написал(а):

dump написал(а):

А кстати в Oracle то можно указать индекс в хинте - а вот в DB6 (DB2 )
я не нашел - там только через OPTLEVEL можно как-то влиять на план выполнения или у кого-то есть другая информация ?

Посмотри ноты
162034
150037

Правильная статейка про хинты http://www.sapbasis.ru/articles/opensqlhints/

меня эта статья и натолкнула на вопрос - я в ней и ноте 150037 не нашел четкого указания индекса в хинте для DB6

vga

dump написал(а):

меня эта статья и натолкнула на вопрос - я в ней и ноте 150037 не нашел четкого указания индекса в хинте для DB6

Code:

* begin of note 977867
          %_HINTS ORACLE 'INDEX("&TABLE&" "COSS~9")'
                  DB6 '<IXSCAN TABLE=''COSS'' SAP_INDEX=''9'' />'.
* end of note 977867

dump

vga написал(а):

dump написал(а):

меня эта статья и натолкнула на вопрос - я в ней и ноте 150037 не нашел четкого указания индекса в хинте для DB6

Code:

* begin of note 977867
          %_HINTS ORACLE 'INDEX("&TABLE&" "COSS~9")'
                  DB6 '<IXSCAN TABLE=''COSS'' SAP_INDEX=''9'' />'.
* end of note 977867

спасибо - то что надо

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

Как такое может быть?! Быстродействие.

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