Текущее время: Вт, июл 22 2025, 19:25

Часовой пояс: UTC + 3 часа


Правила форума


ВНИМАНИЕ!

Вопросы по SAP Query и Quick View - сюда



Начать новую тему Ответить на тему  [ Сообщений: 35 ]  На страницу 1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Обработка больших таблиц
СообщениеДобавлено: Пт, июн 11 2010, 14:31 
Специалист
Специалист

Зарегистрирован:
Вт, июл 07 2009, 13:24
Сообщения: 235
Hello,
есть очень большая таблица
как лучше ее обработать , так как из за ее размеров (более 1 000 000) всю ее скачать во внутреннюю табличку нельзя, надо делать по частям, но нужно пройти по ней всей, не пропустить ни одной записи наверное нужно делать что то вроде

do max_count.
select ***up 1000 rows.
***
max_count = max_count + 1000.
***
Enddo.

или …?
не будет ли при таком варианте пропущенных строк, например если в таблицу во время работы программы добавятся еще строки .


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Обработка больших таблиц
СообщениеДобавлено: Пт, июн 11 2010, 14:49 
Менеджер
Менеджер
Аватара пользователя

Зарегистрирован:
Чт, мар 09 2006, 10:12
Сообщения: 565
Откуда: Волгодонск
Пол: Мужской
В этом случае лучше использовать OPEN CURSOR... FETCH и т.д.
почитайте внимательно документацию к этим операторам
в частности обратите внимание на дополнениям WITH HOLD и PACKAGE SIZE

WITH HOLD позволяет выполнить комит но курсор всё равно останется открытым

_________________
Изображение Попытка не пытка


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обработка больших таблиц
СообщениеДобавлено: Пт, июн 11 2010, 15:31 
Специалист
Специалист
Аватара пользователя

Зарегистрирован:
Вт, июн 02 2009, 22:28
Сообщения: 228
Откуда: MOW
Пол: Мужской
DaV написал(а):
не будет ли при таком варианте пропущенных строк, например если в таблицу во время работы программы добавятся еще строки

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

Возможно, это утверждение неверно для некоторых СУБД, я прежде всего знаю про оракл, где это обеспечивается на уровне СУБД.


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Обработка больших таблиц
СообщениеДобавлено: Пт, июн 11 2010, 16:23 
Специалист
Специалист
Аватара пользователя

Зарегистрирован:
Пт, окт 03 2008, 17:20
Сообщения: 162
DaV написал(а):
так как из за ее размеров (более 1 000 000) всю ее скачать во внутреннюю табличку нельзя
Количество записей не играет роли. Играет роль размер занимаемой памяти этой таблички (ширина х длина). Сделайте ширину таблицы меньше, и будет возможным работать хоть со 100 млн. записей.

_________________
В SAPе есть всё, просто вы чего-то не нашли.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обработка больших таблиц
СообщениеДобавлено: Сб, июн 12 2010, 00:05 
Президент
Президент

Зарегистрирован:
Пт, апр 28 2006, 22:39
Сообщения: 2514
Откуда: North Taxolina, USA
Пол: Женский
Уменьшение не всегда возможно, к сожалению. Например, info structures SAP генерирует на свой лад с кучей ненужных полей.

Мне при таких объемах количества записей удавалось добиться неплохих результатов с SELECT... ENDSELECT, но не уверена как тут будет с появлением новых записей. В принципе обработку таких мощных таблиц лучше запускать по ночам, тогда может и появление записей станет неактуальным.

_________________
"One of the symptoms of an approaching nervous breakdown is the belief that one's work is terribly important." Bertrand Russell


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обработка больших таблиц
СообщениеДобавлено: Вс, июн 13 2010, 18:16 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, авг 19 2004, 17:37
Сообщения: 1962
Откуда: Москва
Пол: Мужской
Я делал так:
Code:
Select ...
  into table it_Buffer
  from ...
  package size 20000
...
  Loop at it_Buffer.
...
*   обработка записей
...
  EndLoop.
...
EndSelect.


"into table" позволяет несколько ускорить процесс, а "package size" ограничивает объем памяти занимаемой порцией данных.

Такую конструкцию я вынужден был использовать при объемной выборке из кластерной таблицы BSEG. В случае с нормальными (прозрачными) таблицами лучше избегать подобных конструкций и пересматривать алгоритм задачи. К слову, что за задача у вас и из какой таблицы выборка?

_________________
"For all entries" не в SAP-ах, "for all entries" в головах! :)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обработка больших таблиц
СообщениеДобавлено: Пн, июн 14 2010, 12:56 
Специалист
Специалист

Зарегистрирован:
Вт, июл 07 2009, 13:24
Сообщения: 235
а из за чего Вы не использовали конструкцию

IF lv_flag_cursor NE 'X'.
FETCH NEXT CURSOR lv_cursor INTO TABLE lt_waren PACKAGE SIZE 1000.
IF sy-subrc <> 0.
CLOSE CURSOR lv_cursor.
lv_flag_cursor = 'X'.
ELSE.
PERFORM prufung using lt_waren
changing lt_result.
ENDIF.
ENDIF.
IF lv_flag_cursor = 'X'.
EXIT.
ENDIF.

задачапроверить все корзинки в системе, таблица crmd_orderadm_h


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Обработка больших таблиц
СообщениеДобавлено: Вт, июн 15 2010, 09:55 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, авг 19 2004, 17:37
Сообщения: 1962
Откуда: Москва
Пол: Мужской
DaV написал(а):
а из за чего Вы не использовали конструкцию
...
задача проверить все корзинки в системе, таблица crmd_orderadm_h

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

С таблицей crmd_orderadm_h я раньше не сталкивался, но главное - она прозрачная, значит есть возможность решать задачу средствами СУБД, а не перебирать записи, чего вам и советую.

_________________
"For all entries" не в SAP-ах, "for all entries" в головах! :)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обработка больших таблиц
СообщениеДобавлено: Вт, июн 15 2010, 10:28 
Специалист
Специалист

Зарегистрирован:
Вт, июл 07 2009, 13:24
Сообщения: 235
Parazit написал:
С таблицей crmd_orderadm_h я раньше не сталкивался, но главное - она прозрачная, значит есть возможность решать задачу средствами СУБД, а не перебирать записи, чего вам и советую.


Вы имеете ввиду select *,,,* PACKAGE SIZE 1000 , вместо FETCH NEXT CURSOR? или наоборот?


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Обработка больших таблиц
СообщениеДобавлено: Вт, июн 15 2010, 10:56 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, авг 19 2004, 17:37
Сообщения: 1962
Откуда: Москва
Пол: Мужской
DaV написал(а):
Parazit написал:
С таблицей crmd_orderadm_h я раньше не сталкивался, но главное - она прозрачная, значит есть возможность решать задачу средствами СУБД, а не перебирать записи, чего вам и советую.


Вы имеете ввиду select *,,,* PACKAGE SIZE 1000 , вместо FETCH NEXT CURSOR? или наоборот?

Мне сложно что то иметь ввиду, т.к. подробно вы свою задачу не описали. В общем смысле я имею ввиду, что надо максимально использовать математические средства SQL, типа агрегирования, JOIN или подзапросы и т.д.

_________________
"For all entries" не в SAP-ах, "for all entries" в головах! :)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обработка больших таблиц
СообщениеДобавлено: Вт, июн 15 2010, 15:25 
Гуру-модератор
Гуру-модератор
Аватара пользователя

Зарегистрирован:
Ср, ноя 01 2006, 22:58
Сообщения: 794
Откуда: Заарбрюкен
Пол: Мужской
Не надо искать проблемы там, где их нет.

В табличке чуть более 500.000 записей по корзинкам.
Длина номера корзинки 20 байт.
При выборе в табличку номеров корзинок объем занимаемой памяти примерно 10 Мб.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обработка больших таблиц
СообщениеДобавлено: Чт, июн 17 2010, 11:37 
Специалист
Специалист

Зарегистрирован:
Вт, июл 07 2009, 13:24
Сообщения: 235
Насколько я понял , CURSOR применяется для обработки больших таблиц , и он вроде работает быстрее чем Select *PACKAGE SIZE * endselect. так как CURSOR неч-то типо ссылки на строки таблицы базы данных, если я не прав пожалуйста поправьте, если все верно тогда не понятно из-за чего система вылетает в ДУМП, при обработке таблицы в 100,000 строк с формулировкой Invalid interruption of a database selection.
и как анализ уберите обработку (loop break-point и так далее ) внутри обработки cursor.
Тогда зачем нужен cursor если он не позволяет обрабатывать записи таблицы


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Обработка больших таблиц
СообщениеДобавлено: Чт, июн 17 2010, 11:42 
Гуру-эксперт
Гуру-эксперт

Зарегистрирован:
Вт, сен 07 2004, 17:47
Сообщения: 2988
DaV написал(а):
Насколько я понял , CURSOR применяется для обработки больших таблиц , и он вроде работает быстрее чем Select *PACKAGE SIZE * endselect. так как CURSOR неч-то типо ссылки на строки таблицы базы данных, если я не прав пожалуйста поправьте, если все верно тогда не понятно из-за чего система вылетает в ДУМП, при обработке таблицы в 100,000 строк с формулировкой Invalid interruption of a database selection.
и как анализ уберите обработку (loop break-point и так далее ) внутри обработки cursor.
Тогда зачем нужен cursor если он не позволяет обрабатывать записи таблицы

Про ДУМП в теме упоминается впервые. Приведите содержимое дампа (и побольше, побольше), тогда можно точнее диагностировать проблему.
А внутри обработки курсора у Вас точно не установлено точек прерывания и т.п?

_________________
"После" - не значит "вследствие"


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обработка больших таблиц
СообщениеДобавлено: Чт, июн 17 2010, 12:07 
Специалист
Специалист

Зарегистрирован:
Вт, июл 07 2009, 13:24
Сообщения: 235
Code:
What happened?
    Error in ABAP application program.

    The current ABAP program "Z_PB_PRUFEN" had to be terminated because one of the
    statements could not be executed.

    This is probably due to an error in the ABAP program.
    Unable to perform database selection fully.
    record.



What can you do?
    If the error occurs in debugging mode, you should first run the process
    without debugging activated.
    If the error persists outside debugging, you must check the application
    program more closely.
    No error requiring recovery has occurred.
    Print out the error message (using the "Print" function)
    and make a note of the actions and input that caused the
    error.

    To resolve the problem, contact your SAP system administrator.
    You can use transaction ST22 (ABAP Dump Analysis) to view and administer
     termination messages, especially those beyond their normal deletion
    date.

    is especially useful if you want to keep a particular message.



Error analysis
    An exception occurred. This exception will be dealt with in more detail
    below. The exception, assigned to the class 'CX_SY_OPEN_SQL_DB', was not
     caught, which
     led to a runtime error. The reason for this exception is:
    One of the database selections included a database commit.
    The selection was then supposed to continue. Before a
    database commit, however, all outstanding database selections must be
    concluded.
    .
    Possible causes in the application program:
    Within a loop (SELECT/LOOP/EXEC SQL), one of the following
    statements is used:
    - MESSAGE (apart from MESSAGE S...)
    - COMMIT WORK
- CALL DIALOG
- CALL TRANSACTION
- SUBMIT
- BREAK-POINT
- WAIT
.
In debugging mode, a program sometimes triggers
a "COMMIT WORK" during the database selection. As a result
this termination may also occur in debugging mode with a correct
program.
A "COMMIT WORK" during debugging may be due to the following reasons:
1. A program or screen was regenerated
    and updated in the database.
2. Each user needs a private process in debugging mode, but
    the number of available processes is restricted. If this
    limit is exceeded, each debugging step then requires a
    "COMMIT WORK".
.
The error occurred in a statement that accesses the table "CRMD_ORDERADM_H ".


Code:
   86     IF lv_flag_cursor NE 'X'.
   87       
   88           FETCH NEXT CURSOR lv_cursor INTO TABLE lt_orderadm_h PACKAGE SIZE 1000.
>>>>>           IF sy-subrc <> 0.
   90             CLOSE CURSOR lv_cursor.
   91             lv_flag_cursor = 'X'.
   92           ELSE.
   93             PERFORM prufung TABLES lt_orderadm_h
   94                                    lt_ergebnis.
   95             i_lll = i_lll + 1.
   96     
   97           ENDIF.
   98         
   99           i_lll = 11111.
  100           EXIT.
  101         
  102
  103       
  104     ENDIF.



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


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Обработка больших таблиц
СообщениеДобавлено: Чт, июн 17 2010, 12:56 
Гуру-эксперт
Гуру-эксперт

Зарегистрирован:
Вт, сен 07 2004, 17:47
Сообщения: 2988
DaV написал(а):
...
я так понимаю что система сама делает коммит и вылетает в дамп, типо попытка открыть курсор который уже открыт, если да то как можно данное поправить

Не обязательно commit. Просто в процессе работы выполняется что то, что либо прерывает текущий диалоговый шаг или транзакцию.
Совет тут только самого общего характера - проанализировать и изменить код программы.

_________________
"После" - не значит "вследствие"


Принять этот ответ
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 35 ]  На страницу 1, 2, 3  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


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

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB