Т.е. ваш слив защитан? Привести цитату из хелпа вы не можете. Все остальное - ваши измышления?

1) Кажется вы не понимаете суть алгоритма LRU. Объясню. Если вы делаете пример на mseg, а потом делаете его же полное перечитывание что бы забить кэш, то на выходе есть не нулевая вероятность, что в кэше остануться те же данные, на которых вы тестируете. И это будет вне зависимости от размера кэша БД. Как-то так.
2) Да. именно. Не бывает сферических коней в вакууме. Задача вполне утилитарна. И совет в данном случае не покрывает всего поля возможностей
3) Как я вижу хелп и курсы вы не примаете как аргумент. Адекватного аргумента не приводите, кроме голословных утверждений "я знаю" и рекламы вашего опуса. Я, например потрудился и прочел хотя бы часть вашего труда на форуме и высказал вполне обоснованные сомнения в его адекватности. Опровергнуть вы их не можете. Как говорили математики: ЧТД.

1. Замечательно что вы ее знаете, т.е. вы предполагаете что кеша хватит на полную заливку таблицы MSEG в память, путем удаления вообще всего ранее считанного? Не ну думайте так дальше.
 
2. Ну это вы решили тут совместить написанное в двух разных местах. А в описании есть отдельно процесс массового обновления объектов и процесс определения наличия объекта в БД, в данном случае через блокировку.
 
3. Для меня конечно мало, мне как вы говорите зарплату не платят чтобы разжевывать вам перевод справки системы, который вы не очень понимаете. Так что дальше будьте уверены что синхронного апдейта и включенного локального обновления вам будет достаточно для появления объекта в БД.

Зачем вам цитаты из хелпа? Вы их уже привели, но вы их не очень понимаете судя по всему. Толкование расписано в книге, ну вам то она не нужна, а переписывать сюда то что там уже написано, как то не вижу смысла.
 
PS: Да и это не толкование, это фактическая проверка того как это работает. Тоже в свое время свято верил что синхронный апдейт гарантирует появления объекта на уровне БД. Пока не понял как же это по факту работает. Будет время можете проверить, программка пишется быстро, а вот результат вас я думаю немного озадачит. Можете там покомбинировать синхронный/асинхронные апдейты, локальное обновление и т.д.

Кстати, пожалуйста, изложите ваше толкование того, что изложено в хелпе. Только пожалуйста, каждую вашу сентенцию снабдите ссылкой на цитату из хелпа. Пока что, вы только голословно утверждаете, что мое понимании не верно, не смотря на приложенную однозначно трактуемую цитату из документации. Как мне кажется, документация в этом случае все определяет  однозначно. Развейте-таки мои сомнения!

1) Методику кеширования например оракла я знаю, это LRU алгоритм. Вам знакомо такое понятие? Т.е.'least recently used'. Т.е. вытеснение менее нужных данных при заполнении кэша, см. например docs.oracle.com/cd/B28359_01
И не надо приплетать хану. Есть некий объем кэша. Читаем больше чем есть в нем места? происходит вытеснение  реже читаемых данных из кэша.
2) Какие? да например те же самые, что вы описывает, когда пытаетесь через чтение блокировок поймать ранее созданный документ\запись справочника и т.д.
3) Ну если для вас мало синхронного апдейта, несмотря на вполне исчерпывающее описание (зря не потрудились прочитать, там сказано, что вольется именно в базу, если не используете апдейт таск модули, а есть и такие BAPI), то есть еще и LOCAL UPDATE. Вот в них уже даже апдейт таски выполняются в том же процессе. Или вы опять буде спорить с хелпом сапа?

1. Ну это у вас какие-то упрощенные представления о методике кеширования записей на уровне СУБД. Не хана же, все в память затаскивать. Да и еще раз, тестирование проводилось на разных системах с разной загрузкой и это усредненные числа. Можете предложить свои варианты расчета производительности, хотя конечно вам за это ж не заплатят, поэтому вряд ли.
 
2. Да какие там нафиг бизнес процессы то? Есть объект, надо обновить данные, есть BAPI, нет BAPI смотрим что есть и выполняем задачу. Зачем же усложнять и так сложное.
 
3. Ну вот я и говорю, что прочитать вы прочитали, да только не поняли что. Вот и думаете, что синхронный апдейт вам обещает обновление на уровне БД, хотя там такого нет, но вы то прочитали и поняли так как поняли.

1. Ну это у вас какие-то упрощенные представления о методике кеширования записей на уровне СУБД. Не хана же, все в память затаскивать. Да и еще раз, тестирование проводилось на разных системах с разной загрузкой и это усредненные числа. Можете предложить свои варианты расчета производительности, хотя конечно вам за это ж не заплатят, поэтому вряд ли.
 
2. Да какие там нафиг бизнес процессы то? Есть объект, надо обновить данные, есть BAPI, нет BAPI смотрим что есть и выполняем задачу. Зачем же усложнять и так сложное.
 
3. Ну вот я и говорю, что прочитать вы прочитали, да только не поняли что. Вот и думаете, что синхронный апдейт вам обещает обновление на уровне БД, хотя там такого нет, но вы то прочитали и поняли так как поняли.

По пордяку:
1) про чтение той же таблицы всей целиком. Эта операция сделает вам в кэше как раз данные из той же таблы, что не вариант для очистки кэша.
 
2) про массовые операции: даже массовые операции зависят от бизнес процесса. Поэтому первое пожелание во всех подобных действах: определитесь, что вы хотите делать с точки зрения бизнеса.
3) По поводу синхронного апдейта, с вами не согласен хелп сапа, цитата
In synchronous update, you do not submit update requests using CALL FUNCTION … IN UPDATE TASK . Instead you use the ABAP statement COMMIT WORK AND WAIT. When the update is finished, control passes back to the program.
Пруф: help.sap.com/saphelp_nw70/helpdata

Вы уж простите, я книгу Точенюка не читал. Но я читал его заметки по производительности с сайта sapforum.biz. Могу сказать, что там были моменты, которые, на мой взгляд, являются скорее уж вредными советами. Т.е. модель "дешево и сердито" конечно хороша, но не стоит забывать про "кроилово ведет к попадалову".
Изданная книга это конечно хорошо, но был ли у нее тех.редактор? На примере статей этого ресурса по ABAP, можно сказать, что они не подвергаются рецензированию и редактуре (да какая редактура, если даже орфографические и синтаксические ошибки в статьях не вычищены?)

1) В файле с советами везде проводится замер производительности на примере таблиц MKPF\MSEG.
 
Ну на самом деле замеры проводились не на одной системе, на разных конфигурациях, короче где был доступ там и гонял программки. Технически после запросов делался  SELECT * FROM <таблица>, типа а прочитайка всю таблицу снова. Вообще-то в документе и книжке представлялись результаты, а не методики измерений. Так что это, как мне кажется, замечание по тому чего в документе нет :-)
 
2. В книге про "FOR ALL ENTRIES" формулировка почти такая же, с парой тестовых примеров при пустой таблицы в условии. Возможно ваше замечание и упрощает формулировку, но кроме вас никто не написал об этом.
 
3. Ну что в JOIN не используется буферизация по тексту есть отдельное замечание в разделе работы с буферизированными таблицами. Вообще-то буферизацию можно отключать/включать, хотя конечно проблемы при таких операциях могут быть уже вашими, о чем SAP собственного говоря и предупреждает.
 
4. Ну почему же, вот вы считаете что общего рецепта нет, я считают что он есть. Замечание касалось массовой заливки/обновления данных в системе. Переполнить транзакшин лог? Но, как раз данное замечание и касалось того, что нужно выполнять периодические промежуточные фиксации результатов работы. Делать это после каждого обработанного объекта, страдает производительность, делать это в конце обработки всех объектов, тоже страдает производительность + технические проблемы журнала транзакции. Поэтому там ровно сказано то, что периодически фиксируйте ваши изменения. Рецепт фиксации мой, чисто опытный. Если правильно помню, то там же сказано, что в каждом случае нужно смотреть на что обновляется и как.
 
5. Ну вот этот пункт это не у меня "шикарно", это у вас "шикарно", я бы данное замечание приводил как яркую иллюстрация к фразе зачем нужны книги русском и пользе чтения английских текстов. Вы вот сослались на справку, она по абапу на английском, вот только проблема в том, что вы прочитав, подумали что поняли все правильно. По факту же, вы абсолютно не поняли разницы между синхронными и асинхронным коммитом (в книге на русском я таки это описал более развернуто чем в документе с форума). Данный вывод я делаю по вашей фразе "программа будет гарантировано ждать, когда же объекты доедут в БД". Так вот синхронный коммит не будет ждать, пока объекты куда-то доедут, он просто подождет выполнения модулей/подпрограмм обновления и ВСЕ! Последующее чтение после выполнения синхронного коммита периодические будет выдавать сообщение об отсутствии записи в базе данных. Вариантов обхода этой ситуации много, я поделился тем, который для себя определил как самый быстрый при массовой вставке объектов в БД, при условии, что последующий объект ссылается на предыдущий.
 

И в завершении "почему не буду вести здсь блог\колонку: мне за это не платят зарплату" - Ну это вам к Дублину, он на такие темы любит объяснить кто и где заблуждается :-)

Упс, неожиданно интересная статья на вроде бы банальную тему.
Отвечаю на вопрос Как Вы используете календари? применительно к Финансам и к России.
 
Есть у нас в FI, MM и SD к такая замечательная функциональность как управление сроками оплаты. Базируется в основном на полях Базовая дата и Условие платежа. Хотя, если покопаться, можно найти и поле для собственно плановой даты оплаты.
Есть у нас в России (полагаю, в других странах бывшего СССР тоже) такая бизнес-традиция как отчет отсрочки оплаты от некоей опорной (включение счетчика) не в календарных днях, а в т.н. банковских. Что характерно, нигде в законодательстве термин "банковский день" не описан, а в договорах термин применяется повсеместно и без подробного описания.
Есть у нас в России такая плохая традиция, как наплевательское отношение консультантов к этой полезной функциональности - Условия платежа и определение базовой даты. Или, как сказали бы тренеры по лицемерию (коучи по эффективности персональных коммуникаций), потенциал для улучшения практики применения этого дела.
 

Практика использования календаря именно в РФ и именно для управления сроками оплаты.
1. На одном проекте пришлось собрать целый методологический совет, чтобы определить, что банковский день = рабочий.
2. Так как клиент работал в основном на территории Республики Татарстан, но имел бизнес еще и в Москве и в Самаре, пришлось вести два календаря: один федеральный, другой республиканский.
3. Был разработан экзит по пересчету банковских дней в календарные.
4. Зачастую условия договоров включали экзотические условия определения момента включения счетчика. То есть, в переводе на саповский птичий язык, Базовая дата. Поэтому пришлось сделать некоторое число экзитов для манипулирования Базовой датой, которая по умолчанию может быть настроена всего на 4 вида дат.
Для запуска в продуктив пришлось провести инвентаризацию требований договоров и законодательства по определению алгоритмов определения сроков оплаты относительно сроков чего-то еще. Получилось, что можно разделить все алгоритмы на две группы:
- государственные, в основном связанные с уплатой налогов, настраиваются достаточно просто через фиксированное число дней после начала месяца
- коммерческие договора обычно насыщены экзотическими условиями по дате включения счетчика и по использованию банковских дней вместо календарных. Вот на коммерческих договорах и приходится чаще всего обращаться к производственному календарю для расчета экзитами правильных дат подготовки платежек и ожидаемых дат поступления денег за дебиторку.

печально то, что в СНГ только 2 нормальные книги на русском: Виталия Поцелуева и Олега Точенюка.
 
далеко нам уже до индусов и остальных - те книги пачками выпускают.

Относительно обучения SAP - алгоритм полезен больше заказчику, чем тренерам\компаниям\фрилансу\etc, занимающимся обучением. Для этой категории все более, чем очевидно.
По таблице 3 - использование новичков в обучении -может быть ошибкой, зависит от модуля SAP, и от начальных требований, предъявляемых к новичкам.
 
По поводу публикаций - не смотрела источники, но выглядит, как западная\американская действительность, не адаптированная к российским реалиям. Очень много хороших тренеров, не имеющих публикаций. Наличие последних - не показатель степени квалификации.

для анализа взята версия 1-2 с сайта
Ну начнем с простого.
1) В файле с советами везде проводится замер производительности на примере таблиц MKPF\MSEG. При этом, говорится о многократном выборе данных из одной и той же таблы, но с разными вариантами параметров. Но нигде не озвучивается, что у БД есть, в общем-то, свой кэш, и что для чистоты замеров кэш надо бы сбрасывать (забивать каким-то мусором, иначе БД будет брать данные из кэша)
2) Цитата со стр 7 "Кстати,
известный факт при использовании довеска «FOR ALL ENTRIES IN», не забываем делать
проверку на наличие данных в таблице, используемой в условии. Потому что, если данных
там нет, то будет выполнен полный проход по таблице выборки, а это плачевно отражается на
скорости выбора данных, даже если вам нужно получить все записи.". Не совсем понятно что понимается в этом случае под таблицей выборки. Проще было написать "при пустой таблице фильтра, будет прочитана полностью таблица СУБД из которой производится выборка"
3) Примеры с чтением таблицы T006A(стр16-18): нигде не указывается что таблица буферизована и в соответствии с этим при джойнах буфер не используется.
4) Стр 19: цитата "При массовых вставках или изменениях данных, не следует использовать COMMIT WORK,
после каждой вставки или изменения данных.". Если до этого были просто замечания, то вот это как раз вредный совет. решение о том, как именно производится коммит\роллбэк принимается на основании бизнес-процесса.  Общего рецепта тут нет и быть не может. Кроме того, стоит помнить, что все изменения логируются в спец. областях СУБД до своей фиксаци в БД. если выполнять длинную транзакцию БД (или LUW если угодно использовать терминологию SAP), то есть все шансы нарваться на переполнение rollback segment\transaction log
5) не менее шикарно смотрится рассуждение с 19 по 25 страницу, о том как после коммита ловить факт создания объекта. Скажите, а почему просто не используется синхронное обновление с использованием COMMIT WORK AND WAIT? Ведь, согласно хелпу, как раз в этом случае программа будет гарантировано ждать, когда же объекты доедут в БД.
Я могу искать и дальше, но я не буду этого делать по той же причине почему не буду вести здсь блог\колонку: мне за это не платят зарплату.

Собственно вот цитата из курса BC402 (версия 2006 Q2, страница 200) про то, какой алгоритм используется для хэш-таблиц.
Access to a hashed table is implemented using a hash algorithm. Simplified, this
means that the data records are distributed randomly but evenly over a particular
memory area. The addresses are saved in a separate table, the hashed table. To
do this, a hash function uses the key data to calculate an address where the hashed
table entry can be found.
The function is not injective, that is, there can be two data records stored at a single
address. This is implemented internally as a chained list. Therefore, the system may
have to perform a sequential search within this type of area. However, the chained list
can only contain a maximum of two entries. If the same hash table address results
for a third new key, the system uses a changed hash function and rebuilds the entire
management area. The graphic illustrates the simplest case, in which only one record
is stored at each address.

Занятное замечание: "если я ничего не путаю, то наиболее заметно скорость поиска по хэш табле зависит от собственно длины ключа таблы"
 
Вы представляете что такое хеш доступ и как он реализуется при построении индекса? Вообще-то скорость доступа зависит не от длинны ключа (ну если мы не ассемблерный код хеш-функции анализируем и такты процессора с внутренними стеками да длину команд высчитываем), а от качества используемого алгоритма - хеш функции. Чем больше коллизий у алгоритма расчета тем медленнее поиск, так как выполняются различные дополнительные методы обхода коллизий и т.д.
 
PS: Не я понимаю что простое сложение байт строки в 10 символов и строки в 20 выполняется дольше, но мы то про базы данных, а не про что быстрее посчитается на уровне процессора и памяти.

Ну вы их читали, но по факту так ничего в примеры кроме вот этого вот: "являются скорее уж вредными советами" не привели, поэтому беседа как бы ни о чем. Хотя я предложил вам ранее это сделать на конкретных примерах, где по вашему или совет не тот или граната не той системы.
 
По повожу технического редактора, ну я писал, Александры Дублин и Яков Михалыч Басок редактировали, Василий Ковальский вроде как рецензировал, но если для вас это ни о чем не говорит, то фиг с ним, оригинал тоже подойдет, хотя именно это издание я не читал. Но если вы думаете что мне было нечего делать, просто пересказать своими словами приведенную вами ссылку, то я тоже не возражаю.
 
PS: По поводу статей, именно статей тут по абапу их вообще-то мало (кажется 2), вы наверное имеете в виду авторские колонки/блоги. Их конечно же кроме автора вряд ли кто редактирует. Кстати, сделайте свою колонки, а мы почитаем...