С некоторых пор программа моя (точнее целый комплекс программ) стала работать ужасно медленно. Сказался тот факт, что объем данных вырос, а изначально в программу это не закладывалось. При анализе в se30 выяснил, что 80% времени приходится на одну и туже таблицу.
Однако выборок из этой таблицы очень много и очень разных, так что под все возможные варианты не подберешь.
Как я понял в se30 показывается первый попавшийся код выборки из этой таблицы, а не тот, что тормозит больше всего.
В настройках таблицы в технических параметрах есть такой раздел "Буферизация". Может вногоуважаемый ALL может рассказать в чем суть этой буферизации и может ли она помочь в данном случае?
И дополнительный вопрос: В коде у меня выборка идет в виде

т.е. таблица задается динамически. Может это сильно влиять на скорость работы?

Думаю что нет, влияет * + условия выборки, по каким полям выбираете, ключевым или нет и многое другое. Про оптимизацию очень много говорили. Буферизация возможно поможет, но Вам надо учесть все, сколько раз Вы обращаетесь к этой таблицы, на сколько актуальные данные будут в ней и тд. Так же надо смотреть код программы, может у Вас в loop-е select например. Еще для оптимизации программы можно использовать field-symbols.
Из какой Вы таблицы выбираете(где тормозит)?
В se30 есть подробный анализ.

1. Буферизация - копия данных таблицы (полностью либо частично) содержится в памяти на сервере приложений. Применяется для малоизменяемых относительно небольших таблиц, видимо это не ваш случай
2. SELECT * FROM (TABNAME) - напрямую на производительность влияет мало, но есть нюанс - на разных таблицах скорее всего разные индексы, а значит по разному надо строить запросы.

Посмотрите какие индексы есть на эту вашу проблемную таблицу, и перестройте запросы так чтоб индексы использовались, либо добавьте новый, если старых недостаточно. Отследить выполнение запросов можно через ST05, и кстати поизучайте внимательно 'Советы по производительности' в SE30

точно никакой разницы между и Вы и не увидите а если итераций несколько миллионов, то и подавно

по последнему абзацу поддерживаю

У меня тормозит выбор из Z-вской таблицы.
При анализе в se30 столкнулся с таким неприятным явлением. Провел анализ, отсортировал по нетто и вижу, что 80% нетто затрачивается на выборку из моей таблицы. Нажал на просмотр кода. Мне показался кусок кода. Я его оптимизировал, создав индекс для данного запроса.
Запускаю анализ - время работы не изменилось. Последующий анализ показал, что тот кусок кода, который мне показал SAP на самом деле вызывается всего один раз и на скорость работы влияет мало. Т.е. получается, что показывается не самая тормозная выборка из этой таблицы, а первая попавшаяся. Т.е. если в программе 2 селекта из этой таблицы, то SAP может показать вам запрос №1, хотя на самом деле самый тормозной запрос №2.
За все остальные советы спасибо.

Вообще я то надеялся, что буферизация - это буферизация запросов. Т.е. все запросы буферизируются и при повторе этих запросов данные берутся из КЭШа. А при внесении в таблицу изменений этот КЭШ сбрасывается.

даже более того - практически не увидите разницы между:

и

в случае выборки по одному и тому же документу, естессно

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

Я не исключаю своей кривости рук, поэтому и описал процесс получения неприятности так подробно.

Для оптимизации работы с базой данных могу посоветовать не использовать select *, делайте выборки только нужных вам полей, тут тоже все зависит от ширины таблицы базы данных. Все выбранные данные будут гоняться между сервером базы данных и сервером приложений, хорошо если записей выбрано немного, а если наоборот, то это могут быть мегабайты или десятки мегабайт информации, что загружает как трафик, так и память обоих серверов. В кипе с другими тяжелыми процессами может быть очень неприятно.

Тр. ST05 еще посмотрите.

походу тут используется select * .. endselect. этож долго используй select * into table, а лучше еще выбирать только конкретные поля, заметно ускорится.

На самом деле дело больше не в самих запросах, а в их количестве. Так что самый верный способ - переписать всё.

...До тех пор, пока этот код не увидит другой русский программист.(с)

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

а мы делали трассировочку SQL и заметили разницу в выполнении
select * from mseg... и select werks from mseg ...
кстати, это один из советов sap по производительности. Еще очень помогает читать во внутреннюю табличку, даже если вы в цикле по номеру читатете позиции документа. Читайте сразу во внутреннюю табличку и старайтесь избегать конструкцию corresponding fields