Добрый день, уважаемые коллеги!

Работает следующий функциональный модуль:

FUNCTION Z_SPD_LOG_TIME.
*"----------------------------------------------------------------------
*"*"Локальный интерфейс:
*" IMPORTING
*" VALUE(I_TR) TYPE INT2
*" VALUE(I_OPER) TYPE INT2
*"----------------------------------------------------------------------

tables ZSPDLOG.

ZSPDLOG-TR = I_TR.
ZSPDLOG-OPER = I_OPER.

insert ZSPDLOG.

ENDFUNCTION.

И вот в один прекрасный день произошло резкое падение производительности втечение суток. В результате произошли какие-то системные критические операции, вообщем не сохранились только мои данные для анализа в собственной таблице.

Слышу два мнения своих специалистов:
1. Администратор - твои update не прошли, твоя написанная программа не ставит их в очередь, как это делать не знает (Есть ли другой надежный способ накопления данных в собственной таблице?)

2. Программист - нужно обязательно ставить COMMIT WORK после Insert. (Я не ставлю commit, так как вроде по умолчанию это делает ФМ по факту выполнения, верно ли это?, как же тогда эта конструкция работала пол-года и собрала миллионы записей).

С уважением, Сергей

Commit work обычно ставят для принудительной записи в таблицу (типа чтобы не дожидаясь окончания ФМ, программы). В данном случае проблема может быть в том, что при системных сбоях данные об обновлении таблицы из твоего ФМ не дошли до очереди системы.
О причинах сразу сложно говорить - надо знать харатер сбоя...

Здравствуйте.
ФМ вызывается в update task ? Если да, то думаю ваши записи просто были удалены из очереди на обновление например тем же администратором(о причинах можно только догадываться). Если нет, то конечно обновление производится самим рабочим процессом , а не UPD процессом, и естественно не сохраняется ни в каких очередях на обновление, любая критическая ошибка приводит или к полной потере обновлений или частичной (завистит от логики написания отчета).

Начнем с того, что в R3 несколько способов обновления данных.
1. Без использования задач обновления. (Прямое обновление)
2. С использованием задач обновления
а) асинхронное
б) синхронное
в) локальное
Судя по тому, что Вы не указали, каким именно способом обновляли таблицу, могу предположить, что прямым обновлением. Могу также предположить, администратор имел в виду, что надо использовать обновления 2.а или 2.б. Сомневаюсь, чтобы это помогло. Ставить commit work после каждой команды insert далеко не всегда является разумным решением. Внутри задач обновления commit work вообще ставить запрещается. Функциональный модуль ни при вызове, ни по завершении своей работы не посылает commit work в БД. Неявные commit work посылаются самой R3 в конце работы программы, в конце диалогового шага (перед тем как пользователь увидит новый/обновленный экран), при командах call transaction, submit и т.п.
Теперь к самому вопросу. Так как полных данных нет, могу лишь предполагать. Возможно, у Вас есть отчет, который в процессе своей работы вызывает Ваш ФМ, чтобы вести протокол работы. Тогда все просто. Система "висит", ваша программа снимается с выполнения либо самой системой, либо администраторами. Т.к. никаких явных или неявных commit work не было, БД откатывает все изменения обратно. Если моя догадка верна, могу посоветовать ставить commit work на несколько команд insert. К примеру, 1 commit work на 1000 insert. Почему на несколько? Дело в том, что команда commit work довольно медленная, и если ее ставить после каждой команды insert время выполнения программы может существенно увеличиться.

Можно поподробнее про локальное обновление? В документации скромно умалчивают, что это за зверь.

Коллеги, большое спасибо за отзывы!

Уточнение ситуации.

Идет прямая запись данных.
ФМ используется в следующей ситуации:
пользователь делает множество однообразных операций через переносной терминал.
По завершению стандартных САПовских операций, дописывается собственный протокол.

Выглядит это следующим образом, пользователь запускает на переносном терминале сап-диалог,
который состоит из вызова всего одного функционального модуля ФМ1,
внутри которого вызывается две задачи L_TO_CONFIRM - стандартный САП модуль (подтверждение транспортного заказа),
Z_SPD_LOG_TIME - мой модуль, который пишет протокол, все запускается без update task:

CALL FUNCTION 'ФМ1'

CALL FUNCTION 'L_TO_CONFIRM'
ENDFUNCTION.
.
.
* ....идет обработка результата вызова L_TO_CONFIRM на ошибку
*..............................при положительном результате идем дальше
.
.
CALL FUNCTION 'FUNCTION Z_SPD_LOG_TIME'

tables ZSPDLOG.

ZSPDLOG-TR = I_TR.
ZSPDLOG-OPER = I_OPER.

insert ZSPDLOG.

ENDFUNCTION.

ENDFUNCTION.

Операция получается разовая, одна запись пишется в диалоге,
ставить COMMIT крайне не хочется - существенно увеличивает время обработки,
при этом эта операция происходит очень часто, до тысячи раз в сутки,
промежуток между вызовами ФМ1: 1-2 минуты.
Также добавлю, что данные у меня пропали не выборочные, а массово за 1.5 суток.

С уважением, Сергей

Коллеги, большое спасибо за отзывы!

Уточнение ситуации.

Идет прямая запись данных.
ФМ используется в следующей ситуации:
пользователь делает множество однообразных операций через переносной терминал.
По завершению стандартных САПовских операций, дописывается собственный протокол.

Выглядит это следующим образом, пользователь запускает на переносном терминале сап-диалог,
который состоит из вызова всего одного функционального модуля ФМ1,
внутри которого вызывается две задачи L_TO_CONFIRM - стандартный САП модуль (подтверждение транспортного заказа),
Z_SPD_LOG_TIME - мой модуль, который пишет протокол, все запускается без update task:

CALL FUNCTION 'ФМ1'

CALL FUNCTION 'L_TO_CONFIRM'
ENDFUNCTION.
.
.
* ....идет обработка результата вызова L_TO_CONFIRM на ошибку
*..............................при положительном результате идем дальше
.
.
CALL FUNCTION 'FUNCTION Z_SPD_LOG_TIME'

tables ZSPDLOG.

ZSPDLOG-TR = I_TR.
ZSPDLOG-OPER = I_OPER.

insert ZSPDLOG.

ENDFUNCTION.

ENDFUNCTION.

Операция получается разовая, одна запись пишется в диалоге,
ставить COMMIT крайне не хочется - существенно увеличивает время обработки,
при этом эта операция происходит очень часто, до тысячи раз в сутки,
промежуток между вызовами ФМ1: 1-2 минуты.
Также добавлю, что данные у меня пропали не выборочные, а массово за 1.5 суток.

С уважением, Сергей

Ну если вызов в 1-2 минуты тогда ставь свой COMMIT потому как за это время столько всего в системе пробегает... да и вызов до тысячи раз в сутки это вызов в среднем в полторы минуты... и поверь что это совсем не часто... для вставки одной записи.

нет, время выполнения критично до секунд.

Ваш пользователь завершает терминальную сессию, то бишь вашу программу "САП-диалог"?

Все просто. При асинхронном и синхронном обновлении, данные задачи обновления помещаются в специальные таблицы БД. При локальном обновлении эти данные помещаются в ABAP memory (команда EXPORT TO MEMORY). Включить локальное обновление можно командой SET UPDATE TASK LOCAL, но делать это надо до первого вызова CALL FUNCTION IN UPDATE TASK. Еще в 4.7 можно вызвать тразакцию с локальным обновлением - CALL TRANSACTION UPDATE 'L'. Разумеется, что задача обновления при локальном обновлении будет обрабатываться тем же рабочим процессом, что и основная программа.

Скажу честно, я смутно представляю, что такое "переносной терминал". ФМ1 - это случаем не RFC-функция, которая вызывается из другой системы?
Вообще ситуация странная. Выполняется одна стандартная САП-операция, а затем пишется свой протокол. Никаких явных commit work. При этом данные САП-операции сохранились, а протокол нет. И никаких дампов не было? Если не было, можно предположить, что это ошибка в программе, например, где-то здесь

Или что такая запись в ZSPDLOG уже есть. Можно добавить после INSERT:
IF sy-subrc <> 0. MESSAGE Xnnn(id). ENDIF.
Хотя бы дампы останутся.
Других предположений у меня нет. Могу только дать советы.
1) Не обязательно использовать команду COMMIT WORK. Эта команда делает много разных действий. В некоторых случаях вполне можно использовать CALL FUNCTION 'DB_COMMIT'. Это будет быстрее, вряд ли на много.
2) Если надо при выполнении стандартной САП-операции попутно сохранять еще и собственный протокол, лучше сделать так, чтобы данные САП-операции и собственный протокол сохранялись в одном LUW. При правильной реализации, это даст гарантию, что либо все сохранится, либо ничего не сохранится. К сожалению, эта задача в R3 нетривиальная и не всегда реализуемая (без изменения стандартных программ).

Большое спасибо всем за рекомендации!

Сознался мой администратор, был дамп, не хватило физически места под мою таблицу, руками он убил мои updates.

Действительно там распухла таблица до критичных размеров.
Сейчас будем настраивать-писать фоновый читильщик протокола.
Еще разок, всем большое спасибо!

С уважением, Сергей

Вот и все. Как всегда просто. А утт уже СЕМИНАР открыли.