Добрый день.
В обшем, ситуация следующая. Запустил в фоне "тяжелую" программу, которая читает с сервера большой DBF и потом парсит. Работает уже 2 дня.
В тр.SMX показывает, что задание выполняется (активно). В SM50 тоже "циферки бегают", только подозрительно, что показатели по БД и памяти не меняются (но в целом такое возможно). Файл большой, но не настолько, чтобы его парсить 2 дня. Есть подозрение, что программа каким-то образом зависла. С кодом по идее всё ок, работало в диалоге на частичных выборках.
Вопрос - как проверить, что там система в рамках фонового процесса реально делает??

Натравить SAT\SE30 на работающий процесс. По содержимому трассы можно понять, что там происходит

Посмотреть процесс в отладке, зайдя через sm50

Только сегодня изучал доку по аналогичной теме

http://scn.sap.com/community/abap/testing-and-troubleshooting/blog/2009/12/11/abap-runtime-analysis-se30--how-to-analyze-abap-program-flow

Блок 3, "How to trace a long running batch job?"

Всем спасибо, жаль нельзя отметить как правильные все три ответа
Отладка фонового задания это вообще нечто, сразу ясно сколько еще будет работать ))

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

С трудом верится в существование такого файла DBF, который мог бы парситься 2 дня. Явно проблемы с алгоритмом.

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

1. лог работы программы хоть SAP-лог хоть Z-лог
2. распарсенную строчку таблицы писать в буфферную таблицу БД с коммитом (наличие коммита можно также регулировать таблицей с 1 настроечной строкой - ) и тогда проверяя её будет видно на какой строке все повисло ... Да и данные не пропадут если что-то рухнет, а бд выживет.
Так я знаю кто когда и что.

Достаточно в спул писать с помощью write или в журнал задания с помощью message s...

+100500
Автор , все же интересно чем дело закончилось?

Программа удачно завершилась без ошибок, только в БД по факту записей не оказалось
Хотя там везде проверки стоят, в т.ч. на COMMIT.
Забил я на этот фоновый режим, проще десять раз онлайн запустить с частичной выборкой.


Нет. Зачем в онлайн, если такие задачи в фоне должны делаться. В диалоге все работает, DBF полностью считывется, только для парсинга частичные данные подаются.


БД адресов ФИАС - 1.7 Гб, такой файл у меня напрямую через GUI даже не загружается, пишет мало ресурсов. С алгоритмом всё ОК, даже оптимизированый алгоритм чтения DBF на стороне сервака пришлось писать. Не говоря про сам парсинг содержимого. Думаю, дело в слабом серваке в системе разработки.


Не считаю эти усложнения целесоообразными в данном конкретном случае, IMHO. Мне более чем достаточно оказалось отладки. И даже она(!) по факту не помогла в итоге ))

Решил проверить, так ли всё плохо. Скачал отсюда http://fias.nalog.ru/Updates.aspx базу fias_dbf.rar за 09.06.2016 (размер 2 578 288 192 байт). Попробовал загрузить самый большой файл ADDROBJ.DBF (1.7 Гб). Конечно для чтения через SAP GUI такой размер проблематичен, поэтому грузил с сервера приложений.
Результат загрузки:

Т.е. в среднем примерно 1 час на 1 млн. записей. Работает одинаково в диалоге и в фоне. Затраты времени парсинг/запись БД примерно 50/50. Думаю, парсинг можно ещё подкрутить.
Всё крутилось на одном бюджетном (куплен в 2011 г. за 20 т.р.) ноутбуке Lenovo Ideapad V560 - Intel Core i5, M480, 2.67GHz-2.67GHz, 8 GB (под виртуалку SAP 4 GB), Windows 7 Home 64. Если уж сервак слабее, то зачем нужен такой?!

Черт его знает, почему так медленно работало. Для интереса проверил сейчас скорость чтения DBF во внутреннюю таблицу (без записи в БД). В диалоге 8-10 мин, в фоне чууть медленнее.

Действительно, подшаманил ещё, чтение DBF и парсинг стали занимать 6 минут.
Соответственно вместе с записью в БД:

Теперь основное время занимает запись в БД, результат 1.5 часа на ~3 млн. записей более-менее терпимый для SAP.
Хотя я скорость ~550 зап./сек. считаю просто черепашьей, хотя бы 10тыс./сек минимум. Ну, возможно, дело уже в моём ноутбуке. Хотя даже Foxpro на стареньком Pentium 233MHz и то кажется быстрее работал.

Один момент - я чтение/запись делаю пачками по 20 тыс. записей, после каждой пачки Commit. Если делать Commit после каждой записи, то работать будет заметно медленнее.
Если пачки делать большими, например, по 1 млн. записей (или вообще всю таблицу целиком), то СУБД будет создавать большую область Rollback, возможно будет её расширять на диске, а после commit копировать данные из неё в оригинальную таблицу и чистить область Rollback. Это тоже может отнимать больше времени или вообще не записать данные, т.к. не хватит пространства под расширение Rollback.
Может у вас что-то подобное случилось, как часто делаете Commit?

Этот момент я как-то оставил без внимания, сохраняется целиком. Спасибо, попробую и тут немного подкрутить.