Могу. Кажись первыми это сделали в Sybase. Идея была проста, можно задать несложные правила разделения БД на части (например, на четные и нечетные записи), хранить их на разных серверах и распараллеливать выполнение запроса. Т.о. легко увеличить производительность БД простой докупкой серверов (их количество практически не ограничено) и несложным преобразованием БД.

p.s.
Когда то был хороший журнальчик "СУБД", вот его архивчик:
http://lib.csu.ru/dl/bases/prg/dbms/archive/

один практический довод в пользу внутренних таблиц:
если между select и endselect есть достаточно сложная математика,
(или если select - endselect не укладывается в 1 fetch)
попытка ее продебажить может вызвать дамп.

да, при отладке вывалится дамп, если внутри select.. endselect
находится вызов select,
мне кажется, в режиме отладки кросс-сессии бд не отлаживаются,
допустим объект сессии бд в отладочный и не переваривает одновременно
курсор-итератор и обычную выборку,
или может там вообще не курсор, а последовательность выборок,
если таймаут debug сессии больше таймаута сессии бд

У САПа есть такая штука - ABAP performance tuning - там настоятельно советуют сбрасывать данные во внутренние таблицы, так как ABAP заточен на их использование (и сортировочные таблицы с быстрым поиском, и команда collect, и быстрые присвоения [] = [] и т.д.).

Хотя... у нас есть примеры, когда САПовская транзакция вылетала в дамп из-за нехватки памяти на сервере, а этот же алгоритм, но прооптимизированный нами, прекрасно работал...

Лучше молчи - у меня профильное образование - "Автомобили и Автомобильное Хозяйство"

Молчу-молчу, как тот попугай: "Ну ты понял!"

Что значит "нарвался"? Читаю ноту, например 548845, там вроде и больше можно. Или это базисники ограничивают?

С чего вы взяли такое ограничение?

У меня как раз вылезла такая ошибка в


хотя я подозреваю, что тут просто надо select .. andselect или типо



и дальше уже ворочать такими здоровыми интернал таблицами

В ноте говорится что больше 2 гиг можно начиная с версии SAP BASIS 6.20, чего у нас пока нет.

а на размер чего могут быть ограничения? впервые такую прорву данных обрабатываю. Чуть ли не select * from bkpf. (Фон)

Cмысл: выбрать из таблиц TOA** все записи SAP_OBJECT = bkpf. К ним из bkpf и bseg(понятное дело, не из самого) выдрать к ним данные по OBJECT_ID (в нем зашиты bukrs belnr gjahr). Засунуть в z-таблицу.

можно ли при таких больших объемах commit work только один раз в самом конце программы вставить?

Просветите пожалуйста.

2 Galka
одним коммитом крайне не желательно, скорее всего будет дамп.
А вообще что то поменять в постановке/ реализации надо - 2 гига это очень внушительный обьем надо как говорили древние "разделяй и властвуй".
в вашем примере можно разбить so_ardat на периоды по X дней и в другую протокольную табличку писать по какую дату действия успешно выполнены.

На мой взгляд проще количество винтов Raide массиве увеличивать благо стоят они щас не дорого

Неполучится roll back сегмента нехватит.

а если не select .. endselect, а что-то типо курсора БД? Прочитала штук 1000 записей, сохранила курсор, обработала , коммит, прочитала штук 1000 с курсра.

2 Galka
А какой дамп получился?

сама мечтаю увидеть дамп Посмотрим, пришлют ли.

пока изучаю
http://help.sap.com/saphelp_46c/helpdat ... ontent.htm

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