Добрый день.
Кто-нибудь сталкивался?
При запуске тр. SCU3 по Z-таблице за длительный период – дамп.
Если запускать тр. SCU3 по Z-таблице в фоновом режиме - сообщение задание остановлено.

В дамп то пробовали заглядывать? Там что то написано обычно.

Памяти не хватает. Не понятно почему.

Вы нам предлагаете с волшебным шаром погадать? Или может дамп покажете?

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

К сожалению, к системе доступа нет.
Завтра попробуем.

ТР. SCU3 запускаю по Z-таблице . В Z-таблице порядка 40 тысяч записей.
В таблице DBTABLOG по Z-таблице за анализируемый период показывает – 408.527 записей.
Запускаю за период 3 месяца. Но это месяцы загрузки данных в систему.
Вываливается в дамп на этом селекте
IF from_time = '000000' AND to_time = '235959'.
SELECT * FROM (log_table_name) APPENDING TABLE log_list
FOR ALL ENTRIES IN obj_list
WHERE tabname = obj_list-tab AND
logdate >= from_day AND
logdate <= to_day AND
username IN user_list AND
logkey IN log_keys.
ELSEIF from_day = to_day.
SELECT * FROM (log_table_name) APPENDING TABLE log_list
FOR ALL ENTRIES IN obj_list
WHERE tabname = obj_list-tab AND
logdate = from_day AND
( logtime >= from_time AND logtime <= to_time ) AND
username IN user_list AND
logkey IN log_keys.
ELSE.
SELECT * FROM (log_table_name) APPENDING TABLE log_list
FOR ALL ENTRIES IN obj_list
WHERE tabname = obj_list-tab AND
( ( logdate = from_day AND logtime >= from_time ) OR
( logdate = to_day AND logtime <= to_time ) OR
( logdate > from_day AND logdate < to_day ) ) AND
username IN user_list AND
logkey IN log_keys.
ENDIF.
ENDIF.

ДинамОшибка TSV_TNEW_PAGE_ALLOC_FAILED
Дата и время 03.05.2018 08:55:56
Краткий текст
No more storage space available for extending an internal table.
Что произошло?
You attempted to extend an internal table, but the required space was
not available.
Что Вы можете сделать?
Note which actions and input led to the error.

For further help in handling the problem, contact your SAP administrator
You can use the ABAP dump analysis transaction ST22 to view and manage
termination messages, in particular for long term reference.
Try to find out (e.g. by targetted data selection) whether the
transaction will run with less main memory.
If there is a temporary bottleneck, execute the transaction again.
If the error persists, ask your system administrator to check the
following profile parameters:
o ztta/roll_area (1.000.000 - 15.000.000)
Classic roll area per user and internal mode
usual amount of roll area per user and internal mode
o ztta/roll_extension (10.000.000 - 500.000.000)
Amount of memory per user in extended memory (EM)
o abap/heap_area_total (100.000.000 - 1.500.000.000)
Amount of memory (malloc) for all users of an application
server. If several background processes are running on
one server, temporary bottlenecks may occur.
Of course, the amount of memory (in bytes) must also be
available on the machine (main memory or file system swap).
Caution:
The operating system must be set up so that there is also
enough memory for each process. Usually, the maximum address
space is too small.
Ask your hardware manufacturer or your competence center
about this.
In this case, consult your hardware vendor
abap/heap_area_dia: (10.000.000 - 1.000.000.000)
Restriction of memory allocated to the heap with malloc
for each dialog process.
Parameters for background processes:
abap/heap_area_nondia: (10.000.000 - 1.000.000.000)
Restriction of memory allocated to the heap with malloc
for each background process.
Other memory-relevant parameters are:
em/initial_size_MB: (35-1200)
Extended memory area from which all users of an
application server can satisfy their memory requirement.

Анализ ошибки
The internal table "???" could not be further extended. To enable
error handling, the table had to be delete before this log was written.
As a result, the table is displayed further down or, if you branch to
the ABAP Debugger, with 0 rows.

At the time of the termination, the following data was determined for
the relevant internal table:

Memory location: "Session memory"
Row width: 16824
Number of rows: 373516
Allocated rows: 373516
Newly requested rows: 1 (in 1 blocks)

Указания по устранению ошибки
The amount of storage space (in bytes) filled at termination time was:
Roll area...................... 2718352
Extended memory (EM)........... 2002743520
Assigned memory (HEAP)......... 5120088000
Short area..................... " "
Paging area.................... 40960
Maximum address space.......... " "

If the error occures in a non-modified SAP program, you may be able to
find an interim solution in an SAP Note.
If you have access to SAP Notes, carry out a search with the following
keywords:

"TSV_TNEW_PAGE_ALLOC_FAILED" " "
"SAPLSVPR" or "LSVPRU09"
"DBLOG_READ_TABLE"

If you cannot solve the problem yourself and want to send an error
notification to SAP, include the following information:

1. The description of the current problem (short dump)

To save the description, choose "System->List->Save->Local File
(Unconverted)".

2. Corresponding system log

Display the system log by calling transaction SM21.
Restrict the time interval to 10 minutes before and five minutes
after the short dump. Then choose "System->List->Save->Local File
(Unconverted)".

3. If the problem occurs in a problem of your own or a modified SAP
program: The source code of the program
In the editor, choose "Utilities->More
Utilities->Upload/Download->Download".

4. Details about the conditions under which the error occurred or which
actions and input led to the error.

Информация о месте прерывания
Termination occurred in the ABAP program "SAPLSVPR" - in "DBLOG_READ_TABLE".
The main program was "RSVTPROT ".

In the source code you have the termination point in line 63
of the (Include) program "LSVPRU09".

Попробуйте за один месяц для начала, разбейте вашу выборку.

А вот эти 400 тыс записей изменения - они за какой период? А то может быть стоит намекнуть разработчику, что не совсем корректно данные относящиеся к категории "переменные" логировать через тех.параметры таблицы и надо заменить логирование на функционал документов изменений?

Добрый день.
Спасибо за поддержку.
Данные интересны за большой период, чтобы увидеть реальные изменения и убрать ненужные.
К сожалению разработчиков уже не достать. Старт 2009 год.
Разгребать придется самим.
Те 400 тысяч записей – это три месяца 2009 года.
Алгоритм записи в Z-таблицу изменили, чтобы не писалось в историю, что не надо. Изменения по таблице предполагались минимальные.
Теперь пытаемся почистить историю от пустых данных.
Программисты пишут программу выборки актуальных данных из таблицы DBTABLOG по Z-таблице.
Затем будем проверять и чистить.
Остается надеяться, что удастся.

Так вы выгрузите сначала за месяц, или за неделю из вашего требуемого периода.
Потом следующий месяц/неделю.
Не совсем понимаю в чем проблема...
У вас внутренней таблице не хватает памяти что бы обработать то что вы запрашиваете, 7GB не достаточно.
Если есть несколько application серверов, поставьте один в пассив мод, дождитесь пока выйдут все пользователи,
измените Временно параметры:
abap/heap_area_total
abap/heap_area_dia
abap/heap_area_nondia
Если есть память на сервере, то можете начать с 40GB.
Перестартуйте и поставьте опять в пассив.
Зайдите на этот аппликейшн сервер и попробуйте заново ваш отчет.
Это я описал крайний вариант, если прям никак нельзя разбить вашу выборку на части.

P.S. верните потом все обратно, как было

P.P.S. вы упоминали про 408.527 записей -->
в вашем дампе видно вот что -->
Number of rows: 373516
Allocated rows: 373516

Попробуйте просто abap/heap_area* параметры увеличьте на 3GB для начала (если есть память на сервере!),
думаю таких излишеств как 40GB может и не понадобиться.

Добрый день.
Спасибо за совет. Но права на это отсутствуют. Администраторы что-то молчат.
К сожалению, месяц , тем более неделя - неинтересны.
Необходимо по каждой строке Z-таблицы увидеть историю изменений за весь период.
Проблема в том, что Z-таблица – это данные по переоценки основных фондов. Загружены в систему при старте.
По идеи не должны были меняться.
Но реализовали таким образом, что при каждом изменении карточки ОС данные из Z-таблицы удалялись и затем снова записывались, пользователь даже не догадывался, что с его данными что-то происходит. Мало того, периодически записывалось непонятно что и откуда. В результате начальные данные (по ним сальдо на счете) и то, что сейчас в Z-таблице не соответствуют друг другу.
Все это писалось в историю.
Вот и стоит задача найти реальные изменения и восстановить данные.
Количество записей показывает SE11 в DBTABLOG по Z-таблице.

Ну, как бы, тогда я не знаю что вы ждете, открывая вопрос в Базисной ветке )

Изумление вызывал дамп.
Не верилось, что стандарт может давать дамп.
Да ещё по одной таблице.

Ну у вас настройки такие всего 7 Гигабайт на внутреннюю таблицу.
Я не говорю, мало это или много, везде по разному, я видел системы где под это выделено под 20-30 Гиг, там бы не дампило
У вас можно попробовать на 3GB прибавить параметры что я указал, думаю для вашео запроса хватит, если нет, то временные изменения как писал.
Если программу напишут и на отработает с правильной разбивкой, еще лучше.